Methodology

This page is the specification for every number and every judgement SiteRank AI shows you. If a figure appears in the interface, its definition is here, including its numerator, its denominator and what it cannot tell you. Anything we do not measure is listed as not measured rather than filled in with an estimate.

Definitions are versioned. Stored rows carry the version of the formula that produced them, so a change to a definition never silently rewrites history.

How the SEO checks are produced

Every technical SEO check is a deterministic local rule. There is no model in this path, no outbound request, and no content leaving the WordPress install. The site's own database is the input; the output is a set of findings.

Each rule is a single class with one responsibility — one check, one severity, one evidence tier. A rule takes an extracted document (title, meta description, canonical, headings, body text with navigation, header, footer, sidebar, script and form markup already stripped, links, images) and returns zero or more findings. A finding always carries:

• the URL or post it was observed on
• the observed value that triggered it — the actual title, the actual character count, the actual missing attribute, not a category
• a severity
• an evidence tier
• the rule that produced it, so you can read what it does

That traceability is the constraint the rest of the methodology is built around. A number you cannot decompose into specific page-level observations is not shipped.

Rules run over the whole corpus, in batched background jobs with resumable cursors, so a large site produces the same result as a small one rather than timing out halfway and reporting a partial answer as complete.

Two deliberate suppressions are worth knowing about. Word count is measured as Latin word tokens plus individual CJK characters, because splitting on whitespace badly undercounts CJK text — and it is treated as a readability measure, never as a quality measure. And where a page builder is detected, the extraction method is recorded and the thin-content rule is skipped, because reporting thin content on a rich builder-generated page is a false positive serious enough to discredit everything else on the screen.

What GEO means here

Generative engine optimisation, in this product, means one narrow and checkable thing: whether a page is structured so an AI retrieval system can find, extract and correctly attribute a passage from it. Nothing more.

The GEO checks look at entity clarity, machine-readable structure, passage retrievability, authorship transparency, site transparency (a real about page, a real contact route) and content freshness. Each of those is inspected locally against the page as published.

What GEO does not mean here is a claimed influence on any AI system's output. Google states there are no additional requirements or special optimisations for its AI features beyond normal SEO. We do not contradict that. GEO checks tell you the page is retrievable and interpretable; they do not tell you it will be retrieved, and they never claim to.

The six evidence tiers

Every finding and every recommendation carries a tier. The tier is not decoration — it decides whether the finding is allowed to affect a status band at all.

Findings at the scoring tiers are weighted, with the weight decreasing as the evidence weakens. EXPERIMENTAL and HYPOTHESIS findings carry zero weight and are excluded from the band calculation in the database query itself, not by a caller remembering to filter them. A rule author cannot accidentally promote a hypothesis into a deficiency.

Those two bottom tiers still appear in the interface, separated from standards compliance, phrased as things you might try rather than things you have got wrong. An idea worth testing is not a defect, and presenting it as one is the specific dishonesty this product exists to avoid.

Why there is no 0–100 score

A composite score compresses dozens of unlike observations into one number, and the compression is where the dishonesty gets in. Two sites scoring 74 have nothing in common; a score that moves from 74 to 78 tells you nothing you can act on; and the weighting that produced it is almost always arbitrary and almost never published.

Instead, each domain reports a status band plus the counts it came from. The bands are:

• critical — if there is at least one critical finding
• critical — if there is at least one high-severity finding and the density is 1.0 or above
• needs attention — if the density is 0.25 or above
• good — otherwise
• not measured — if no documents were analysed at all

Density is a per-document measure of how much high-severity and medium-severity work is outstanding. Each high-severity finding counts as five, each medium-severity finding counts as two, those are added together, and the total is divided by the number of documents analysed. Dividing by document count is the point: a 4,000-page site is not penalised for being large, and a ten-page site with the same proportion of problems reports the same band.

Only findings at the four scoring tiers reach this calculation. Low-severity findings are listed but do not move a band.

The band is always shown next to its counts, and every count opens into the findings that produced it, and every finding opens onto the URL and observed value. That is the whole chain, and it is short on purpose.

How prompts are monitored

Visibility monitoring is the only part of the product that talks to anything outside your site, and it is optional. You write a prompt set — the questions you believe a real person would ask an AI assistant in your category. Each prompt is versioned. You approve the set before anything runs.

On a schedule you choose, each enabled prompt is sent to a configured provider through its official API, using your own key. The response is stored as a snapshot together with complete provenance: provider, the model you requested, the model string the API actually returned, parameters, whether web-search grounding was enabled, locale, timestamp, prompt id and prompt version. An observation without full provenance is not written, because it could not be compared to anything later.

The response is then analysed locally for two distinct things: whether your entity was mentioned in the text, and whether any citation was returned and to which domain. A mention is not a citation, and both are recorded separately.

Model output is treated as untrusted input throughout. It is never executed, never followed as an instruction, and never rendered as markup. It is data shown to a person.

Metric definitions

Every metric returns its value, its numerator, its denominator, its sample size, a 95% Wilson score interval and a plain-language definition. A bare percentage is never returned.

Share of voice deserves a warning label, and gets one in the interface. It is a proportion within your prompt set and your competitor list. Add a competitor and it falls; add a prompt and it moves. It is not market share, it is not a share of anything a model does globally, and both of its denominators are always displayed alongside it.

