AI WordPress best practices: a safe-operations playbook

What does it take to run AI on production WordPress safely?

Handing a live site to an AI agent feels risky — until the risk is engineered out. Running AI on production WordPress safely is less about trusting the model's judgment and more about configuring the server so every action is previewable, logged, and — in most cases — reversible, then keeping a short operating discipline on top. Cowboy MCP supplies the guardrails; this playbook is the discipline that gets the most out of them.

The playbook: seven habits for letting AI manage WordPress

None of these habits need a developer, and none of them slow ordinary work down much. Each one pairs a reason with the concrete Cowboy MCP mechanism that backs it and an example ask you can copy. Work down the list once when you set up a site, then let the last few settle into routine as you go.

1. Give each client its own named, revocable key. A valid API key acts with administrator capabilities, so a leaked one is as serious as a leaked admin password. Issue a separate key per client — one for Claude, one for ChatGPT, one for a teammate — so you can revoke exactly the one that went astray without disrupting the rest. Keys are stored only as a one-way hash, shown once, revocable individually, and capped at 120 requests a minute. The Claude and ChatGPT guides show where each key is generated. Example: "Show me every action the marketing key took this week."

2. Dry-run bulk operations before you run them. A bulk change executes a mistyped number as faithfully as a correct one, and bulk is where a small error multiplies fast. Every non-read-only tool accepts a dry run that reports exactly what would change — the tool, the target, and the parameters — without touching anything. Read the list, then approve. Example: "Bump every Summer Sale price 15%, but dry-run it first so I can check the product list before it applies."

3. Take a checkpoint before updates and big changes. Updates and migrations are the changes most likely to white-screen a site. Plugin and theme updates already trigger an automatic database checkpoint, a file backup, and a post-update health check that restores the previous version on its own if the site breaks — a setting that ships on by default in 1.6.0. Before anything else you would hate to redo, take a manual checkpoint too; it snapshots your database tables so you can roll back to this moment. Example: "Take a database checkpoint, then update every plugin that has an update pending."

4. Review the audit log on a schedule. Silent automation is the enemy of trust, so make a habit of looking. Every tool call, error, and authentication attempt is written to an audit log in your own database — timestamped, with the key, tool, arguments, result, and client IP — filterable on the Logs tab and pruned after 30 days. A weekly skim, plus a look after any large session, catches a misused key or a run of failures early. Example: "Summarize the audit log for the last seven days and flag any failed sign-ins or tools I would not expect."

5. Leave safe mode on. Safe mode is the backstop against an agent acting more broadly than you meant. It is on by default and keys on each tool's destructive flag: deletes, resets, and bulk overwrites refuse to run until you resend the call with explicit confirmation, and the refusal includes a preview of what would have happened. Ordinary writes still flow, so it rarely gets in your way, and there is no good reason to switch it off on a site you care about. Example: "Delete every spam comment" — it will pause and show you the list before removing anything.

6. Keep power mode off on production. Power mode removes the deepest guardrails — it permits schema-destroying SQL, eval and shell in WP-CLI, and file writes outside wp-content. That is occasionally useful on a staging copy for a specific migration, and almost never worth the exposure on a live store. It is a wp-admin checkbox that cannot be flipped through the API, so an agent can never grant itself the power. Turn it on for one job on staging if you must, then turn it straight back off. Example: run a raw schema migration on a staging clone, never on the site paying your bills.

7. Start read-heavy and earn the writes. The fastest way to trust an agent is to watch it read before it writes. Read-only requests — listing plugins, summarizing orders, checking site health — change nothing and need no confirmation, so they are a zero-risk way to learn how the agent reads your site. Move to writes once its read answers match reality, and keep the first few writes small and reversible. Example: "List the plugins with updates available and summarize this week's orders."

What if a mistake still gets through?

Discipline lowers the odds; it does not zero them. When a wrong change lands anyway, the recovery path is the same one the guardrails were built around. Every journaled change is captured as a full before-state snapshot in the undo journal, so a single bad edit rolls back on its own from the Activity tab without disturbing anything else on the site.

Three honest limits keep this trustworthy rather than magical. Undo-journal entries are kept for seven days by default, so a rollback is a same-week option, not a permanent archive. Some actions have no inverse — a sent email, a cache flush, an arbitrary WP-CLI command — and the journal records those as not-undoable rather than pretending otherwise. And database checkpoints restore your database tables, not your uploaded files or code, so treat them as a data backstop, not a whole-site time machine. The full mechanics, and where each guardrail stops, are laid out on the security page.

FAQ