WordPress
Connect WordPress to RankX AI with an Application Password, and understand what is writable on your site, what is refused, and why every write is read back.
RankX AI connects to WordPress over the site's own REST API using a WordPress Application Password, which you create in your WordPress profile and paste into RankX AI. Once connected, RankX AI can read your content, propose changes, and apply them with every write verified by reading the object back. Nothing is applied without a dry run first.
Before you connect
You need three things:
- A WordPress site reachable over HTTPS with the REST API enabled. It is enabled by default; some security plugins disable it.
- An account on that site with the capabilities you want RankX AI to have. RankX AI acts as that user and can never do more than that user could.
- Application Passwords available. They ship with WordPress and are on by default, but some hardening plugins switch them off.
Creating the Application Password
Open your WordPress profile
In wp-admin, go to Users, then your own profile. Application Passwords are per user, not per site, so create it on the account you want RankX AI to act as.
Scroll to Application Passwords
Give it a name you will recognise later, such as RankX AI. The name is only a
label for you; revoking it later is how you disconnect.
Copy the generated password immediately
WordPress shows it once, in groups separated by spaces. Copy the whole thing including the spaces. If you lose it, revoke that entry and create another; there is no way to see it again.
Paste it into RankX AI
In RankX AI, open the Website's settings and its Integrations section. You need three fields: the site URL, the WordPress username (not the email address), and the Application Password.
Let RankX AI describe the site
RankX AI immediately probes what your site actually supports: which content types exist and are editable, which taxonomies exist, whether SEO fields are writable, whether WooCommerce is present, and whether a page builder is in use.
This probe is the reason nothing later has to guess. A WordPress site only exposes what its plugins and the connected account allow, so nothing about it can be assumed.
What RankX AI can do once connected
| Area | What it does |
|---|---|
| Content | List, read and create posts, pages and custom types. Update title, body, excerpt, slug, categories, tags and featured image |
| Targeted edits | Change specific text inside an existing page without rewriting the rest of it |
| Blocks | Add, place or remove whole blocks, with a free outline action that lists every block first |
| SEO metadata | Set the SEO title and meta description, where your plugin exposes them |
| Media | List images, upload new ones, and set alt text, caption and title |
| Taxonomies | List and create categories, tags and custom terms |
| Bulk | Apply one change across an explicit list of ids, dry run first |
| Site settings | Read settings, menus, users, comments, widgets, templates, plugins and themes. Change a small set of site settings and moderate comments |
| Revisions | List a page's WordPress revisions, which is what an edit can be rolled back to |
Every one of those is also an MCP tool, and in practice that is how most of it gets used: you ask an assistant, it dry runs, you look, it applies.
The four rules, and why each exists
1. Every write is verified by reading the object back. RankX AI writes, then re-reads the object and compares. A write it cannot confirm is reported as unverified, never as success. This exists because plugins that return HTTP 200 while persisting nothing are common, and a status code proves nothing on this platform.
The read-back deliberately bypasses your page cache, without which a successful write reports as failed on most managed hosts.
2. Every write can be refused before it is attempted. RankX AI checks whether a page's body can be rewritten at all before offering to rewrite it, and reports that on every listing row rather than only on failure.
3. Nothing you send is discarded. A body the converter cannot map to native blocks is preserved verbatim in a raw HTML block and reported. It used to be dropped with a warning; that was a defect and it is closed.
4. Every write defaults to a dry run. The dry run runs the identical conversion pipeline as the real write, so the warnings it produces are the warnings the write will produce. Applying is a second, explicit call.
Page builders: three tiers, and two are limited
Page builders store content in different places, and where a builder stores it decides what is possible. RankX AI classifies every page into one of three tiers and tells you which:
| The page is | Where its content lives | What RankX AI can do |
|---|---|---|
| Plain Gutenberg | The page body, core blocks | Replace the whole body, or patch specific text |
| A block-based builder | The page body, in the builder's own block namespace | Targeted text patches only, and only with builder editing explicitly allowed |
| A meta-based builder | Post meta rather than the page body | No body edit is possible by any tool. Every attempt is refused |
Elementor, Divi and WPBakery are the common meta-based case. A page built with one of them is listed as not writable and refuses a body write, and there is no override from MCP. That is a guarantee rather than a limitation to work around: the alternative is a page that keeps every word and silently loses its layout.
An unrecognised builder namespace is classified as meta-based rather than plain, deliberately. Refusing by shape rather than by name keeps the guard working for a builder RankX AI has never seen.
Builder editing is currently switched off in production. The code is built and tested, and enabling it needs a human to confirm on a real patched builder page that WordPress raises no block-validation errors afterwards. Until then, block-based builder pages are read-only for body edits too.
SEO metadata: it depends on your plugin, and the answer is actionable
Whether RankX AI can write your SEO title and meta description depends entirely on how your SEO plugin stores them and whether it exposes them over the REST API.
| Plugin | Writable over the REST API? |
|---|---|
| Yoast | Partially, and it varies per content type. Measured registered on posts and not on pages on a real site |
| Rank Math | Not by default, because its fields are not exposed to the API. Exposing them makes them fully writable |
| SEOPress | Same as Rank Math |
| All in One SEO | No. It stores metadata in its own database tables rather than in post meta, so a write returns success and persists nothing. RankX AI refuses rather than appearing to succeed |
If your plugin's fields are not exposed, RankX AI does not simply report a flat "cannot write". It tells you which of the possible reasons applies, and where the fix is a small registration snippet it gives you that snippet with your site's actual field names in it, in the form that will parse wherever you paste it.
The remedy travels with the refusal, on the tool that hit the wall, rather than sitting on a different screen. That was learned the hard way: the caller who hit the wall was not the caller who had been shown the door.
Two things the snippet deliberately leaves out, and both are safety rather than oversight. It does not expose the robots field, because that field can be stored as an array and declaring the wrong type can stop a post opening in the editor at all. And it does not expose the focus keyword, because making a field readable over the API makes it publicly readable, and for an agency that would publish every page's target keyword to anyone who asks.
After a successful write
A verified write means RankX AI confirmed the change in the database, through the REST API. That is the signal that catches a plugin returning 200 while persisting nothing, and it is the right one.
It does not mean your visitors see the change yet. A page cache in front of your site can serve the old version for as long as its own rules say, and RankX AI appends a note saying exactly that to every successful content or SEO write rather than letting you discover it on the live URL.
Disconnecting
Revoke the Application Password in your WordPress profile. That is the whole disconnection: RankX AI holds no other credential for your site, and every subsequent call fails cleanly.
Removing the connection inside RankX AI is worth doing too, so the Website stops offering publishing actions that can no longer work.
Where to go next
- WooCommerce, which uses the same connection.
- The WordPress MCP tools, for driving all of this from an assistant.
- Publishing to WordPress, for the content workflow.
- Troubleshooting connections, when something stops answering.
Integrations
What RankX AI connects to, what each connection unlocks, and the rules every write obeys. Includes the two things RankX AI deliberately will not do.
Troubleshooting connections
What to do when a WordPress or Google connection stops answering in RankX AI. Symptom first, with the difference between a refusal and a zero.