If you want to audit visibility in AI-assisted search, check three separate things: whether a provider can retrieve the page, whether the page is a useful answer to a real query, and whether the provider actually cites it in a repeatable observation. Technical access and clear writing make a page eligible to be considered. Neither guarantees a citation.
This guide is a practical review of public pages, not a promise of placement. Start with the questions people ask, map them to the pages that answer them, and record the evidence you can verify.
Separate search eligibility from citations
Google says its AI features use the same foundational Search technical requirements as other search results. There is no special AI schema or required word count that makes a page eligible. The page still needs to be crawlable, indexable, useful and consistent with the searcher's task. Google's current guidance for AI features in Search explains how its existing Search guidance applies.
Eligibility is not a citation. A page can be indexed and never be selected for an AI answer. A provider can also retrieve a page without showing it for every query. Treat eligibility checks as prerequisites, then measure observed citations separately.
Check the crawler that serves the product
Do not treat every bot with an AI-related name as the same crawler. OpenAI documents separate crawlers for different purposes. OAI-SearchBot is used to surface sites in ChatGPT search. GPTBot relates to model training, and ChatGPT-User is associated with user-initiated visits. Their purposes and robots.txt controls differ.
Review your robots.txt rules, edge firewall, bot protection, server logs and any CDN challenge page for the specific crawler you intend to permit. A robots.txt directive is a request to cooperative crawlers, not an access-control mechanism. If you intentionally restrict training access, check that the separate search crawler remains configured as intended. Test the actual public URL and response instead of inferring access from a rule alone.
For Google, inspect the same ordinary access signals you would audit for Search: response status, robots directives, canonical destination, internal discovery and rendered main content. For any provider, confirm that the response is not a login screen, empty shell, bot challenge or stale redirect. Use the complete website audit checklist for the broader crawl and template review.
Make the page answerable and checkable
Write the direct answer close to the start of the relevant section, then explain the conditions, exceptions and steps needed to apply it. Headings should identify a real subtask, not repeat a keyword phrase. Use stable names for products, places, people or concepts so a reader can tell which entity a sentence describes.
Specificity is useful when it is supported. State the scope of a recommendation, describe how a reader can reproduce a check, and link to the primary source for claims that can change. If a statement comes from your own research, show the method and date. Do not add invented statistics, broad “expert” claims or filler FAQs to make a page appear authoritative.
Original evidence can be a documented procedure, a clearly described observation, a comparison with stated limits or a first-hand dataset you are permitted to publish. Attribution lets readers follow the evidence; it does not require adding markup that has no visible counterpart. Structured data should describe the page accurately, not act as a special pass into AI answers.
Map questions to pages before editing
Gather queries from customer questions, support requests, sales conversations, site search or search reports that you can actually access. Group close variants by the task behind them. Assign one useful destination to each group, and record whether that page already answers the question.
| Query or question | Reader's task | Best existing page | Direct answer present? | Evidence or gap |
|---|---|---|---|---|
| How do I check whether a WordPress page is indexable? | Diagnose a specific platform setting | WordPress audit guide | Yes or no after review | Visibility setting, response, canonical |
| What does a poor INP field result mean? | Find the interaction causing delay | Core Web Vitals guide | Yes or no after review | Field segment and reproducible interaction |
| How can I tell whether an enquiry was received? | Verify a completed action | Full audit checklist | Yes or no after review | Confirmation state and receiving-system record |
These are example prompts for organizing a review, not evidence that any provider has shown a particular answer.
Review access, content and attribution in order
- Choose a small set of important public pages and write the question each one should answer.
- Fetch each exact URL without a signed-in browser. Record its response, redirect, canonical, robots state and whether the main answer appears in the delivered page.
- Check internal links and the sitemap for the intended public URL. Correct duplicates or missing destinations before rewriting copy.
- Read the page against the query. Add the missing explanation, limits, original evidence or attribution instead of adding generic AI language.
- Check that visible claims, author information, dates and any structured data agree.
- Retest the same URLs after a change and keep the previous version or source revision available for comparison.
Keep an observation worksheet
Use the same provider, query wording, locale, date and signed-out conditions when you compare observations. Save the answer and cited URLs when the product allows it. Record “not observed” rather than guessing why a page was omitted.
| Date and provider | Exact query and locale | Page intended to answer | Citation observed? | Cited source URL | Context or limitation |
|---|---|---|---|---|---|
Separate direct referral sessions from a citation seen during a manual check. Analytics may show identifiable referrals when a provider sends them, but a referrer report will not reveal every answer view or every citation. Search reports also do not necessarily provide a complete provider-by-provider citation log. Note gaps in the measurement rather than presenting partial observations as total visibility.
Do not use a language-model simulation as proof that a live search product found or cited a URL. A simulation can help draft questions or critique clarity. It cannot replace an observation in the named search product with the query and date recorded.
Worked example, explicitly hypothetical
Imagine a fictional repair shop that wants to answer “How do I know if my site needs a WordPress SEO audit?” Its current service page says it improves SEO but does not explain what is checked. The reviewer first verifies that the page is public and that the main copy loads, then maps the question to the service page and the detailed WordPress guide.
The page is revised to describe the actual review areas, the limits of the service and the evidence a site owner can prepare. The reviewer records the exact query in two chosen products on separate dates, saves any visible citations and labels absent observations as such. If a citation appears once, that is a useful observation, not proof of a guaranteed or durable ranking. No customer result is implied by this fictional example.
What not to change for AI search
Do not add FAQ or HowTo markup solely because an AI system exists, invent an answer page for every wording variant, block all non-Google crawlers without checking the business goal, or rewrite accurate content into vague keyword patterns. Google AI feature eligibility remains grounded in ordinary Search eligibility. Search access, training use and a user-requested visit are separate crawler purposes for OpenAI.
Your next step is to select three important questions and fill in the query-to-page table with evidence from your own site. For loading and interaction findings, follow the Core Web Vitals diagnosis guide.