AI Search Visibility Audit: Find What’s Holding Your Website Back

What should an AI search visibility audit deliver?

An AI search visibility audit should produce an evidence log and a prioritized set of changes. For each important page, record what a crawler can retrieve, what an indexing report shows, what a saved answer actually cites and what visits you can attribute. Keep those observations separate so a successful technical check cannot silently become a claim about commercial visibility.

This guide is for a B2B team that needs to decide what to fix next. It concentrates on the audit record and the handoff to implementation. Start with a service page and its supporting guides, or another small group of pages with one commercial purpose. A ten-page review with complete evidence can support a decision; an unlabeled sample presented as a whole-site audit cannot.

Our working example shows the distinction. On September 27, 2026, Cendar Lab checked 57 sitemap URLs after a release. All returned HTTP 200 and exposed a title, an H1 and the expected canonical. That supported a narrow conclusion about delivery and metadata. We had no corresponding Search Console export, saved AI-answer sample or conversion report in that check. Their status remained unmeasured.

References: Cendar Lab — Public URL release check, September 27, 2026

Set one audit question and a stable page set

Write the decision before collecting data. For example: ‘Can someone comparing our workflow integration service find a useful explanation and reach the inquiry page?’ Name the service URL, the supporting articles, the country and language, and the observation period. This prevents the audit from expanding into every query containing AI.

Give each page one primary job. A service page explains a purchasable engagement; a guide helps someone make or implement a decision. Record both where the relationship is useful. If two articles answer the same question, examine their contents and existing search evidence before drafting a third one. A new keyword spelling alone is not a distinct user need.

For repeat observations, keep the original page set and label additions. Record template or URL changes that could affect comparability. If a page moves, retain its old address, redirect target and reason. An audit needs enough history to explain why the same request now reaches a different document.

Use four evidence layers

The four layers below are Cendar Lab's reporting convention. They help a reviewer see where a claim is supported and where another observation is still needed. They are not a scoring system and do not describe every internal step used by a search platform.

Keep impressions distinct from these records too. An impression reported by a platform is an observation under that platform's counting rules. It is not a saved copy of the answer, a verified endorsement of a claim or proof that a person visited the site.

Check access and indexing with different records

Request the public page and retain the final address, HTTP status and the content you received. A 200 response can still contain an error page, challenge screen or empty application shell. Read the heading and the substantive answer in the returned or rendered page. Compare the canonical with the intended address and check the route from another public page.

In Search Console, inspect the indexed result and, when investigating a current change, run the live test. Google's documentation distinguishes these views: indexed data describes the version known to Google, while a live test examines current accessibility. A successful live test does not guarantee indexing and cannot predict Google's canonical selection. Save the view and its timestamp with the finding.

When server logs are part of the evidence, verify crawler identity before labeling traffic as Googlebot. Google's documented methods use published IP ranges or reverse DNS followed by forward DNS confirmation. A matching user-agent string alone is not that verification. Even a verified request establishes a fetch, not a citation or a human visit.

References: Google — URL Inspection toolGoogle — Verify requests from crawlers and fetchers

Check the current Google AI report and inclusion control

Google now documents a Generative AI performance report for Search covering impressions in AI Overviews and AI Mode. Its help page describes page, country, date and device dimensions, and says the rollout reached websites worldwide on August 31, 2026. Check the report available in your property and retain its filters. Do not reinterpret these impressions as AI-only clicks, conversions or query-level observations.

The same help page warns about missing reports, aggregation differences and export behavior: values displayed as unavailable can become zeros in the download. Preserve a note about availability beside the export. A page-table sum can differ from the property total. An absent report or unavailable value should remain unknown in your audit until you establish what it means.

Also inspect Settings > Search generative AI. Google documents inclusion, exclusion and inherited settings, including inheritance from a parent property. Record the effective choice and property scope. Exclusion from these features is distinct from blocking all Search or controlling model training. Inspect first; a configuration change should follow the site's actual publishing policy.

Older guides may discuss only the combined Web performance report. Date your reporting method and use the current feature-specific help page. For Cendar Lab's release example, no authenticated property was inspected, so the report and effective inclusion setting remain unverified. Documentation availability is not evidence of a particular site's account configuration.

References: Google — Generative AI performance report (Search)Google — Search generative AI control

Sample answers without overstating the sample

Choose questions from actual customer conversations, on-site needs and search queries you are permitted to use. Include a factual question, a comparison and an implementation question tied to the page set. Write down the exact wording, product surface, language, location where known, session conditions and date. Decide the observation schedule before seeing the results.

