Skip to content
RankX AI
RankX AI Docs
Integrations

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.

RankX AI connects to two kinds of system. WordPress and WooCommerce are read and write: RankX AI can read your content, propose changes and apply them, with every write verified by reading the object back. Google Search Console and Google Analytics are read-only, and they feed the Traffic section.

Everything else runs on RankX AI's own measurement, so a Website with no integrations at all still gets AI visibility, rank tracking, AI Shopping, audits and AI Readiness.

What each connection unlocks

ConnectionDirectionWhat it gives you
WordPressRead and writePublishing drafts, updating pages, SEO metadata, media and alt text, taxonomies, and applying fixes from the Tasks board
WooCommerceRead and write, narrowlyProduct listings, thin-description detection, and description and SEO rewrites
Google Search ConsoleRead onlyClicks, impressions, position and index coverage in the Traffic section
Google AnalyticsRead onlySessions, page views, landing pages and realtime visitors

The rules every write obeys

WordPress and WooCommerce are the only places RankX AI changes something outside itself, so the guarantees are worth reading before you connect.

Every write is verified by reading the object back and comparing it, never by a 2xx 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, never as success.

Every write can be refused before it is attempted. Pages built by a page builder that stores content outside the page body are listed as not writable, and a body write to one is refused rather than attempted and half-applied. There is no override for that from the MCP server, ever.

Nothing you send is discarded. A body the converter cannot map to native blocks is preserved verbatim in a raw HTML block and reported, rather than dropped with a warning.

Every write defaults to a dry run. You get the exact before and after first, and applying it is a second, explicit call.

What RankX AI deliberately will not do

These are permanent limits rather than a roadmap, and knowing them before you buy is better than discovering them mid-retainer:

  • No user writes at all. RankX AI cannot create, change or delete a WordPress user, and cannot issue an application password.
  • No plugin or theme install, activation or update. It can read what is installed and nothing more.
  • No redirects. The common SEO plugins either expose no redirect route at all or expose a write that cannot be verified, and RankX AI does not ship an unverifiable write. It reports this with the plugin named rather than failing quietly.
  • No social metadata. Open Graph and Twitter fields cannot be set on any site and the attempt is refused.
  • No order, customer or refund writes in WooCommerce. Those are reads only, and there is no write function to call.
  • No permanent deletion. Removing a post moves it to the trash, where you can restore it. There is no flag that changes this.

Google Search Console and Google Analytics

Both connections are read-only, authorised with OAuth, and scoped to reading: Search Console performance and index data, and Analytics traffic data. RankX AI never writes to either.

Two behaviours matter more than the setup:

Search Console publishes on a two to three day delay at source. The last day or two being absent is a healthy connection reporting honestly, and RankX AI marks those days provisional rather than plotting a decline.

Both refuse rather than reporting zero. A connection is in one of four states and only one of them yields figures. See why traffic data is missing for all four, and troubleshooting connections for what to do about each.

Dedicated setup pages for Google Search Console and Google Analytics are not published yet. They are written the day RankX AI's Google consent screen is published, because until then a connection has to be reauthorised on a short cycle, and documenting the setup without saying so would be a promise the product cannot keep. The connections themselves work, the Traffic section is documented, and the four availability states above are correct regardless.

Driving integrations from an assistant

Everything on this page is also reachable over the MCP server, which is how most of it is used in practice: describing a site, listing content, patching a page, uploading media with alt text, and reading Search Console and Analytics.

The MCP surface carries the same rules, and adds one. WordPress tools sit behind their own scopes rather than the general write scope, so a token issued before those tools existed reaches none of them. Scopes are fixed when a token is issued, so the alternative would have granted a capability nobody agreed to and which could not be withdrawn. See MCP authentication.

Where to go next