Managing client WordPress sites with an AI assistant

Using an AI assistant on your own WordPress site is a solved problem with a dozen answers. Doing it across eight sites that belong to other people is a different problem, and most of the difficulty has nothing to do with AI.

A client site comes with constraints your own site does not. Someone else approves what gets installed. Someone else may have a managed host with a plugin allowlist. Someone else will ask what happens to their access when the engagement ends, and will want an answer that does not require trusting you. Multiply that by the number of sites and the thing that breaks first is never the assistant — it is credential sprawl and the approval queue.

The four arrangements

A plugin per site is the most capable option and the highest ongoing cost. It reaches things core REST does not — theme switching, updates, Customizer values — because it runs inside WordPress. In exchange, every site carries code you are responsible for: a new version to roll out, a PHP compatibility matrix, and a conversation with anyone who reviews what goes on their site. On eight sites that is eight approvals and eight update cycles.

A local MCP server runs on your laptop and reaches each site over the REST API. Nothing is installed anywhere, which removes the approval problem entirely. The cost is distribution: the server is configured per machine, so a credential exists once per site per machine. Eight clients across a laptop and a desktop is sixteen places a password lives, and no single place to revoke from. It also cannot serve the ChatGPT or Claude web clients at all — they cannot start a local process, so this route is Claude Code and Cursor only.

A hosted connector moves the same REST approach to a server you reach over HTTPS with OAuth. Sites are registered once, credentials live in one place you can revoke from, and the web clients work because there is a URL to point them at. The cost is that you are trusting a third party with credentials to your clients' sites, which is a real thing to weigh rather than wave past.

Hand-rolled scripts are fine and genuinely underrated for a fixed set of repeated tasks. They stop being fine the moment you want to describe a change in a sentence rather than implement it.

The credential arithmetic

This is the part that decides the answer more often than capability does.

One credential per site is unavoidable — WordPress issues application passwords per user per site, and that is the right granularity. The question is how many copies of each exist and how many places you must visit to revoke one.

• Plugin per site: the credential is effectively the plugin's own connection. Revoking means deactivating on that site.
• Local server: one copy per machine. Revoking means editing every machine, or rotating the password in WordPress and hoping you remember every config file that had it.
• Hosted: one copy. Revoking is one action, and the client can revoke independently from their own site without asking you.

That last property is the one clients care about and the one worth leading with. An application password is revocable from Users → Profile on the site itself. The client does not need your cooperation, your dashboard, or a support ticket — they open their own WordPress, delete the row, and access ends immediately. Being able to say that sentence in a kickoff call is worth more than any feature.

Which role to issue

Per site, not once for all of them. The smallest role that does the job:

• Editor when the work is posts, pages, media, categories and comments. That is most retainer work.
• Administrator only when design is in scope. Templates, template parts, navigation, menus and widgets are all gated on edit_theme_options, which no role below Administrator holds. WordPress offers no middle role that covers block-theme design without also covering plugin installation — a limitation of the capability model, not of any tool.

If a client is uneasy about an administrator credential, the honest framing is that the credential can do what the account can do, that it never permits wp-admin login, and that it is revocable on its own without touching the account's real password.

What a client will actually ask

Four questions, in roughly this order. Have the answers ready.

"Are you installing anything on my site?" With a REST-based approach the answer is no, and that alone clears most managed-host and security-review obstacles. With a plugin the answer is yes, and it needs to go through whatever process they have.

"What can it change?" The honest ceiling is core REST: content, media, taxonomies, comments, and on a block theme the whole design layer — templates, navigation, global styles. It cannot switch the theme, run updates, or touch classic-theme Customizer values, because core registers no route for those. Saying what it cannot do is more convincing than listing what it can.

"What if I want it to stop?" They revoke the application password from their own site. It ends immediately, independently of anything you do.

"What did it actually do?" This is the one people forget to prepare for and the one that becomes urgent the first time a page looks different. You need a per-site record of what changed and when, and ideally a way to undo it. WordPress revisions cover posts and templates; a connector should hand back a restore handle on every write and keep a log of its own. wpreef keeps 90 days of audit history per account, recording what changed and when, never the content itself.

Where this is not the right tool

Worth saying plainly, because it is the boundary that gets oversold.

An assistant reaching WordPress over REST is a content and design tool. It is not a maintenance platform. Backups, uptime monitoring, vulnerability scanning, staging, bulk core updates across a fleet and one-click rollbacks are what MainWP, ManageWP, WP Umbrella and their peers exist for, and those run agents on each site precisely because that job needs code inside WordPress.

The two are complements, not substitutes. If your week is patching and monitoring, a maintenance platform is the answer. If your week is publishing, restyling, fixing a menu, reorganising categories and answering "can you change this by Thursday", that work is mostly above the REST line and the assistant handles it without anything installed.

A reasonable setup for a small agency

1. 1

   One application password per site, on an account with the smallest role the work needs.

2. 2

   Register the sites once with a hosted connector, so the credentials live in one place and each client can still revoke from their own site.

3. 3

   Keep the optional companion plugin for the sites where theme switching or updates genuinely matter, and skip it everywhere else.

4. 4

   Keep a maintenance platform for backups and patching. Different job.

5. 5

   Check the audit log before the client does.

wpreef is priced for this shape: one site free, up to three on Starter at $9 a month, up to ten on Pro at $19 — metered by sites rather than by calls per day, with unlimited reads on every tier. The npm package and the companion plugin are free and open if you would rather run it yourself.

Questions people ask

Can I manage multiple WordPress sites from one AI assistant?

Yes. A connector that holds several registered sites presents them as a closed list the assistant chooses from, so one conversation can reach any of them. The practical limit is credentials rather than the protocol: each site still needs its own application password, and what matters is how many copies of each exist and where you revoke them.

Do I have to install a plugin on my client's WordPress site?

No. The REST API has been in core since WordPress 4.7 and application passwords since 5.6, so an external server can read and write a site with nothing installed. A plugin is only needed for things core exposes no route for, such as switching themes, running updates or classic-theme Customizer values.

How does a client revoke access to their site?

From Users → Profile → Application Passwords on their own WordPress, by deleting the row. It takes effect immediately, needs no cooperation from whoever was using it, and does not change the account's password or affect anything else the account can do.

Is this a replacement for MainWP or ManageWP?

No. Those are maintenance platforms — backups, uptime, vulnerability scanning, bulk updates — and they install an agent on each site because that work needs code running inside WordPress. A REST-based assistant handles content and design without installing anything. Most agencies want both, for different halves of the week.

What role should the application password have?

The smallest that does the work. Editor covers posts, pages, media, taxonomies and comments, which is most retainer work. Administrator is required only when design is in scope, because templates, menus, navigation and widgets are gated on edit_theme_options and no lesser role holds it.