For each completed observation, retain the answer and the exact citation destination when permitted. Open the cited page and identify the passage that supports the answer. Record a mention without a link separately from a citation. If the service errors or provides no usable observation, retain that state rather than quietly removing the attempt or counting it as a successful absence test.

Report the raw counts with the denominator: for example, ‘the domain was linked in 4 of 12 completed observations in this scheduled sample.’ Those fictional numbers describe a sample statistic, not market share. If you change the questions or platform settings, begin a new series or label the break. Repeating a prompt until the brand appears produces a different, biased record.

Download the evidence worksheet

Use one row for one claim about one URL in one observation context. A row can be observed, contradicted, unmeasured or excluded from scope. Add the evidence location, its limit, an owner and a next check. The blank CSV below has the same columns as this worked table; all four rows in the table are fictional examples.

Store exported reports and saved answers in an access-controlled project folder. Use filenames or internal record IDs in the worksheet, not account tokens, private customer questions or public links to sensitive data. If you distribute a report, include only the supporting material the recipient is authorized to see.

Download the blank AI search evidence log (CSV)

A real release check: 57 accessible URLs, discovery unmeasured

Our downloadable September 27 snapshot records checks at 23:50 UTC for the 57 URLs in Cendar Lab's then-current sitemap. Each row contains the public URL, response status, title, canonical, H1-presence flag and a repeated-brand check. The recorded responses were 200, each H1 flag was true and each canonical matched the expected public address. This is a historical snapshot of the release, not a continuous monitor.

The decision supported by that record was to close the release's HTTP and metadata checks. It did not establish that Google had selected those canonicals, that an AI system had cited the articles, or that a visitor had contacted us. Those questions need their own evidence. Even the H1 flag only records presence; it does not certify the heading's usefulness or the article's accuracy.

This is also why a high technical score should not be renamed a visibility score. A team can complete a valid release check and still have an unfinished discovery audit. Report the completed layer, then assign the missing observations. The source snapshot makes that boundary inspectable by another reviewer.

References: Cendar Lab — Public URL release check, September 27, 2026

Turn findings into changes with a clear acceptance check

Sort the log by consequence and certainty. A confirmed error preventing access to an important page deserves a concrete fix. A missing data export needs an evidence-gathering task. A weak explanation needs editorial work. Treat these as different kinds of work instead of averaging them into one percentage.

For a technical finding, state the request that failed and the result that will close it. For an editorial finding, identify the unanswered decision and the evidence that the revision must provide. For a measurement gap, name the authorized source and required dimensions. Assign an owner and review date. Avoid a task such as ‘improve AEO’ with no observable completion condition.

Google's current guide emphasizes useful original content, accessible pages and ordinary SEO practices. It does not require an AI-specific schema or an llms.txt file. Choose changes because they help readers or repair a verified technical problem. Adding a file cannot substitute for a missing answer or a broken page.

References: Google — Optimizing for generative AI features

Recheck the fix, then observe outcomes

After a release, repeat the check that originally failed and record the new result against the original row. Keep the earlier evidence. A reviewer should be able to see what changed and why the finding is closed. If the result is still unknown, leave it open with a reason rather than marking it passed because the code deployed.

Measure subsequent indexing, impressions, citations and visits on their own schedules. Record simultaneous changes to content, navigation, tracking and platform settings. A rise after a release can suggest a useful follow-up, but the sequence alone does not establish which change caused it. Use comparable periods and the same sample definition where possible.

The final audit handoff should fit in a short decision note: scope, confirmed findings, completed changes, unresolved evidence and the next review date. Attach the log for detail. The person who approves the next piece of work should be able to distinguish what the team knows from what it plans to investigate.

From an audit finding to a decision queue

An audit finding becomes useful when someone can act on it and check the result. Give each finding one owner, one next action and one condition for closing it. Keep the original observation attached so the next person can see why the task exists.

Consider this hypothetical example. A service page describes an audit as a ‘complete visibility solution,’ but it does not explain what the client receives. The observation is about missing information on that page. It does not prove that the page has lost traffic or that an AI system has ignored it.

The next action could be to add a short scope section: pages included, evidence reviewed, deliverables, exclusions and the process for agreeing on implementation. The editorial check is straightforward: can a reader identify those elements in the published page? Search and commercial outcomes would need separate observation over time.

Do not close a finding simply because a task moved to done. Save the revised page, record what was checked and note any remaining uncertainty. If the correction depends on another team, keep that dependency visible instead of treating the delay as a failed outcome.

Start with one important page. A small, complete decision queue is easier to use than a large list of recommendations with no owner or follow-up. Use the related AEO readiness checklist to choose one finding to turn into a checked action.