SiteRank AI is a WordPress plugin, not a SaaS crawler with a WordPress connector bolted on. The distinction is not marketing. It determines where your content goes, what the tool can see, what it costs to run, and how it behaves when you already have an SEO plugin installed — which you almost certainly do.
The analysis runs inside your install
A hosted crawler sees what a crawler sees: rendered HTML, from outside, at whatever rate its budget allows. A plugin sees the database.
That means SiteRank AI can read the post that is scheduled but not published, the page that is noindex, the custom post type your theme registers, the taxonomy terms that never appear in a menu, and the actual internal link graph rather than a reconstruction of it. It knows which pages are indexable because it can read the setting, not because it inferred it from a meta tag. And it can tell a page-builder page from a thin page, which matters more than it sounds: word count on a builder-generated page is unreliable, so the thin-content rule is skipped there rather than producing a false positive on a rich page.
It also means the analysis costs nothing per page. There is no crawl budget, no per-URL pricing and no queue behind other customers.
No API key for the core product
Content scanning, technical SEO auditing, GEO auditing, topic clustering, crawler inspection and structured-data inspection all run locally, with no outbound request and no site content leaving the install.
That is the whole core product. An LLM provider key adds one thing: visibility monitoring, where prompts are sent to a provider API to observe whether AI answers mention or cite you. Bring your own key — we ship none, and we proxy nothing through our own infrastructure. When monitoring runs, only the prompt text goes to the provider. No post content, no corpus, no visitor data.
Credentials resolve in a fixed precedence: environment variable, then a wp-config.php constant, then an encrypted value stored in the database. Where a variable or constant supplies the key, the admin shows it as configured by the server and read-only. No credential ever reaches the browser — not in a REST response, not in localised script data, not in a bundle — and a single redactor scrubs every log line, exception message and diagnostics export.
Detection before ownership
SiteRank AI detects Yoast SEO, Rank Math, All in One SEO, SEOPress, The SEO Framework and Slim SEO, and it tracks ownership per output type rather than per plugin: canonical URLs, meta descriptions, robots meta, robots.txt, XML sitemaps and Schema.org graphs are six separate ownership questions, and on a real site the answers are not always the same plugin.
Where something is owned, the audit reports the finding and names where the fix belongs — the setting in the plugin that emits it — instead of emitting a competing value. Two plugins writing canonicals, two graphs on one page or two sitemap indexes is a bug the site owner has to debug later, and creating it in order to look feature-complete is not a trade we make.
Where nothing owns an output, SiteRank AI still does not take it over silently. robots.txt and /llms.txt changes are proposed as a diff and applied only when you act.
This is the part that is least verified in the product today, and it is worth saying so: detection is by constant, class and function, it is correct by inspection, and it has not been exercised against a live install of every plugin in that list.
Everything site-visible is a proposal
Recommendations carry the observation that triggered them, an evidence tier, and an honest statement of expected effect. They are applied by you, they are reversible, and they are recorded.
Nothing rewrites your content. Nothing silently changes a canonical, a title, a description, a schema block, a sitemap or a redirect. robots.txt and llms.txt are never written without an explicit action, and /llms.txt is served virtually rather than written to disk, so there is no file left behind on your server and nothing for a deploy to overwrite.
There is also no 0–100 score anywhere in the product. Each domain reports a status band — good, needs attention, critical, or not measured — plus the counts it derives from, and every contributing finding is traceable to a URL and an observed value. Findings at the EXPERIMENTAL and HYPOTHESIS tiers never affect a band, and that exclusion is enforced in the query rather than left to a caller to remember.
Long work is queued, and WP-Cron is not trusted
Full-site analysis never runs in a request. Scans are batched, resumable background jobs with a cursor, running through a table-backed queue with atomic claiming and exponential backoff, so two workers cannot claim the same job and a failure resumes rather than restarts.
WP-Cron is the default dispatcher, and it is unreliable by design — it fires on page views, so a low-traffic site can go hours without a tick. Rather than pretend otherwise, the queue is also dispatched by an authenticated REST tick while the admin screen is open, which is why a scan you are watching makes visible progress. For a large site, a real system cron hitting wp-cron.php is the right setup, and the product says so instead of quietly under-delivering.
Two current limits, stated rather than discovered: topic clustering stops at 600 documents and returns nothing rather than a partial result above that ceiling — see topical authority for why — and scan discovery still runs in the starting request, which is fine to roughly 25,000 posts and needs to become its own cursor job beyond that.
Requirements and footprint
PHP 8.1 or newer, WordPress 6.5 or newer. The always-loaded bootstrap is small: admin work is hooked to admin screens, REST work to rest_api_init, and nothing loads on a front-end request that a front-end request does not need.
Every REST route names a specific capability in its permission callback — there is no __return_true in the surface — and five purpose-built capabilities separate viewing from managing, running scans, configuring providers and running visibility observations, so the two that spend money can be delegated separately.
Data is preserved on uninstall by default. Dropping the plugin's tables, options and capabilities is opt-in in the settings. Credentials are removed either way.
Related reading
Frequently asked questions
Do I have to remove Yoast or Rank Math first?
No, and you should not. SiteRank AI detects the SEO plugin you already run, tracks ownership per output type, and reports findings against what that plugin emits while naming the setting where the fix belongs. It does not emit a competing canonical, meta description, sitemap or schema graph. The honest caveat is the one stated above: that detection is correct by inspection and has not been exercised against a live install of every plugin in the list.
Do I need an API key to get anything useful out of it?
No. Technical SEO auditing, GEO auditing, topic clustering, crawler inspection and structured-data inspection are the core product, and they run locally with no key and no outbound request. A provider key adds visibility monitoring and nothing else, which is a different measurement with a different cost model — you pay your provider directly for it. If you never configure a key, that one feature is all you are missing.
Will running a full scan slow my site down?
Scans never run inside a page request, so a visitor never waits on one. The work is batched into resumable background jobs with a cursor, dispatched by WP-Cron and, while you have the admin screen open, by an authenticated REST tick — which is why progress moves visibly when you are watching it. On a low-traffic site WP-Cron can go hours without firing, so a real system cron hitting wp-cron.php is the right setup for anything large. The one part still done in the starting request is scan discovery, which is fine to roughly 25,000 posts.
What happens if my site is over the topic-clustering ceiling?
Clustering returns nothing and records why, rather than handing you a partial set of clusters that reads as complete. Everything else is unaffected by that ceiling: the SEO audit, the GEO checks, crawler inspection and structured-data inspection still run across the whole corpus in the same batched jobs. It is a limit of the local clustering engine specifically, and it is stated up front so you meet it here rather than inside a result you would half-trust.