A page is technically eligible to appear as a supporting link in AI Overviews or AI Mode when four things are true: Googlebot can crawl it, Google has indexed it, it is allowed to show a snippet, and the site has not opted out of Search generative AI features in Search Console. That is the whole technical list Google publishes. There is no AI-specific markup, no special file, and no separate crawler to allow.
The list is short, which is why it is easy to fail without noticing. Each condition can be broken by a setting made for a different reason: a CDN rule, a template noindex, an old max-snippet value, a Search Console toggle on a parent property. This post takes them one at a time, then lists what doesn’t affect eligibility at all.
Eligibility is a floor. It says a page can be selected, not that it will be.
What does Google say the requirements are?
Google’s documentation on AI features states that to be eligible as a supporting link in AI Overviews or AI Mode, “a page must be indexed and eligible to be shown in Google Search with a snippet,” and that “there are no additional technical requirements.” The same page says you don’t need “to create new machine readable files, AI text files, or markup to appear in these features,” and that “there’s also no special schema.org structured data that you need to add.”
Google’s newer guide, Optimizing your website for generative AI features on Google Search, repeats the indexing and snippet requirement and adds one more: “a site must be included in Search generative AI features in Search Console.” That refers to a site-level control Google says it rolled out “to all websites worldwide” as of 31 August 2026. Inclusion is the default, so for most sites this is not an extra step. It is an extra place for an exclusion to hide.
Put together, the requirements stack like this. Each one depends on the one above it.
| # | Requirement | What breaks it | Where to check |
|---|---|---|---|
| 1 | Googlebot can crawl the URL | robots.txt disallow for Googlebot; CDN or firewall blocking Google’s crawlers | robots.txt, URL Inspection live test |
| 2 | The URL is indexed | noindex; non-200 status; no indexable content; canonicalized elsewhere | URL Inspection, Page indexing report |
| 3 | The URL may show a snippet | nosnippet; max-snippet:0 | View-source, response headers |
| 4 | The site is included in Search generative AI features | The Search Console control set to exclude, on the property or a parent | Search Console → Settings |
Can Googlebot reach the page?
Googlebot is the crawler for AI Overviews and AI Mode, because these features are part of Google Search. Google’s documentation says “robots.txt directives for Googlebot is the control for site owners to manage access to how their sites are crawled for Search.” There is no separate AI search crawler to allow, and no way to let Search in while keeping the AI features out through robots.txt.
Google-Extended is the token people most often reach for here, and it is the wrong one. Google’s crawler documentation states that Google-Extended “does not impact a site’s inclusion in Google Search nor is it used as a ranking signal in Google Search.” It governs Gemini model training and grounding. GPTBot vs OAI-SearchBot has the full map of which token controls what, and Training vs. retrieval crawlers covers why Google is the one vendor where the training and search decisions can’t be separated by crawler.
The second half of access is the network layer. Google’s list of best practices includes “ensuring that crawling is allowed in robots.txt, and by any CDN or hosting infrastructure.” When your CDN or firewall blocks bots robots.txt allows covers that failure in detail.
By hand: open /robots.txt on the host that serves the page and read the group that applies to Googlebot (or *, if there is no Googlebot group). Then run a live test in Search Console’s URL Inspection tool. The live test fetches the page in real time and reports Crawl allowed? and Page fetch, so it can catch a server or CDN refusal that reading the file never will. One caveat: Google says the live test uses Google-InspectionTool, not Googlebot, so a rule written against the Googlebot string specifically can treat the two differently.
Is the page indexed?
The page has to be in Google’s index, and Google’s technical requirements for that are three: “Googlebot isn’t blocked,” “the page works, meaning that Google receives an HTTP 200 (success) status code,” and “the page has indexable content.” Meeting them makes a page eligible for indexing; it doesn’t guarantee it.
The usual causes: a noindex meta tag or X-Robots-Tag header left over from staging, a soft 404, a redirect, or a canonical pointing to a different URL so that the other URL is the one indexed. Status codes, redirects, and canonical drift on AI surfaces walks through each.
Content that only exists after JavaScript runs is a softer case: Google’s generative AI guide says Google “is able to process content within JavaScript as long as it isn’t blocked,” but rendering is a step that can fail. JavaScript content and what never makes the trip covers the difference across crawlers.
By hand: URL Inspection’s indexed view reports whether the URL is on Google, the user-declared and Google-selected canonicals, and Indexing allowed? If the Google-selected canonical differs from the URL you inspected, the eligible page is the other one.
Is the page allowed to show a snippet?
This is the requirement most often broken by accident, because snippet directives predate the AI features. Google’s robots meta tag documentation states that nosnippet applies to “AI Overviews, AI Mode” and “will also prevent the content from being used as a direct input for AI Overviews and AI Mode.” It defines max-snippet:0 as “No snippet is to be shown. Equivalent to nosnippet.”
Two things follow:
- A page with
nosnippetormax-snippet:0can be indexed and rank in ordinary results while being ineligible as a supporting link. - A positive
max-snippetvalue is not an exclusion, but Google says it “will also limit how much of the content may be used as a direct input for AI Overviews and AI Mode.”
data-nosnippet works at element level and does not remove the page from eligibility; it removes the marked text from what can be used.
By hand: open view-source: and search for robots. Then open the browser’s developer tools, reload, select the document request in the Network panel, and read the response headers for X-Robots-Tag, which never appears in the HTML.
Is the site included in Search generative AI features?
Search Console now has a property-level setting, under Settings → Search generative AI, with two options: “Include my site’s links and content in Search generative AI features” and “Exclude my site’s links and content from Search generative AI features.” Google’s help page describes inclusion as “the default control for all properties,” and says the control covers AI Overviews, AI Mode, and generative AI features in Discover.
Three details matter for an audit:
- Inheritance. Child properties, such as a URL-prefix path or a subdomain property, inherit from the closest parent by default and can override it. An exclusion set on a parent property applies to every child that has not overridden it.
- It is not a ranking control. Google says the control “isn’t used as a ranking or inclusion signal affecting other parts of Search.”
- It is not a training control. Google says it doesn’t affect AI training, and points to
Google-Extendedfor that.
Google says excluded content drops out “within 1-2 days after the control goes live,” with some content taking longer because of caching.
What doesn’t affect eligibility?
Google’s own documentation rules out several popular recommendations by name.
| Often recommended | Effect on eligibility | Google’s statement |
|---|---|---|
| Schema.org markup for AI | None | ”There’s no special schema.org markup you need to add.” |
llms.txt or other AI text files | None | Google Search “doesn’t use them” and ignores them. |
| Splitting content into small chunks | None | ”There’s no requirement to break your content into tiny pieces.” |
| A target page length | None | ”There’s no ideal page length.” |
Allowing or blocking Google-Extended | None for Search | It “does not impact a site’s inclusion in Google Search.” |
None of this makes structured data or clear structure worthless. Google still recommends structured data “as part of your overall SEO strategy,” and lists “making sure your structured data matches the visible text on the page” among its best practices, alongside internal links, page experience, and textual content. Those are quality considerations for an eligible page, not gates. llms.txt: what it is, how it works, and whether to bother covers the case for that file on surfaces other than Google.
How do you check eligibility across a site?
At scale, the four requirements become four columns in a spreadsheet. Search Console fills two, a crawler export fills one, and the fourth is a settings check.
From Search Console, no crawler needed. The Page indexing report lists URLs that are not indexed, with the reason: “URL marked ‘noindex’,” “URL blocked by robots.txt,” “Alternate page with proper canonical tag,” “Duplicate, Google chose different canonical than user,” and the rest (Page indexing report). Export the example URLs for each reason. That covers requirements 1 and 2 for every URL Google knows about. Requirement 4 is a settings check on each property, done once.
From a crawler export. Crawl with any desktop crawler and export status code, indexability, meta robots, and the X-Robots-Tag header. Filter the meta robots and header columns for nosnippet and max-snippet:0. That is requirement 3, which Search Console doesn’t report. If your crawler supports custom extraction, add //meta[@name='robots' or @name='googlebot']/@content so the Googlebot-specific tag is captured too.
From a terminal, for a single URL’s headers:
curl -sI https://example.com/page/ | grep -i x-robots-tagGEOBee’s grid carries an Index column (whether the page is indexable) and a Status column per URL, and the Readiness coverage panel reports the share of pages that are indexable (The Overview & grid). It doesn’t read your Search Console settings, and its AI bot access check covers the AI crawlers listed in the three lenses, so the Googlebot live test and the Search generative AI setting stay manual steps. How to check whether AI crawlers can actually reach you has the equivalent checks for the other vendors’ crawlers.
What eligibility buys you, and what it doesn’t
Eligibility is binary and deterministic. Selection is neither. Google’s guide says that even with every requirement met, crawling, indexing, and serving aren’t guaranteed, and AI Overviews and AI Mode may use a “query fan-out” technique that pulls supporting links from many related searches. Which page gets picked is decided by Google’s systems, not by a checklist.
What the checklist does is remove the reasons a page cannot be picked at all. They are invisible in ranking data and usually one line to fix, which makes them the first thing to clear in any audit of AI crawler access, before anything that depends on content.
If you want indexability, status, and AI crawler access checked for every URL in one pass, download GEOBee and run the 7-day trial on your own site.