DEV Community: GoBuildWP

How to Rewrite WooCommerce Product Descriptions in Bulk with Claude or ChatGPT (in Small, Reviewed Batches)

GoBuildWP — Tue, 06 Oct 2026 03:59:57 +0000

Most WooCommerce catalogues have the same problem hiding in them. The first fifty products got real descriptions because someone cared at launch. The next few hundred got the supplier's two lines, a copy of the product title, or nothing at all. Nobody plans to fix them, because opening products one by one in wp-admin is a week of tabs.

AI looks like the obvious answer, and store owners are trying it. In one r/woocommerce thread, an owner with about 4,000 products to improve said they were throttled after roughly 50 products. Replies pointed to process rather than a new tool: work in batches (one mentioned MCP with Claude Projects), and another suggested batches of around 50 to 100 with retries and logging. In another thread, a store owner described more than 10,000 old products with poor descriptions they wanted to redo.

Batching is good advice, but it's only half the job. It keeps the AI from stalling. It doesn't tell you which products need work, whether the new copy is accurate, or how to get the old text back when a batch goes wrong.

This tutorial covers the full loop: measure, batch, review, save, verify, undo. I'll use Claude and ChatGPT connected to WordPress over MCP through GoBuildWP (formerly WPPilot)'s WooCommerce MCP, and I'll say which steps work on the free plugin and which need Pro.

Disclosure: I work on GoBuildWP. Everything below was checked against the live docs on 5 October 2026.

Why not export a CSV and paste it into ChatGPT?

For 30 products, that's fine. At a few hundred it breaks down:

The CSV carries every column, so the re-import can quietly overwrite prices, stock or categories you never meant to touch.
You lose the link between what the AI read and what it wrote. If a description says the jacket is waterproof, you can't easily tell whether that came from the product data or from the model.
The only undo is re-importing yesterday's file, which also reverts every legitimate change made since.

Working over MCP changes the unit of work. The AI reads one product record, proposes one description, and saves one field. In the WooCommerce ability reference, the free product editor (woocommerce-edit-product) is described with "PATCH semantics: only the fields given change." If the call contains only description, prices and stock aren't part of the write.

What you need

WordPress 6.9+ with PHP 8.0+, and WooCommerce 9.0 or newer (GoBuildWP's store abilities don't register below that).
GoBuildWP Free, installed and connected. Pro is optional.
Claude (desktop, web or Claude Code) or ChatGPT (web, with Developer mode).
A recent backup. The GoBuildWP ledger docs are blunt: "Take a backup before a large batch, regardless."

Free vs Pro for this job

Step	Free	Pro
List products and read full product records	Yes	Yes
Rewrite a product's long description	Yes, one product per call	Yes
Rewrite the short description	Not in the free editor's field list	Yes
Rewrite variation descriptions	No	Yes
Undo an edit from the change ledger	Yes	Yes, except on stock-managed products (see Step 7)
Save your writing rules as a reusable skill	Yes	Yes
Hold every write until a person approves it	No	Yes, the approval queue

On a variable product, the free editor can only change the name and description, because prices and stock live on the variations. For a description rewrite that's all you need.

Step 1: Connect in Read Only, as a dedicated user

Give the AI its own WordPress login rather than connecting as yourself. Every change in the ledger then names that user and the agent behind it, and you can switch it off without touching your own login. Check the role requirement first: the WooCommerce products use case says the connection identity needs manage_options on a single site, and that "a plain Shop manager does not meet the connection prerequisite."

Before connecting, go to GoBuildWP â†’ Settings â†’ Agent access â†’ Safety profile, choose Read Only and save. A fresh install starts on Production Safe, so this is a deliberate change. Under Read Only, write abilities are hidden from the AI's tool list entirely, so nothing can be saved while you measure.

To connect:

Claude Code: GoBuildWP's Connect screen gives you a command like claude mcp add wppilot-your-site-com --transport http https://your-site.com/wp-json/mcp/wppilot-oauth. Run /mcp inside Claude Code and sign in through the browser as the AI's WordPress user.
ChatGPT: turn on Developer mode under Settings â†’ Security and login, create an app with your site's /wp-json/mcp/wppilot-oauth URL and OAuth, then choose the app from the plus menu in each new chat.

Test with something harmless: "Run woocommerce-check-setup and tell me the WooCommerce version and currency."

Step 2: Measure before you write anything

Most bulk rewrites skip this, and it's the step that saves the most time. If you don't know how many products are actually thin, you can't size batches, and you'll spend AI time rewriting descriptions that were fine.

One technical wrinkle: woocommerce-list-products returns a compact row per product (ID, name, SKU, status, type, stock fields, prices, permalink, date modified). The description isn't in it. So measuring takes two reads: list IDs page by page, up to 200 per page, then open each product with woocommerce-get-product.

Audit my WooCommerce product descriptions. Read only, change nothing.

1. Run woocommerce-check-setup.
2. Page through woocommerce-list-products with status "publish" and limit 200.
   Collect ID, name, SKU, type and manage_stock for every product.
3. Read each product with woocommerce-get-product. Strip HTML from the
   description and count the words. Note whether a short description exists.
4. Flag a product as THIN if the description is empty, has fewer than
   40 words, only repeats the product name, or is identical to another
   product's description.
5. Show THIN products only: ID, name, SKU, type, word count, short
   description yes/no, manage_stock yes/no, and the reason it was flagged.
6. End with totals: products checked, products flagged, count per reason.

Adjust the 40-word threshold to your catalogue. It's plenty for a washer and far too little for skincare.

Two columns matter later. Short description yes/no, because that field needs Pro. manage_stock yes/no, because it changes what can be undone when Pro is active. Save the table as your baseline.

Step 3: Write the rules down once, as a skill

Re-explaining your style in every chat is how tone drifts. Batch 1 gets a careful brief, batch 6 gets "same as before", and by batch 12 the copy reads like three different writers.

GoBuildWP Free includes Skills: Markdown instructions stored on your WordPress site that an agent loads by name when a task matches. They're saved as a private post type with no public URL. Because the skill lives on the site rather than in the client, Claude and ChatGPT read the same rules. Ask the AI to create one with skill-write:

Create a user skill titled "Product description rules" with this body:

Use only facts in the product record: name, attributes, categories,
dimensions, weight, existing description and short description.
Never invent materials, certifications, health or safety claims,
compatibility, warranty terms, shipping times or prices. If a fact is
missing, leave it out and add the product to a "needs info" list.
Length: 80 to 150 words.
Structure: a short opening paragraph on what it is and who it's for,
3 to 5 bullets from the attributes, then a care or use line only if
the record supports it.
Tone: plain and specific. No "elevate", no "unleash", no exclamation marks.
Keep any existing size chart, HTML table or shortcode exactly as it is.

The "never invent" line matters most. GoBuildWP's own WooCommerce automation guide says: "Do not infer regulated claims, prices, stock, tax treatment, or shipping facts from incomplete context." A product description is a promise to a customer. A model filling a gap with "BPA-free" or "fits all standard models" turns a copywriting job into a returns problem.

Edit the skill as you go. If batch 2 overuses a phrase, ban it in the skill and every later batch follows.

Step 4: Pick a batch size you can actually read

The 50-to-100 advice from Reddit is about keeping the AI client from stalling. In this workflow the real limit is the reviewer. GoBuildWP paces writes at 120 per minute per credential, so the site isn't the bottleneck. You are.

What I'd do:

First batch: 5 to 10 products. Mix a simple product, a variable product, one with an HTML table and one with almost no data.
Then 25 per batch while you're still tuning the rules.
Then 50, once three batches in a row need no corrections.

Group the thin list by category. Twenty-five phone cases in a row are quick to review, and the odd one stands out.

Step 5: Draft the batch and review it before saving

Switch the safety profile to Production Safe, since the next steps write. Then ask for drafts only:

Load the "Product description rules" skill.
Take the next 25 products from my THIN list, in category order.
Read each with woocommerce-get-product and draft a new description.
Do not save anything.

Show a review table: ID, name, current description (first 30 words),
proposed description in full, and the facts from the record you used.
List any product you skipped and why. Then stop and wait.

The "facts used" column is your accuracy check. If a description mentions merino wool and the facts column doesn't, that line was invented.

Be clear about what kind of preview this is. GoBuildWP has a formal preview-before-write feature with a field-by-field diff and a wp-admin screen to apply or discard it, but the docs scope it to edits of posts, pages and media, plus settings changes and deletions. Product edits aren't on that list, so for products the review happens in this chat table.

If a second person has to sign off on store copy, use GoBuildWP Pro's approval queue with its policy set to hold writes. Each product edit then waits until someone approves it. The docs add a fair warning: "a hold is not a rendered diff." The approver sees the held request and its arguments, so keep the chat table as the readable version.

Keep your own draft ledger

Before approving, ask for the batch as a CSV:

batch, product_id, sku, old_description, new_description, approved_by, approved_at

Save it outside WordPress. This isn't redundant. The change ledger docs say the ledger holds at most the latest 10,000 changes or 90 days of history, whichever limit is hit first, and "drops large before-images once a change is 30 days old, at which point that change can no longer be undone." Ledger exports leave before-images out too. Long descriptions are exactly the kind of large field that ages out, and your CSV is the copy that doesn't.

Step 6: Save only the description, then read it back

Approved, except products 2213 and 2240 (skip those).
For each approved product, call woocommerce-edit-product with only id and
description. Send no other field.
After each save, re-read the product and compare the saved description
with the approved text. Report any mismatch or error.
Finish with the GoBuildWP change ID for each product.

Practical notes:

Only id and description. With partial updates, everything you leave out stays untouched.
Backslashes. The reference warns that "WordPress strips single backslash characters from description on save". Use double backslashes if your copy contains code or file paths.
Change IDs. Add them to your CSV. If someone questions a description next month, you can go straight to its entry.

Then open three products from the batch in a private window. Check that bullets render, size charts survived and mobile looks right. If you run a page cache or CDN, the old copy may show until it's purged.

Step 7: Undo, and know exactly what can be undone

On GoBuildWP Free, the basic product editor keeps a before-image of only the fields it changed and writes them back through WooCommerce on rollback. Three ways to use it:

Ask the AI to call rollback-change with the change ID. The call won't run without explicit confirmation, and it compares what it wrote back with the saved before-image rather than assuming it worked.
Open GoBuildWP â†’ Changes in wp-admin, filter by the agent and the batch's time window, and undo one change or everything the filter shows, as many as 200 at once. No AI involved.
Use undo-session to revert everything one agent session changed, newest first. It refuses without changing anything if something else edited one of those products in the meantime.

With GoBuildWP Pro active, Pro's fuller product editor answers under the same ability name, and it has one exception. GoBuildWP's WooCommerce docs explain that on a product that manages stock, Pro's edit is recorded without a before-image, because restoring it would also write back the old stock level and erase every sale since. Those entries say they can't be undone. Products that don't manage stock roll back normally.

That's what the manage_stock column was for. On Pro, for a stock-managed product, your CSV is the way back: have the AI write old_description back with another woocommerce-edit-product call.

For everyone: rollback isn't a backup. It only knows about GoBuildWP's own writes, so a manual edit between the AI's save and your undo can produce a result nobody predicted.

Step 8: Repeat, then re-measure

Every batch is the same short loop: draft, review table, CSV, save, read back, spot-check. Every few batches, tighten the skill based on what you corrected, and look at the needs info list. A product with no attributes and no text can't be described honestly by an AI. Someone has to add the facts first.

When the list is done, run the Step 2 audit again and compare the flagged count with your baseline. That number is what you can prove. Whether better descriptions lift sales or search traffic is something to check in your analytics over the following weeks, not something to assume.

Short descriptions and variations

On many themes the short description sits next to the price and the Add to cart button, so it can matter more than the long one. With Pro, the same workflow works with short_description in the edit call. Keep it to two or three lines and give it its own rule in the skill.

Variation descriptions are a separate field on each variation, edited with Pro's woocommerce-edit-product-variation. Most stores can leave them until the parent descriptions are done.

The short version

Connect Claude or ChatGPT in Read Only as a dedicated user.
Measure thin descriptions and save the baseline.
Put your writing rules in a skill.
Start with 5 to 10 products, then 25, then 50.
Review a before/after table with the facts used, and keep your own CSV.
Save only the description, read it back, check the storefront.
Undo from the ledger when needed. On Pro, stock-managed products need your CSV instead.
Re-measure at the end.

The free plugin covers the whole loop for long descriptions. Pro adds short descriptions, variations and an approval queue. The Free vs Pro comparison lists everything else.

