AEO and listening
Why does AI recommend your competitor? A citation gap audit for SaaS teams
When AI recommends a competitor, audit the customer requirement, your product’s eligibility, page access and the cited evidence before commissioning content. For software as a service (SaaS) teams, the useful output is a verified correction or a clearly bounded investigation.
Takeaways
- Preserve the question, answer, engine, date and cited pages before deciding why a competitor appeared. A citation is evidence of a displayed source; it does not expose every step that produced the answer.
- Verify whether your product actually meets the buyer's requirements. A correct exclusion calls for different work from a false claim about your capabilities.
- Inspect the exact cited page and relevant passage. Domain-level citation totals cannot tell you which explanation needs correcting.
- Separate technical access checks, evidence gaps and observed answer changes. Fixing a verified problem is worthwhile even when its effect on future citations remains uncertain.
What is an AI citation gap?
An AI citation gap is an observed difference between the sources an answer displays and the sources you expected it to use. A competitive visibility gap is broader: your competitor might be recommended while your own company is omitted, even when neither company's website is cited.
Those are different review problems. Suppose an answer cites an independent tutorial and recommends two webhook services. Your documentation is absent from the source list. That does not establish that your product was considered and rejected. It also does not establish that buying a mention in the tutorial would change the recommendation.
For this audit, write down the observation before writing down a cause:
| Observation | What it establishes | What still needs investigation |
|---|---|---|
| A competitor is recommended | The saved answer recommends that company for this question | Whether the recommendation satisfies the buyer's requirements |
| Your product is mentioned but no link appears | The saved answer names your product | Where the product facts came from and whether they are correct |
| A third-party page is cited | The interface displays that page as a source | Which claims it supports and whether it is current |
| Your documentation is accessible | The tested request retrieved the page | Whether the engine retrieved or used it for this answer |
Two provider contracts make source inspection concrete. OpenAI's web-search documentation[1] distinguishes inline citations from its fuller list of consulted sources. Anthropic's web-search documentation[2] describes citation records containing the source URL, title and cited text. Those are API contracts; a consumer interface may expose less information. Save what the tested surface actually shows.
Decide which gap you are investigating
Save the answer before opening a content brief. Then choose the question the evidence can answer:
| Gap | Test | Useful result |
|---|---|---|
| Recommendation | Does the named product meet the stated requirements? | A qualified recommendation or a documented mismatch |
| Factual accuracy | Does the answer contradict a maintained product reference? | The exact false or incomplete claim and its correction |
| Owned-source citation | Does the answer display a link to your page? | A count of answers citing the page in the saved test set |
| Third-party coverage | Does a cited comparison or tutorial omit relevant evidence? | A correction or evaluation brief for that page’s owner |
| Technical access | Can the relevant page be fetched and, where required, indexed? | A reproducible access finding for an engineer |
An answer can name your product accurately without citing your domain. A cited comparison can mention your product while the answer recommends someone else. Treat each outcome as a separate field. A single visibility score would hide the work needed.
Start with a small set your team can inspect completely. For example, choose one buying decision, three materially different questions and one assistant surface. Expand once reviewers agree on eligibility and source classification. This is a workload recommendation, not a statistically representative sample.
Start with a question that can produce a consequential mistake
Choose a decision someone genuinely needs to make. A support record, a lost-deal note or a recurring implementation question is a better starting point than a prompt invented solely because it returns a competitor.
Consider this hypothetical question:
Which webhook delivery services let a small support team inspect and replay failed events on a self-serve plan?
The important requirements are the support workflow, inspection, replay and plan access. A response that recommends an enterprise-only replay feature can be commercially misleading even if every product name is spelled correctly.
Before running the question, list what would make a recommendation eligible. For this example:
- A support user can inspect failed deliveries.
- A support user can initiate replay with documented permissions.
- The required feature is available under the stated purchasing constraint.
- The answer acknowledges any replay-retention limit relevant to the task.
Do not add a budget, region or security requirement that the customer never expressed. If an unspecified condition could change the answer, record the ambiguity.
For selecting the initial questions, use our AI-search prompt strategy guide. This article begins once you have a question worth investigating.
Capture a baseline that another reviewer could inspect
Save the complete response, its sources and the test conditions. A screenshot of the first three product names is insufficient when the qualification appears farther down the answer.
Record the exact submitted prompt; product and mode; date and time; visible model identifier where available; account or personalization conditions; requested location; and any exposed search-query record. Record an unavailable field as unavailable.
Run the question again under comparable conditions on separate occasions. There is no universal number of runs that makes a small sample representative. Choose a manageable repeat schedule, state it in advance, and report the resulting counts. If you change the prompt, preserve the original series and start a new one.
For a hypothetical set of six valid runs, “our product was named in two of six saved answers” is a defensible description. “We own 33% of the market” is not. The denominator is your test set, not the population of customer conversations.
Keep failed requests and responses without sources in the record. They affect what you can measure. Do not silently count a failed request as a brand omission or discard an unlinked answer because it makes citation coverage look worse.
A repeat schedule and counting rule you can copy
For the webhook question, a team could plan six runs: two fresh conversations on each of three separate days, in the same product and mode, with the exact same prompt. Keep follow-up context out of a fresh run. Record available personalization settings and retain any uncertainty about them. This schedule makes the work inspectable; six answers cannot establish a category-wide rate.
Use one row per attempted run, with a link to the saved answer. Count a brand once per answer, regardless of repeated name mentions. For citations, record both whether the domain appeared and the exact distinct URLs shown. Keep consumer-interface results separate from API results even when the model names look similar.
Suppose seven attempts produce six complete answers and one request error. Two complete answers name your product, one cites your documentation, and two have no displayed sources. Report: 2/6 answers mention the product; 1/6 cites the documentation; 2/6 have no displayed sources; 1/7 attempts failed. An answer with no sources is still an answer. A failed request is not a brand omission.
For every follow-up, preserve these counting rules and the original prompt. If the assistant changes its mode or exposes a different source interface, annotate the change before comparing periods.
Check product eligibility before looking for a content problem
Read the recommendation against maintained product evidence. Can your product satisfy each requirement today? Where is that capability documented? Does the answer preserve the relevant plan, permission and version restrictions?
A fictional vendor might support replay but only through an internal engineering tool. That is different from support-team replay. A pricing page might advertise self-serve access while the feature reference places replay on a contracted plan. Treat that disagreement as an unresolved product-information problem until an owner establishes the applicable rule.
Use four review outcomes:
| Outcome | Evidence needed | Appropriate next step |
|---|---|---|
| Eligible and correctly described | Current sources support the requirements and the answer preserves them | Investigate the remaining visibility difference |
| Eligible but incorrectly described | Current sources contradict a material statement in the answer | Save the claim, supporting passage and dated correction |
| Ineligible for this task | A documented restriction prevents the required use | Accept the exclusion and clarify the supported alternative |
| Unresolved | Evidence is missing, conflicting or too vague | Ask the product owner; avoid assigning an accuracy verdict |
This step prevents a visibility project from rewarding an unsuitable recommendation. It also gives product marketing a more useful brief than “get us into ChatGPT.”
Inspect access at the page level
For Google AI Overviews and AI Mode, Google documents that a supporting page must be indexed and eligible to appear with a snippet. It also says eligibility does not guarantee serving. Those are Google-specific conditions, not a complete description of other assistants. Google Search Central: AI features and your website[3].
Check the page that contains the required fact. Inspect its status, rendered text, indexing settings, canonical destination and access restrictions. A successful homepage request does not establish that an application reference or pricing tab is available.
For another assistant, use the provider's relevant access documentation. Our ChatGPT crawler guide and Claude crawler guide explain the distinctions between search crawling, user-directed retrieval and training-related access.
A request using a copied crawler name is a server-behavior test. It is not proof that an authenticated provider request reached the page. Save the tested URL, method, response and date so an engineer can reproduce a failure.
Route an access finding to the right check
| Finding | Check next | What passing establishes |
|---|---|---|
| The page requires login or returns an error | Final response and body at the exact URL, including redirects | That request can reach the intended content |
| A page loads but the relevant fact is absent | Rendered body, hidden tabs and canonical destination | The fact is available on the tested page |
| Google cannot index the page | Search Console URL Inspection, indexing directives and selected canonical | Google’s reported indexing state; record the inspection date |
| A provider appears blocked | Its documented search-crawler policy and verified request logs, if available | Access for the provider request you can actually verify |
| Access checks pass but the page is never cited | Saved answers and cited alternatives | The omission remains unexplained by these access tests |
Send engineering the URL, timestamp, reproduction and expected text. Avoid changing training-crawler permissions as a generic fix for a search problem. The linked provider guides explain which access controls serve which purpose.
Read what the cited sources actually contribute
Now inspect each source shown in the saved answer. Record the final destination after redirects, the relevant passage and the role it plays: product fact, implementation example, comparison, first-hand experience or background explanation.
One frequently cited domain may contain an excellent product test, an outdated comparison and a community thread that never mentions your category. Those pages deserve separate decisions.
For a comparison page, ask whether its inclusion criteria match the customer's requirements. For a tutorial, try the steps or inspect the demonstrated version. For a forum post, distinguish an author's report from an established limitation. If you cannot access a cited source, mark it unreviewed; the citation alone does not verify its contents.
Microsoft's AI Performance announcement[4] describes cited-page and sampled grounding-query reporting for supported Microsoft AI experiences. Such records can add evidence to a review. They should retain their platform scope and should not be relabeled as private Google searches or customer prompts.
For the distinction between observed searches and generated research ideas, see query fan-out explained.
Turn the finding into a small, verifiable work item
An audit item should name the claim, the page and the condition a reviewer will check.
Weak brief: Publish an article about webhook replay to improve AI visibility.
Useful brief: The replay reference does not state which role can initiate replay. Confirm the supported roles with engineering, publish the rule beside the replay instructions, and test the procedure using that role. Link the plan restriction to the applicable feature.
If a third-party comparison is wrong, prepare a factual correction with the exact passage and maintained source. The publisher decides whether and how to update its article.
If the evidence is already clear and accessible, retain “cause unresolved” as a legitimate result. Avoid filling an unexplained gap with an unsupported instruction to add schema, repeat a phrase or publish dozens of similar pages.
Worked audit: an incorrect replay limitation
This completed record is fictional. The URLs use the reserved .example domain, and the quoted passages illustrate the evidence a real audit would need to preserve.
| Field | Completed example |
|---|---|
| Customer decision | A support lead needs to recover failed webhook deliveries without engineering access |
| Prompt | Which webhook delivery services let a small support team inspect and replay failed events on a self-serve plan? |
| Test conditions | One consumer assistant in web-search mode; fresh conversations; same prompt; six complete answers over three days; one request error logged separately |
| Observation | Two of six answers name the fictional RelayDesk; one cites its documentation. A saved answer says “RelayDesk replay requires an Enterprise plan” |
| Owned evidence | relaydesk.example/docs/replay: “Support admins can replay retained events on the Team plan.” Pricing confirms Team is self-serve; role reference confirms support-admin permissions |
| Third-party evidence | delivery-review.example/webhook-tools still says replay is Enterprise-only. It is displayed as a source in the incorrect answer |
| Eligibility verdict | Eligible under the documented role and plan; the answer’s Enterprise-only qualification conflicts with current evidence |
| Verified finding | The third-party comparison is outdated. Its causal contribution to the assistant’s answer remains unknown |
| Action and owner | Product marketing submits the precise correction and maintained references to the publisher; documentation owner adds a direct plan-reference link beside replay instructions |
| Acceptance condition | The owned references agree, the support-admin procedure works, and the correction request includes the exact disputed passage. Publisher acceptance is recorded separately |
| Follow-up | Repeat the fixed prompt under recorded conditions. Count factual accuracy, recommendations and cited URLs separately; preserve any product/mode change |
The decision is to correct a demonstrably stale statement. It is not to commission another general webhook article. If the comparison already described the plan correctly, this same observation would need further investigation.
If you uncover an outside-source problem, use the third-party contribution guide to prepare the publisher brief. For a missing owned reference, use the content-assignment workflow.
Use this citation-gap worksheet
Copy one record for each material finding. Keep source evidence adjacent to the proposed action.
| Field | Record |
|---|---|
| Customer decision and evidence of demand | Customer's task; link to the research or support record |
| Exact prompt and test conditions | Submitted text; engine; mode; time; location; personalization notes |
| Observation | Named brands; recommendation; displayed sources; valid runs and failures |
| Requirement and product eligibility | Capability; plan; permission; version; qualifying source |
| Claim being reviewed | Exact answer passage and supporting or conflicting evidence |
| Access check | Specific URL; tested response; indexing or access finding |
| Cited-page review | Exact source URL; passage; source role; reviewed or unavailable |
| Proposed action | One correction, investigation or maintained-page improvement |
| Acceptance condition | What a reviewer can verify independently |
| Follow-up | Date; same-prompt results; denominator; remaining uncertainty |
Evaluate the correction and the next answers separately
First verify that the intended change shipped and works. Then rerun the saved questions under the recorded conditions. Compare factual correctness, qualification, recommendations and citations separately.
If a hypothetical follow-up names your product in four of six runs instead of two, report that change with both denominators. A page edit, model change, different source set or ordinary output variation could contribute. The before-and-after observation does not identify the cause on its own.
End the review with an evidence-backed decision: keep the correction, investigate a conflicting source, improve a distinct missing procedure, or continue observing an unexplained omission.
Continue the work in EarShots
Explore Prompt Universe to organize the questions and answer evidence your team wants to review. Bring a real customer decision and the product references needed to evaluate it. Use the worksheet above to keep the audit reproducible regardless of which monitoring tool you use.
Method and updates
Research checked October 29, 2026. This guide proposes an editorial audit method; it reports no original engine experiment or customer results. All webhook examples and run counts are hypothetical. Platform claims apply only to the linked surfaces. The workflow and counting rules are EarShots editorial recommendations, not a validated predictor of future citations.
Sources
- Web search. OpenAI. API citations, consulted sources and supported approximate-location settings.
- Web search tool. Anthropic. Claude API source-citation fields and user-location configuration.
- AI features and your website. Google Search Central. Google AI-feature eligibility and the limits of inclusion guarantees.
- AI Performance in Bing Webmaster Tools. Microsoft Bing. Microsoft AI citation and sampled grounding-query reporting.
Download the blank working records for all four guides.