Claude Code can take over a lot of that work, provided it can actually see and operate the site. This post shows how to do that with LW Site Manager, a WordPress plugin that exposes site-management operations to AI tools, and how to keep the workflow safe enough to use on production.

What Claude Code is

Claude Code is Anthropic’s command-line coding agent. You run it in a terminal inside a project directory, describe a task in plain language, and it reads files, runs commands, edits code and reports back. It works in a loop: inspect, plan, act, verify.

Two properties make it useful for WordPress management rather than only for writing code:

• It can use tools. Through the Model Context Protocol (MCP), Claude Code can call external services — a WordPress site, in our case — the same way it runs shell commands.
• It can be constrained. A CLAUDE.md file in the project root gives it standing instructions: which site it is working on, what it may and may not do without asking, how you want changes reported.

On its own, Claude Code knows nothing about your site. It needs a way in.

What LW Site Manager is

LW Site Manager (“WordPress Site Manager with Abilities API — AI-ready site maintenance”) is a GPL-2.0 plugin by LW Plugins. It builds on the WordPress Abilities API and registers a large set of abilities: discrete, described operations such as check-updates, update-plugin, create-backup, flush-cache or list-posts. At the time of writing the README lists 167 of them, grouped roughly as:

• Updates — check, update core, plugins, themes, or everything.
• Plugins and themes — list, install, activate, deactivate, delete.
• Content — posts, pages, comments and media (create, read, update, delete).
• Users and taxonomy — user management, categories, tags, custom taxonomies.
• Settings — general, reading, discussion, permalinks, homepage.
• Backup and database — create and restore backups, optimise tables, clean up.
• Cache — flush the caches of the common caching plugins and Redis/Varnish.
• Health — health checks, error logs, pending plugin database updates.
• WooCommerce — products, orders, variations, reports, refunds, shipping.

Every ability is reachable over the REST API, and the plugin ships a built-in MCP server that exposes the same abilities to AI clients. That MCP server is the bridge to Claude Code.

Requirements, per the repository: PHP 8.1+, WordPress 6.9+ and the WordPress Abilities API.

How the two connect

The plugin’s MCP server lives at https://YOUR-SITE/wp-json/mcp/lw-site-manager. It is off by default; you enable it in the WordPress admin under LW Plugins → AI / MCP. Authentication uses a standard WordPress Application Password for an administrator account, sent as HTTP Basic auth.

Claude Code reads MCP servers from a .mcp.json file in your project. The repository’s documented configuration is:

{
  "mcpServers": {
    "lw-site-manager": {
      "type": "http",
      "url": "https://YOUR-SITE/wp-json/mcp/lw-site-manager",
      "headers": {
        "Authorization": "Basic BASE64(username:application_password)"
      }
    }
  }
}

Once that is in place, “check what needs updating on the site” becomes a tool call Claude Code can make, and “update plugin X” becomes another. It can chain them: check → back up → update → run the health check → report.

Keep the .mcp.json with real credentials out of version control. An Application Password for an administrator is as sensitive as the administrator’s login.

Tasks worth delegating

Good candidates share two traits: they are well-defined, and the outcome is easy to verify.

• Audits. Inventory of theme, plugins, versions, settings, and an architecture summary you can paste into a handover document.
• Update runs. Check for updates, back up, update, verify, and write the change log entry.
• Debugging. Read the error log, correlate with recent changes, propose a fix.
• Performance triage. Find the expensive plugins, autoloaded options and cache misconfiguration before you open a profiler.
• Database hygiene. Identify large tables, orphaned metadata and transient build-up.
• Content operations. Bulk-create or update posts and pages following the site’s existing conventions.
• WooCommerce housekeeping. Reports, stock and order lookups, catalogue fixes.

Tasks that are a poor fit: anything with an ambiguous goal, and anything you cannot check afterwards.

Why this matters for developers and agencies

The gain is not that the AI is smarter than you at WordPress. It is that the inspect-and-report part of every maintenance task — the part that is mostly reading — becomes cheap, so you spend your attention on decisions. For an agency running twenty sites, a consistent monthly audit that used to be skipped for lack of time becomes a prompt. Because every ability is described and logged, the work is also more reproducible than a person clicking through wp-admin.

Review before production, always

Claude Code will happily execute a plan that is subtly wrong. Treat it like a capable junior colleague with a production login: useful, fast, and in need of a review step.

• Read-only first. Start every engagement with audits and investigations. Only grant write operations once you trust the output.
• Backup before change. LW Site Manager has create-backup and backup-status; make the backup a mandatory first step in any prompt that changes state.
• Plan, then approve. Ask for a plan and read it before saying “go”. This is where most mistakes are caught.
• Staging when you can. If a staging environment exists, run the change there first with the same prompt.
• Explicit confirmation for destructive operations. Deleting plugins, users, content, database rows or backups should never happen inside a single “just fix it” instruction. Put this rule in CLAUDE.md so it applies to every session.

A simple recommended workflow

