This week an AI agent made dozens of live edits to this site — rewriting pages, fixing dead links, deploying PHP snippets, correcting published posts — through the WordPress REST API. No staging site. Straight to production, verified after every change.
That only works because every edit follows the same five-step protocol. It lives in this repo as docs/AI_LIVE_WORDPRESS_UPDATE_WORKFLOW.md and scripts/lib/wp-rest-deploy.mjs. This post is the honest version of it.
The protocol
- Back up first. Every script that touches live content writes the pre-change HTML to private-backups/ before it sends a single POST. Not “trust the revisions system” — a literal file on disk, timestamped, that can be restored by hand.
- Dry run. Scripts that transform content run against fetched data first and print exactly what would change. The diff is reviewed before –apply is passed.
- Apply through the API. Application-password auth, scoped REST routes, one object per call. No SQL, no admin screens.
- Verify the live result. Fetch the rendered page — not the stored field — and assert on real output. “The API returned 200” is not verification. The page HTML containing the new marker is.
- Document. What changed, why, where the backup lives, how to roll back. The next agent (or the owner at 2am) should be able to answer “what did you do to my site” in one read.
The step everyone skips
Verification against *rendered* output, not stored output. WordPress filters content on the way out — a snippet can be “active” in the database and broken on the page. Earlier this week a stored snippet source diffed clean and the live page was still wrong; the fix only showed up because the check fetched /now/ and looked for the marker string.
That is the whole insight, really. Trust the rendered page. The database lies politely.
What the protocol caught this week
Real examples, all prevented from shipping broken:
- A regex that double-wrote href= into 530 links — caught by fetching a live page and finding the literal broken markup, then fixed and re-verified
- A hero image preloaded with the wrong URL — found by checking response codes on the link header, not the config
- Content changes that saved fine but rendered stale — caching layer was serving the old page; the verify step saw it
The rollback reality
Every backup file is a restore point, but the honest caveat: a bad snippet can break wp-admin before you can reach the deactivate button. That is why PHP snippets carry a versioned marker comment and are written to be surgically removable — delete the marker block, the rest of the snippet still works. The deployment runbook documents this, including the nuclear option (rename the snippet’s file via FTP if admin is dead).
Where it still needs a human
Content approval. The agent drafts, the owner decides what ships — especially anything touching product identity, pricing, or lore canon. The protocol makes the mechanics safe. Judgment is still a person.
Keep reading
- Jester King Prime — the AI agent project
- JKP multi-agent mode: 3 agents, one refactor
- JKP debugged a memory leak across two projects
- What I am working on now
Agree, disagree, or caught something off? The comment form is below — I read all of them.
