There is a demand we hear almost every week: connect Claude, or another AI assistant, directly to WordPress, so marketers, SEOs, and other non-developers can change the website themselves.
We understand it. Waiting for a developer for every headline, landing page, or meta description feels slow. If AI can do it, why not let everyone do it?
As the team responsible for keeping websites fully functional, we are not against this. But we are honest about the fear that comes with it.
You know that old meme — the person drags a file into the trash, then drags the whole computer into the trash, and the computer disappears:
Give an AI with full admin rights one unclear instruction — “clean up the old pages” — and that joke stops being funny. A section, a template, a whole site can be deleted in seconds, with full confidence.
So the real question is not “AI or no AI in WordPress?” We already use AI in WordPress delivery every day. The question is: who gets the keys, and how many doors do they open?
We always wanted teams to edit on their own
To be clear: we have always encouraged website owners, marketers, and content teams to make changes themselves. WordPress and Elementor exist for exactly that.
But independent editing still requires knowledge: which template a page uses, what a change does to mobile, forms, tracking, SEO settings, and the next person who edits. AI does not remove that knowledge. It only changes who — or what — acts on it.
That is why “just give AI full access” worries us. Not because we want to keep the work, but because someone still carries responsibility when the site breaks.
And here’s our take on that old meme, updated for the AI era 🙂
Three options, none of them free
1. Full access. Everyone can ask for anything, including on the live site. Fastest in the short term, most dangerous in the long term. One wrong prompt and you learn what backups are for.
2. Limited access. AI can draft content, propose layouts, and update text and SEO fields — but only as drafts, only in defined areas, with a human approving before anything goes live. Safer. But someone has to define those areas, set the permissions, provide a preview, and review the result. That setup is real work.
3. Wait. Keep AI in the developer’s hands for now and watch the tools mature. Safest today, slowest tomorrow — and teams will try workarounds anyway, from editor agents to generic chatbots with too much access.
We have sketched safe-and-useful setups internally. The pattern that works is always the same shape: the AI works on a copy or a draft, it can only do explicitly allowed changes there, and nothing reaches the live site without a human approving it. It works — and it needs upfront work to define, configure, and maintain. There is no install-and-forget button yet, only trade-offs.
Keeping the site working while more people can improve it faster
Our job here is the same job we always had: keep the website working while letting as many of the right people as possible improve it safely.
In practice that now means designing how others — including AI assistants — can safely change things: what the AI may touch, what stays read-only, where drafts happen, and who approves before publish. A healthy site is not one nobody touches. It is one where marketers, SEOs, and developers can all make changes without fear that one click breaks everything for everyone else.
The tools are moving in this direction — WordPress abilities with permission checks, connectors that expose only deliberately chosen actions, editors that leave behind maintainable content. But installing a connector still leaves open the decisions about what it can access and how its work gets checked.
So what do you think?
We don’t have a final answer. We are figuring it out fast, on real sites where we carry responsibility for the result.
Whether you run a website, market one, or build them — how do you see it?
- If you are responsible for a site: would you give AI full access today? If not, what would have to be true before you would?
- If you are in marketing or SEO: do you want full access to change anything, or would fast draft-and-approve access be enough?
- Full access, limited access, or wait — which would you choose for your team right now?
Even if you don’t write anything publicly, these are worth asking internally before connecting an assistant to production. If you do want to join the conversation, tell us on LinkedIn — link coming with the published post — or in the comments. The best answers will shape how we build this next.
Frequently asked questions
Yes, within limits: AI drafts content or proposes changes in defined areas, a human reviews a preview, and only an approved change goes live. What is unsafe is AI with unrestricted admin rights on the live site.
The AI works on a draft or a copy of the page, on staging (the development environment) rather than the live site. It can only perform explicitly allowed changes (for example text, images, or SEO fields — not plugins, themes, forms, or site-wide settings). A person reviews it there, and only then is it published to the live site. A preview and a way to undo are part of the setup.
Because “be careful” does not survive real workloads. One unclear instruction can delete or break far more than intended, and recovery costs more than the time saved. Permissions and review exist so carelessness is not fatal.
Waiting is the safest option today but has its own cost: teams adopt unofficial workarounds with even less control. A narrow pilot — drafts only, defined areas, human publish — is usually a better way to learn than either full access or a full stop.
Yes. We can review your current setup, define what AI may do, configure permissions and review steps, and establish a practical release process starting from one recurring job.

