Eligibility Is Not Preference: What AI Search Requirements Actually Mean

A page can pass every technical check and still be absent from an AI answer. Understanding what each check proves changes what you should do next.

For a webpage to qualify as a supporting link in Google's AI Overviews or AI Mode, it must be indexed and eligible for a search snippet. Google specifies no additional technical requirements for these features. That establishes a route into the candidate pool; it does not establish which page an answer will select. A useful generative engine optimization (GEO) audit therefore separates documented requirements, recommended practices, and unproven optimization hypotheses. It also distinguishes the current page from the version a search engine has processed. Those distinctions help teams choose between fixing access, improving evidence, and investigating performance without treating every missing citation as a technical failure. Google's AI features guidance

Imagine a manufacturer that has rebuilt its English website. Product pages load successfully. A technical audit reports no obvious crawl restrictions. Structured data validates. The team asks an AI search service about suppliers in its category and receives an answer that names other companies.

The temptation is to look for one more missing requirement: another file, another schema type, another change to the opening paragraph. The audit was green, so something must still be keeping the company out.

That diagnosis moves too quickly. An implementation check establishes only what it actually tested. It cannot tell a team why a particular answer selected a competing source, whether the tested question represents a real buyer's task, or whether a different page would have been a better source. Those are separate questions, with different evidence requirements.

What Google actually requires

The clearest starting point is Google's documentation for AI Overviews and AI Mode. Its stated eligibility conditions concern indexing and snippet availability, alongside the existing requirements and policies for Search. The same guidance says publishers do not need special AI files or additional schema.org markup to appear in these features. This is a statement about Google's named search experiences; it is not a specification for every product that generates answers from the web. Google's AI features guidance

One level below that, Google's technical requirements for indexing are concrete: Googlebot must be able to access the page, Google must receive a successful HTTP 200 response, and the page must contain indexable content. Meeting those conditions makes indexing possible; Google explicitly leaves the indexing decision open. Google Search technical requirements

This creates two questions that are easy to collapse. Is the page technically capable of being indexed? Has it actually been indexed? A successful response from the live website helps answer the first. It does not, by itself, settle the second. Treating those states as interchangeable can send a team straight into rewriting content when it has not yet established what version the search engine holds.

The unit of investigation should also be the relevant page. A functioning homepage tells you little about a product specification hidden behind a login, an English translation published under a different URL, or a downloadable document served with different response headers. A site can contain pages in several different states at once.

Why passing a requirement does not explain selection

Eligibility is a necessary-condition claim. Selection is an outcome under particular circumstances. Passing a prerequisite does not determine the outcome; failing a relevant prerequisite may eliminate a particular route to it.

Google's broader account of Search makes the distinction visible: discovering and processing pages precede the decision about what to return for a query. Relevance and quality matter at serving time, and factors such as language and location can affect the results. Google also explains that an indexed page can be absent from results because its content does not suit the query. How Google Search works

Consider a page describing a company's history and another documenting one product's operating limits. Both might be eligible to appear. A question about the company's founding calls for different evidence from a question about whether the product meets a buyer's operating conditions. The pages' eligibility does not resolve that difference.

The practical inference is that a missing citation has several possible explanations. The relevant material may be unavailable, it may not yet be represented in the engine's processed version, or the answer may have selected other material. The observed absence alone does not identify which explanation is correct.

The reverse observation is limited too. A citation establishes that a page appeared in the answer you recorded. It does not establish that the system endorses the company, that the cited text supports every nearby claim, or that the visit will produce a qualified inquiry. Each additional conclusion requires another check.

Separate requirements, recommendations, and hypotheses

A useful GEO checklist should make the strength of each claim visible. The following classification is an editorial decision tool, not a description of a proprietary ranking algorithm.

These categories prevent a reasonable recommendation from quietly becoming an invented admission rule. For example, Google's content guidance asks publishers to assess originality, completeness, sourcing, and demonstrated knowledge. These are useful editorial questions. The document does not turn them into a public formula that assigns a citation probability to a paragraph. It also rejects the idea that Google has a preferred word count. Google's people-first content guidance

