Managing multiple WordPress sites with AI agents: what to decide before connecting them to 23+ sites

Managing WordPress sites changes in nature when you go from one site to a fleet. It is no longer about knowing how to run WordPress. It is about doing the same thing 23 times without every site ending up different.

I manage a fleet of 23+ sites in production, on AlmaLinux servers with WHM. Now that services are appearing that promise a single AI connection for every site you manage, the obvious question is whether it makes sense to connect an agent to that fleet.

This article does not claim I have already done it. It covers what I would decide before doing it: what permissions I would grant, which tasks I would leave to deterministic tools, and where AI actually saves work. The code is illustrative.

The starting point: what running 23+ sites looks like

Day-to-day work with a fleet like this is not design or content. It is operations: tuning Apache and PHP-FPM, recovering disk space, upgrading PHP versions and untangling DNS spread across several providers.

In that work I recovered more than 40 GB of disk. It did not come from a magic tool. It came from going account by account, checking what was taking up space and why it was still there.

That experience leaves three clear ideas, and all three apply to any agent you want to connect:

• Risk multiplies. A mistake on one site is an incident. The same mistake repeated on 23 sites is a crisis.
• Every site has history. Old plugins, different PHP versions, settings someone changed by hand. What works on one can break another.
• The inventory is what matters. Knowing what is on each site is worth more than any automation that runs blind.

Connecting AI agents to multiple sites

Connecting an agent to a fleet means handing it a credential. That credential defines everything else: what the agent can see, what it can change, and what it can break if it gets something wrong or someone manipulates it.

An AI agent makes mistakes differently from a person. It can misread an instruction, follow malicious text it found in a log or a comment, or execute with total confidence something it should not have.

That is why the design starts with permissions, not capabilities. These are the decisions I would make before connecting anything:

• A dedicated user per site. Never a human admin's account. If the agent does something odd, the activity log says exactly who it was.
• Application passwords per site. WordPress lets you create application passwords for the REST API. One per site, clearly named, revocable in seconds without touching the others.
• Read-only in the first phase. The agent starts by reading: versions, plugins, logs, status. Writing comes later, and only if reading proved it is worth it.
• No root on the server. If the agent runs WP-CLI, it does so as each account's user. A mistake stays contained in one site.

One detail that gets forgotten: a WordPress role limits what the API can do, but an administrator role can install plugins, and a plugin can run any code. Giving an agent "administrator" is giving it that site's server.

If the agent needs to run commands, do not give it a shell. Give it a closed list of allowed commands and enforce it in your code, not in the model's instructions:

import subprocess
# The agent does not get a shell: it gets a closed list, read-only at first.
ALLOWED = {("core", "version"), ("plugin", "list"),
           ("core", "verify-checksums"), ("theme", "list")}

def run(site: str, args: list[str]) -> str:
    if tuple(args[:2]) not in ALLOWED:
        raise PermissionError(f"command not on the list: {args[:2]}")
    # No shell=True: the agent cannot chain or inject commands.
    r = subprocess.run(["sudo", "-u", USERS[site], "wp", f"--path={PATHS[site]}", *args],
                       capture_output=True, text=True, timeout=60)
    return r.stdout

Notice what is not on the list: option get. It looks harmless, but many plugins store API keys in the options table. A "read-only" command can leak secrets too.

The underlying rule is simple: security lives in the code around the agent. Instructions like "don't make changes without asking" are a preference, not a control.

Tools for managing sites in bulk

Before asking what AI can do, ask what a deterministic tool already solves. In fleet management, the answer is: almost everything repetitive.

Bulk management tools, whether commercial dashboards or your own scripts, solve the same thing: seeing the status of every site in one place and applying the same action to several. That does not require a language model.

In my case, the foundation is WP-CLI run in bulk. A read-only inventory, running as each site's owner, tells you in minutes which WordPress version each site runs and which plugins have pending updates:

# Read-only inventory: WordPress version and plugins with pending updates.
for dir in /home/*/public_html; do
  [ -f "$dir/wp-config.php" ] || continue
  owner=$(stat -c %U "$dir")
  # Runs as the site's owner, never as root: WP-CLI executes the site's code.
  echo "$owner,$(sudo -u "$owner" wp --path="$dir" core version 2>/dev/null)" \
    >> /root/inventory/core.csv
  sudo -u "$owner" wp --path="$dir" plugin list --update=available \
    --fields=name,version,update_version --format=csv 2>/dev/null \
    | sed "1d; s|^|$owner,|" >> /root/inventory/plugins.csv
done

That inventory is more useful than any agent for one reason: it always gives the same result for the same state. It can be compared across days, versioned and audited.

What remains the server panel's job, WHM in my case, does not need AI either:

• PHP versions per account. Changed site by site, with a test first, because an old plugin may not support the new version.
• Disk space. Forgotten backups, unrotated logs and caches that grow without limit. You find them with per-account reports, not conversations.
• Apache and PHP-FPM tuning. Process limits are calculated from server memory and each site's traffic. They are numbers, not opinions.
• DNS spread across providers. An inventory of where each zone lives prevents a change from being made at the wrong provider.

If you want to bring this discipline to infrastructure as code, I wrote about modeling a fleet like this in Terraform on AWS for 23+ sites.

Optimizing management with AI

With permissions scoped and the repetitive work solved, the interesting question remains: where does an agent actually add value? In tasks that mean reading a lot, understanding context and summarizing.

Log triage

Reviewing the PHP error log of 23 sites is slow and tedious. Most lines are repeated notices; a few announce a real problem.

An agent can group repeated errors, separate notices from fatal errors and tell you which site started failing since the last update. You review a ten-line summary, not ten thousand lines.

One precaution: logs contain text written by outsiders, such as URLs, user agents and parameters. An agent that reads logs may run into malicious instructions hidden there. That is why the agent that reads logs must not be able to write anything.

Update summaries

With the inventory in hand, the agent can read the release notes for every pending plugin and answer what matters: is it a security fix? does it change something this site uses? are there incompatibility reports?

That turns a list of 60 updates into three groups: apply today, apply with testing, and wait.

Change drafts with human approval

The agent can draft the plan: what to update, on which sites, in what order and how to roll back. A person reviews and approves it. Execution runs in a deterministic script, not in the model.

That separation is the important part. The agent proposes; the script runs what was approved, backs up first and rolls back if the test fails:

# ⚠️ Production: a person approved the change; even so, back up first.
user=site01; root=/home/$user/public_html; stamp=$(date +%F-%H%M)
wpu() { sudo -u "$user" wp --path="$root" "$@"; }
wpu db export "/home/$user/backups/$stamp.sql"
previous=$(wpu plugin get "$plugin" --field=version)
# One plugin at a time: if something fails, you know exactly what it was.
wpu plugin update "$plugin"
# The smoke test decides; the agent cannot declare success.
if ! curl -fsS -o /dev/null --max-time 20 "https://$domain/"; then
  wpu plugin install "$plugin" --version="$previous" --force
  echo "rolled back $plugin to $previous on $user" | logger -t fleet
fi

The smoke test in this example is minimal: the home page responds. On a real site you add the pages that matter most, such as the cart or the contact form.

Audit and rollback: non-negotiable

With a fleet, the question "what changed and who changed it?" has to be answered in minutes. If the agent takes part, the answer must name it explicitly.

• A record of every action. What the agent proposed, who approved it, which command ran, on which site and with what result. Stored off the site's server, so a compromised site cannot erase it.
• A backup before every write. Database and affected files, with the date in the name. No backup, no execution.
• Tested rollback, not assumed. Restoring a backup is rehearsed on a test site. A backup that has never been restored is a hope.
• Rollout in groups. First one low-risk site, then a few, then the rest. A mistake is caught when it affects one site, not 23.
• A kill switch. Revoking the agent's application passwords must take seconds and affect nobody else.

None of this is exclusive to AI. It is the normal discipline of running production. The difference is that an agent acts faster than a person, so the controls have to be ready first.

What NOT to do

• A single admin account for the whole fleet. If that credential leaks or the agent gets something wrong, the damage reaches every site at once. Separate credentials per site, always.
• Letting the agent execute directly in production. Updating plugins or editing files without approval or a backup turns a misinterpretation into an outage. The agent proposes; an approved script executes.
• Using AI for what a command already solves. Asking a model to "check which WordPress version each site runs" is slower, more expensive and less reliable than a WP-CLI inventory.

The next step

Managing WordPress sites with AI agents can save hours, but only if the agent arrives at an orderly fleet: an up-to-date inventory, least privilege, deterministic execution and tested rollback. Without that, AI only speeds up mistakes.

If your team manages many sites and wants to bring order to its operations, evaluate whether an AI agent makes sense, or audit its servers before automating, at Conqr Digital Agency we design architectures that scale. Let's review your case.

If you want to know how I handle the server side, take a look at the Linux servers and email service.

FAQ

Is it safe to connect an AI agent to all my WordPress sites?

It depends on the permissions you give it. With separate credentials per site, a closed list of read-only commands and human approval for any write, the risk is manageable. With a single admin account for the whole fleet, it is not.

What tools should I use to manage many WordPress sites at once?

The foundation is deterministic: WP-CLI run in bulk as each site's user, an inventory of versions and plugins, and the server panel (WHM in my case) for accounts, PHP and disk space. An AI agent can lean on those tools, not replace them.

Which admin tasks are worth delegating to AI?

The ones that mean reading a lot and summarizing: reviewing error logs across sites, explaining what an update changes and drafting a change plan. Executing those changes in production is still a person's decision.