1. Inspect. Ask Claude Code to look at the site and describe what it finds — versions, plugins, settings, recent errors.
2. Analyse. State the change you want and ask it to work out what is involved and what could break.
3. Plan. Have it propose a step-by-step plan, including the backup and the verification steps. Read it.
4. Implement. Approve the plan, or the parts of it you agree with.
5. Check. Run the health check, hit the affected pages, look at the error log.
6. Review. Read the summary of what changed and compare it with the plan.
7. Apply. Deploy or, if you worked on staging, repeat on production with the same prompt.

Steps 1–3 are read-only. If a task never gets past step 3, nothing on the site has changed.

Useful Claude Code prompts

These are copy-paste starting points. Each one tells Claude Code to inspect before acting, and the ones that change state ask for a plan and a backup first. Adjust the site name and specifics.

Website audit

Using the lw-site-manager MCP tools, inspect this WordPress installation without changing anything. Report: WordPress version, PHP version, active theme (and parent theme), active and inactive plugins with versions and available updates, key settings (permalinks, reading, discussion, homepage), caching setup, and anything the health check flags. Then summarise the site's architecture in a few paragraphs and list potential issues ordered by severity. Do not make any changes.

Plugin investigation

Investigate the plugin "PLUGIN-NAME" on this site. Do not modify anything. Explain what the plugin does and which parts of the site depend on it. Check its version against the latest available, look for known compatibility issues with our WordPress and PHP versions, and assess its impact on performance and security based on what you can observe (hooks, scheduled events, database tables or options it owns, assets it enqueues). Finish with recommendations, clearly separated into "safe to do now" and "needs discussion".

Debugging

Pages under /shop/ return a 500 error since yesterday. Investigate the root cause without changing anything yet. Read the recent error log entries, identify the plugin or theme code involved, and correlate with recent updates or setting changes. Explain the likely root cause, the evidence for it, and the fix you propose, including any risk. Wait for my confirmation before applying anything.

Performance

Analyse this site's performance without making changes. Look for: plugins that add heavy front-end assets or admin-ajax/cron load, expensive hooks on every request, large or unindexed database tables, autoloaded options over 1 MB in total, transients that never expire, and caching that is disabled, misconfigured or bypassed. Report findings ordered by likely impact, with the evidence for each, and propose fixes as a plan I can approve item by item.

Database

Investigate the WordPress database read-only. Report the largest tables with row counts and sizes, the total size of autoloaded options and the biggest individual ones, orphaned post/term/user meta, expired transients, revision and spam/trash counts, and any tables left behind by removed plugins. Recommend clean-up steps with the expected space saving. Do NOT delete, truncate or optimise anything. Any destructive database operation requires my explicit confirmation of the exact step, after a backup.

Security

Perform a basic security review of this site without changing anything. Check: outdated core, plugins and themes; inactive plugins and themes that should be removed; user accounts with administrator role and weak or default usernames; whether XML-RPC is enabled; whether PHP execution is possible in wp-content/uploads; file editing in the admin; debug mode and display_errors in production; file and directory permissions where you can observe them; and any suspicious scheduled events, options or recently modified files. Report each finding with severity and a recommended fix.

Content management

I need five new blog posts from the outlines in content-briefs.md. First inspect the existing posts: categories, tags, typical length and heading structure, featured image usage, excerpt conventions and SEO fields. Then draft each post as a WordPress draft (not published) following those conventions, using the same author and category scheme. Give me the list of draft URLs to review. Do not publish.

Production change

Prepare the following production change: update the "PLUGIN-NAME" plugin to the latest version. Before anything else: run the health check, confirm a fresh backup with create-backup and wait for backup-status to report success, and record the current plugin version. Then apply the update, flush the cache, run the health check again, load the homepage and /shop/ and confirm they return 200 with no new errors in the log. Finish with a concise deployment report: what changed, from which version to which, checks performed and their results, and the backup identifier to restore from. If any check fails, stop and report instead of continuing.

Getting started

At a high level, the setup is:

1. Install Claude Code following the official documentation, and run it once in a project folder you will dedicate to the site (a CLAUDE.md with your rules lives there).
2. Install LW Site Manager on the WordPress site. Per the repository: composer require lwplugins/lw-site-manager, or download the latest release from GitHub, upload it to wp-content/plugins/lw-site-manager and activate it. The site needs PHP 8.1+, WordPress 6.9+ and the Abilities API.
3. Enable the MCP server and create credentials. In wp-admin go to LW Plugins → AI / MCP and turn the MCP server on. Under Users → Profile → Application Passwords create a password for an administrator account and base64-encode username:app_password.
4. Point Claude Code at the site. Add the .mcp.json shown above to the project folder with your URL and encoded credentials, and keep that file out of git.
5. Verify read access. Start Claude Code and ask it to list the site’s plugins or run check-updates. If the tool call succeeds, the connection works.
6. Start read-only. Run the audit prompt above and a couple of investigations before you let it change anything. Write your rules into CLAUDE.md: which site this is, backup before every write, no destructive operations without explicit confirmation.

The repository has the full ability list, REST examples and a changelog: github.com/lwplugins/lw-site-manager.

Closing note

The tools are new; the discipline is not. Inspect before you change, back up before you write, read the plan before you approve it, and verify after. Claude Code with LW Site Manager makes the inspecting and the reporting nearly free — which is exactly what leaves you time to do the reviewing properly.