An editor can therefore have a strong reason to replace vague claims with verifiable information without promising a measured increase in AI visibility. The immediate result is a more useful page. Whether the change alters source selection remains an empirical question.

The same discipline applies to a vendor's audit score. Ask which findings correspond to documented requirements, which reflect the vendor's judgment, and which have been tested against outcomes. A score can summarize an inspection. Its numerical precision does not supply the missing evidence connecting that inspection to a commercial result.

Three checks that are easy to overinterpret

The first is a successful live inspection. Google's URL Inspection documentation distinguishes information about its indexed copy from a live test of whether a URL might be indexable. The live test cannot establish the canonical URL Google will select. Even a status indicating that a URL is on Google does not guarantee its appearance in results. URL Inspection documentation

Record what was tested and when. An indexed copy from before a repair and a successful live test after that repair describe different moments. Reading them as one current state conceals the very delay the investigation needs to resolve.

The second is a permissive robots.txt file. Crawl permission and permission to display content are different controls. Google's robots documentation says a page-level nosnippet rule prevents text snippets and prevents the page's content from being used as a direct input for AI Overviews and AI Mode. A max-snippet value of zero has the same effect as nosnippet. These directives may be delivered in page markup or HTTP headers, and crawlers must be able to access them to read them. Google's robots meta and HTTP header specifications

A review of robots.txt alone cannot establish the absence of those restrictions. Equally, finding a restriction does not mean it is a mistake. A publisher may have deliberately chosen a limited preview policy. The useful audit finding is the mismatch, if any, between the publisher's intended policy and the actual implementation.

The third is valid structured data. Google's structured data guidelines require markup to represent the visible content accurately. They also state that correct markup does not guarantee a rich result. Rich-result validation evaluates a different feature from selection as an AI supporting source. Google's structured data guidelines

A validator can help catch a malformed field. It cannot repair a missing technical explanation, confirm a manufacturer's unsupported capability claim, or tell you whether an answer will prefer that page. Structured data should describe the evidence the page provides. Treating it as a substitute for that evidence reverses its purpose.

Improve the information the question requires

Once the relevant technical conditions have been checked, the most productive editorial question is specific: what would a reader need to verify the answer to this question?

For a manufacturer, a page stating that a component offers reliable performance gives a buyer little to inspect. A more useful page identifies the product variant, states the conditions under which a specification applies, and links the claim to the appropriate test method or documentation. These changes improve the reader's ability to evaluate the product even before any search outcome is measured.

The critical work is often preserving relationships. A maximum operating value without its test conditions can mislead. A certification reference without its scope may invite the reader to apply it to products it does not cover. A company name that changes between the specification, the certificate, and the contact page creates an identification problem. Adding more prose does not automatically repair any of these weaknesses.

This is also a practical way to set a boundary around a page. It should answer its chosen question well enough that a reader can understand both the claim and its limits. If another question needs different evidence, it may deserve another page. There is no need to turn every product page into an encyclopedia of its industry.

These are editorial recommendations derived from the buyer's task. This article does not present them as experimentally established citation factors. That boundary preserves the value of the work: a clearly documented product can improve evaluation and sales conversations even when the effect on AI source selection is still unknown.

Diagnose one important page in five steps

Start with one page tied to a real customer question. The following sequence is a proposed working method; no client site was tested for this article.

1. Define the outcome and the product. Write down the exact question, the relevant URL, and the experience you are investigating. Appearing as a supporting source in Google AI Mode is a different outcome from receiving a brand recommendation in ChatGPT. Keep the language, market, and date with the observation so that someone else can interpret it later.

2. Inspect access and the response. Check the page's response and the content it actually provides, together with applicable crawl rules and delivery restrictions. A successful load in your own signed-in browser is insufficient evidence about a public crawler's access. Preserve the findings, including any uncertainty about the client that made the request.

3. Compare the live page with the indexed record. For Google, use URL Inspection to examine indexing information and the selected canonical where available. Compare the crawl date and recorded content with the repair or publication date. A live test can help investigate the current page, but it does not prove that a recent change has reached the index. URL Inspection documentation

