Setting up an AI SEO agent comes down to five concrete steps: create a scoped WordPress account instead of using an administrator login, generate an application password from that account, register every custom meta field you plan to write before you try to write it, write your publishing code so post content never passes through shell string interpolation, and verify every publish against the live rendered page, not just the API response. Skip any one of these and the failure is usually quiet – a field that silently doesn’t save, or a page that looks fine in an API response and broken in a browser.
This site runs exactly that setup daily, publishing through a public operating log rather than a private one. The steps below, and the two failures further down, are pulled from that log – not written up in the abstract.
How it actually works, concretely
The account layer comes first. WordPress core has shipped Application Passwords since version 5.6: 24-character credentials generated from a user’s profile page, sent over HTTPS with ordinary HTTP Basic Auth, and kept separate from that user’s real login password. The detail that matters for a checklist is that a password inherits the full role of whichever account generated it – there’s no scoping on the password itself. This site runs its agent from a dedicated Editor-role account rather than an Administrator account, a setup detailed in this site’s own application-passwords guide. The tradeoff is explicit and documented, not assumed: an Editor-role password can create, update, and publish posts and their SEO meta, but it cannot purge a plugin’s cache or manage users, because those actions require manage_options. What an agent can and cannot touch under a given role is worth writing down before the first publish, not discovered by trial and error – see this site’s breakdown of agent permissions for the fuller list.
Next is the write path itself. Custom fields, including SEO plugin meta, don’t appear on the REST API automatically. WordPress core’s register_post_meta() function needs show_in_rest set to true for a given key before that key becomes readable and writable through the standard meta object on /wp/v2/posts. Skip the registration step and the API does not throw an error – it just silently drops the field, which is the single most common reason a “successful” write leaves a value unchanged. The full mechanics of this, along with the other REST primitives an agent needs (context parameters, verifying writes by re-reading with context=edit rather than trusting a rendered field), are covered in this site’s REST API primitives piece.
Networking is the third layer, and it is easy to skip because it rarely shows up in a checklist written from a demo environment rather than a live one. A bare HTTP client with no custom User-Agent header – Python’s standard library urllib, unmodified – has drawn an intermittent HTTP 403 from this site’s own Cloudflare-backed firewall. Sending a browser-style User-Agent header, or using a tool like curl that sets one by default, avoids the block. This isn’t a one-off: the same missing-header gap turned up again on a separate code path (an internal-link crawler, not the publishing client) months later, and setting an explicit User-Agent on that crawl produced zero blocks across a 72-page run. Any agent making direct HTTP calls against a real, firewalled site should assume it needs an identifying header from day one, not after the first unexplained 403.
What this site does, and what it refuses to do
The agent drafts, optimizes, and publishes content, sets SEO meta fields, and monitors its own output against a public log. It does not use an Administrator-role credential for routine publishing, does not write post content through raw shell string interpolation, and does not treat an HTTP 200 from a write request as proof the value is correct – every write gets re-read and compared against the raw stored value before it counts as done. Those refusals are not caution for its own sake; each one maps to a specific failure this site has already had, which is the point of a checklist built from a live operating log instead of best practices written in the abstract.
Failure modes observed in production
Two incidents from this site’s history are worth naming exactly, because neither is a WordPress bug – both are expected behavior that looks like a bug the first time it happens.
The first is a rendering failure, not a data failure. One published post ended up with eighteen literal, unparsed Gutenberg block comments visible as garbage text on the live page – strings like a backslash-escaped block-opening tag that WordPress could not parse as a real HTML comment. The cause was shell interpolation: post content passed through a shell command where an exclamation mark inside a Gutenberg comment got backslash-escaped before it ever reached WordPress. An API-level scan of the saved content passed cleanly, because the escaped text was exactly what got saved – the page still rendered broken in a browser. The fix has two parts: never send post content through shell interpolation where a character like ! can be history-escaped, and treat a passing API response as necessary but not sufficient. Publish verification has to fetch the live rendered HTML and confirm there’s no literal block-comment text or backslash-escaped character visible on the page, not stop at a 200 status code and a title match.
The second is a formatting failure, not a technical one. A batch of seven posts on this site once opened with a visible “In short:” label inside what was supposed to read as a natural opening paragraph, and because no custom excerpt had been set on any of them, WordPress’s automatic excerpt pulled that same label text into every listing page. Readers saw what looked like an internal instruction to a writer, not body copy. All seven were correct in every SEO meta field – title, description, focus keyword – and still visibly wrong on the page itself. The rule that followed applies to any agent generating body copy on a template: article bodies should contain only reader-facing prose, never label text like “Title:” or “In short:”, and the excerpt field should always be set explicitly to a clean one or two sentence summary rather than left for WordPress to auto-generate from the first paragraph.
When a human must take over
Three situations on this site route to a person rather than getting resolved by the agent itself. First, anything that needs a permission the scoped account doesn’t have – the sitemap-cache purge that requires manage_options is the recurring example, logged as a known, still-open gap rather than silently worked around with broader credentials. Second, any factual claim that can’t be verified against a live source at draft time gets dropped, not guessed – if that means a section of a checklist has to stay thinner than planned, it stays thinner. Third, judgment calls about voice, tone, or whether a claim is being stated more strongly than the evidence supports go to a human editor pass before publish, following the same human-in-the-loop pattern described in more detail here. An agent that never hands anything back to a person is either operating in a narrower scope than this one, or it’s making calls it shouldn’t.
Frequently asked questions
What’s the minimum WordPress setup an AI SEO agent needs before its first publish?
A dedicated Editor-role account (not Administrator), an application password generated from that account’s profile, and every custom meta field it will write registered with show_in_rest set to true. Those three cover authentication, scope, and the write path; networking and verification steps come after.
Why would a WordPress REST API write succeed but the value never actually change?
The most common cause is an unregistered meta key – WordPress accepts the write request without error but silently drops any field that hasn’t been registered with register_post_meta() and show_in_rest: true. Re-reading the field with context=edit after every write catches this before it becomes a pattern.
Why did a published page render broken Gutenberg block comments as visible text?
Almost always shell interpolation: an exclamation mark inside a block comment gets backslash-escaped by the shell before the content reaches WordPress, and WordPress cannot parse the escaped version as a real comment. Passing content via a file rather than an inline shell string, and fetching the live rendered page (not just the API response) after every publish, catches this.
Does an AI SEO agent need an administrator-level WordPress account?
No. An Editor-role account is enough to create, update, and publish posts along with their SEO meta fields. Reserve Administrator-level credentials for the small number of actions, like plugin cache management, that specifically require manage_options, and treat anything needing that permission as a task for a human.
Leave a Reply