How to Find and Fix Missing Meta Descriptions in WordPress with Claude or ChatGPT

GoBuildWP — Mon, 05 Oct 2026 06:25:40 +0000

A practical Yoast and Rank Math workflow: audit first, write from the page, check what the site actually serves, and keep a way back.

Many WordPress sites share the same quiet SEO gap. The homepage and the handful of pages someone cared about at launch have hand-written meta descriptions. Most posts published after that have an empty description field, so the SEO plugin falls back to a template and Google picks its own snippet.

People ask about this all the time. A recent r/Wordpress thread asked how to bulk edit Yoast meta descriptions for post categories, because Yoast's bulk editor didn't show them. Whole plugins exist just to find posts with no description and fill them. Meow Apps even lists it as a typical weekly request to an AI agent: "List every post without a meta description, write one for each in my tone, and show me before saving."

The writing part is easy now. Claude or ChatGPT can write a decent 150 character summary in seconds. The hard parts are the boring ones:

Knowing which posts are actually missing a description.
Making sure the AI writes from what the page says, not from a keyword and its imagination.
Saving into the right field of the SEO plugin you run, and nothing else.
Being able to undo it when a description turns out wrong.

This tutorial walks through that loop with an AI client connected to WordPress over MCP through GoBuildWP (formerly WPPilot). I'll be clear about what the free plugin does, where Pro starts, and where you still need a human.

A reality check on meta descriptions

Google's documentation says snippets are "primarily created from the page content itself", and that Google "sometimes uses the meta description HTML element if it might give users a more accurate description of the page than content taken directly from the page." So a description is a strong suggestion, not a guarantee.

The same page gives three rules that matter once AI writes the copy:

Unique per page. "Identical or similar descriptions on every page of a site aren't helpful."
Prioritise. If you can't do every page, "at the very least, create a description for the critical URLs like your home page and popular pages."
Generated is fine if it's good. Programmatic descriptions "can be appropriate and are encouraged. Good descriptions are human-readable and diverse." Strings of keywords "are less likely to be displayed as a snippet."

That's the green light for AI, if every description is readable, specific and different.

And a saved description is not a ranking result. GoBuildWP's SEO page says a successful write "proves the operation returned successfully". Measure clicks in Search Console a few weeks later.

What you need

WordPress 6.9 or newer and PHP 8.0+.
One supported SEO plugin active. GoBuildWP Free reads and sets one post's SEO title, meta description and robots in seven: Yoast SEO, Rank Math, AIOSEO, SEOPress, The SEO Framework, Slim SEO and SmartCrawl. The reference pages list minimum versions, for example Yoast SEO 21.0+ and Rank Math 1.0.200+.
An MCP client. I'll use Claude and ChatGPT as examples.
GoBuildWP Free. Pro is optional; I'll point out exactly where it helps.

If you have two SEO plugins active (common mid-migration), the plugin-neutral SEO calls refuse to guess. They return wppilot_seo_provider_ambiguous and ask you to name the one the front end actually uses. Decide which plugin is live before writing anything.

Step 1: Connect with a dedicated user, in Read Only

Create a separate WordPress user for the AI. GoBuildWP's SEO use case recommends this "so the ledger names it rather than your administrator account." Free's per-post SEO calls check edit_posts plus the right to edit that post, according to the Yoast and Rank Math references. Pro's full modules check manage_options, so Pro work needs an administrator-level user.

Then set the GoBuildWP safety profile to Read Only for the first session. The docs call Read Only "the correct starting point for audits, discovery, reporting, and connection tests," and it hides writes rather than just refusing them: "An ability the active profile does not allow is withheld from discovery." During the audit, the write tools simply aren't there.

Connecting:

