Methodology
How Xaeo measures AI visibility
An AI visibility report is a record of answers to a defined set of buyer questions. It can show whether a brand was mentioned or a page was linked in those answers. It cannot show how every buyer sees that brand, or prove that a site change caused an AI recommendation.
Key points
- A report records answers to a disclosed set of buyer questions on named surfaces, at recorded times.
- A mention, a citation and a recommendation are different observations. Errors and refusals are not negative results.
- Evidence labels say how sure we are that a problem exists, not that fixing it will change an AI answer.
- A rescan shows change in a sample. It does not prove what caused the change.
The short version
An AI visibility report is a record of answers to a defined set of buyer questions, collected on named surfaces at recorded times. It can show whether a brand was mentioned, whether a page was cited and whether the business was recommended, and it keeps those three observations separate. A defensible report discloses what was asked, where and when each answer was collected, how answers were classified and what changed between scans. Errors and refusals are reported as collection failures, not as negative results. Fixes carry a Strong, Medium or Weak evidence label that says how sure we are a problem exists, plus a separate High, Medium or Low impact judgment. A rescan can show change in a sample, but it cannot prove what caused the change, and nothing here promises a mention, a ranking or revenue. Xaeo is pre-launch, and its public demo uses illustrative sample results.
What does an AI visibility scan measure?
An AI visibility scan measures whether a business is mentioned, cited or recommended in answers to a defined set of buyer questions. The unit of observation is one answer to one question on one recorded surface, so a product API response and a consumer app response are separate observations, not interchangeable “ChatGPT” results.
- Brand mention
- The answer names the business. A mention is not automatically a recommendation or a link.
- Citation
- The answer includes a source link to the client’s domain or page. Record the destination URL; a citation to a directory listing is a different observation.
- Recommendation
- The answer presents the business as an option for the buyer’s need. Preserve enough context to distinguish a positive recommendation from a warning or incidental reference.
- Not mentioned
- A usable answer was collected and the business was absent. An error, refusal or unavailable surface is not a negative result.
For the demo, these labels describe a fictional example. They are not measurements of Northside Plumbing or the domain a visitor enters.
What should a defensible report disclose?
A defensible report discloses what was asked, where and when each answer was collected, how answers were classified and what changed between scans. Our proposed protocol keeps that evidence attached to every observation, so a client can check a finding instead of trusting a score. Before sending a live report, an agency should answer the seven questions below.
- What was asked? Store the exact buyer question and its intent. Separate unbranded discovery questions from questions that name a business; they measure different tasks.
- Where was it collected? Name the provider, collection surface and model identifier where available. Record whether web search or grounding was enabled.
- What context was used? Record language, target location and any location setting actually supported. Distinguish a city written in a prompt from verified location targeting.
- When and how often? Record collection timestamps, time zone and sample count. Keep repeated responses separate rather than choosing the most flattering answer.
- What came back? Retain the answer evidence and citation destinations where storage and reporting rights allow. Record failures separately.
- How was it classified? Disclose the matching rules, brand aliases, domain rules and manual corrections. Ambiguous names need review.
- What changed? Record changes to questions, model, tools or collection settings before comparing periods.
Provider availability, permitted data use and the final beta collection settings are still being established. A published report must list its actual supported surfaces. This page does not promise a specific provider configuration or sample count.
How should a fix be connected to evidence?
A useful fix connects a verifiable site problem to a specific action. It also separates the confidence that the problem exists from the possibility that fixing it changes an AI answer. We label the first as Strong, Medium or Weak evidence and keep impact as a separate High, Medium or Low judgment.
| Evidence label | What supports the fix | What it does not establish |
|---|---|---|
| Strong evidence | A directly observed defect: an inaccessible target page, incorrect visible business fact or markup that contradicts the page. | That correcting it will produce a mention. |
| Medium evidence | A relevant information gap identified from the question, the client’s service and the current page. | That the gap explains the observed answer. |
| Weak evidence | A plausible editorial opportunity or hypothesis needing more evidence. | That the action is an established ranking factor. |
This is a proposed editorial rubric, not a validated prediction model. High impact, Medium impact and Low impact are prioritization judgments. A gain labelled “(estimate)” is a projection, not a measured result.
Can a rescan prove that a fix worked?
No. A rescan can show a change in the sampled answers. It cannot, by itself, isolate the cause. Answers may vary between requests; providers, retrieval sources and competitors may change too. A report should state what shipped, when it shipped, and whether the collection method stayed comparable.
Use the same question set, language, location context and collection surface when possible. If a model or question changes, start a new baseline or clearly mark the comparison. Never turn an increase in sample mentions into an unsupported revenue or ranking promise.
How should visibility rates handle errors?
For a disclosed sample, calculate mention rate as answers naming the brand divided by usable answers. Report collection coverage separately: usable answers divided by planned observations. Show both raw counts. A high mention rate with poor coverage should not look like a complete scan.
Are API answers the same as consumer app answers?
Not necessarily, and a report should not assume they are. The model, retrieval tools, context and settings can differ. A future API-based report should describe API observations explicitly; it should not be presented as a replay of every buyer’s experience in the consumer app.
| Observation | What can usually be recorded | What it does not show |
|---|---|---|
| Product API response | The request, model identifier where returned, tool and search settings, timestamp and any returned citations. | What a person sees in the consumer app, which can use different models, tools and context. |
| Consumer app answer | The visible answer, cited links, account and location context, and the time it was observed. | A repeatable configuration. Personal context and unannounced product changes can affect the answer. |
Platform facts behind this approach
Google says pages need to be indexed and eligible for a search snippet to appear as supporting links in its AI features. Eligibility does not guarantee inclusion. Read Google’s AI feature guidance.
OpenAI identifies OAI-SearchBot as its search crawler and GPTBot as a crawler for potential model training. Those controls are independent. Read OpenAI’s crawler documentation.
Perplexity describes PerplexityBot as a search crawler, rather than a foundation-model training crawler. Read Perplexity’s crawler documentation.