4. Check whether the page supports the intended answer. Identify the exact passage, table, or document that answers the customer question. Verify the source of important claims and preserve their conditions. Check relevant display controls separately from access. If the necessary evidence is absent, describe the editorial gap directly instead of assigning it a speculative technical cause.

5. Observe outcomes after a defined change. Record the intervention and retain a consistent set of relevant questions. Keep technical status, observed citations, answer accuracy, and qualified inquiries as separate measures. Repeated observations can describe a pattern; attributing a change to the intervention requires stronger evidence, such as a credible comparison and consideration of changes elsewhere.

The sequence produces a decision rather than a collection of green checks:

What this looks like for an exporter

Consider a hypothetical exporter with an English product page and a separate technical PDF. The product page is indexed. The PDF contains the operating information a buyer needs, but visitors must sign in to retrieve it. The public page describes the product in general terms and provides no equivalent explanation.

Two findings matter. The product page's indexing status concerns that page. The inaccessible PDF represents a separate information boundary. Neither observation proves why any particular AI answer omitted the exporter, but together they show that the public source does not contain the evidence needed to evaluate the buyer's question.

A proportionate response would be to decide which technical facts the company intends to disclose, then publish an accurate, accessible explanation of those facts on the relevant product page. Confidential material can remain restricted. The public explanation should identify the product and make the scope of each claim clear.

The team now has something concrete to verify: the intended information is publicly available and accurately stated. Later, it can investigate whether the processed page has changed and whether observed answers use that information. Those are successive findings, each useful on its own. Announcing that the company has become preferred by AI would skip the evidence needed for the final claim.

Keep the rules specific to the product

The diagnostic logic travels more easily than the platform settings. Google indexing is the relevant starting point for the Google features discussed here. It should not be promoted into a universal requirement for every AI search service.

OpenAI's crawler documentation, for example, distinguishes OAI-SearchBot, which serves search discovery, from GPTBot, which concerns potential model-training use. Their controls are independent. The documentation also distinguishes ChatGPT-User requests from automatic search crawling. Allowing a training crawler is therefore not a substitute for making the intended search-access decision. OpenAI's crawler documentation

Measurement also varies by product. Bing's February 2026 announcement describes an AI Performance view reporting citations across supported Microsoft experiences and selected integrations. It explicitly limits what those counts mean: they do not establish ranking or placement, and the reported grounding queries are a sample. A publisher should read those fields according to their definitions rather than treat them as a universal AI visibility score. Bing's AI Performance announcement

For an international team, this means keeping a short record for each target product: the documented control, the URL being assessed, the evidence collected, and the outcome being measured. Platform names are part of the diagnosis, not labels to add after combining the data.

What a successful audit should leave behind

A successful audit narrows uncertainty. It tells the engineer which access problem was observed, tells the editor which customer question lacks evidence, and tells the analyst which outcome still needs to be measured. It should also be able to conclude that the inspected technical conditions are satisfactory without inventing a new requirement to explain an unanswered question.

The most useful deliverable is a dated record of those findings, with a clear owner for the next action. A corrected response can be verified. A claim can be traced to its source. An indexing record can be revisited. A citation can be checked in the answer where it appeared. Each is more informative than an undifferentiated label saying a website is ready for AI.

Before approving the next optimization, ask what result would demonstrate that the change worked. If the proposed answer shifts between access, citations, and sales, clarify the claim first. That small act of precision is where a technically competent GEO program becomes an accountable one.

Three questions worth keeping beside the checklist

Does every missing citation mean there is an eligibility problem? No. The absence is an outcome in a particular observation. Establish the relevant technical state before assigning a cause.

Can an AI answer mention a company without citing its website? Yes, a company mention and a citation to its own domain are distinct observations. Record the linked sources and the statement actually made before judging the company's visibility.

What should a consultant promise to deliver? A defined investigation, documented repairs or editorial changes, and measurement appropriate to the stated outcome. A technical checklist alone cannot substantiate a promise of preferential source selection.

Sources checked on September 7, 2026. This article interprets public product documentation and proposes an editorial diagnostic method. The manufacturer scenarios are hypothetical. No original citation experiment, site audit, or conversion study is reported.