Claude (web): Customize, then Connectors, then Add custom connector. Paste the MCP URL from GoBuildWP's Connect screen and approve through OAuth as the dedicated user. claude.ai connects from Anthropic's side, so the site needs public HTTPS. For a local or staging site, Claude Desktop can reach it instead.
ChatGPT: on ChatGPT web, open Settings, then Security and login, and turn on Developer mode (GoBuildWP's guide notes OpenAI documents it for Plus, Pro, Business, Enterprise and Education accounts). Create the app from ChatGPT Plugins with the OAuth URL your Connect screen generates. Apps are enabled per conversation from the plus menu, which explains most "it's connected but ChatGPT ignores it" reports.

Test with a harmless question: which SEO plugin is active?

Step 2: Find the posts that are actually missing descriptions

You need the list first.

GoBuildWP Free includes audit-content, a content audit that changes nothing. Its seo_meta check reports a missing meta description or SEO title, read through the active SEO plugin, and "the source used is reported." By default it runs as a background job over published posts and pages and returns a job_id; audit-content-status pages through the findings worst first. Findings are kept for seven days after the job ends.

Run a content audit with only the seo_meta check, as a background job.
When it finishes, give me a table: post ID, title, URL, post type, and
whether the title, the description, or both are missing. Tell me which
SEO plugin the audit read from. Change nothing.

"Missing" means no override was set. The Free Yoast reference says an empty description "means Yoast uses the post type template," and Rank Math works the same way. A post on the list may still output a template-built description. That's usually what you want to replace, but the page isn't blank in search.

The audit sees stored content. The platform reference warns that stored-content audits "can omit runtime templates, dynamic output and external content." If your theme prints its own meta tags, the audit won't see them. Step 5 covers that.

On Pro, seo-bulk-get-meta reads SEO title, description, canonical, robots and Open Graph fields for many posts in one shape across all supported plugins, with filters for missing_description, missing_title and duplicate_titles. A filtered read inspects at most 1,000 posts and reports truncated=true when there were more, so page by post type on big sites. Use the duplicate filter too; GoBuildWP's own rules say "fix duplicates before rewriting unique ones."

Step 3: Pick the order, don't do everything

GoBuildWP's SEO page is blunt: "Bulk-rewriting every title on a site is the least useful thing WordPress AI SEO automation can do." Google says to prioritise critical and popular URLs. A sensible order:

Pages that make money: services, key category pages, booking or contact.
Posts that already get impressions in Search Console.
Evergreen guides you still link to.
Everything else, later, in batches. Some old posts need a merge or a noindex more than a description, and that's a separate decision.

Give the AI your Search Console data instead of letting it guess. On Pro with Site Kit by Google connected, site-kit-search-pages lists pages with many impressions but a click-through rate under half the site average. Every Site Kit ability only reads.

Step 4: Write from the page, one post at a time (Free)

Switch the profile from Read Only to Production Safe for writing, then start a fresh client session so the AI picks up the new tool list.

On Free the loop is one post at a time. That's fine for the first 20 or 30 important pages and keeps every change easy to review. For Yoast the calls are yoast-get-post-seo and yoast-edit-post-seo; for Rank Math, rank-math-get-post-seo and rank-math-edit-post-seo. The other five plugins have equivalents.

For post 318:
1. Read its current SEO title, description and robots. Show them to me.
2. Read the post content and summarise in two lines what the page offers,
   using the service, product and place names the page itself uses.
3. Propose one meta description of about 140-155 characters:
   - describe only what is on the page
   - no prices, guarantees, awards or response times unless the page states them
   - no keyword lists, no "Welcome to"
   - different wording from every description you wrote earlier in this chat
4. Wait for my approval. Then write ONLY meta_description. Do not touch
   the SEO title, canonical or robots.

Why this is safe rather than lucky:

It's a partial merge. The edit call changes only the fields you send. The Yoast reference says "send only the fields to change," and "everything is validated before anything is written." Send only meta_description and the title, canonical and robots stay as they were.

Plugin variables still work. Yoast variables such as %%title%%, %%sep%% and %%sitename%% work, and Rank Math keeps variables such as %title% and %sep%. An empty string clears the override so the post type template applies again.

No invented facts. This is the rule not to relax. GoBuildWP's guidance: "prices, guarantees, awards and response times come from the page or the owner, never from the model." Language models like adding "fast", "affordable" or "trusted". Read every draft against the page before you approve it.

Here's the target shape, from GoBuildWP's documented Yoast example (placeholder business, real field names):

{
  "post_id": 123,
  "meta_description": "Book a boiler service in Leeds. See what the service includes, the areas covered and how to request an appointment."
}

Every write is recorded. Free's Yoast and Rank Math edits go into the change log with a before-image of just the SEO keys they wrote, and wppilot/rollback-change restores them. AIOSEO is the special case: Free's per-post AIOSEO edit keeps its own before-image and can be undone, but Pro's AIOSEO writes are marked irreversible, so read the old values first on AIOSEO sites.

Step 5: Check what the site actually serves

A saved field isn't a served tag. Page caches hold old HTML, themes override things, and a forgotten second SEO plugin can print its own tags.

GoBuildWP Free's verify-rendered-page "fetches the page as a visitor gets it and reports what was served." After each write:

Re-read post 318's SEO fields, then run verify-rendered-page on it.
Confirm the served meta description matches what we saved. If not,
tell me what was served instead.

If the saved value is right and the served one isn't, purge the page cache first. GoBuildWP's use case notes "a cached page can keep serving the old title until the page cache is purged." Still wrong? Check the theme header or a leftover SEO plugin before blaming the AI. A WordPress.org Rank Math support thread about missing descriptions ended the same way: clear the cache and check the page source.

Step 6: Scale up carefully (Pro)

One at a time gets slow on a site with hundreds of posts. This is where Pro earns its place.

seo-bulk-update-meta sets SEO fields on up to 100 posts per call through the active plugin's own per-post writer. Without dry_run or confirm it is refused with wppilot_confirmation_required and told how many posts it would overwrite. dry_run=true returns each post's before and after and writes nothing; confirm=true writes. Results are per post (updated, unchanged or error), and one failing post never stops the rest. A field the plugin doesn't store fails that post with wppilot_seo_field_unsupported instead of pretending it saved.

Take the next 25 posts from the audit list that are missing a description.
Draft a description for each with the same rules as before. Run
seo-bulk-update-meta with dry_run=true, one item per post. Show me the
before and after as a table. Do not confirm until I reply with the post
IDs I approve.

Why 25, not 100? Because you should actually read the dry run, and 25 rows is a table you'll check properly. Advice in r/woocommerce threads about rewriting thousands of product descriptions points the same way: smaller batches with retries and logging are more reliable.

Modest batches also matter for undo: the ledger docs say a single bulk call keeps before-images for its first megabyte of changes only.

Each written post gets its own ledger row. Yoast SEO, Rank Math, SEOPress, The SEO Framework, Slim SEO and SmartCrawl rows restore with wppilot/rollback-change. AIOSEO rows are irreversible; to undo them, rerun the write with the before values from the batch.

Pro also covers the case from that Reddit thread: category and tag archive descriptions. In Yoast that's yoast-edit-term-seo. Term SEO is available for Yoast, Rank Math, AIOSEO and SEOPress, not the three smaller plugins. And Pro's content-fix-plan can turn a finished audit into reviewable items, including "adding a missing description through the SEO plugin," which content-fix-apply applies only for the items a person picked.

Step 7: Undo when you need to

You'll write a few descriptions you regret. Every change shows up in wp-admin under GoBuildWP > Changes, which "undoes one change, one bulk batch, or every undoable change a filter shows, up to 200 at a time, without involving the agent that made them." Bulk writes are grouped, so you can undo a whole batch or just the posts that came out wrong.

Two limits from the same page: "Rollback is never universal," and history ages out. The ledger keeps the newest 10,000 changes or 90 days, and drops large before-images after 30 days. Review new descriptions within the month.

Step 8: Stop the gap from coming back

New posts keep going out with empty descriptions. GoBuildWP Free's scheduled routines are read-only audits the server runs on WP-Cron with no agent connected. A routine can run audit-content with checks set to ["seo_meta"] daily or weekly at an hour you choose, compare each run with the last, and email a summary to administrators you pick by user ID. Routines can only run read-only audits, so they never change a page.

Create a weekly routine for Monday at 7:00 site time that runs
audit-content with the seo_meta check and emails the report to user 1.
Show me the routine before saving it.

Each week you get the new gaps to close with the Step 4 prompt.

Mistakes worth avoiding

Letting copy work touch canonicals and robots. GoBuildWP's rules say to leave them "out of copy work"; they decide which URL search engines see.
Skipping the served-page check. Caches and themes will happily show the old tag.
Treating length as law. Google says there's no limit on description length; the snippet is truncated to fit the device. Around 140 to 160 characters keeps the important part visible, but a good 170 character description is still good.

Free vs Pro for this job

The Free vs Pro comparison has the full list. For missing meta descriptions:

GoBuildWP Free

audit-content with the seo_meta check
Read and set one post's SEO title, description and robots in all seven SEO plugins, with undo
verify-rendered-page for the served HTML
Scheduled routines that re-run the audit and email results
The change ledger and the GoBuildWP > Changes undo screen

GoBuildWP Pro adds

seo-bulk-get-meta with missing description, missing title and duplicate title filters
seo-bulk-update-meta, up to 100 posts per call, dry run first
Category and tag archive SEO in the four larger suites
Canonicals, keyphrases, social fields, schema and redirects where the suite supports them (Yoast redirects also need Yoast Premium)
content-fix-plan / content-fix-apply, and Site Kit reads to choose pages by click-through rate

For a few dozen important pages, Free covers the whole job. Pro matters when the list runs into the hundreds or you need archive pages. Global SEO plugin settings stay read-only in both.

Where to go next

The audit-first version with Claude, including its ability list: Fix WordPress SEO with Claude
Bulk calls, filters and confirmation rules: Supported SEO plugins ability reference
The weekly check: Scheduled WordPress audits
What undo covers and what it can't: Change ledger and rollback

The whole workflow in one line: audit in Read Only, pick the pages that matter, write from the page with no invented claims, save only the description, check what's served, and let a weekly routine flag new gaps. The AI does the typing. You still decide what's true.

How to Manage All Your WordPress Sites from One ChatGPT or Claude Chat

GoBuildWP — Sun, 04 Oct 2026 17:38:07 +0000

GoBuildWP (formerly WPPilot) wrote this.

If you look after more than one WordPress site, the boring part is not the writing. It is the doors. Open the shop, check it, open the brochure site, open the client's blog, and try to remember which login is which. Use an AI app as well and you do that job a second time: add this site, sign in, add the next site, sign in again. Two sites and two apps is four connections. Ten sites is an afternoon.

There is an optional way around the pairs. Connect each WordPress site once to a GoBuildWP Cloud account, then add one link to ChatGPT, Claude, or another app you already use. After that you talk to those sites from that chat. The site still decides what is allowed. Cloud only passes the call on.

This is the setup as the site described it on 4 October 2026. It is not a claim that a chat will run a portfolio while you are away. The first job below is a read. Check the answer before you let anything write.

Why a connection per site gets old

A direct connection is still the right idea for one site. The free plugin makes that site its own server. The app talks to it. There is no relay and no GoBuildWP account. If you have one blog and one app, stop there. The direct ChatGPT guide is the shorter path.

The mess is the pairs. Each new site needs a connection in each app, and each new app needs a connection on each site. Miss one and you will sit in a chat that sounds sure of itself and is not looking at the site you mean.

Cloud flips that. Each site connects once to your account. Each app connects once to Cloud. Adding a site is one step. Adding an app is one step. The docs say it the plain way: without Cloud, every AI app needs its own connection to every site, which is fine for one site and tedious for ten.

The rules do not move off the site. A call still ends there, under that site's safety profile, confirmations, and change ledger. Undo stays there too. Cloud cannot do more than the site granted when you connected it.

What you are connecting

The account is at app.gobuildwp.com. Every app uses the same link, https://app.gobuildwp.com/mcp. You paste it once per app and sign in with OAuth. You do not keep a different URL for the shop and another for the blog.

On each site, install GoBuildWP Free 1.17 or newer. The free release named on the site is 1.17.0. Pro, where a site has it, is 1.11.0. WordPress has to be 6.9 or newer, and PHP 8.0 or newer. The site needs HTTPS, except a local development environment. PHP needs the sodium extension, because the site creates a signing key for Cloud. If sodium is missing, the host has to enable it.

Switch AI abilities on under GoBuildWP, then Settings, before you open Connect. Cloud tests the connection before it finishes. A site with abilities off refuses to start and tells you to turn them on.

Be signed in to wp-admin as the WordPress user you want the AI to act as. The confirmation names that user, and later calls run as that user, with that user's capabilities, under the access you picked.

Connect the first site in Read Only

Create the account at app.gobuildwp.com. Cloud is free for up to three connected sites, with every single-site feature. There is no separate Cloud price.

On the first site, open GoBuildWP, then Connect, then GoBuildWP Cloud, and select Connect to GoBuildWP Cloud. A browser tab opens. Sign in.

Choose Read Only. The access you pick is the most Cloud can ever use on that site. Connecting every site as Production Safe because it is quicker means every AI app you later allow in can write to all of them. Connect in Read Only, prove a read, then reconnect only the sites that need writes.

Read the confirmation. It spells the grant out in one sentence: this site, your Cloud account with the email masked, the access level, and the WordPress user the connection will act as. Cancel leaves the site untouched.

You never see the key and you never copy it. The browser only carries a one-time code. The site creates an access token and sends it server to server. Cloud stores it encrypted, then calls the site back to check the connection. The panel should say the site is connected, with the account and a Site ID. In the Cloud account it appears under Sites, with a heartbeat, a last-check time, the name, the URL, the GoBuildWP versions, and health.

Do the second site the same way, still Read Only, and leave the third slot until those two answer. Three is the free cap. One site links to one Cloud account. If it is already connected, disconnect first. A request lasts about ten minutes and belongs to the admin who started it.

Add the one link to the app you use

Once per app, not once per site.

In ChatGPT on the web, open Settings, then Security and login, and turn on Developer mode. Open Plugins, select the plus button, and paste https://app.gobuildwp.com/mcp. Authentication is OAuth. Sign in to the Cloud account when asked. A GoBuildWP plugin for ChatGPT, with a sites panel, an @-mention for a site, settings inside the chat, and approval forms, is coming to the plugin directory. It is not listed yet. Until it is, Developer mode is the route, and it works through the Cloud account.

In Claude, add a custom connector with the same link on claude.ai. It is then available on desktop and mobile too. In Claude Code the documented command is claude mcp add --transport http wppilot-cloud followed by the link. In Cursor, add the link as a remote MCP server and sign in when Cursor asks.

The same once-per-app sign-in covers Claude Code, VS Code Copilot, Codex, Gemini CLI, Antigravity, Windsurf, Zed, Kiro, and JetBrains Junie. Cline, scripts, and CI jobs cannot use a browser sign-in. For those, create a personal access token, limit it to the sites that job needs, set an expiry, and revoke it when the job ends.

After the app signs in, pick the sites it may reach. You can make that connection read-only even on a Production Safe site, and a read-only connection stays read-only. Revoke the app from the account when you want it gone. Attach one app first. If three apps answer strangely on the same afternoon, you will not know which sign-in failed.

Ask for one job you can check

Do not start with "update every plugin" or "rewrite every homepage." Start with a question you can check yourself.

List the WordPress sites you can reach through GoBuildWP Cloud.
For each one, give me the name, the URL, and the health you can see.
Do not change anything. If a site is missing, say so. Do not guess.

You should get the sites you allowed that app to reach. If the reply names a site you did not connect, or invents a plugin list without looking, stop. The app is not on the Cloud link yet.

The gateway tools behind a normal request are dull, which is what you want. sites_list finds the sites the app may reach. site_tools reads one site's tool list and schemas. run calls one tool on one site. The app has to name the site on each call. It does not see every site's abilities as if they all lived in the chat. If a tool list comes back empty, open that site under Sites and use Check now. The gateway caches what the site reported at its last check.

When the list matches, ask for a second read on one site only:

On [the site name you just saw], show the recent changes in the change log.
Do not undo anything. If you cannot see a log, say that and stop.

Those reads are changes and change_detail. Undo is a separate tool, and the site may ask you to confirm it. Do not use it on this pass. Open wp-admin and see whether the log in the chat is the log on the site. That is the test. A chat that names your sites and shows a change you recognise is connected. A chat that writes a smooth status report with no site names is not.

Only after that read checks out should you move a site to Production Safe, and only a site that needs a write. Disconnect it and connect again. You cannot edit the Cloud token's limits on the Connect screen, because Cloud keeps what was agreed at connect time. Revoking the token from the list does the same as Disconnect.

If most apps should only read and one should edit, connect the site as Production Safe and mark the other apps read-only. That applies at once. You do not reconnect the site for it.

ChatGPT can show an approval pop-up before a risky action. Treat it as a pause. The action still runs on the site, under that site's profile and confirmations, and it lands in that site's change ledger. If you need it back, undo is on the site. The undo and rollback page is the longer account of what a restore can put back. Read it before you undo a client site from a chat window.

What stays on each site

"All your sites in one chat" sounds like one big site. It is not.

Each site keeps its own safety profile. Read Only on the brochure site does not loosen because the shop is Production Safe. Production Safe still blocks raw PHP, WP-CLI, filesystem and database access, plugin and theme installation, and temporary administrator access. Developer Full Access is a different profile, for deliberate development or staging. The Cloud choice the docs describe is Read Only or Production Safe. It is not a switch that turns those blocks off.

Confirmations stay on the site. So does the change ledger, and so does undo. Disconnect from the Cloud account or from GoBuildWP, then Connect, in wp-admin, and the key stops working from either side.

Cloud does keep a few things, and the Cloud page lists them: your email and a hashed password; each site's URL, name, versions, and health; the encrypted key; which apps may reach which sites; a gateway log of tool name, site, outcome, time, and any error, kept 90 days. Bulk runs, if you use them later, keep the tool, the arguments, and each site's result for 30 days. Sign-in sessions store a browser name and a hashed IP address. Cloud does not store WordPress passwords, and it does not keep pages, posts, or products, except what a bulk run returns, which is deleted after 30 days.

You can tell ChatGPT what to do when a site's state changes. The events named on the page are a site going down, coming back, a key revoked, a site connected, and a bulk run finishing. An action started by an event still goes through that site's safety profile and confirmations, and it still lands in the ledger. "Tell me if the shop goes down" is a fair first instruction. "If anything looks wrong, change the settings" is how you get a surprise.

Three sites on the free account, and what Pro adds

Cloud has no price of its own. Free covers three connected sites. A Pro licence linked to the account raises the limit and unlocks bulk actions. The same email links automatically. A different email can be proved from the Cloud account.

The figures on the Cloud page are the Pro plugin prices, in USD before tax. Solo is $39 a year or $59.99 once. It licences Pro on one site and keeps Cloud's three, with bulk actions. Crew is $59.99 a year or $79.99 once, for 10 Pro sites and 10 Cloud sites. Fleet is $79.99 a year or $119.99 once, for 100 and 100. Command is $99.99 a year or $199.99 once, unlimited on both. Pro includes priority support, meaning a faster first reply. Check the pricing page before you pay.

Bulk is the part people mean by "do this on all of them," and it is not on the free Cloud account. On every Pro plan you can run one tool, with the same arguments, on many sites, in the background. bulk_status reports each site. The app needs bulk permission on its connection. Start with a dry run, which shows what would happen before anything does. The Bulk actions screen lists recent runs and can start one by hand. When a run finishes, an event can summarise what changed and what failed. Read it. A dry run you skip is a slower way to make the same mistake on every site.

Pro tools appear in Cloud only where Pro is installed. Putting ten sites on the account does not install Pro on ten sites. On Solo, the other Cloud sites stay on what Free can do unless they are licensed another way. If you are sorting client work, the agencies page is the page written for a portfolio. Use the Cloud page for the site counts. Do not assume a chat can call a Pro tool on a site that only has Free.

If it refuses to connect

A failed connect leaves the site as it was, unless the message says the token was revoked.

No HTTPS, and Cloud cannot be used from the site. No sodium, and the site cannot create the signing key. If the site could not reach Cloud, try again, then check the host's outbound firewall. If Cloud revoked the token, it could not reach the site: a login wall, an IP allowlist, or a private network. "Connection cancelled" means you backed out before Confirm.

After the first read works

Ask one more read on one site, something you already know: the active plugins, or the title of the front page. Compare it with wp-admin. If you need a write, reconnect that one site as Production Safe and ask for one change you can undo.

Add a second app only after the first one has done that, and a third site only after the first two show a heartbeat you trust. Leave a direct connection, with no Cloud account, on any site you do not want on the shared link. The free plugin still works without Cloud.

Keep the connect guide open while you click through. If a label on the screen disagrees with this article, believe the screen and that guide. Menus and plans can move. The installed plugin and the live site are the record.

How to Speed Up WordPress with ChatGPT, Claude, or Any AI

GoBuildWP — Sun, 04 Oct 2026 15:28:17 +0000

GoBuildWP (formerly WPPilot) wrote this.

Ask ChatGPT how to raise WordPress speed and you get a familiar list. Turn on a page cache. Cut the image size. Lazy load whatever sits below the fold. Serve WebP. Watch Core Web Vitals. None of that is a measurement. The model cannot see your server, so it cannot tell you whether the last request was served from cache or built by PHP, and it cannot see the width and height attributes on the images in the HTML.

Do the smaller job. Connect the site, look at what is actually installed, time two URLs, change one setting, time them again, and put the settings back if the page got worse. If you want a PageSpeed number, open PageSpeed in a browser. Do not let the chat invent it.

GoBuildWP is how ChatGPT, Claude, or Cursor run that loop on a site you administer. The writes that change WordPress speed are Pro. Free can look, and it can edit one image. It cannot tune the cache.

What you need connected before the prompt is worth pasting

You need three things in place. If any one of them is missing, the model will still answer, and the answer will be the generic list above.

WordPress has to be running GoBuildWP, and the AI client has to be connected to that site. "Connected" is not a mood. It means the client can call the site and get a result back from an ability, not a paragraph from memory. The easiest test is to ask which site it is attached to and to ask it to run a read before it gives advice. If it starts recommending plugins you did not ask about, it is not looking at the site yet.

The client can be ChatGPT, Claude, or Cursor. The steps are the same. What changes is where the calls come from. On ChatGPT the site must be public HTTPS. Those calls come from OpenAI's servers, so localhost will not answer, and a password-protected staging site will not answer either. Developer mode is documented for Plus, Pro, Business, Enterprise, and Education on the ChatGPT site. A workspace policy can disable it. If the app does not show up in the picker, fix that before you touch a cache setting. You will otherwise spend an hour judging advice that never left the chat.

A cache or optimisation plugin has to be installed and active already. GoBuildWP does not bring its own page cache. The cache module loads only while a supported cache or optimisation plugin is active. If none is active, the module does not load, and there is nothing for the prompt to tune. LiteSpeed Cache, WP Rocket, WP Fastest Cache, SiteGround Speed Optimizer, and WP-Optimize are among the plugins whose settings share one vocabulary. Ten drivers share that vocabulary. Of 26 layers, Autoptimize, Perfmatters, and Converter for Media are the three that sit under assets and images. The rest are detected by native option names, a purge callback, or read-only evidence. You install and activate the cache plugin in wp-admin. The prompt does not do that for you.

Free and Pro are different tools, and it saves a lot of confusion to know which one you are holding. Free includes a performance audit. That audit is a set of bounded server checks, and it does not make a synthetic speed claim. Free also includes system status for WordPress, PHP, the database, cron, cache, and the plugin runtime. Status will show you whether caching looks present. It will not change LiteSpeed Cache, WP Rocket, SiteGround Speed Optimizer, or any other plugin. The cache module is Pro. Its 14 abilities register only while the licence is active, and the module is on every Pro plan. Pricing stays on the site, so this walk-through does not repeat it. Check the platform reference and the feature list if you want the current split. On 4 October 2026 those pages listed Free 1.16.0 and Pro 1.10.0.

Two modes matter once you are on Pro. Read Only lists layers, reads settings, and measures. Production Safe is for writes. Stay on Read Only until you have a baseline you have actually read. A baseline you skipped is how people "optimise" a page that was already fine, or break one that was not.

Pick two URLs and write them down before you open the chat. The home page, and one heavier URL. A shop or a checkout is a fair second page if you sell anything. Warming later accepts up to ten URLs. Two is enough for a before-and-after that you can hold in your head. Ten pages times three repeats is a spreadsheet, and you will not compare it honestly.

Have a note open as well. You are going to copy four things out of the first measure: HIT or MISS on each repeat, the time to first byte, the count of images missing width, height, or a loading attribute, and the names of any render-blocking stylesheets or head scripts. Those four lines are the whole decision. Everything else in a long reply is commentary.

Paste this prompt, then read what each step returns

Paste this into ChatGPT with the app selected, or follow the same order in Claude or Cursor. Change the two URLs. Do not add a sentence that asks for a Core Web Vitals score. If you add it, you are asking the model to guess, and it will.

Audit the speed of https://your-site.com/ and https://your-site.com/shop/.
1. Run cache-check-setup and list every layer you find, including edge layers you cannot purge.
2. Start a cache experiment before changing anything.
3. Measure both URLs three times. Give me TTFB, HIT or MISS, HTML size, and render-blocking files as a baseline. Also say how many images lack width, height, or a loading attribute.
4. Propose the single lowest-risk change and wait for my OK. Prefer an images.* key such as lazy-load or missing sizes before any CSS or JS combine, defer, or delay.
5. Apply only that change, purge, warm both URLs, and measure again.
6. Run cache-verify-in-browser and give me the browser checks and PageSpeed links. Do not claim a score you did not open.
7. If anything got worse or a check fails, revert the experiment.
Never enable combine, defer, delay, critical CSS, or logged-in caching without asking me first.
Do not say you recompressed image files. If next-gen images need a converter, say which plugin screen I still have to run.

A useful reply is dull. It names what it called, it shows what came back, and it stops when the prompt says to wait. A bad reply sounds finished. It announces an LCP, it says the library was converted to WebP, or it says Cloudflare is clear. Those are not results this plugin can produce. If you see them, stop the run and tell it to stick to the prompt. Then make it repeat the step from the tool output, not from a summary it wrote on top.

Here is what each step should hand you, and what you should type back.

Step 1 runs cache-check-setup and lists every layer, including edge layers it cannot purge. You want names. A page cache. An asset optimiser. An object cache. An edge layer, if one is in front, such as Cloudflare or a host cache. The edge line is the one people skip, and it is the one that makes a later purge look like it failed. If the reply says no supported plugin is active, stop. There is no cache module to drive. Activate the plugin you already installed, then start again. Do not let the model suggest a new plugin and turn it on in the same breath.

What you type if the list looks real: "Snapshot that. Do not change anything yet." What you type if it is vague: "Name each layer and say which ones you can purge. Do not recommend a setting until you have."

Step 2 starts a cache experiment before any write. The snapshot covers the page cache, the asset optimiser, the object cache, and any edge layer. Taking the snapshot writes nothing. Only the newest five experiments are kept, so a sixth start drops the oldest. You want this snapshot even when you are sure the change is harmless. Revert later restores every layer in that snapshot. It cannot restore a plugin you never included, and one rollback cannot span two plugins. If you have been clicking around in the cache plugin's own screens during the chat, say so, and start a fresh experiment after you stop clicking. A snapshot of a moving target is not a way back.

Step 3 measures both URLs three times. Pro fetches one URL from the server on each repeat. You should see time to first byte, HIT or MISS, HTML weight, whether the response was compressed, render-blocking stylesheets and scripts in the head, a count of images missing width, height, or a loading attribute, and any font preload. Three repeats are there because one fetch is often a cold outlier, especially the first request after a quiet period. This is server-side delivery. The cache reference calls it that on purpose. It is not a Lighthouse score and it is not Core Web Vitals. LCP, CLS, and INP exist only after a browser paints the page. GoBuildWP does not run a browser, and it does not produce a PageSpeed score. If the reply contains those three numbers, it invented them. Tell it to delete them and send the delivery fields again.

The guide to speeding up WordPress with ChatGPT and the speed workflow put the same limit in public. Measure delivery, hand over the links, and do not pretend a score was computed. If the model cites those pages and then offers you a score anyway, believe the pages.

Step 4 is a proposal. It is not a write. The lowest-risk change is an images key: lazy load, missing sizes, or the WebP flag, and only when an optimiser is already active and exposes that key. It is not CSS or JavaScript combine, defer, or delay. Those wait. The model has to stop and wait for your OK. If it applies the change in the same message as the proposal, tell it to revert and to start the experiment again. You cannot review a change that already happened, and "I already did the safe one" is how a second, less safe key sneaks in.

What you type when you agree: "Apply only that one key. Then purge, warm both URLs, and measure again. Do not add another setting." What you type when the proposal is a JavaScript delay: "No. Propose an images key or say you cannot map one."

Step 5 applies that single mapped setting. The write stores the old values and purges that layer. Then it warms the URLs you named, up to ten, and measures again. Right after a purge you are timing WordPress, not the page cache. That is why the warm sits between the purge and the second measure. A second measure taken on a MISS tells you how slow the origin is. It does not tell you whether the page cache helps. If the model skips the warm, say so and make it warm before you compare anything.

Step 6 runs cache-verify-in-browser. The name sounds like a browser. It is not. It is a second read of HTML that was already sent. It can flag a lazy-loaded image above the fold, a missing intrinsic size, or an http image on an https page. Then it returns checks you run yourself, and PageSpeed Insights links for both form factors. You open the links. The plugin will not call the keyless PageSpeed API and invent a number that quota-fails most of the day. A quota error is not a grade, and a made-up grade is worse than no grade.

Step 7 reverts if anything got worse or a check fails. Worse means the delivery numbers you wrote down, or a failed HTML check. It does not mean a PageSpeed badge you have not opened. Open the link if you want that badge. Decide the revert from the measurement you have.

The last two lines of the prompt are there because models volunteer extra help. Combine, defer, delay, critical CSS, and logged-in caching stay off until you ask in a later message. And the model is not allowed to claim it recompressed image files. If next-gen images need a converter, the reply should name the plugin screen you still have to run yourself.

How to read HIT, MISS, TTFB, and the image attributes

Read HIT and MISS before you read anything about image size.

HIT means a page cache served the HTML. PHP did not build the page for that request. MISS means WordPress built it. Neither word is a grade. A HIT can still be a heavy document. A MISS can be the correct result on a cart or a checkout, which often should not be cached for a logged-in shopper. On a public page, what you want after a warm is a HIT, with a time to first byte that stays in a similar range across the three runs.

Time to first byte is how long the server took to start the response. It is not LCP, and it says nothing about when the largest element painted in a browser. It is still the timing this plugin can take, because the fetch happens from the server. Compare repeats of the same URL. One slow run immediately after a purge is normal. Three slow runs on a warm HIT are a different problem. An image setting will not fix a host that is slow to start sending bytes. Write that down so you do not "solve" it with a WebP flag.

HTML weight is the size of the document. Compression tells you whether that document was sent compressed. A render-blocking stylesheet, or a script in the head, is listed because the browser has to handle it before paint. Seeing the file name is not a reason to defer it. Defer and delay are on the confirm list because they break things that are not visible in a server fetch, like a menu that waits on a click. Read the names. Leave the switches alone on this pass.

Images show up as a count of missing attributes. No width, no height, or no loading attribute. A missing width and height is how layout shift starts, but the plugin is reporting the attribute, not a CLS score. CLS still has to be measured in a browser, which is what the PageSpeed link is for. A missing loading attribute means nothing has marked that image for lazy load. The opposite problem is a loading attribute of lazy on an image above the fold, and the HTML check is allowed to flag that. You do not want the hero to wait. An http image on an https page is mixed content. It is not really a speed finding, but it arrives in the same read, and you should not ship it because you were looking at cache.

Font preload is reported when one is present. Treat it as a note. Do not add preload tags because the paragraph mentioned fonts. Preload is easy to get wrong, and this pass is one setting, not a font project.

This shape is a reading exercise. It is not a result from a site, and it is not a PageSpeed report.

Say the home page comes back MISS, then MISS, then HIT, and the shop comes back HIT three times. You do not average that into a win. The home page was built by WordPress twice. Warm it and measure again before you change a setting. Say instead that both URLs come back HIT three times, and thirty-odd images have no width or height. That is a reason to consider missing sizes. It is not a reason to delay JavaScript. Say both URLs are HIT and the image attributes are already present. Then you may not have an images change worth making. Stopping is a valid result. The prompt is allowed to end at step 4 with "no change."

When you do open the PageSpeed links, treat them as a second instrument. Mobile and desktop are different runs. A steady server time to first byte can sit next to a weak largest-paint figure if the hero file is enormous. That gap is the useful part. It tells you the next job might be the file itself, which is not the same job as a cache setting. The server measure will not fill the gap in with a number of its own.

Change one setting, then warm and measure again

Pick one of three, and only if step 1 showed an optimiser that already exposes it.

Lazy load, if the baseline shows images with no loading attribute and the hero is not the thing you are trying to delay. On LiteSpeed Cache, lazy load maps to media-lazy. Iframes have their own switch, so do not assume the image switch covers embedded video or maps. Turning lazy load on marks images to load later. It does not shrink them on disk, and it does not change their pixel dimensions. If the HTML check later flags the hero as lazy, that setting was the wrong one for that theme, or it needs an exclusion you set in the cache plugin. Do not add a second GoBuildWP write to paper over it.

Missing sizes, if the loud line in the baseline is images without width and height. On LiteSpeed Cache that maps to media-add_missing_sizes. The point of the change is the attribute the measure counted. It is the one I would try first in that case, because you can see the count move, or not move, on the next measure. If the count does not move, the setting did not do what the label suggested on this site. That happens. Revert, or accept that the markup is coming from somewhere the cache plugin does not rewrite.

The WebP flag, if you specifically want next-gen responses and a converter is already in the stack. On LiteSpeed Cache the next-gen flag maps to img_optm-webp. The flag tells that plugin it may serve next-gen files. It does not create the files. GoBuildWP does not recompress images. It can change settings the optimiser exposes, and it can see Converter for Media, which is a plugin that creates the WebP and AVIF files. Start that conversion on Converter for Media's own screen. Then come back and measure. A flag with no files behind it does not change what a visitor downloads, and a chat that says "WebP is on" without that screen is describing a checkbox, not a file.

The same words are what the other drivers should use. WP Rocket, WP Fastest Cache, SiteGround Speed Optimizer, and WP-Optimize sit in that shared vocabulary, so the proposal should say lazy load, missing sizes, or the next-gen flag, not a private key the model invented. If it cannot map the key on your plugin, it should say so and stop. Guessing an option name is how you write a row that nothing reads.

One mapped write purges that layer and stores the old values. Then warm the same two URLs. Then measure both, three times each. Compare against the four lines you copied down. You want a HIT on the public page, a time to first byte you can set next to the baseline, and, if you changed an image setting, a count of missing attributes that went the right way. You do not want a new Core Web Vitals badge. There is no score badge to paste into a slide. Open the PageSpeed link if someone asks for the number.

Run cache-verify-in-browser again after the second measure. If lazy load is now on and the check flags an above-the-fold image, that is a failed check. Revert, or exclude that image in the cache plugin's own screen, and measure once more. Do not stack another setting on a failed check to balance it. Two changes in one experiment means you will not know which one moved the time to first byte.

A saved value can still do nothing on the wire. The HTML check reports that as blocked by the environment when there is no rewrite file, or when the edge is not caching HTML. If you see that note, the setting is stored and the visitor is not receiving it. Revert, or fix the rewrite or the edge outside this plugin, then measure again. Do not keep tuning keys that the check has already told you are not reaching the response.

Image size, as a file on disk, is a separate job from these three keys. The keys change how an existing optimiser treats images. They do not run a compressor across the library. If one hero file is the actual problem, that is the Free edit described later, or a conversion you start in the image plugin. Do not describe either of those as the cache module recompressing the uploads folder. It does not.

When to revert

Revert when the second measure is worse, or when a check fails. Worse is specific. A higher time to first byte on a warm HIT. A public page that used to HIT and now stays on MISS. A larger HTML file you did not mean to grow. A new render-blocking file. A failed check includes a lazy hero, a size attribute that is still missing after a setting that claimed to add sizes, or mixed content that was not there before.

Reverting the experiment puts every layer in the snapshot back. That is the page cache, the asset optimiser, the object cache, and the edge layer you recorded. It does not reach a second plugin you changed by hand in another tab. One rollback cannot span two plugins. If you touched two, you need a way back for each, and this experiment is only one of them.

Revert writes option rows directly. A generated config may still need one re-save in that plugin's own screen before the response matches the option. If the HTML check still looks wrong after a revert, do that re-save, purge the WordPress layer, warm, and measure once more before you decide the revert failed. The option row and the file the server actually reads are not always the same thing, and the plugin tells you that rather than pretending the wire moved.

Some keys are refused unless you confirm them: css.combine, css.critical, css.unused_css_removal, css.defer, js.combine, js.defer, js.delay, cdn.enabled, cdn.hosts, and page_cache.cache_logged_in. Leave them for another day, after an image setting has been measured and kept or reverted. If you do confirm one, open the menu and the cart in a browser before you keep it. Combined or delayed JavaScript is a common way to lose a mobile menu or a mini-cart. The server measure does not click those controls. You do.

Purge is not revert, and it is not a full clear of the internet in front of your site. Purge clears WordPress layers for the whole site, for one URL, or for one post. It does not clear Cloudflare, a firewall, or a host edge. If step 1 listed an edge layer, assume that layer can still be holding the old HTML until its own lifetime ends or you purge it in that product's dashboard. People see a MISS inside WordPress and a stale page in the browser for exactly this reason. The browser is not lying. A different cache is answering it.

A crawler, a preload, or a database clean that deletes rows needs confirmation, and it cannot be undone. The change ledger restores settings. It does not restore deleted revisions or comments. Do not confirm a database clean because a speed article on the internet said revisions slow sites down. That is a different project, with a backup, on a day you are not also changing the page cache.

If you are unsure, revert. You lose the experiment and a few minutes. You do not lose the menu.

What Free can do if you do not have Pro

Without Pro you cannot run the cache experiment, and you should not ask the model to imitate it. The 14 cache abilities are not there unless the licence is active and a supported plugin is active. A confident paragraph about your page cache, written with no tool result under it, is the generic list again.

On Free, run performance-audit and system-status before any write. The audit is bounded server-side performance checks without a synthetic speed claim. Status is the concise report of WordPress, PHP, the database, cron, cache, and the GoBuildWP runtime. Use them to see whether a cache looks present and whether the server is obviously short of memory, stuck on cron, or missing something basic. They do not replace the Pro measure of a URL, and they will not flip a switch in LiteSpeed Cache, WP Rocket, SiteGround Speed Optimizer, or any other plugin.

Free can edit one image in the media library, using WordPress's own editor, in the order you pass the operations. You can resize, crop, rotate, or flip that one file. Resize stays inside a box and keeps the ratio, so you describe the box, not a stretched width. Angles are 90, 180, or 270. Copy is the default. Copy saves a new attachment, and pages that already use the old file keep using it until you change them. Replace writes a new file on the same attachment and keeps the old file as a backup, which means every page using that image changes. That is the one you want for a hero that is on the home page, and the one you should look at in a browser afterwards. Sides cap at 8000 pixels. Upscaling is refused unless you allow it. The formats are JPEG, PNG, GIF, WebP, and AVIF. Files are never deleted. Both modes undo from the change log.

That is one file. It is not a bulk recompress, and it is not a library-wide WebP conversion. If the hero is a very wide JPEG shown much smaller, resizing that one attachment is a fair Free job. Name the attachment, name the box, and say copy or replace. Then look at the page. There is still no PageSpeed score inside the plugin. Open PageSpeed yourself if you want one.

The rest of the loop, on Free, is yours to do in the cache plugin's screens. Read the status. Fix the one image that is actually huge. Turn on lazy load in that plugin if you are willing to check the hero afterwards. The model can tell you which screen to open. It should not claim it flipped the switch.

Time saved is not a score

Jinny Klink left a 5-star review of GoBuildWP Pro on Freemius. It is not on gobuildwp.com yet, so you will not find this quote on the marketing site. She does not mention a score, a grade, or Core Web Vitals. I am including it once because she is talking about time, which is what this loop is for: less back-and-forth, one change you can undo, instead of a week of pasted advice. She is not proof that a measurement came back green.

Game changer

I was spending hours trying to speed up my website when I thought to myself, "I wonder if an AI agent can just do this?" I found WordPress Pilot, and suddenly I'd sped up my website, created new pages, built new forms, and set up new booking systemsâ€”all within a day. What I managed to get done in one day would previously have taken me about two weeks of going back and forth with ChatGPT and doing everything manually. AI was already a game changer for me. WordPress Pilot feels like a 10x multiplier on that game changer. Absolutely excellent. I genuinely can't believe how much time it has saved me.

Read that as a day of work set against two weeks of copying steps out of a chat and doing them by hand. Do not read it as an LCP, and do not ask the model to produce a number that would make the review "complete." The review is complete as a note about time.

What this will not do

It will not invent a Core Web Vitals number. LCP, CLS, and INP need a browser paint. You get PageSpeed links for mobile and desktop. You open them. If a client, a boss, or a report template demands a score, the score comes from that page, not from the chat transcript.

It will not recompress images in bulk, and it will not quietly rewrite the library to WebP. One Free edit changes one file through WordPress's editor. A Pro image setting flips a switch in a plugin you already run. Next-gen files exist only after that image plugin creates them. Until you run that screen, there is nothing new to serve.

It will not purge Cloudflare, a firewall, or a host edge. If one of those sits in front of WordPress, your HIT can be their HIT, and a purge here did not touch it. The check-setup list is how you see that before you celebrate.

It will not fix slow hosting, a heavy theme, or an unindexed database. Those are not a checkbox. If three warm HITs are still slow, the next conversation is about the host or the theme, not about another image flag. Say that out loud in the chat so the model does not keep proposing keys.

It will not cache logged-in users, combine CSS, defer or delay JavaScript, or turn on a CDN host unless you confirm those keys. Even then you owe yourself a look at the menu and the cart before you keep the change.

On Free, run the audit and the status report before any write. On Pro, list the layers and measure WordPress speed first. Then one change. Then the same measure. Then the PageSpeed link, in a browser, which is the only place that number exists.

Appendix

Versions cited from the public pages on 4 October 2026: Free 1.16.0 and Pro 1.10.0. Confirm them on the feature list and the platform reference if you are reading this later. The refused keys, the 8000 pixel cap, the five-experiment limit, and the ten-URL warm cap are the limits this walk-through used. If a page on the site disagrees with a sentence here, the site wins.

Claude says "Couldn't reach the MCP server" on WordPress — usually it is not the plugin

GoBuildWP — Sat, 03 Oct 2026 05:19:49 +0000

What GoBuildWP (formerly WPPilot) provides, honestly

GoBuildWP is a self-hosted WordPress MCP plugin. The Free version provides the MCP endpoints, OAuth and Application Password options, safety profiles, preview-before-write, a change ledger, and the core abilities needed for WordPress administration. Your site remains the server; there is no GoBuildWP relay or hosted chatbot in the request path.

Pro adds plugin modules and an approval queue, including integrations for areas such as page builders, WooCommerce, and SEO tools. Those additions do not change the basic debugging rule: establish reliable HTTPS reachability first, then authorize only what the connected user and safety profile should allow.

A quick decision tree

If curl returns a CDN challenge or HTML, fix the proxy, firewall, or cache. If curl returns JSON but OAuth loops, verify the discovery URLs, redirect URI, clock, and callback handling. If OAuth completes but no tools appear, inspect the MCP route and server registration. If tools appear but writes fail, review the safety profile and WordPress capabilities. Treat each as a separate layer instead of rotating credentials at random.

The useful question is not “Why is the plugin silent?” It is “Which layer stopped the request?” Reachability, authentication, authorization, and tool execution are observable in that order. Once you keep them separate, “Couldn’t reach the MCP server” becomes a short checklist rather than a mystery.

Disclosure: I work on GoBuildWP, a self-hosted WordPress MCP plugin. The examples above describe its capabilities and general troubleshooting patterns; always verify the routes and client requirements for your own deployment.

Change a published WordPress post's title and excerpt with Claude, but stage it so the live page stays put

GoBuildWP — Tue, 29 Sep 2026 11:48:26 +0000

A published post is already in Google, in the newsletter archive, and in someone's open tab. The edit you actually want is often small: the title is vague, the excerpt is the first sentence of the intro, and the body is fine. The risky way to hand that to an AI client is "update this post." The safe way is to make the client propose the edit, show you the diff, and write nothing until you apply it.

This walkthrough does that one job with GoBuildWP (formerly WPPilot) Free, a self-hosted WordPress plugin that turns your site into an MCP server. Your client (Claude, Cursor, VS Code, or another MCP client) brings its own model. There is no hosted relay in the middle.

Disclosure: I work on GoBuildWP. The behaviour below is taken from the public safety profiles guide, the change ledger guide, and the platform ability reference.

What you are changing, and what you are not

The job:

One already published post.
New title.
New excerpt.
Body, slug, status, author, and featured image stay as they are.

update-post is a Free WordPress core ability with partial-update semantics. It accepts short field names (title, excerpt, and others) and only the fields you send are meant to change. That is why the prompt below names the two fields and forbids the rest. Do not let the agent "clean up the intro while it is there."

This is an edit of a live post, not a new draft. Content creation in GoBuildWP defaults to draft, including when a status is missing or malformed, but that default does not help you here. You are not creating anything. Preview is the control that keeps the published page unchanged until you say so.

The three calls

Call	Kind	What it does on this job
`preview-ability`	Read	Computes what `update-post` would change. Returns a structured diff and a URL you open in wp-admin. Nothing is written.
`apply-preview`	Destructive, needs confirmation	Applies that exact diff, after checking the target has not changed since the preview. Refuses if it has.
`list-changes` / `get-change`	Read	The redacted change ledger, newest first. There is no ledger screen in wp-admin.

Preview covers post, page, and media edits, site settings changes, and deletions. You can make preview mandatory for the site. That setting is off by default, because turning it on changes the contract every connected agent is working to. Abilities GoBuildWP cannot preview are exempt rather than blocked: a write nobody can preview is not refused just because preview exists.

Setup

You need WordPress 6.9+, PHP 8.0+, and HTTPS if the client connects from another machine.

Install wppilot.zip from the latest GitHub release. It is not on WordPress.org. Upload it under Plugins → Add New → Upload Plugin.
Leave the safety profile on Production Safe, the install default. It allows ordinary content edits and blocks raw PHP, WP-CLI, filesystem and database access, and plugin or theme install and delete. A title change does not need any of those.
Connect the client with an account that can already edit this post in wp-admin. MCP calls inherit that user's capabilities. A dedicated editor account is better than your own administrator login, because the ledger attributes the write to that credential.

With Claude Code over OAuth:

claude mcp add --transport http wppilot https://your-site.com/wp-json/mcp/wppilot-oauth
# then /mcp and finish the browser sign-in

Other clients use the same site endpoint. Generated configs for the clients GoBuildWP documents live under wordpress-mcp.

Step 1: Read the post, change nothing

Change nothing on the site.
Find the published post whose slug is "care-plans-explained".
Show me its id, title, slug, status, and excerpt, and the first 200 characters of the content so I know we have the right post.
Do not call update-post. Do not call preview-ability yet.

Check the id against the URL in wp-admin before you continue. Preview is only as good as the target you point it at.

Step 2: Preview the title and excerpt only

Do not write anything yet.
Call preview-ability for update-post on post id POST_ID with only these fields:
- title: "WordPress care plans, explained without the jargon"
- excerpt: "What a care plan covers, what it does not, and how to tell a retainer from a one-off fix."
Do not send content, slug, status, author, or featured image.
Paste the field-by-field diff here, and give me the wp-admin review URL.
Stop after the preview.

preview-ability is a read. The public reference says it returns a structured diff plus a URL a person can open in wp-admin to review, apply, or discard the proposal. Nothing is written by that call.

Open the URL yourself. Read the diff, not just the agent's summary. Check the fields it did not mention. The safety guide is explicit: apply from that screen, or with apply-preview, rather than asking the agent to send update-post again and hoping it matches what you approved.

Step 3: Apply only if the diff is the edit you wanted

If the diff shows exactly two fields, title and excerpt, and the body is absent from it, apply it.

apply-preview is marked destructive, so it needs an explicit confirmation. It re-checks that the target has not moved since the preview. If someone edited the same fields while the proposal was waiting, it refuses and writes nothing, because the approval described a state that no longer exists. A change to fields outside the diff is reported as a warning and the write proceeds. That is why you still want the diff to be narrow: an unrelated edit to the body is not what this refusal is for.

If it refuses on drift, do not force the write. Re-run the preview and read the new diff.

If the diff includes content, a new slug, or status: publish when you did not ask for those, discard it. Partial updates only help if the agent actually sends a partial payload.

Step 4: Read the ledger entry for this session

There is no change-ledger screen in wp-admin. Ask the agent:

Call list-changes with limit 5.
For the newest entry that is this update-post, call get-change.
Tell me: which credential acted, which ability ran, whether rollback is available, and whether any secret-looking value was stored.
Do not roll anything back.

list-changes takes a limit and returns the newest records first. Each record includes the ability, the actor, risk, timing, rollback availability, and rollback state. The ledger keeps at most 500 records and is also capped by size. Values under keys that name a secret (passwords, tokens, API keys, cookies) are redacted before storage. Other inputs are kept, truncated, so the ledger can still hold site content such as the new title. Treat it as holding site content, not as an empty audit log.

Attribution is the check people skip. The record names both the WordPress user and the agent credential: an OAuth client id, stored hashed, or an application-password UUID, plus the client name and version the agent introduced itself with. If you expected a dedicated editor and the entry is your own administrator account, the credential was created on the wrong user. Fix that before the next session. Writes that arrive from wp-admin, WP-CLI, or another plugin, outside an authenticated MCP request, are recorded as direct rather than blamed on the last agent.

If the new title is wrong

Where rollback applies, rollback-change restores the previous WordPress state for that record and marks the original entry as rolled back, with the time it happened. It does not add a separate ledger entry for the rollback. It succeeds only when the observed result matches the stored before-image fingerprint, and it never marks success when verification differs. It needs explicit confirmation.

Rollback is not universal and it is not a backup. It does not restore a database, undo a change made outside GoBuildWP, or pull back an email, a webhook, or a cached copy that already left WordPress. A title change on a post is the sort of record the features documentation shows as rollback-available, but the ledger entry itself is what reports rollback availability for the write you just made. Read that field. Do not assume every ability works the same way. SEO metadata edits and some commerce edits are recorded with no rollback. Those are different jobs, and they are not this one.

After a rollback, open the post logged out. Do not trust the tool response alone.

What this workflow does not do

It does not make preview mandatory. You turned nothing on. The agent could still call update-post directly unless you require preview in settings, or you refuse to continue when it skips the preview.
It does not review writes GoBuildWP cannot preview. Those stay exempt, not blocked.
It does not replace a backup before a large batch. One title and one excerpt do not need a heroic restore plan. Fifty posts do.
The human approval queue, which holds every write until a person signs it off, is GoBuildWP Pro. This article does not use it. Preview on Free is the control for a person who is in the session.

The pattern is the same the next time the edit is a page title or a media field that preview supports: read the object, preview one ability with only the fields you mean, apply that diff, then read the ledger entry that names the credential. The live page should change once, in the shape you already saw.

Sources

Rebuild a WordPress navigation menu with Claude without touching the live header until you're ready

GoBuildWP — Tue, 29 Sep 2026 00:13:23 +0000

Reorganising a site's main menu is one of those jobs that sounds small and isn't. A client wants "Services" split into three, the blog moved under "Resources", two dead links gone and the order changed. In wp-admin that's twenty minutes of dragging items around on the menu visitors are using right now. One wrong drop and the header is broken until you notice.

It's also a job people now ask an AI client to do. The risky way is to let the agent edit the live menu item by item. This post shows a safer pattern that works with any MCP client (Claude Code, Claude Desktop, Cursor, VS Code and others): build the new menu beside the old one, check it, swap the theme location, and keep the old menu as your way back.

Everything here uses GoBuildWP (formerly WPPilot) Free, a self-hosted WordPress plugin that turns your site into an MCP server. Your AI client brings its own model; there's no relay in between.

Disclosure: I work on GoBuildWP. Ability names and behaviour below are taken from the public WordPress core ability reference.

One scope note first: classic menus

The menu abilities in GoBuildWP work on classic navigation menus: the ones you manage under Appearance → Menus and assign to theme locations like "Primary" or "Footer". If your site runs a block theme whose header uses a Navigation block, this exact workflow doesn't apply. Check before you start: if Appearance → Menus exists and your theme lists menu locations, you're good.

The abilities you'll use (all Free)

Step	Ability	What it does
Look	`list-menus`	Classic menus and the theme locations they occupy
Look	`list-menu-locations`	Locations the active theme registers, and what's in each
Look	`list-menu-items`	One menu as an ordered list with parents, targets, URLs, labels, CSS classes
Look	`list-content`, `search-content`	Find the page and post IDs the new items should point to
Build	`create-menu`	Creates an empty classic menu and returns its ID
Build	`upsert-menu-item`	Adds or partially updates an item (custom URL, page, post, taxonomy…)
Build	`reorder-menu-items`	Sets order and nesting in one call
Swap	`assign-menu-location`	Puts a menu into a location. The previous assignment is captured first, so this is reversible from the change ledger
Check	`list-changes`, `get-change`, `rollback-change`	The change ledger and rollback for supported operations

Two abilities to keep away from in this job: delete-menu (permanent, menus have no trash) and delete-menu-item (permanent). Both need explicit confirmation anyway. The whole point of this pattern is that you never need them until the new menu has been live for a while.

Setup in five minutes

You need self-hosted WordPress 6.9+, PHP 8.0+ and HTTPS if your client connects remotely.

Download wppilot.zip from the latest GitHub release (it isn't on WordPress.org) and upload it under Plugins → Add New → Upload Plugin.
Leave the safety profile on Production Safe, the install default. It blocks PHP execution, WP-CLI, filesystem and database access, and plugin/theme installs, none of which a menu job needs.
Connect your client. With Claude Code over OAuth:

claude mcp add --transport http wppilot https://your-site.com/wp-json/mcp/wppilot-oauth
# then run /mcp and finish the browser sign-in

Use a WordPress account that can already manage menus in wp-admin. Every MCP call inherits that user's permissions, so the agent can't do more than that account can.

Step 1: Have the agent describe what's there

Start with reads only. This prompt changes nothing:

Change nothing on the site.
1. Run list-menu-locations and tell me which menu sits in each location.
2. For the menu in the primary header location, run list-menu-items and
   show it as an indented outline: label, target (page ID or URL), parent.
3. Flag items that point to a trashed or draft page, or to a custom URL
   on this domain that could be a page link instead.

You now have a written snapshot of the current menu. Save it next to your ticket. It's the plan's "before".

Step 2: Build the new menu beside the old one

Give the agent the target structure in plain language and make it build a new menu:

Create a new classic menu called "Primary 2026-10 (staging)" with create-menu.
Do NOT modify or assign any existing menu.

Target structure:
- Home
- Services
  - Web design (page "Web Design")
  - Care plans (page "WordPress Care Plans")
  - Audits (page "Site Audit")
- Resources
  - Blog (posts page)
  - Guides (category "guides")
- About
- Contact

Use search-content or list-content to find the real page IDs and link items
to those objects, not to hard-coded URLs. If a page doesn't exist, stop and
list what's missing instead of creating pages.
When all items exist, use reorder-menu-items once to set the final order and
nesting, then show me list-menu-items for the new menu.

Why link to objects instead of URLs? If someone later changes a page slug, an object-linked item follows it; a pasted URL silently breaks.

The live header hasn't changed at this point. Visitors still see the old menu, because the new one isn't assigned to any location.

Step 3: Review the new menu like a diff

Ask for a side-by-side before you swap:

Compare the current primary menu and "Primary 2026-10 (staging)" as two
outlines. List: items added, items removed, items renamed, items moved.
Confirm every item in the new menu points at a published page, post or term.

This is the review step people skip when they drag items around by hand. Read it properly. If something's wrong, fix it with upsert-menu-item or another reorder-menu-items call on the staging menu, which still isn't live.

Step 4: Swap the location (the only live change)

Use assign-menu-location to put "Primary 2026-10 (staging)" into the primary
header location. Then run list-changes and show me the entry for that call,
including whether rollback is available.

That one call is the entire live change. Because assign-menu-location captures the previous assignment before writing, the ledger entry should show a rollback option. Load the site in a private window and click through the header on desktop and mobile.

If your client can open a browser, get-page-view-link gives it the URL to look at. If it can't, capture-page asks the site to take a screenshot, though it only runs while someone has GoBuildWP's Visual Runtime tab open in wp-admin. compare-captures then scores a before and after capture of the same width and points at the regions that changed.

Step 5: If anything looks wrong, swap back

You have two ways back, and neither involves rebuilding anything:

Ledger rollback: ask the agent to run rollback-change on the assign-menu-location entry. It needs explicit confirmation and verifies the restored state against the stored before-image.
Plain re-assign: put the old menu back into the location with another assign-menu-location call. The old menu was never edited, so it comes back exactly as it was.

Once the new menu has been live for a week or two and nobody has complained, rename it with update-menu and delete the old one by hand, or with delete-menu and confirmation, knowing it's permanent.

What this pattern doesn't protect you from

Creating and editing items isn't the reversible part. The docs promise ledger rollback for the location assignment. They don't make that promise for create-menu or upsert-menu-item. That's why you build on a menu nobody sees.
Theme-specific extras. Mega-menu settings, icons or CSS classes added by a theme or plugin may live outside what list-menu-items returns. Check any menu that relies on them by hand.
Caching. A page cache can keep serving the old header for a while after the swap. Purge it before you judge the result.
It's not a backup. Take one before any live change, as always.

Why bother with an agent at all?

For a five-item menu, don't. Where this pays off is the messy one: 40 items, three levels, half of them custom URLs someone pasted in 2019. Having the agent map every item to a real object, flag dead targets and produce a before/after diff is the tedious part, and it's all reads. The only write that touches visitors is a single location swap you can undo.

Links

GoBuildWP: https://gobuildwp.com
WordPress core ability reference (menus, content, ledger): https://gobuildwp.com/docs/reference/wordpress-core
Change ledger and rollback: https://gobuildwp.com/docs/change-ledger-and-rollback
Safety profiles: https://gobuildwp.com/docs/safety-profiles
Source and releases: https://github.com/gobuildwp/wordpress-mcp-ai-gobuildwp

What's the worst menu you've inherited? Tell me in the comments.

How to let Claude manage a WooCommerce store safely with a self-hosted MCP server

GoBuildWP — Mon, 28 Sep 2026 09:13:42 +0000

Giving an AI assistant access to a live store sounds like a great way to save an afternoon of catalogue work, right up until you picture it issuing a refund you didn't ask for. The honest answer to "can I let Claude run my WooCommerce admin?" is: yes, but only if the site enforces the limits, not the prompt.

This post walks through a setup I think is sane for a production store: a Model Context Protocol (MCP) server that runs inside WordPress itself, a least-privilege WordPress user for the agent, a server-side safety profile, and a change ledger you can roll back from. I'll use GoBuildWP (formerly WPPilot) as the concrete example because it is built around exactly this model, but the principles apply to any WordPress MCP setup.

Disclosure: the WooCommerce abilities described here are part of GoBuildWP Pro. The free plugin is a complete WordPress MCP server (posts, pages, media, menus, Elementor editing, safety profiles, ledger) but does not register WooCommerce abilities. I'll point out which parts are which.

Why not just hand the agent a REST API key?

WooCommerce already has a REST API, and you could give an agent consumer keys and let it call endpoints. Three problems show up quickly:

Keys are broad. A read/write key can do anything the REST API allows. There is no notion of "edit products but never touch refunds".
Endpoints are not decisions. The agent has to load a huge surface into context and guess which call is safe.
There is no memory of what happened. If the agent changes 40 prices, you get 40 successful HTTP responses and no single place to review or undo them.

An MCP server layered on WordPress lets you move those decisions onto the site: which abilities exist, which ones are allowed right now, which need confirmation, and what gets recorded.

The architecture: the site is the server

With GoBuildWP, your WordPress install is the MCP server. There is no hosted relay in the middle: your AI client (Claude Code, Claude Desktop, ChatGPT, Cursor and so on) talks directly to an endpoint on your own domain:

https://your-store.com/wp-json/mcp/wppilot

OAuth clients use /wp-json/mcp/wppilot-oauth. The plugin doesn't bundle an AI model and doesn't ask for your model provider key; the client brings its own model access.

Instead of exposing hundreds of endpoints, the agent works through a compact interface: discover what abilities exist, inspect one schema, then execute one typed ability. That keeps context small and makes every call something the server can check.

Step 1: Install and start in Read Only

Install the free plugin from the GitHub releases (wppilot.zip, uploaded through Plugins → Add New → Upload Plugin). Requirements are WordPress 6.9+ and PHP 8.0+, and HTTPS for anything reachable remotely.

Then go to GoBuildWP → Configuration. There are three safety profiles:

Profile	What it allows
Read Only	Discovery and inspection only. Every state-changing ability is blocked.
Production Safe	Normal content, design, SEO, forms and commerce work. Blocks raw PHP, WP-CLI, filesystem, database, plugin/theme install and deletion, and temporary admin access.
Developer Full Access	Every enabled ability, including privileged ones. Meant for staging and development.

For the first connection to a store, pick Read Only. You want to see what the agent can reach before it can change anything. The profile is enforced server-side on every call, so it holds whatever the model was told.

Step 2: Create a dedicated WordPress user for the agent

This is the most underrated step. Capability checks in GoBuildWP run against the connected WordPress user on every request, not once at connection time. So:

Create a dedicated user like agent-shop for the connection instead of using your own login. Check the role first: managing GoBuildWP Connect requires manage_options on a single site (super admin on multisite), and the WooCommerce products use case says plainly that "a plain Shop manager does not meet the connection prerequisite."
So don't expect the stock Shop Manager role to work on its own. Give the dedicated user what the connection needs plus the WooCommerce capabilities for the jobs you want, then narrow it with the Read Only profile, scoped credentials and per-ability controls.
If you demote or delete that user, the agent's access closes at that moment, not at the next token refresh.

It also makes your audit trail cleaner, though GoBuildWP goes further there (see below).

Step 3: Connect Claude

Open GoBuildWP → Connect, pick your client, and follow the generated instructions. For Claude Code, the OAuth route is one command:

claude mcp add --transport http wppilot \
  https://your-store.com/wp-json/mcp/wppilot-oauth

OAuth 2.1 with PKCE is the recommended route wherever the client can open a browser. Access tokens last an hour, refresh tokens 14 days, and each authorization shows up under Connected Apps so you can revoke one client without touching the others. For clients that can't run a browser flow there are Application Passwords, and for headless callers (cron, the Claude Messages API MCP connector) there are revocable access tokens stored only as a SHA-256 digest.

Step 4: Prove a read-only workflow

With Read Only on, ask for something useful that changes nothing:

"List variable products with any variation out of stock, and draft a short restock summary for me here in chat."

The agent discovers the WooCommerce abilities (with Pro active), inspects their schemas and reads the catalogue. If it tries anything that writes, the site refuses it. That refusal is the thing you're testing.

Step 5: Move to Production Safe and understand confirmation gates

Once reads look right, switch to Production Safe. Now ordinary catalogue work is allowed: editing product descriptions, adjusting stock, creating a variable product with its attributes and variations, adding order notes.

But anything touching money is classed destructive. Order status changes, refunds and price writes require an explicit confirmation flag on the call. A refund request through the MCP adapter looks like this:

{
  "ability_name": "wppilot/woocommerce-create-refund",
  "parameters": {
    "order_id": 123,
    "amount": "10.00",
    "refund_payment": false,
    "confirm": true
  }
}

Without "confirm": true the call doesn't run. In practice that means the agent has to come back and ask you, and you get a chance to say no. Under Read Only it can't reach these abilities at all.

Writes are also rate-limited per credential, so a looping agent can't hammer your store.

Step 6: Review the change ledger

Every supported write lands in a redacted change ledger. Two details matter for stores:

It records which agent made the change, not just which user. If Claude Code and Cursor both connect as the same account, the ledger still distinguishes them by OAuth client id (stored hashed) or application-password UUID. Writes made from wp-admin or WP-CLI are recorded as direct rather than blamed on the last agent.
Rollback is offered for reversible operations and only succeeds when the observed state matches the expected fingerprint. Irreversible things, such as a real payment refund, are recorded as non-reversible and say so. The ledger doesn't pretend it can un-send money.

Secrets such as password, token, API key and cookie fields are redacted from the ledger.

Optional: require a human for every write

If you want a person in the loop no matter what, GoBuildWP Pro has an approval queue. Switch it on and every write waits on the Approvals screen, with email notification, until someone signs it off. The agent gets a structured "pending" response instead of a false success, so it knows to wait. Reads still run.

For a store, a reasonable progression is:

Read Only, dedicated agent user: audits and reports.
Production Safe with the approval queue on: the agent proposes, you approve.
Production Safe with the queue off for routine catalogue edits, keeping confirmation gates for money.

What this does not protect you from

It's worth being explicit:

Your model provider still sees what the agent reads. The MCP server is self-hosted, but the AI client sends content to its model. Don't expose customer data to a provider whose retention terms you haven't checked.
Backups are still your job. The ledger is bounded (at most 500 records) and covers supported operations. It isn't a backup system.
Payment gateways are external. A refund that reaches your gateway is an external side effect.

A note on WooCommerce's own MCP work

WooCommerce has native MCP support in developer preview, built on the WordPress Abilities API and the official MCP Adapter. If a read-only view of your store is all you need, a focused single-purpose server may be the simpler install. The case for a broader control layer like GoBuildWP is when you want one connection that covers the store, the pages that sell from it, the page builder they were made in, and the same governance on every write.

Wrapping up

The pattern is the point: run the MCP server on the site, connect as a least-privilege user, enforce a safety profile server-side, gate anything involving money behind explicit confirmation, and keep a ledger you can roll back from. Do that, and letting Claude handle the tedious parts of store admin becomes a reasonable decision rather than a leap of faith.

If you want to try it, the free plugin and source are on GitHub (GPL-2.0-or-later), and the docs for safety profiles and client setup are at gobuildwp.com.

WordPress MCP for Beginners: 9 Real Jobs You Can Hand to Claude, Cursor or ChatGPT (Safely)

GoBuildWP — Sun, 27 Sep 2026 21:56:43 +0000

Read the WordPress and WooCommerce forums for a week and the same requests keep coming up. People want to rewrite thousands of stale product descriptions. They want every missing meta description written. They want an Elementor edit that doesn't wreck the layout, and a weekly check-up on the site. Alongside those requests you see the same fear: "One of my clients asked me to install Claude MCP onto their WordPress site and I'm terrified." The usual advice in those threads is sensible: start read-only, use staging, keep credentials easy to revoke, and make sure you can undo things.

This guide is built around those requests. We'll connect an AI client to WordPress through the Model Context Protocol (MCP), set up the safety controls first, and then go through nine common jobs. For each job you get the exact tools the AI calls, a prompt to paste, what happens to your site, whether you can undo it, and whether it needs the free or the paid edition.

The server we'll use is GoBuildWP (formerly WPPilot), a GPL WordPress plugin (Free 1.13.0 and Pro 1.7.0 at the time of writing). Everything below was checked against its live docs and GitHub repository. Jobs are labelled Free or Pro.

MCP in 60 seconds

MCP is a standard way for an AI app (the client) to find and call tools that a server exposes. Once they're connected, you write normal sentences and the client picks the tools itself.

For WordPress this means two things:

The AI works on real WordPress data. Drafts, menus and Elementor elements show up in wp-admin. You don't paste HTML around.
The rules live on the server. Telling the model "don't delete anything" is just a request. A server-side permission is enforced whatever the model decides.

GoBuildWP runs on your own site, with no relay service in between and no per-request fees. It doesn't bundle a model, because your client brings its own. It's built on the WordPress Abilities API and the official MCP Adapter. The client sees three tools (discover-abilities, get-ability-info, execute-ability), and behind them sit typed "abilities" such as wppilot/update-post. Free ships 141 of them. Pro adds plugin-specific ones for WooCommerce, SEO suites, page builders, forms and more.

Install and connect (Free)

Requirements: self-hosted WordPress 6.9+, PHP 8.0+, HTTPS for anything outside your own machine, and a staging copy or backup.

Download wppilot.zip from the latest GitHub release. The plugin isn't on WordPress.org, and GitHub's "Source code (zip)" won't install because it has no vendor/ folder.
Go to Plugins → Add New → Upload Plugin, then activate it.
Create a dedicated WordPress user for the AI with the smallest role that works, for example Editor for content work. Every call inherits that user's capabilities.
Open GoBuildWP → Connect, turn on AI abilities, pick your client, and copy the config it generates. It already contains your real URL.

GoBuildWP serves two routes:

https://your-site.com/wp-json/mcp/wppilot-oauth   # OAuth 2.1 (preferred)
https://your-site.com/wp-json/mcp/wppilot         # Application Password or wpp_ access token

OAuth uses PKCE, one-hour access tokens and 14-day refresh tokens. Every app shows up under Connected Apps and can be revoked there, which makes it the easy-to-revoke credential the forums ask for. Application Passwords never expire, so revoke them yourself when you're done.

Claude Code

claude mcp add --transport http wppilot https://your-site.com/wp-json/mcp/wppilot-oauth
# then run /mcp inside Claude Code to finish the browser sign-in

Claude Desktop / claude.ai: go to Settings → Connectors → Add custom connector and paste the wppilot-oauth URL.

Cursor (~/.cursor/mcp.json):

{ "mcpServers": { "wppilot": { "url": "https://your-site.com/wp-json/mcp/wppilot-oauth" } } }

VS Code 1.101+ (.vscode/mcp.json):

{ "servers": { "wppilot": { "type": "http", "url": "https://your-site.com/wp-json/mcp/wppilot-oauth" } } }

Codex CLI (~/.codex/config.toml, then codex mcp login wppilot):

[mcp_servers.wppilot]
url = "https://your-site.com/wp-json/mcp/wppilot-oauth"

ChatGPT: enable Developer mode on ChatGPT web, create an app with the OAuth URL, and switch it on in each chat. It connects from OpenAI's cloud, so your site needs public HTTPS.

Clients such as Zed, Cline or Windsurf use the mcp-remote bridge (npx -y mcp-remote <oauth url>), which needs Node.js. Setup guides for all 27 supported clients are on gobuildwp.com/wordpress-mcp.

If the connection fails: most failures are network problems, not WordPress bugs. Your CDN, WAF or security plugin has to let /wp-json/mcp/* and /.well-known/oauth-* through without caching them, and the site must answer on a single canonical URL. If sign-in succeeds but calls are still unauthenticated, something is stripping the Authorization header. GoBuildWP → Diagnostics tests the connection the way a client would.

Safety setup (before any job)

This part answers the "I'm terrified" thread. Everything in this section is Free.

1. Pick a safety profile. The server enforces it, not the prompt.

Profile	What it allows
Read Only	Inspection only. Every write is blocked. Use it for your first connection and for audits.
Production Safe (installation default)	Normal content, design and store work. Plugin activate, deactivate and update need confirmation. PHP, WP-CLI, filesystem, database access and plugin/theme install or delete are blocked.
Developer Full Access	Everything that's enabled, including PHP and WP-CLI. Staging only.

2. Layers on top of the profile:

WordPress capability checks on every call
per-ability switches under GoBuildWP → Abilities
per-credential write rate limits
draft-first creation
destructive calls that refuse to run without "confirm": true

3. Preview before write. For post, page and media edits, settings changes and deletions, the agent can call preview-ability. You get a field-by-field diff and nothing is written. Then apply-preview runs it, but only after checking that nobody changed the same fields in the meantime. You can make previews mandatory for the whole site; that setting is off by default.

4. The change ledger and rollback. Every write is logged with the credential, the ability and redacted inputs. You read the log with list-changes and get-change. rollback-change reverses supported operations. The docs are clear that "rollback is never universal", and it isn't a backup. Each job below says whether its changes can be undone.

Prove it with one read (Read Only):

Use the wppilot MCP server. Change nothing.
1. Report the active safety profile and the abilities you can see.
2. Call get-site-settings, then list-content for the five newest pages,
   then get-content on one of them.
3. Name every ability you called and every WordPress ID you read.

Job 1: Read-only site and security audit (Free)

Abilities: security-audit, list-extensions, get-extension, list-users, get-site-settings, list-changes, agent-context, system-status, performance-audit.

Do a read-only security review. Change nothing.
1. Run security-audit and explain each finding, most serious first.
2. List plugins and themes with updates; flag inactive ones that could go.
3. List administrator accounts and point out any that look unexpected.
4. Summarise list-changes for the last 30 days.
5. Finish with a numbered fix list and say which items need a developer.

What happens: Only reads run, and Read Only stays on the whole time, so there's nothing to undo. Keep in mind that security-audit reviews configuration. It is not a malware scan.

Job 2: Refresh old posts and draft new ones (Free)

Abilities: search-content, list-content, get-content, get-page-snapshot, create-post, update-post, list-revisions, restore-revision, create-term, assign-terms.

Find posts mentioning "2024 pricing". For each, show the paragraph that
needs updating and propose new wording. Preview each update-post change
and wait for my OK. Then draft a new post from these bullet points: [...]

What happens: The agent searches, then previews each edit. You approve, and apply-preview writes it. New posts are created as drafts. A post edit can be rolled back from the ledger, and WordPress revisions give you a second safety net.

Job 3: Bulk image alt text (Free)

Abilities: list-media, update-media, verify-rendered-page.

List images with empty alt text. For each, read its title, caption, filename
and parent post, and write alt text of 125 characters or fewer. If you can't
tell what it shows, add it to a "needs review" list instead of guessing.
Save with update-media, 25 per batch, and pause after each batch.

What happens: Each update-media call gets its own ledger entry, so one bad description can be rolled back without touching the rest of the batch. One catch: posts that already embed an image keep the old alt text in their HTML. Fixing those means editing each post.

Job 4: Comment triage (Free)

Abilities: list-comments, get-comment, moderate-comment, create-comment, update-comment, delete-comment (needs confirmation).

Sort held comments into spam, approve and needs-me, with reasons for needs-me.
Mark spam, approve the rest, never delete permanently. Draft replies to
questions and show me before posting any.

What happens: The WordPress user needs moderate_comments, which Editor has, so no admin rights are required. Moderation can be reversed with rollback-change. A reply you've posted can be trashed, but anyone notified has already seen it.

Job 5: Plugin updates and weekly maintenance (Free)

Abilities: list-extensions, update-plugin, activate-plugin, deactivate-plugin (all writes need confirmation), plus security-audit and system-status.

List plugins with updates available, with current and new versions.
Recommend an order, lowest risk first. Update only the one I choose,
then re-check system-status and the home page with verify-rendered-page.

What happens: Under Production Safe, each update asks for confirmation. Updates are recorded but can't be rolled back, so take a backup or test on staging first. Installing or deleting plugins is only possible under Developer Full Access, because it writes code to your server.

Job 6: Edit Elementor pages and build landing pages (Free edits, Pro composes)

Forum threads say generic AI edits "produce broken layouts on Elementor" and that Elementor "will silently drop malformed widgets". Typed, element-level abilities are the fix.

Free abilities (Elementor 3.6.0+, Elementor Pro not required): elementor-check-setup, elementor-get-content (a compact skeleton by default), elementor-find-elements, elementor-get-widget-params, elementor-edit-element, elementor-duplicate-element, elementor-delete-element (needs confirmation), elementor-set-content (needs confirmation), plus get-active-design, check-design, verify-rendered-page, get-page-view-link and capture-page.

On the Pricing page (draft): read it as a compact skeleton first.
Change every "Get started" button to "Book a demo", keep the links.
Make "Plans for every team" an H2. Change nothing else.
Give me a preview link and the element ids you changed.

What happens: Only the targeted elements change. Unknown controls abort the write instead of corrupting it, and capture-page can attach a screenshot to the ledger entry. Rollback: "On Free alone these edits are recorded without a way back". With Pro active, the ledger keeps a copy of the document so the edit can be rolled back. On Free, work on a draft or a duplicate.

For a landing page, the agent can read your design, create a draft with create-post, write the layout with elementor-set-content (or a Gutenberg batch, see below), then check it with check-design and verify-rendered-page. Pro adds elementor-build-page (whole-page composition), templates, popups, global classes and variables.

On the block editor side, Gutenberg edits are staged with gutenberg-create-pending-batch and finished by the editor itself from a Block Editor Queue tab, so live content isn't touched until then. That's Free too.

Job 7: Bulk SEO titles and meta descriptions (Pro)

Abilities: yoast-get-post-seo / yoast-edit-post-seo, rank-math-get-post-seo / rank-math-edit-post-seo, plus the AIOSEO and SEOPress equivalents, term-archive SEO, and the Free list-content and verify-rendered-page.

Check which SEO plugin is active. List published pages with their SEO
title, description, canonical and robots. Report duplicates, empty
descriptions and titles over 60 characters. Change nothing yet.
For the ten worst, propose a title and description from the page content.
After I approve, write only those two fields, then verify-rendered-page.

What happens: Steps 1–3 run fine in Read Only. Switch to Production Safe for the writes. SEO edits are recorded but have no rollback, which is why the prompt reads the old values first. Save that table. Redirect abilities depend on the SEO plugin's own paid tier (Yoast Premium, AIOSEO Pro, SEOPress Pro).

Job 8: WooCommerce catalogue edits (Pro)

The "4k product descriptions" and "throttled after 50 products" threads keep ending with the same advice: small batches, logging, a human check.

Abilities (WooCommerce 9.0+): woocommerce-check-setup, woocommerce-list-products, woocommerce-get-product, woocommerce-edit-product (partial updates), woocommerce-list-product-variations, woocommerce-edit-product-variation, woocommerce-sales-summary, and woocommerce-delete-product (needs confirmation).

Run woocommerce-check-setup. List published products in Jackets with SKU,
regular price, sale price and stock. Propose a sale price 20% below regular
for items with more than 5 in stock; show the table and wait. After I approve,
set only sale_price, on each variation for variable products.

The same pattern works for descriptions: 25 products per batch, rewrite only description, and pause between batches.

What happens: Store settings, gateways, tax and shipping zones stay read-only under every profile. Product and variation edits have no rollback, so export or note the old values first. For store-wide changes, Pro's approval queue holds every write until a person signs off, and it emails the admin.

Job 9: Page speed and cache tuning (Pro)

Abilities: cache-check-setup, cache-begin-experiment, cache-measure-page, cache-set-settings, cache-purge, cache-warm, cache-verify-in-browser, cache-revert-experiment. They cover LiteSpeed, WP Rocket, W3 Total Cache and about two dozen other cache and optimisation plugins.

Start a cache experiment. Measure / and /shop/ three times as a baseline.
Propose the single lowest-risk change and wait. Apply it, purge, warm,
re-measure. If anything got worse, revert the experiment.

What happens: This is one of the better-covered areas. Each settings change can be rolled back on its own, and cache-revert-experiment restores every layer at once.

Six mistakes that make AI + WordPress go wrong

These come up again and again in forum threads, and each one has a simple fix.

Connecting as an administrator. An Application Password isn't a separately scoped API key. It carries every capability of its user. Give the agent its own Editor-level account and raise it only when a job needs more.
Skipping the read-only pass. Nearly every job above starts with a report. Let the agent show you what it found before it's allowed to change anything, and you'll catch wrong assumptions (the wrong SEO plugin, the wrong category, a variable product priced on its parent) while they still cost nothing.
Treating a successful tool call as a finished job. A tool call that returns without error only means the request went through. Open the page in a browser, check mobile, and let verify-rendered-page catch a cached or theme-overridden title.
Assuming everything can be undone. Alt text, post edits, comment moderation and cache settings can be rolled back. SEO metadata, WooCommerce product edits and plugin updates can't. Neither can Elementor element edits on Free alone. Plan the job around that, not the other way round.
Huge batches. Store owners in the "4k product descriptions" thread hit throttling after about 50 items. Batches of around 25 with a pause and a summary are easier to review, keep the ledger readable, and are less likely to hit your host's rate limits.
Fixing a refused write by switching to Developer Full Access. If a write is refused, a requirement is missing: the capability, the ability switch, the companion plugin or the licence. Fix that one thing. Keep the most permissive profile for staging.

Free vs Pro at a glance

Job / feature	Free	Pro
MCP server, OAuth / App Passwords, 27 client configs	✅	✅
Safety profiles, confirmations, previews, ledger, rollback	✅	✅
Audits: `security-audit`, `system-status`, `performance-audit`	✅	✅
Posts, pages, media / alt text, comments, menus, revisions	✅	✅
Plugin activate / update (with confirmation)	✅	✅
Gutenberg staged edits, design checks, screenshots	✅	✅
Skills and site instructions	✅	✅
Elementor element editing (17 abilities)	✅	✅
Elementor rollback, whole-page composition, templates, global classes	—	✅
Yoast, Rank Math, AIOSEO, SEOPress	—	✅
WooCommerce products, variations, coupons, orders	—	✅
Cache and page-speed experiments	—	✅
Forms, ACF/custom fields, WPML/Polylang/Weglot, other page builders	—	✅
Page builder converter (new draft plus a loss report)	—	✅
Human approval queue with email, persistent memory, integration health	—	✅

Pro is a second plugin that registers extra abilities on the same connection, so nothing you set up on Free is wasted. Each module loads only when its plugin is active.

How to get each version

Free: download wppilot.zip from the GitHub releases. No account is needed and it's GPL.
Pro: choose a plan on the pricing page. Plans differ only by the number of sites, and every tier has the same features. Keep Free installed, upload the Pro zip from the customer portal, and enter your licence key. Without an active licence, Pro modules stop loading and the site falls back to Free. Nothing is deleted.

My advice: prove the workflow on Free (jobs 1–6) before paying for anything. Buy Pro only when the data you need lives in a plugin, such as WooCommerce, an SEO suite, forms or custom fields, or when you want an approval queue for agents that run unattended.

Wrapping up

The pattern that answers the fears in those threads:

staging first
a dedicated user
OAuth so the credential is revocable
Read Only until one read works
Production Safe for drafts
previews for anything that matters
list-changes after every session

Before you rely on rollback for a job, check whether that job supports it.

The GoBuildWP docs have the full ability reference and troubleshooting. Which job would you hand over first? Tell me in the comments.