A reliable AI visibility audit begins before the first prompt is entered into ChatGPT, Google AI Mode or Perplexity.
It must define the entity, verifiable claims, relevant user intentions and exact product surfaces, then preserve enough evidence to distinguish a representation problem from a one-off answer or uncontrolled condition.
The five dimensions introduced in What should an AI visibility audit measure? — Presence, Position, Provenance, Precision and Persistence — provide the analytical structure. This article explains how to design and execute the audit that supplies those measurements.
A prompt list is not an audit design. The audit begins with entities, claims, scenarios and controlled conditions.
Step 1: define the entity and claim scope
The first task is to establish precisely what is being audited.
A brand is rarely a single name. The scope should cover the commercial and legal names, spelling variants, domain, products, services, sub-brands, key people, locations, categories, competitors and similarly named entities. This prevents product-only mentions or plausible descriptions of the wrong organisation from being counted as valid brand visibility.
Build a reference claim map
The audit also needs a verified set of claims against which answers can be assessed.
The map should cover the company definition, offer, features, limitations, customer groups, markets, pricing, integrations, certifications, ownership, leadership and material historical changes. Each claim should record a reference source, verification date, applicable conditions and known inaccurate versions.
The map must distinguish facts from interpretation, positioning and aspiration. “The leading platform” is not equivalent to a documented feature or current price.
The underlying entity, claim and source work is described in more detail in Brand Semantics Infrastructure.
Define when the brand should not appear
An audit should not reward maximum inclusion regardless of fit.
Before testing, define:
scenarios in which the brand should be considered;
scenarios in which it may be relevant only under specific conditions;
categories to which it does not belong;
requirements that disqualify its offer;
competitors with which it should genuinely be compared.
Absence from an unsuitable scenario may indicate appropriate selection; repeated inclusion in the wrong category can inflate mention rate while revealing a semantic problem.
Step 2: build intent scenarios, not a keyword list
A conventional SEO keyword list is not enough for an answer-system audit.
A scenario should describe the user’s problem, intent, decision stage, organisational context, location, language, evaluation criteria and boundaries of suitability.
For example:
An operations director at a mid-sized European manufacturer is looking for a process-analysis platform that integrates with an existing ERP system and supports enterprise access controls.
That one scenario can generate several prompt variants:
“Which process-analysis platforms should a mid-sized manufacturer consider?”
“Compare process intelligence tools for a European manufacturer using an ERP system.”
“Which platforms combine ERP integration with enterprise access controls?”
“I need an alternative to product Y for process analysis in manufacturing. What would you recommend?”
Keep the units of analysis separate
Unit | Meaning |
|---|---|
Scenario | the problem, audience, intent and conditions |
Prompt | one linguistic expression of the scenario |
Prompt variant | an alternative wording of the same scenario |
Follow-up | a question dependent on an earlier answer |
Run | one execution under defined conditions |
This distinction matters because paraphrases test prompt sensitivity, while repeated runs of identical wording test stochastic variability. They should not be combined into one undifferentiated result.
Include branded and non-branded scenarios
Branded scenarios test entity recognition and claim accuracy:
What does brand X offer?
Does brand X provide feature Y?
How does brand X compare with competitor Z?
What are the limitations of brand X?
Non-branded scenarios test discovery and recommendation:
Which providers solve problem X?
What are the strongest options for a company with these requirements?
Which alternatives should be compared with the category leader?
Who specialises in this use case?
A brand may perform strongly in explicit questions while remaining absent from commercially important discovery scenarios. Report them separately.
Step 3: define the product-surface matrix
The provider name alone is not sufficient metadata.
“Google visibility” may refer to conventional search results, AI Overviews, AI Mode or Gemini. “ChatGPT” may refer to a response with Search, a parametric answer without current retrieval or a deep-research workflow. “Copilot” may refer to public Bing search or an organisational environment grounded in private data.
A baseline public audit can include:
Provider | Surface | Search condition | Main observable evidence |
|---|---|---|---|
AI Overviews | integral to the surface | activation, answer, supporting links | |
AI Mode | integral to the surface | answer, sources, follow-ups | |
OpenAI | ChatGPT Search | active | answer, citations, source panel, conversation context |
Perplexity | public search interface | active | answer, citations, sources |
Gemini with web search | active or identifiable | answer and visible sources | |
Anthropic | Claude with web search | active | answer and citations |
Microsoft | Copilot Search in Bing | active | answer, sources used, related links |
DeepSeek | public interface with web search enabled | active according to the interface | answer and visible source information |
Google AI Overviews and AI Mode
Google’s guidance for AI features in Search treats AI Overviews and AI Mode as distinct surfaces. They may use different models and techniques, show different links and use query fan-out across subtopics and data sources.
Because AI Overviews do not trigger for every query, distinguish non-activation from an activated answer in which the brand is absent. Also separate brand mention, domain citation, recommendation and inaccurate representation. Google states that supporting links must be indexed and eligible for a conventional snippet, but eligibility does not guarantee display. Record country, language, device, sign-in state and surface activation; do not merge AI Overviews, AI Mode and Gemini into one Google score.
ChatGPT Search and Perplexity
OpenAI describes ChatGPT Search as providing timely answers with links to web sources. Prompts may be rewritten into targeted search queries, while general location and enabled Memory may affect formulation. Record Search activation, sign-in and Memory state, language, location and conversation context.
OpenAI’s crawler documentation separates OAI-SearchBot, GPTBot and ChatGPT-User; they support different search, model-development and user-initiated functions. Perplexity similarly distinguishes PerplexityBot and Perplexity-User. Its citation-rich interface is useful for source analysis, but raw citation counts should not be compared directly with platforms that expose sources differently.
Gemini and Claude with web search
Gemini should be treated as a separate product surface from Google AI Overviews and AI Mode. Record the public interface, disclosed model or mode, sign-in state, language, location and whether current web grounding is visible or otherwise identifiable.
For Claude, distinguish the public interface from API experiments. Anthropic’s crawler guidance separates ClaudeBot, Claude-User and Claude-SearchBot. Its API web-search documentation shows that API searches can be repeated within one request and can use domain controls, localisation and search limits.
API controls are useful for experiments, but API results should not be reported as equivalent to ordinary public-interface answers.
Microsoft Copilot Search and DeepSeek
The relevant Microsoft surface is Copilot Search in Bing, not Microsoft 365 Copilot or an organisational agent grounded in Microsoft Graph.
Microsoft’s Copilot Search documentation states that the surface provides summarised answers with cited sources, is grounded in Bing results and may issue additional searches on the user’s behalf. The interface also distinguishes sources used to inform the answer from related links that were not used to produce it.
Record that distinction for the tested market and version because functionality can vary.
Public DeepSeek can be included when the interface visibly indicates that web search is active. The official DeepSeek API documentation does not provide a comparably detailed description of the public interface’s search and citation behaviour. The audit should therefore record only what can be observed: search state, visible model or mode, source presentation, clickability, date, language and location. It should not infer an undocumented retrieval architecture.
Step 4: assess the brand’s owned sources
AI testing should not be the auditor’s first encounter with information about the brand.
Review the homepage, category and product pages, documentation, pricing, reports, company information, leadership profiles, language versions and official platform profiles.
Technical accessibility
Check whether important pages are crawlable, indexable and available in textual HTML; whether canonicalisation selects the right URLs; whether a WAF or CDN blocks relevant crawlers; and whether outdated pages remain public and discoverable.
Google states that the conventional foundations of SEO still apply to AI Overviews and AI Mode: crawlability, indexability, internal links, textual availability of important information and consistency between structured data and visible content. Its guidance also states that no special AI file or dedicated schema is required for those surfaces.
Technical access does not guarantee visibility, but inaccessible information cannot function reliably as a current source.
Claim availability and consistency
Important claims should be explicit, current, attributable to the correct entity and supported by evidence.
Check for missing definitions, ambiguous categories, contradictory features, old prices, discontinued functions, cross-language inconsistencies, entity confusion and important facts available only in obsolete documents.
Not every inaccurate AI answer originates in the model. The brand’s own estate may contain the outdated or conflicting material from which the error is reconstructed.
Step 5: map the external source ecosystem
The representation may also be shaped by media, directories, reviews, partner pages, public documentation, forums, social platforms, analyst reports, competitor comparisons and institutional materials.
For each relevant source, record the category, associated claims, currency, entity match, appearance in AI answers, correction options and comparative strength against competitor sources.
Identify source gaps
A source gap exists when an important claim has no credible public support, exists only on the brand’s own marketing pages, is unavailable in the tested language or market, or is described less precisely than an equivalent competitor claim.
A source gap does not prove that the brand will be absent. It identifies a weak evidence environment in which retrieval, verification or recommendation may be more difficult.
Identify conflicting descriptions
A brand may describe itself as an analytics platform while directories classify it as project-management software. A partner page may list an integration that has been discontinued. An old press article may name a previous chief executive.
Document these conflicts before testing. They may explain later errors, although they do not establish causality.
Step 6: run controlled tests and preserve the evidence
Every run should produce a record that can be reviewed after the interface or answer changes.
Field | Required record |
|---|---|
Scenario and prompt | IDs, full wording and variant type |
Surface | provider, product surface and search state |
Conditions | date, time, language, location, sign-in and account state |
Context | fresh session, follow-up or extended conversation |
Output | complete answer, refusal or error |
Sources | citations, source titles, URLs and visible cited passages |
Brand data | order, role, competitors and category |
Claims | atomic statements, accuracy status and errors |
Review | reviewer and adjudication status |
A screenshot is useful, but preserve the full text, links, source order, search indicators and relevant follow-ups. Otherwise later reviewers may be unable to distinguish recommendation, listing, source use and material qualification.
Use repeated runs
Repeated sampling research shows why one execution should not be treated as a fixed platform result. Quantifying Uncertainty in AI Visibility found substantial citation variability across repeated measurements, while Don’t Measure Once argues that visibility should be characterised as a distribution across runs, prompts and time.
This article does not prescribe one sample size. It does require that the audit distinguish:
an identical prompt run again;
a paraphrased prompt variant;
a different date;
a different language or location;
a changed model or interface;
a follow-up within an existing conversation.
Control the conversation state
A fresh session and a follow-up answer are not equivalent.
After several turns, the system may already have selected competitors, inferred user requirements or introduced assumptions that affect later answers. Baseline testing should therefore separate:
fresh-session prompts;
controlled follow-ups;
longer decision journeys;
personalised or memory-enabled scenarios.
The audit must be reproducible
A credible audit has a defined entity scope, verified claims, intent scenarios, surface-specific metadata and complete answer records.
That foundation makes it possible to determine whether a problem concerns absence, recommendation role, source provenance, factual error or instability. The next article explains how to classify, interpret and report those findings.
The procedural distinction also follows the GEO control surface: brands can control parts of their information estate, influence parts of the wider source environment and observe outputs they do not directly control.
Discuss an AI visibility audit with Brand Semantics.
Sources and methodological notes
Google Search Central, AI features and your website. Used for AI Overviews, AI Mode, query fan-out, eligibility and technical foundations. The documentation does not disclose complete retrieval or source-selection mechanisms.
OpenAI Help Center, ChatGPT Search, and OpenAI, Overview of OpenAI Crawlers. Used for Search behaviour, query rewriting, location, Memory and distinctions between OAI-SearchBot, GPTBot and ChatGPT-User.
Perplexity, Perplexity Crawlers. Used for the distinction between PerplexityBot and Perplexity-User.
Anthropic, crawler guidance and Web search tool. Used for Claude-SearchBot, Claude-User and API search controls. API documentation is not treated as a complete description of the public interface.
Microsoft, Copilot Search in Bing. Used for Bing grounding, additional searches, cited sources and the distinction between used sources and related links.
DeepSeek, API documentation. Used to identify the limit of the public technical documentation; no undocumented retrieval mechanism is inferred.
Ronald Sielinski, Quantifying Uncertainty in AI Visibility, and Julius Schulte, Malte Bleeker and Philipp Kaufmann, Don’t Measure Once. Both are 2026 preprints used to support repeated measurement rather than one-off testing.
