Publishing to WordPress

Publishing takes a reviewed draft from Content Studio to a connected WordPress site. RankX AI creates the post, verifies the write by reading the object back, and preserves anything the converter could not map rather than dropping it.

Nothing publishes itself. A draft becomes a live page only when a person asks for it, and the write shows you exactly what it will do first.

Before you publish

Three checks, in order, and the first one saves the most time:

Can this page be written at all? RankX AI probes what your site supports and reports whether each content type is editable, whether SEO fields are writable and whether a page builder is in use. Ask for that first; everything below reads differently once you know.

Is the draft reviewed? The quality and GEO gates tell you what to fix, and they are cheaper to act on before the page exists. See content quality scores.

Is the SEO metadata writable on this site? It depends entirely on your SEO plugin, and if it is not, RankX AI tells you which case you are in and how to fix it rather than reporting a flat no. See the WordPress integration.

What publishing does

It creates a draft by default. Publishing straight to live is possible and it is something you ask for explicitly, not the default behaviour.

It sets what you give it in one call: title, body, excerpt, slug, categories, tags and featured image. Doing that in one write is better than creating and then patching, because each write is a separate change to a live site.

It converts the body faithfully. Canonical block markup is passed through untouched. Plain semantic HTML is converted to blocks. Anything the converter cannot map is preserved verbatim in a raw HTML block and reported, never dropped with a warning. That last behaviour was a defect once and is now a guarantee.

It verifies by reading the object back, not by a success response. Plugins that return success while persisting nothing are common enough that a status code proves nothing. A write RankX AI cannot confirm is reported as unverified rather than as success.

Publishing twice by accident

The one destructive mistake available here, and it has a guard.

Pass an idempotency key and a repeat of the same call returns the original post, creating nothing. Without one, calling twice creates two posts and there is no duplicate detection to save you.

So: if you are driving publishing from a script or an assistant and you are ever unsure whether a call landed, do not retry blindly. List the content and look.

Updating an existing page

Different tool, different risk, and getting this wrong is the other expensive mistake.

Prefer a targeted patch for any edit to an existing page. It changes exact text inside existing blocks and nothing else, so it is safe on a long page and far cheaper than resending the whole body. If any of its edits fails to match, nothing is written at all.

A whole-body update replaces the body. That makes it unsafe after a truncated read: a very long body comes back truncated and says so, and sending that back would delete the part you did not see.

Adding, moving or removing a whole block is a third operation, with a free outline action that lists every block first. A text patch cannot do it and refuses rather than trying.

Pages that cannot be written

RankX AI refuses rather than damaging, and there are three tiers:

An unrecognised builder is treated as the most restrictive tier deliberately, so the guard keeps working for a builder RankX AI has never seen.

Builder editing is currently switched off in production, so block-based builder pages are read-only for body edits too for now.

After the write

A verified write means RankX AI confirmed the change in the database through the REST API. It does not mean your visitors see it yet: a page cache in front of your site can serve the old version, and RankX AI appends a note saying exactly that to every successful content and SEO write.

If a write reports as unverified, check the object in wp-admin. It may have landed and been unreadable behind a cache, or the plugin may have accepted and discarded it, which is the case this check exists to catch.

Driving this from an assistant

"Describe my connected WordPress site. Then publish content item X as a draft, with its meta title and description, and show me the dry run first."

Every write dry-runs by default, and the dry run runs the identical pipeline as the real write, so its warnings are the warnings the write will produce. See the WordPress tool reference.

Where to go next

• The WordPress integration, for connecting and for the SEO plugin detail.
• Generating articles, for what gets published.
• Troubleshooting connections, when a write is refused.