Give ChatGPT an application password for your WordPress site and it will change the site when you ask. Most of the time it does what you meant. This article is about the other times, and about what has to sit between a model and a live site so that the other times cost you one click instead of an afternoon: a restore point, a visible difference, and an undo. Asking you first is an option for the sites where you want it, not a gate in front of everything.
What a key actually grants
An application password carries every permission of the user it belongs to. For an administrator that is posts, pages, products, settings, plugins and users. The AI does not know which of those you meant; it knows what you typed. "Update the opening hours" and "update the opening hours everywhere they appear" are the same sentence to a person and two very different jobs to a tool with write access to forty pages.
Three things that go wrong without a loop around it
- A change to a live site is live. A change to a live site is live. If the model rewrote twelve product prices and one is wrong, you are now searching for which one, at the price your customers see.
- The tool reports "done" and nothing else. Without old and new side by side, a wrong assumption stays hidden until someone complains.
- Request and change happen in the same breath. Nobody looks at what is about to happen before it happens, so there is no moment to say no.
Page builders and custom fields make it harder
Much of a real WordPress site does not live in the post body. It lives in Elementor or Bricks layouts, in Advanced Custom Fields, in WooCommerce data and in theme settings. A tool that only knows the standard REST API either cannot reach those or reaches them badly, producing half a change: the contact page updated, the footer and the schema block still showing the old hours. Elementor's own product page says editing an existing layout with its AI "isn't shipped yet", which is a fair description of the state of native WordPress AI in general.
What a controlled loop looks like
| Step | Application password | Restore point, difference, undo |
|---|---|---|
| Request | Typed into the chat | Typed into the chat, in wp-admin or from Claude or ChatGPT over MCP |
| Before writing | Nothing | A restore point of exactly what will change |
| Visibility | "Done" | Old and new side by side, per item |
| Decision | None; it is already live | Made for you and logged; on the sites you choose, it asks first |
| Afterwards | Find out from a customer | Site checked again; one log line; undo in one click |
Your own AI can still be the front door
None of this means leaving the tools you already use. WebCrew is a standard MCP server, so Claude, ChatGPT, Cursor and the rest connect to it and can ask about your sites directly. The difference is what surrounds a write: a restore point before it, a readable difference after it, one click to undo it, and, where you set that rule, a question before it. The restore point and the side-by-side difference come with the assistant as it rolls out. Reading stays instant. Writing gets a safety net.
The real question is whether you find out what an AI changed on your site before your visitors do.
If you still want to hand over a key
Create a separate user with the lowest role that can do the job, never an administrator. Give it an application password you can revoke. Take a backup before every session. Read the site after. That is the loop, done by hand; it works until the day you skip a step.
What MCP is, without the acronym
The Model Context Protocol is a standard way for an AI tool to talk to another system. Claude, ChatGPT, Cursor and the others all speak it. A server on the other end, WebCrew in this case, publishes a list of things the tool may ask for or do, each with a name and a description. The tool reads that list and decides which to call for your question. There is nothing to install for the person asking; the connection is a URL and a login.
What matters for a live site is what that list contains. A server can expose "read the site's plugin versions" and "publish this post" as two equally available actions, or it can expose the first as a read and route the second into a draft that a person approves. The protocol allows both. The difference is a design choice by whoever built the server.
One request, end to end
Say you type into Claude: "The phone number on all forty of our client sites changed to 040 123 4567, update it." With a key to each site, Claude would edit forty sites in a row and tell you it is done. With WebCrew in between, this is what happens instead.
- Claude asks WebCrew which sites contain the old number and where: a footer widget here, a contact page there, a schema block on a few, an ACF field on the rest.
- WebCrew answers in one go, because it already knows how each site is built. That answer costs a few tokens. Your tool did not have to guess where a phone number might live in Elementor.
- Claude asks WebCrew to prepare the change. WebCrew makes one draft per site, with a restore point of exactly the fields it will touch, and the old and new value side by side.
- WebCrew makes the forty changes and writes forty lines in the log. You read three, see the pattern, and move on. Or you notice that one client's number was different on purpose, and undo that one. For the two clients whose sites you set to ask first, the change waits until you say yes.
- Each site is requested again after the change. The log says who asked and what changed. Undo is one click on any line, for as long as the restore point is kept.
Before you connect any AI to a live site, ask these five questions
- Can it read without being able to write? If the only option is an administrator account, the answer is no.
- What does it do before it writes? A restore point of the exact data it will touch, or nothing.
- Can a person see exactly what changed? Old and new, per item, not a summary. And can you choose the sites where a person sees it before it is live?
- Can the rule be set per site? An agency wants a shop's prices to ask first and a brochure site to just run; a shop owner wants to say yes themselves.
- What does undo look like, a week later? A backup from last night is not undo for one change. A restore point per change is.
Sources
- WordPress.org, "Application Passwords: Integration Guide"make.wordpress.org/core
- Elementor, product page for Elementor AIread 24 August 2026; the quoted limitation is on the vendor's own page
- Model Context Protocol specificationmodelcontextprotocol.io
Rik Smeets