Connect AI to WordPress. Start with a useful first task.

Reading the answer to the first task

The first task above is built so that each line of the answer tests a different part of the connection. A profile name proves the client reached GoBuildWP and not some other server. The ability list proves discovery works for this user. The site URL and locale prove the right site answered, which matters more than it sounds when staging and production share a database. The page IDs prove reads go through, and you can open one in wp-admin to check it.

Be suspicious of an answer that describes your site in general terms without ability names or IDs. That usually means the client never called the server and answered from the conversation instead. Ask it to repeat step 2 and quote the ability names exactly; a client with a working connection can, while one without may say it has no such tools or may answer from general knowledge again.

If the connection fails, run the doctor before changing settings

A failed connection is often caused by something between the client and the site rather than by GoBuildWP or the AI client. GoBuildWP's troubleshooting screen in wp-admin runs a set of checks from the site itself and gives a pass, fail or skip for each, with a suggested fix. They cover whether AI Abilities are on and the MCP endpoints registered, whether the endpoint answers with and without credentials, whether the Authorization header reaches PHP, whether OAuth discovery, metadata and client registration work, whether home and site URLs agree on HTTPS, the server clock, the permalink structure, and whether a CDN, firewall, hosting bot filter or security plugin answered instead of WordPress.

Two of the failures it can find, a stripped Authorization header and a host-level bot filter, are fixed in the host or CDN settings, not in the AI client, so changing client settings will not help with either. Once a client is connected, the connection-doctor ability runs similar checks on request, which helps when a working connection later starts failing.

Your second session: one write, then undo it

Once the read works, prove the recovery path before you rely on it. Switch the profile to Production Safe, then ask: "Create a draft page called Connection test with one paragraph. Then list your recent changes, show me the entry for that page, and roll it back." A good session ends with the draft gone and a ledger entry that says it was rolled back, using create-post, list-changes and rollback-change. If the rollback is refused, read the reason before doing real work; it tells you what this site can and cannot reverse.

Moving the connection from staging to production

A connection set up on staging does not carry over to the live site, and that is deliberate. GoBuildWP is locked to the domain set on its settings screen, so a staging database copied to production, or the reverse, does not start answering agents for the wrong site. On production, install and activate the plugin, set its domain, choose the safety profile again, and connect the client as a new server entry with its own sign-in. Give the two entries clearly different names in your AI client, such as site-staging and site-live, so a prompt is less likely to reach the wrong one by accident. Check which entry a session is using before you approve a write.

Keeping GoBuildWP Free updated

The free plugin checks the GoBuildWP website for new releases and offers them in the normal WordPress Plugins screen, so updating works like any other plugin even though the zip came from GitHub. Read the changelog before updating a production site, and update staging first if an agent runs routines on the site. If you later add GoBuildWP Pro, it installs beside Free rather than replacing it; both need to stay current together.