Say what you want changed — a landing page, a price, the same edit across thirty client sites. KeeperWP writes it as a draft, shows you the preview, and never publishes anything you haven't seen.
Nothing to install. Create an account, get a practice WordPress site to try it on, and bring your own when you're ready. Free while KeeperWP is in early access.
Not a code problem — a clicking problem. The settings exist, you just have to know which of several hundred screens they're on. Meanwhile teams who need to move fast have started replacing WordPress with hand-written code, because a site you can't change quickly stops being an asset.
Open the builder, drag sections, match the brand, fix it on mobile, remember where the button settings live.
The same small change, repeated across every client, each on a different theme and a different builder.
Feeding what's on your pages to any other tool means scraping HTML or parsing a page builder's private JSON.
There is no tool in KeeperWP that creates a live page. Every write produces a draft and a preview link — publishing is a separate step you ask for after you've looked. That isn't a setting you can switch off; it's the shape of the thing.
Every other way of pointing an AI at WordPress writes straight to production. That's fine on a developer's staging box and unthinkable on a business's live homepage. A preview link means the worst case is a draft you delete.
Anything published can be pulled straight back to draft. Orders in WooCommerce are read-only by design — a page published in error is embarrassing, an order changed in error is somebody's money.
Ask in your own words. Underneath it is a small, boring, auditable set of operations — and every one that changes something is written down.
Describe a page and it's authored for whichever builder that site uses — Gutenberg, Elementor or Divi. WooCommerce products work the same way, as drafts until you say otherwise.
Pull any page as readable text to feed a different tool — a newsletter, an ad, a report. No HTML scraping, no page-builder JSON to unpick.
Draft WooCommerce products, change prices, see which plugins are out of date, switch one off. Orders stay read-only — a page published in error is embarrassing, an order changed in error is somebody's money.
KeeperWP talks to WordPress the way WordPress already expects to be talked to — its own REST API, its own application passwords. Nothing is installed on your site, nothing depends on your host or your theme, and access is revocable from your own admin in one click.
Page builders — Gutenberg, Elementor, Divi. Describe a page once and it is authored in the markup that particular site actually uses. These are not interchangeable: Gutenberg is block comments, Elementor is a serialized JSON blob in post meta, Divi is shortcodes. Getting each one right, per site, is most of the work — and it is why the same instruction can run across thirty sites that were built by thirty different people.
WooCommerce. Products, prices, SKUs and stock, all draft-first. Orders are read-only and will stay that way.
Plugins. See what is installed, what is behind the version on wordpress.org, and switch one on or off. KeeperWP does not install updates — WordPress offers no safe way to do that remotely, so it tells you what is stale and leaves the update to you.
KeeperWP's own chat. The default. Open it in a browser, sign in, start typing — no assistant subscription, no install, no configuration. Most people never need anything else.
Your own assistant. The same operations are exposed as an MCP server, so if you already work in Claude or ChatGPT you can drive your sites from there instead and keep them alongside everything else you do. Not publicly released yet — it works, but there is no package to install today.
Either way it is the same tools, the same draft-first rule, and the same change history underneath.
WordPress keeps revisions per page. It keeps nothing for products, nothing for plugins, and nowhere does it record why anything happened. KeeperWP writes one ordered list of everything it changed, across pages, products and plugins, each entry carrying the sentence that caused it.
“Deactivated the caching plugin” sits in the same timeline as “Published the returns policy”, each with the request that prompted it, in your own words.
Every entry stores what things looked like beforehand, so putting one back is a button — a page restored to its previous wording, a plugin switched back on.
“What happened to the site last week?” has an answer that takes ten seconds instead of an afternoon of guessing, whoever asked for the change.
KeeperWP uses WordPress's own application passwords — a separate password for one program, revocable on its own, that cannot be used to log in as you. There is no plugin to add to your site.
# 1. create an account — a practice site comes with it your email, a password, nothing installed # 2. in your own WordPress, when you're ready Users → Profile → Application Passwords name it "KeeperWP" → Add New # 3. paste it into KeeperWP site address · username · that password
KeeperWP writes pages and products, reads and rewrites content, manages plugin state, and keeps the change history. That is genuinely all it does today — it does not change your theme, install plugins, or restyle an existing design.
It checks the connection before saving it, and if something is wrong it tells you exactly what: the commonest cause by far is a site still on http://, because WordPress hides application passwords until a site has HTTPS.
The reason teams abandon WordPress is that changing it is slow. That was a tooling problem, and tooling just changed.
Try it free