Find: define and diagnose an AI visibility gap
Use Find when you need to establish what happened before deciding what to change. Register the exact prompt and answer surface, preserve the raw result and source URLs, separate unavailable or failed attempts from observed misses, and compare plausible gap explanations. The output is one bounded, evidence-supported hypothesis for Fix—not a universal ranking diagnosis or a promise that a change will produce a citation.
What is the Find stage for?
Find turns a broad concern such as ‘AI systems do not mention us’ into an inspectable observation. The unit is a declared prompt, surface or configured adapter, collection time, outcome rule, and raw result—not one blended score detached from its denominator.
Start here when the prompt panel is missing, the baseline is stale, or the apparent gap has not been separated from unavailable surfaces, failed runs, access policy, extraction, entity clarity, competitor coverage, or third-party source coverage.
Which Find resource should you use?
Choose the route that matches the decision you need to make. These routes observe different things, so their outputs should not be merged as though a crawler permission, a provider-reported impression, a RankEcho prompt cell, a mention, and a citation were the same event.
| Decision | Start with | Carry forward |
|---|---|---|
| Define a stable buyer-question panel | /product/prompt-intelligence | Verbatim prompts, intent labels, surfaces, and inclusion rules |
| Collect a bounded initial snapshot | /product/ai-visibility-audit | Run time, planned cells, raw outcomes, citations, mentions, rivals, and failures |
| Observe the same panel over time | /product/citation-monitoring | Fixed panel version, cadence, outcome definitions, and per-run evidence |
| Identify which rivals appear instead | /product/competitor-radar | Prompt-level rival observations and the text or sources supporting each classification |
| Inspect the source mix behind answers | /product/source-intelligence | Owned and third-party URLs, surface, prompt, and collection time |
| Run one bounded no-login check | /tools | Tool scope, requested target, returned result, and the limitation stated by that tool |
What must a Find record contain?
Register the protocol before interpreting the result. A reviewer should be able to reconstruct what was planned, what actually ran, what counted, and what was excluded without relying on a dashboard screenshot.
- A stable observation ID and panel version.
- The verbatim prompt, declared surface or adapter, locale and account state when controllable, and collection timestamp.
- Counts for planned, available, successful, observed, unavailable, and failed cells; unavailable or failed cells never become silent non-citations.
- The raw answer, visible source URLs, brand-match rule, and separate outcomes for mention, owned link, other citation, recommendation, and absence.
- At least one competing explanation for the gap and the evidence that would distinguish it.
- The exact existing page, policy, or source surface proposed for review; never an invented URL.
Illustrative synthetic example: from a vague miss to one testable gap
This example is illustrative and synthetic. It is not customer data, a benchmark, or evidence that any provider behaves this way generally.
A team registers six fixed prompts on two declared surfaces, creating 12 planned cells. Ten return inspectable answers, one surface is unavailable, and one attempt fails. The brand is mentioned in two of the ten observed cells, receives one owned-source link, and named rivals appear in six. The unavailable and failed cells remain outside the observed-outcome denominator.
For one category prompt, five observed answers cite the same third-party roundup and that roundup omits the brand. The team records a source-coverage hypothesis, while retaining prompt fit and entity clarity as alternatives. Find hands only that prompt, its raw answers, cited URLs, denominator, and competing explanations to Fix. It does not conclude that inclusion in the roundup will cause a future mention or citation.
What is in scope, and what is not?
In scope are bounded public observations, provider-specific policy or reporting records, declared matching rules, comparison of plausible explanations, and prioritization of one gap that a team can inspect. A robots policy check can describe declared access; it cannot prove a genuine provider request reached useful HTML. A visible citation or link impression is an observation under that surface's rules; it is not a universal rank.
Out of scope are reverse-engineering a provider's undisclosed selection formula, treating a failed run as a miss, inferring causes from one snapshot, combining unlike provider metrics, or forecasting traffic, revenue, rankings, recommendations, mentions, or citations. If the evidence does not distinguish a gap, keep the diagnosis open and collect more observations.
What exactly moves from Find to Fix?
The handoff is a diagnostic record, not a headline score. It carries the observation ID and frozen panel version; verbatim prompt and declared surface; planned, unavailable, failed, and observed counts; raw answer and source URLs; matching rules; the selected gap hypothesis and credible alternatives; the exact existing target; and acceptance criteria that can be checked before any proof run.
Stop the handoff when no specific gap is supported. When it is supported, Fix should alter one bounded artifact while preserving the baseline and every exclusion rule Find registered.
Where can you move in the workflow?
Stay in Find when the baseline or diagnosis is incomplete. Move to Fix only with a named artifact and acceptance criteria. Visit Prove when a dated change has shipped and the registered panel is ready to be repeated.
| Stage | Use it when | Route |
|---|---|---|
| Find | The observation, denominator, or gap remains uncertain | /resources/find |
| Fix | One supported gap can become a bounded shipment | /resources/fix |
| Prove | A dated shipment is ready for a matched re-test | /resources/prove |
Sources reviewed
Provider eligibility and measurement claims below were checked against primary documentation. These records do not establish a universal selection formula, causation, or a guaranteed ranking, impression, recommendation, or citation.
5 claim-level source records
| Claim reviewed | Official source | Review record |
|---|---|---|
| Google's dedicated Generative AI performance report records link impressions from AI Overviews and AI Mode and groups them by page, country, date, and device. Its documentation does not expose a universal prompt rank or selection reason. | Google Search Console: Generative AI performance report | Checked 2026-09-02 · Worldwide rollout stated as August 31, 2026 · Primary-source review; a link impression is not represented as a quotation, endorsement, click, or causal explanation. · Confidence: High |
| OpenAI documents OAI-SearchBot for ChatGPT search, GPTBot for potential model training, and ChatGPT-User for user-triggered actions. Their purposes and controls are not interchangeable. | OpenAI crawler documentation | Checked 2026-09-02 · Current OAI-SearchBot, GPTBot, and ChatGPT-User documentation · Primary-source review; crawler permission is treated as an access decision, not proof of indexing, ranking, retrieval, or citation. · Confidence: High |
| Anthropic documents ClaudeBot for potential model training, Claude-SearchBot for search indexing, and Claude-User for user-directed retrieval, and says all three honor robots.txt. | Anthropic crawler documentation | Checked 2026-09-02 · Crawler taxonomy updated April 7, 2026 · Primary-source review; provider-specific access roles are not converted into a general AI visibility guarantee. · Confidence: High |
| Perplexity documents PerplexityBot for search discovery and Perplexity-User for user-triggered fetching; it recommends verifying both the user agent and published IP ranges. | Perplexity crawler documentation | Checked 2026-09-02 · Current PerplexityBot and Perplexity-User documentation · Primary-source review; a permitted or verified fetch remains distinct from answer selection and citation. · Confidence: High |
| Bing's AI Performance report exposes observed citations, cited pages, and sampled grounding queries. Microsoft cautions that citation count is not placement, ranking, authority, or page importance. | Bing Webmaster Blog: AI Performance | Checked 2026-09-02 · Public preview announced February 2026 · Primary-source review; Bing observations are not merged with Google link impressions or RankEcho prompt-engine cells. · Confidence: High |
Frequently asked questions
One inspectable diagnostic record: a fixed prompt and surface, raw outcomes and sources, explicit denominators and exclusions, a bounded gap hypothesis, credible alternatives, an existing target, and acceptance criteria for Fix.
No. A documented policy can identify one possible access barrier, but reachability, indexing, retrieval, selection, visible links, mentions, and citations remain separate states. Verify the exact request and useful response before choosing an access fix.
No. Keep planned, unavailable, failed, and observed cells separate. Counting a run that did not produce an inspectable answer as an absence changes the denominator and can create a false visibility finding.
Not without a declared normalization supported by the underlying definitions. A Google link impression, a Bing observed citation, and a RankEcho prompt cell are different units and should be reported separately.
When one specific artifact or surface is connected to a supported gap hypothesis, the baseline is frozen, the alternatives remain visible, and acceptance criteria can be checked before a matched proof run.