A mention is your name appearing in an answer. A citation is a source the provider attributed, returned as a URL alongside the text. They are different events, they move independently, and conflating them is the fastest way to a visibility report that cannot be defended. SiteRank AI records both, but citations are the part with a URL attached — which makes them the part you can act on.
What a citation observation contains
Every run of a prompt produces one observation: a single response, under fully recorded conditions. Without complete provenance it is not stored, because a number you cannot trace back to a specific request is not a measurement.
Each observation records the provider, the model id the API actually returned (not the one requested), the prompt id and prompt version, whether web-search grounding was enabled, the locale, the timestamp, and the raw response snapshot. Attached to it are the citations the provider returned, each stored as its own row: the URL as given, the resolved domain, the title, whether it matched your site, whether it matched a competitor you track, and which response field it came from.
That last field matters more than it looks. Providers surface sources in different places — a dedicated citations array, annotations on the message, inline links in the text. Recording where a source came from is what lets you compare two providers without pretending their outputs are the same shape.
Resolving the URL a provider gives you
Providers frequently return wrapped or redirected links rather than the destination. A citation counted at face value therefore under-reports your own domain and over-reports whatever wrapper service sat in front of it.
SiteRank AI normalises every citation before counting it, and records the outcome as one of four resolutions: direct (the URL was already the destination), unwrapped (a destination parameter was extracted from a known wrapper), unresolved-wrapper (a wrapper was recognised but no destination could be read), and invalid (the value was not a usable URL). Unwrapping is bounded to four levels, so a chain of redirects cannot become an unbounded fetch loop.
The normaliser carries its own version constant. When the resolution logic changes, the version changes with it, and stored rows keep the version that produced them — so a historical comparison never silently mixes two different definitions of "cited".
What the report shows
Domain citation rate. The proportion of valid observations that cited your domain at least once. Reported with its numerator, its denominator, the sample size and a 95% Wilson score interval — never as a bare percentage. At small sample sizes that interval is wide, and that width is the honest answer rather than a presentational problem to hide.
Citation share. Of all citations to any domain you track — yours and the competitor set you defined — the proportion that went to yours. Both denominators are shown, because the number changes when either your prompt set or your competitor list changes.
Cited domains. The full distribution of domains the provider attributed across your prompt set, not only your own. This is usually the most immediately useful view in the product: it tells you which sources the model is reaching for on your topics, which is a concrete research input regardless of whether you appear in the list yet.
Citations by prompt. Which specific prompts produce a citation to you and which never do. A domain citation rate averaged over a whole prompt set hides the fact that you own three questions and are absent from twelve.
Citations by provider and model. Held separately, never pooled. Two providers running different retrieval stacks are two instruments, and averaging them measures nothing in particular.
Comparing runs, and why "lost" is a careful word
Because every citation is stored as a row against a dated observation, you can compare any two windows and see which URLs were cited in one and not the other. That comparison is genuinely useful — it is how you notice that a page which used to be the model's preferred source on a topic has stopped appearing.
It is also the single easiest place in this product to over-claim, so the interface constrains it in three ways.
First, volatility is shown next to any change. Volatility is the proportion of samples that disagree with the majority for the same prompt under identical conditions, and it is a first-class reported metric here rather than an error term. If repeated samples of one prompt already disagree with each other 30% of the time, a citation that appeared last week and not this week is inside the noise, not a trend.
Second, discontinuities break the line. If the returned model id or the prompt version changed between two points in a series, the instrument changed, and the chart marks a break instead of drawing continuity through it. A "lost citation" that coincides with a model version change is a comparability problem before it is a visibility problem.
Third, failed calls are excluded from both numerator and denominator, and the excluded count is always shown. A timeout is not evidence the model omitted you. Counting it as a non-citation would bias every rate downward, quietly.
Citation is not recommendation
The chain is crawled → retrieved → cited → recommended, and each arrow is a separate step that no provider fully documents. Citation monitoring observes exactly one of those arrows, at one moment, through one API.
A citation means the provider attributed a source alongside an answer. It does not mean the answer endorsed you, that a person read the answer, that the link was clicked, or that the same question asked inside the consumer chat product would produce the same sources. An API response and what a user sees in a chat interface are different artefacts, produced by different orchestration, and SiteRank AI does not present one as evidence of the other.
Nor is any of this a ranking. Most generative systems expose no deterministic ordered result list, so the product never reports a position, a rank, or a "ChatGPT #3". It reports rates, shares, intervals and the observations underneath them.
What it costs and what leaves your site
Monitoring is the only part of SiteRank AI that makes an outbound provider call, and it runs on your own key. Only the prompt text is sent — no post content, no corpus, no visitor data.
Every call is metered before it is made: provider, model, token counts where the API returns them, and an estimated cost from a per-model price map. The estimate is always labelled an estimate, and it is a floor, because grounded web-search surcharges are not modelled. A budget guard enforces the ceiling before the request goes out rather than reporting the overrun afterwards.
Only OpenAI is implemented today. Other providers appear in the interface as not yet available rather than as configurable options that quietly do nothing.
Related reading
Frequently asked questions
We get mentioned but almost never cited. Is something broken?
Probably not — a mention and a citation are produced by different mechanisms, and a model can name you from what it already holds without attributing a source at all. Citations generally only appear when the provider is returning sources with the answer, which is why the web-search flag is recorded on every observation and why grounded and ungrounded runs are never pooled. Check that flag first; a prompt set running without grounding will show a low domain citation rate for reasons that have nothing to do with your site.
How many samples do I need before a citation rate means anything?
There is no single threshold, which is why the interval is shown instead of a bare percentage. At one sample the 95% interval spans nearly the whole range, and that width is the answer rather than a display problem — it says the observation cannot yet distinguish between very different underlying rates. Raise samples per run until the interval is narrow enough for the decision you are trying to make, and read volatility alongside it, because a prompt whose repeated samples disagree with each other will not settle no matter how many you take.
One of our URLs stopped being cited. Should we rewrite the page?
Not on that evidence alone. Look at volatility for the prompt first: if repeated samples of the same question already disagree with each other, a citation present one week and absent the next is inside the noise. Then check whether the chart marks a discontinuity — a returned model id or prompt version that changed between the two points means the instrument changed, and the comparison is not valid. Only a change that survives both checks is worth treating as a signal about the page.
Does allowing more AI crawlers make citations more likely?
Access is a precondition, not a cause. Letting a provider's retrieval crawler reach your pages makes you eligible to be retrieved and nothing more, and no provider documents the steps between eligibility and attribution. The two features answer different questions: crawler policy tells you what you have permitted, and citation monitoring tells you what was actually observed. Neither one predicts the other.
Will these numbers match what I see if I ask ChatGPT the same question myself?
They may well not, and they are not designed to. An API response under recorded conditions and a consumer chat product are different artefacts, produced by different orchestration, personalisation and model versions. What the API gives you is repeatability — the same wording, the same conditions, the same provenance, month after month — which is the property a chat transcript cannot offer. Use prompt monitoring to keep those conditions stable, and read the numbers as observations of one system rather than as a description of everyone's experience.