Using Claude CLI to Manage WordPress Sites

Claude CLI runs in your terminal, reads and writes files in the current project, and shells out to anything else on your machine. For WordPress that means it can edit theme and plugin code, generate ACF field group registrations, drive WP-CLI through multi-step plans, and triage live-site logs over SSH. I use it daily on the directory sites I run as CTO, and it has reshaped what a single developer can ship in a day.

Jump to:

• What Claude CLI is, in a WordPress context
• The setup that makes this useful
• Workflow 1: Generating ACF field group registrations
• Workflow 2: Running WP-CLI plans end-to-end
• Workflow 3: Log triage on a live site
• Workflow 4: Plugin and theme debugging
• Workflow 5: Bulk content operations
• What Claude CLI is bad at on WordPress sites
• Where this fits in an agency workflow

What Claude CLI is, in a WordPress context

Claude CLI (Anthropic's official terminal client, often called Claude Code) is an interactive agent that lives in a project directory. It reads your files, runs shell commands you approve, and edits code in place. On a WordPress project that means it works on the wp-content/themes/ and wp-content/plugins/ paths the same way it works on any other codebase, and it can drive WP-CLI through tasks you would otherwise script by hand. The model handles the reasoning; WP-CLI handles the actual database and filesystem mutations. The combination is what makes this practical for production work.

If you have used WP-CLI for years, the mental model is simple: Claude CLI is a developer who reads the same docs you read, runs the same commands you would run, and asks before doing anything destructive. The difference is throughput. A multi-step migration that would have taken me a careful afternoon now takes about twenty minutes, including verification.

The setup that makes this useful

There is nothing exotic to install. I run all of this on macOS against both local Docker WordPress installs and remote staging servers over SSH.

A CLAUDE.md at the project root is the single highest-leverage piece of setup. Mine includes things like which custom post types exist, how the ACF field groups are organized, which WP-CLI flags to always pass on the staging server (--allow-root --skip-themes for fast operations), and the names of the production and staging hosts. Without it, Claude relearns the site every session. With it, the agent comes in pre-loaded and gets to useful work in the first minute.

Workflow 1: Generating ACF field group registrations

This is the workflow that moved me from skeptic to daily user. On the directory sites I run, post types can have 40 to 60 ACF fields, including nested Flexible Content with five or six layouts, each with its own sub-fields. Writing the PHP registration by hand from a field-group JSON export was a multi-hour chore. Now I describe the schema and review the output.

A real prompt I used last month:

Generate an ACF field group registration in PHP for a "Case Study" CPT with:
- client_name (text, required)
- industry (taxonomy ref to the existing "industry" taxonomy, single value, required)
- challenge (wysiwyg, no media buttons)
- solution (flexible content with three layouts: hero (heading text + subhead text + cta object), stat_row (repeater of label text + value text + unit text), quote (quote text + attribution text))
- results (repeater of metric text + value number + unit text, min 1, max 8)
- gallery (gallery field, min 0)

Use acf_add_local_field_group. Prefix all keys with group_case_, field_case_, layout_case_. Field names snake_case. Add conditional logic that requires industry to be set before any solution layout is selectable. Output as a PHP file I can drop into mu-plugins.

The output was 180 lines of valid acf_add_local_field_group() PHP with keys correctly hashed, conditional logic wired, and the Flexible Content sub-fields nested correctly. I caught two issues in review: the quote layout had attribution as textarea when I wanted text, and the conditional on industry was applied to the Flexible Content field rather than to each layout. Both were one-line fixes. The whole exchange took about eight minutes versus the forty-five it would have taken me to type from the ACF register-fields-via-PHP docs.

The bigger win is consistency. When I used to write these by hand, key naming drifted across post types. Now I include "use the same key convention as the existing post types in mu-plugins/acf/" in the prompt and the output matches.

Workflow 2: Running WP-CLI plans end-to-end

The second workflow is letting Claude CLI propose and run a multi-step WP-CLI plan, with my approval at each step. A representative example, the kind of thing that comes up after a plugin update goes sideways on staging:

The staging site at staging.example.com is throwing 500s on any page
that loads the events archive. Steps:

1. SSH to staging, tail the last 200 lines of debug.log and report
   what you see.
2. List active plugins and their versions.
3. If you spot a recently updated plugin in the trace, propose a
   targeted deactivation. Wait for my confirmation before running.
4. After deactivation, confirm the archive loads (curl, look for 200).
5. If the archive recovers, generate a one-paragraph incident note
   I can paste into our ops Slack.

What this looks like in practice: Claude runs ssh stage@staging.example.com 'tail -200 /var/www/.../debug.log', surfaces the relevant lines (usually a fatal in a specific plugin file), then proposes the deactivation command. I approve. It deactivates, curls the archive, gets a 200, drafts the note. About four minutes from "production is broken" to "production is back and the team knows what happened."

Two guardrails make this safe. First, Claude CLI asks before running any command it has not been pre-approved for, so I see the wp plugin deactivate before it fires. Second, I never give it write access to production through this flow. Production fixes go through the same pull request and deploy process they always have. Staging and local can take the agentic loop directly; production gets the human in the slow path on purpose.

Workflow 3: Log triage on a live site

Once you have SSH plus WP-CLI plus an agent that can read whatever it reads, log triage gets fast. I keep a prompt template like:

On host {{host}}, look at the last 500 lines of:
- /var/www/{{site}}/wp-content/debug.log
- /var/log/nginx/{{site}}_error.log
- /var/log/php8.2-fpm.log
Group the errors by repeated signature. For each group, give me:
- the first and last timestamp
- the count
- which plugin or theme file is implicated
- a one-sentence hypothesis about cause

What I get back is the kind of triage summary I used to write by hand on a Monday morning to figure out what broke over the weekend. The classifier here is the model, not a log shipper, so it is brittle if your error format is unusual. But for the standard WP debug log plus Nginx and PHP-FPM, it is solid. I have caught at least two slow memory leaks this way that I would have missed scrolling logs manually, both in third-party plugins, both fixable by pinning the prior version while we waited on a release.

Workflow 4: Plugin and theme debugging

This is the workflow that most resembles how I used Claude CLI on non-WordPress projects. The difference is that the project context is "a WordPress theme inheriting from a parent, with ACF blocks under template-parts/blocks/, and a custom plugin under mu-plugins/." I give Claude that map in the CLAUDE.md and then debugging looks like:

The "featured listing" block on the directory single template is
rendering the wrong city for the first card in the loop. The ACF field
is "city" on the "listing" CPT. Read the block template at
wp-content/themes/child/template-parts/blocks/featured-listing.php and
trace why card 1 might be using stale data. Do not edit yet, just
investigate and explain.

The "do not edit yet" instruction matters. It forces the diagnosis turn before the fix turn, which is the workflow I want for non-trivial bugs. For obvious typos and missed wp_reset_postdata() calls, I let it edit in one shot.

The agent will read the block template, follow the function calls into wherever the loop is set up, and tell me whether the issue is a missing wp_reset_postdata(), an setup_postdata() on the wrong object, or an ACF get_field() call that needs the explicit post ID. About 80 percent of the time the diagnosis is correct. The other 20 percent, the conversation gives me enough to find the real issue myself in the next read.

Workflow 5: Bulk content operations

Anything that involves "do the same thing to a few hundred posts" used to be a WP-CLI script I would write, run on staging, review, then run on production. Claude CLI compresses the writing step. An example from this quarter:

There are about 1,200 "provider" posts where the ACF field
"address_state" is stored as the full state name (e.g. "California")
but the directory front-end now needs the two-letter code ("CA").
Write a WP-CLI command (or one-off mu-plugin script if cleaner) that:
- iterates all "provider" posts
- reads address_state
- maps it to the two-letter code using a hardcoded array
- writes the result back to a new field "address_state_code"
- leaves address_state untouched
- logs each post ID with before/after
- supports a --dry-run flag

Do not run it. Output it and explain how to invoke.

The output was a clean WP-CLI command class with --dry-run support. I ran the dry run, eyeballed the log, ran for real on staging, verified, then ran on production through our normal deploy. Total elapsed time was under thirty minutes for what would have been a two-hour ticket back in my agency years.

What Claude CLI is bad at on WordPress sites

Honesty matters more than the pitch here. There are workflows where Claude CLI is the wrong tool, and where pretending otherwise will burn you.

It does not understand your specific site's block editor state. Gutenberg block content is stored as HTML comments inside post_content. The model can read it, but reasoning about block-tree integrity, especially nested blocks with custom attributes, is one of its weaker areas. For non-trivial Gutenberg content transforms I still write the WP-CLI by hand.

It will hallucinate ACF function signatures occasionally. Almost always when I forget to include the ACF docs URL in the prompt. The acf_add_local_field_group API is stable enough that errors are rare, but I have seen it invent a 'wrapper_class' key on field defs where the real key is 'wrapper' with a 'class' sub-key. Always run the output through PHP before committing.

Multisite is harder. The agent will assume single-site WP-CLI invocations unless you tell it otherwise. --url=https://subsite.example.com on every relevant command, or a wp site list early in the conversation, both help.

Production write access is a trap. I do not give the agent direct production credentials, no matter how convenient. The risk is not malice, it is throughput. An agent that can deploy as fast as it can reason is an agent that can break things faster than you can read the diff. Staging and local are the right surface for the agentic loop. Production goes through the pull request.

Where this fits in an agency workflow

For solo developers and small agencies, the throughput shift is real. The ACF field generation alone is worth the setup. I have written about the rest of the AI workflows I lean on for WordPress agency work, and the specific WP-CLI patterns that compose well with Claude CLI. For teams still deciding whether to standardize on ACF or Gutenberg, my take on the ACF vs Gutenberg question for agencies is the relevant background.

The recurring lesson from twenty-plus years of WordPress work is that the bottleneck is rarely typing speed. It is everything around the typing: the lookup, the convention drift, the careful three-step plan, the log-scrolling, the "did I remember to flush rewrites." Claude CLI compresses the work around the work. The judgment, the architecture, the decision of what to ship, the actual review of the diff, none of that goes away. What does go away is the meandering middle, and that is what makes a single experienced developer feel like a team of three.

If you have been holding off because terminal-driven AI tooling felt like a developer-experience curiosity, this is the right moment to revisit it. The integration with WP-CLI is what tipped it from "interesting" to "load-bearing in my day."