How to use Claude Code on a WordPress site

Claude Code works well on WordPress when you give it a local or staging copy of the site and let it work on files: your theme or child theme, custom plugins, and scripts that use WP-CLI, the official command line for WordPress. It works poorly, and riskily, when you expect it to edit your live site through the admin dashboard, because Claude Code edits files and runs commands. Much of a WordPress site lives in the database, not in files.

The practical setup is: a local copy of the site, the code you own in git, WP-CLI for anything that touches content or settings, and a person who tests on staging and decides what goes live. This guide walks through what works, what doesn't, and a step-by-step workflow, as of October 2026. If you haven't used the tool yet, read what Claude Code is first.

Files vs database: why it matters

A WordPress site has two halves. The files include WordPress core and "the wp-content directory, which holds your themes, plugins, and uploads," as the WordPress docs put it. The database holds your posts, pages, menus, widget settings, plugin options, user accounts and, for block themes, any template changes made in the Site Editor.

Claude Code reads and edits files. When it needs something from the database, it has to go through a tool: WP-CLI commands, a database export, the REST API or an MCP connection. That has two consequences for your workflow:

• Editing a theme file may not change what visitors see. For block themes, WordPress's theme handbook says Site Editor changes "are saved in their site's database," and a saved template overwrites the file version. If someone customized the home template in the Site Editor, Claude can edit /templates/home.html all day and nothing changes on the page.
• Content changes are database changes. Rewriting 200 meta descriptions or fixing links inside posts means running commands against a database. Done on a live site, a mistake is live immediately, and Claude Code's rewind feature can't undo it.

Many page builders also store layouts in the database rather than in theme files, so check where your builder keeps its data before asking Claude to "change the header."

What Claude Code does well on WordPress

What doesn't work, or shouldn't be tried

• Editing the live site directly. Don't give Claude Code SSH or FTP access to production and ask it to fix things in place. There is no review step, and a broken PHP file can take the site down.
• Driving wp-admin as if it were a person. Claude Code has browser integrations, but clicking through a live dashboard skips git, diffs and review entirely. Use WP-CLI on a copy instead.
• Editing core or a third-party plugin's files. Updates overwrite those changes. Put customizations in a child theme or your own plugin. That way your changes survive updates.
• Running database commands on production without a backup. Export the database first, every time. See our guide to WordPress backups.
• Trusting a builder-generated page to match its files. If layouts live in the database, a code change alone may not show up, or may be overwritten by the next edit in the builder.

Set up a local copy first

Claude Code needs a version of the site it can break safely. Three common options:

• wp-env. WordPress's official tool "lets you easily set up a local WordPress environment for building and testing plugins and themes." It is "powered by Docker by default." Install with npm -g i @wordpress/env, run wp-env start, and the site appears at http://localhost:8888. The wp-env docs list the defaults.
• WordPress Studio. WordPress Studio is described as "the agentic local development tool for WordPress," free and open source, for macOS, Windows and Linux. WordPress.com says it "gives Claude Code, Cursor, VS Code, and Codex the WordPress context and access they're missing" through MCP setup and agent skills. Studio Sync pushes and pulls with WordPress.com paid plans and Pressable.
• Your host's staging site. Many hosts offer one-click staging. Pull a copy of files and database down from it, or work on staging directly with the same review rules. Our guide to WordPress staging sites covers the options.

Then put the code you own under git. That is usually your child theme and any custom plugins, not WordPress core or third-party plugins.

A step-by-step workflow

1. Back up production. Export the database (WP-CLI's wp db export backup.sql does this) and copy wp-content.
2. Restore it locally. Import into wp-env or Studio. Replace the live domain with the local one using wp search-replace, which "intelligently handles PHP serialized data," something a plain find-and-replace on a database file breaks.
3. Write a short CLAUDE.md. Note the theme, the child theme folder, the page builder, which plugins matter, and rules such as "never edit parent theme or plugin files" and "run WP-CLI against the local site only." See how to write a CLAUDE.md for a website.
4. Start a branch and plan. Ask Claude to explore and propose a plan in plan mode before it edits anything.
5. Dry-run every database change. For search-replace, --dry-run will "Run the entire search/replace operation and show report, but don't save changes to the database." Read the counts. If they surprise you, stop.
6. Test locally, then on staging. Check the pages that changed and a few that shouldn't have.
7. Review the diff and approve. A person reads the code changes and the list of database commands.
8. Deploy through your normal process. Push theme or plugin code through your host's deploy method, and repeat reviewed WP-CLI commands on production only after a fresh backup.

Permission settings matter here because WP-CLI commands run in your terminal. Our guide to using Claude Code safely on a live website covers ask and deny rules, the sandbox and the deploy gate.

WP-CLI: Claude Code's main tool for WordPress

WP-CLI is "The command line for WordPress. No browser required," per the WP-CLI site. Because Claude Code runs terminal commands, WP-CLI is how it reaches content and settings without touching wp-admin. Useful commands for site work:

• wp db export to back up the database before anything else.
• wp search-replace with --dry-run for domain changes and bulk text fixes.
• wp post, which "Manages posts, content, and meta," for listing and updating content.
• wp plugin, which "Manages plugins, including installs, activations, and updates."
• wp rewrite for permalink rules, and wp cache flush after changes.

A good habit: ask Claude to write the commands into a script file first, review the script, run it on the local copy, and keep the script so the same reviewed steps can be repeated on production.

MCP: connecting Claude to WordPress directly

MCP (Model Context Protocol) is an open standard that lets Claude call tools in other systems. WordPress has official options as of October 2026:

• The WordPress MCP Adapter. "The official WordPress package for MCP integration" connects WordPress's Abilities API to MCP. Clients connect through WP-CLI or an HTTP endpoint. Abilities stay private unless marked public. The plugin requires WordPress 6.9 or higher.
• WordPress.com MCP. Available on WordPress.com paid plans, it lets AI agents "interact with your websites, posts, comments, and settings." Its support page says "Enabling MCP access turns on both the Read and Write tool groups by default," so switch off write tools you don't need.

An MCP connection to a live site is a live connection. Anthropic doesn't security-audit MCP servers, so connect read-only first and use write access on staging. Our guide to MCP servers for website teams covers scoping and precautions.

When moving off WordPress makes more sense

Sometimes the better project is a rebuild. When we rebuilt eseospace.com in June 2026, we moved about 2,227 URLs off WordPress (the WoodMart theme with WPBakery, Contact Form 7 and Popup Maker) to a static build. Our first attempt, a clean Next.js rebuild that stripped out the theme's JavaScript, was abandoned on day one because it broke animations, accordions, widgets and menus. A person decided to keep the theme's own scripts instead. Claude Code did the crawling, scripting and site-wide edits; people made that call and approved every deploy.

A rebuild suits sites where the plugin stack is the main maintenance burden. Staying on WordPress suits teams whose editors rely on wp-admin every day. Read rebuilding a website with Claude Code before deciding.

Conclusion

Use Claude Code on WordPress for what it is good at: theme and plugin code, WP-CLI scripts and audits, all on a local or staging copy with your code in git and every database change dry-run first. Don't use it to edit a live dashboard, and don't assume a file change shows up when the Site Editor or a page builder stores the real version in the database. If you'd rather have a team do the build or the maintenance with these safeguards in place, see our Claude Code development services. More guides are in our Claude Code Guide.

Frequently asked questions