Letting an AI assistant work on your WordPress site? Decide what it may touch first

Connecting an AI assistant to a WordPress site has become a ten-minute job. A plugin or a connector, an application password, and suddenly a chat window can draft posts, update plugins, rewrite page copy and tidy the media library. The tutorials showing this are full of questions, and they are rarely about setup. They are about trust.

Across the communities we follow, the same worries keep coming up from very different people. A site owner who let an assistant run updates woke up to a broken layout and could not tell what had changed. An agency wants one assistant across many client sites and is nervous about what a single mistake would do at that scale. A public body uses an assistant to keep notices and event pages current, and has drawn a hard line around the homepage and anything legal. A small company asks a broader question: can a business safely give an agent access to email, files and databases at all? And people building sites with AI from scratch are now asking who maintains them once the novelty wears off.

We build and look after WordPress sites for a living, and we have started to use these tools ourselves. The setup is the easy part. The decision that matters is what the assistant is allowed to touch, and what happens before its changes go live. Here is how we would approach it.

Step 1: List the jobs before you list the permissions

Start with what you actually want help with, not with what the connector can do. For most sites the list looks something like this:

• Drafting posts, event listings or product descriptions
• Fixing typos, broken links and missing image alt text
• Summarising comments, form entries or support requests
• Running plugin and theme updates
• Changing settings, menus, page layouts or user roles

Each item carries a different kind of risk. A bad draft costs a few minutes. A bad update can take the site down. A changed user role can quietly hand someone the keys. Grouping the jobs this way makes the rest of the decisions obvious.

Step 2: Give it its own account, never yours

Create a separate user for the assistant, with its own application password or key, and the lowest role that covers the jobs on your list. If it only drafts content, an author or contributor role is enough. That gives you three things at once: its changes show up under its own name in revisions and logs, you can revoke it in one click without changing your own login, and it physically cannot do what the role does not allow.

Sharing an administrator login with an assistant is the most common shortcut we see, and the hardest one to undo after something goes wrong.

Step 3: Sort changes into three tiers

A simple model that holds up well:

• Tier 1, do it: low-risk, easy-to-reverse work. Drafts, alt text, internal link fixes, notices that expire on their own. The assistant can save these directly, ideally as drafts or pending posts.
• Tier 2, propose it: changes a person approves before they go live. Published page copy, plugin updates, menu changes. The assistant prepares the change and explains it; someone clicks publish.
• Tier 3, never: the homepage, legal pages, payment settings, user roles, deleting content, anything touching member or customer data. A person does these, full stop.

The public-body example fits this neatly: routine notices and drafts were tier 1, while the homepage, legal text and deletions stayed with a named person.

Step 4: Make every change visible and reversible

Before the assistant touches anything in tier 2, check that you can see and undo its work:

• Revisions are switched on for the content types it edits.
• An activity log records who changed what and when.
• A backup runs before updates, and you have tested restoring from one.
• Updates happen on staging first when the site matters, then on production.

The site owner with the broken layout could have recovered in minutes with an activity log and a tested backup. Without them, the change was a mystery.

Step 5: Be careful with scale

One assistant across many sites multiplies both the saving and the risk. If you look after client sites, roll changes out to one site, check it, then the rest. Keep a separate key per site so revoking one does not lock you out of all of them. Write down which client agreed to an assistant working on their site, and what it may do there. Clients should not find out from their revision history.

Step 6: Decide who owns the result

This is the step most guides skip. When an AI-assisted update breaks a checkout page at night, who notices, and who fixes it? If the answer is "the assistant", nobody owns it. Whoever connected the tool owns its output, the same way a person owns the work of a junior colleague they supervise. For agencies, that belongs in the care plan in plain words: what the assistant does, what a person reviews, and what is still billed as human work.

What tends to go wrong

• The admin shortcut. Full access because setup was quicker, then no way to tell which changes were the assistant's.
• Updates with no rollback. Automatic updates plus no tested backup is the same risk it always was, only faster.
• Silent drift. Small edits pile up across pages and nobody reviews them until a customer points out something odd.
• Keys that outlive the experiment. A trial connection nobody revoked, still active months later.
• Data the assistant did not need. Access to orders or member records because the role allowed it, not because the job required it.

Where we land

An assistant can take real weight off a small team, especially for repetitive content work. Treat it like a new contractor on day one: its own login, a narrow brief, review before anything public changes, and a clear person who answers for the result. Widen its access as it earns trust, not because the connector offers a button.

Your turn

1. If you have connected an AI assistant to a live site, what is the one thing you would never let it change?
2. Do you let it run plugin and theme updates on its own, or does a person always approve them?
3. For agencies: how do you explain AI-assisted maintenance to clients, and does it change what you charge?
4. What is missing from these tiers that has already caught you out?