Volatility measures how much the same question disagrees with itself. It is the proportion of samples that differ from the majority answer for the same prompt under identical conditions, where identical conditions means the same prompt id, prompt version, provider, returned model, web-search flag and locale. The prompt id is part of that key deliberately: pooling different prompts that merely share a model would measure variation between prompts, which is a different quantity with a similar-looking number. Volatility ranges from 0 to 0.5. With fewer than two samples it reports as not measurable rather than as zero. It is a headline metric, not an error bar hidden in a tooltip, because it is what tells you how much any single observation is worth.

The Wilson score interval is the uncertainty around a proportion. It is calculated at 95% confidence, at the actual sample size, and it is asymmetric near 0 and 1 — which is the reason to use it rather than the textbook normal approximation, since rates of 0% and 100% are exactly the cases this product produces most often. At a sample size of one, the interval spans nearly the whole range. That is the honest answer to "we asked once", and the interface shows it rather than presenting 0% or 100% as a finding.

Only valid observations count

An observation counts as valid only if the API call completed and returned a usable response. Errors, timeouts, rate-limit rejections and content-filter blocks are excluded from the numerator and the denominator of every rate, and the excluded count is always reported next to the metric.

The reason is straightforward: a failed request is not evidence that the model omitted your site. Counting a timeout as a non-mention would bias every rate downward by exactly as much as your network was unreliable. Excluding failures without reporting them would hide a run that mostly failed. So both happen — they are excluded, and you are told how many.

Provider and API limitations

Only OpenAI is implemented. Other providers appear in the interface as not yet available and are not configurable, so that nothing looks implemented which is not.

Capabilities differ by provider and by model, and are feature-detected rather than assumed. Web search grounding, citation return, structured output and system prompt handling are not uniform. Where a capability is absent, the product degrades explicitly and records that it did; it never substitutes a different capability and reports the result as if the requested one had run.

Providers also rate-limit, deprecate models, and change defaults. A prompt set that ran cleanly last month can return errors this month for reasons that have nothing to do with your site.

An API observation is not what a person sees

This is the single most important limitation in the product, and it is not a caveat — it is a different measurement.

When you ask ChatGPT, Gemini or Perplexity a question in the consumer product, the answer is produced by a stack that includes retrieval infrastructure, orchestration, product-specific prompting, personalisation, memory of your previous conversations, your account settings, your location, and a model version that may not be the one exposed through the API. None of that is reproducible through an API call, and none of it is available to us.

What we measure is a provider API, under conditions we record completely and can reproduce. That is a genuinely useful signal — it is repeatable, comparable over time, and comparable across competitors on identical prompts — but it is a proxy. It is not a ranking, the word "ranking" is not used for a generative answer anywhere in this product, and no number here should be described as your position in ChatGPT.

We also do not scrape consumer chat products to simulate an API. That would violate provider terms and would produce a number no more faithful than this one.

Model variability and discontinuities

The same prompt sent twice to the same model can return different text. That is a property of the systems, not a fault in the measurement, and volatility exists to quantify it rather than hide it.

Sharper than variability is discontinuity. When the model string returned by the API changes, or when you edit a prompt and its version increments, observations before and after are no longer measurements of the same thing. The product detects these breaks and marks them on the chart as a break, rather than drawing a continuous line through a changed instrument. A movement across a discontinuity is not a trend and is not presented as one.

Nor is any movement attributed to a cause. Model updates, index updates, competitor publishing, and sampling noise all move these numbers, usually at once. The product reports association and shows volatility alongside every delta. It does not tell you why something changed, because it cannot know.

Sampling and historical tracking

Sampling is the trade you control. More samples per prompt narrow the Wilson interval and make volatility measurable; they also cost more, because every sample is a paid API call on your own key. Fewer prompts sampled more times gives you a confident answer about a narrow question; more prompts sampled once each gives you a wide but very uncertain view. The interface shows the sample size on every metric so the trade stays visible instead of being buried in a settings screen.

Every observation is retained with its full provenance and raw snapshot, so history is a record of what was actually observed rather than a rolled-up average. Comparisons over time re-derive metrics from stored observations under the methodology version that produced them. Historical rows are never recomputed under a new formula and presented as though they had always read that way.

Cost estimation

Cost is shown before a run and after it, and it is always an estimate, always labelled as one.

The estimate is derived from a per-model price map that is configuration, not a live lookup. Prices go stale. Grounded web-search surcharges are not modelled at all. Both of those push the same way, so the estimate should be read as a floor: your provider bill can be higher than the figure shown, and should not be lower. The authoritative number is the one on your provider's own dashboard.

Privacy

The analysis engine is local. Content scanning, SEO auditing, GEO auditing, topic clustering, crawler inspection and structured-data inspection make no outbound request at all, and no post content, URL, corpus or site metadata is transmitted.

The one outbound data flow in the product is the prompt text you wrote, sent to the provider you configured, using your key. The request is constructed from the prompt row alone, so the boundary is a property of the code path rather than a promise in copy. Your content is not sent to a model, your site structure is not sent to a model, and nothing is proxied through us — you talk to your provider directly.

The chain that must not be collapsed

Every claim in this product respects one sequence, and so should every decision you make from it:

Crawlability does not guarantee retrieval. Retrieval does not guarantee citation. Citation does not guarantee recommendation.

An AI crawler being allowed in robots.txt means it may fetch a page. Fetching it does not mean any retrieval system holds it, or would surface it for a given question. Being retrieved and used does not mean the answer names you or links to you. And being cited does not mean you were recommended — a citation can support a sentence that argues against you.

Every check, band and metric on this page sits somewhere on that chain. None of them jump a link in it, and any tool that tells you they do is selling you the jump.