Troubleshooting connections

Start by reading what RankX AI actually said. Every unavailable state in the product names its own cause and its own remedy, because a connection that is not working and a connection reporting genuine zeros look identical otherwise. A refusal means RankX AI declined to answer; a zero means it answered and the answer was none.

Find your symptom below.

Google: "no data" on a Traffic screen

RankX AI classifies a Google connection into four states, and only the last one yields figures.

In the first three RankX AI refuses and says which state you are in. It never prints a zero, because "no traffic" and "we cannot see your traffic" are different facts and only one of them is about your website.

Google: the last day or two is missing

That is correct and it is Google's delay, not RankX AI's sync. Search Console publishes clicks and impressions on a two to three day delay at source. A healthy connection legitimately has nothing for yesterday.

RankX AI marks the most recent days provisional and counts them separately, so a trend never renders those days as a decline. If you are quoting a figure from the last few days, quote it as provisional; it will rise.

Google: connected, but no property is selected

A connection can be healthy while pointing at nothing. RankX AI reports this as its own state rather than letting it look like "wait for the sync", because waiting will never fix it. Open the Website's Integrations settings and choose the property or site.

Google: it worked, then stopped after about a week

If a Google connection needs reauthorising on a short cycle, that is a known current limitation on RankX AI's side rather than something wrong with your account. Reconnecting restores the data, and no history is lost.

This is also why RankX AI does not yet publish dedicated setup pages for Search Console and Analytics: documenting a connection as persistent while it is not would be a promise the product cannot keep today. The connections work and the Traffic section is documented in full.

WordPress: the connection is refused at setup

Work through these in order, because each is more common than the one after it:

1. Use the username, not the email address. WordPress Application Passwords authenticate against the username.
2. Keep the spaces in the password. WordPress generates it in groups separated by spaces, and the whole string is the password.
3. Check the REST API is reachable. Open https://your-site/wp-json/ in a browser. If it does not return JSON, a security plugin or a server rule is blocking it, and that has to be fixed on your side first.
4. Check Application Passwords are enabled. Some hardening plugins disable them entirely. If the section is missing from your WordPress profile, that is the cause.
5. Check the site URL. Use the address WordPress itself is installed at, including www if that is what it uses.

WordPress: a page will not save

The message names which of three cases you are in:

• The page is built with a meta-based builder (Elementor, Divi, WPBakery and similar). Its content lives outside the page body, so no tool can edit it and every attempt is refused rather than half-applied. Edit it in the builder.
• The page is built with a block-based builder, which allows targeted text patches but not a whole-body replace. Builder editing is currently switched off in production, so these are read-only for body edits too for now.
• The body was too long to read in one go. A truncated body says so, and a whole-body write must never be sent back from a truncated read, because it would delete the part that was not read. Use a targeted patch instead, which changes specific text without transferring the body at all.

WordPress: "the SEO fields are not writable"

This is about your SEO plugin, and RankX AI tells you which of the possible reasons applies rather than reporting a flat no.

• Rank Math and SEOPress store their fields in post meta but do not expose them to the REST API by default. Exposing them makes them fully writable, and RankX AI hands you the registration snippet with your site's own field names already in it.
• Yoast exposes them per content type, so posts can be writable while pages are not on the same site.
• All in One SEO stores metadata in its own database tables, so no amount of configuration makes a meta write work. RankX AI refuses rather than appearing to succeed.

If a site was writable before and is not now, RankX AI names that as a regression rather than telling you to apply a snippet you already applied. The usual cause is a plugin update or a setting changed in wp-admin, and the first move is finding what removed it.

WordPress: the write succeeded but the live page looks unchanged

Almost always a page cache. RankX AI verifies a write by re-reading the object through the REST API, which confirms the database changed, and that is the only signal that catches a plugin returning success while persisting nothing.

A cache in front of your site can serve the old version afterwards. RankX AI appends a note saying exactly this to every successful content and SEO write. Purge the cache and check again.

WordPress: a write is reported as unverified

RankX AI could not confirm the change by reading it back. That is deliberately not reported as success. The write may have landed; RankX AI is telling you it cannot prove it did.

Check the object in wp-admin. If it changed, the read-back was blocked, usually by a cache or a security rule on the REST API. If it did not, the plugin accepted the request and discarded it, which is exactly the case this check exists to catch.

WordPress: an image lost its layout after an edit

If a block's attributes could not be parsed, WordPress discards what is between the braces on save while keeping the block and its inner content. On a builder block, the discarded part is often the identifier its generated styles are keyed to, so the page keeps every word and loses its appearance.

RankX AI defends against this twice: it warns before the write when a block's attributes will not parse, naming the block and the error, and it compares attributes after the write and reports any that were lost. If you see either warning, do not apply the change.

MCP: a tool is missing rather than failing

Not a connection problem. A token's scopes are fixed when it is issued, and a tool outside them is not listed and not callable rather than listed and denied. If an assistant cannot see a tool you expected, the token does not carry its scope, and the fix is to issue a new one.

The WordPress tools sit behind their own scopes rather than the general write scope, so a token created before those tools existed reaches none of them. See MCP authentication.

Still stuck

Two things make a support conversation short: which Website you are on, and the exact message you saw. Every refusal in RankX AI is written to name its own cause, so quoting it usually saves a round trip.