Google AI Mode: 132 of 1,083 home pages sent the directive that governs it, and 3 limited anything

What controls whether your content appears in Google AI Mode?

Two things, read at different moments, and only one of them is on your page. Google's crawler documentation is explicit about the first. Google's page on its common crawlers, Last updated 2026-07-14 UTC, states that Google-Extended is a standalone product token publishers can use to manage whether content Google crawls may be used for training future generations of Gemini models that power Gemini Apps and Vertex AI API for Gemini, and for grounding in Gemini Apps and Grounding with Google Search on Vertex AI. The same entry 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. AI Mode is a Google Search surface. AI Overviews is a Google Search surface. Neither is named in that scope.

The second is the snippet directive, and it is the one the robots meta tag page ties to both surfaces by name. This matters because the two controls are not substitutes and are not even about the same thing. Google-Extended governs Gemini's training and the grounding of Gemini Apps. The snippet directives govern how much of your text Google may take as a direct input when it composes an answer in Search. A site can block Google-Extended at the root and still be quoted at length inside an AI Overview, which is the configuration this blog described when it reported that AI Overviews retrieved less from Google-Extended blockers without their disappearing from the surface, and the distinction is the same one behind how to get cited by Gemini through one token covering two systems.

There is a third control and it is not on your site at all. Google began testing a Search Console setting in June 2026 that excludes a property from AI Overviews and AI Mode, which this blog wrote about under the finding that the AI Overviews opt out does not live on your site. It is an account setting inside an authenticated dashboard, so no external scan can see whether it is set, including this one. Everything measured below is therefore the on-page layer only, and a site could be opted out at the account level while sending max-snippet:-1 on every page. The two statements do not contradict each other and this measurement cannot see the first.

What a reader can take from the documentation, before any count, is that the on-page lever is narrow and precise. It does not say a crawler will stay away. It says the text will not be used as a direct input, or will be used only up to a character budget you set. That is a different kind of control from the gate that two layers decide if AI can read your site describes, and it sits strictly after it.

How many sites set a snippet limit at all?

132 of the 1,083 readable home pages sent either nosnippet or max-snippet. That is the headline count and it overstates the position badly, because 129 of those 132 set max-snippet to -1. Google's documentation defines -1 as a special value meaning Google will choose the snippet length that it believes is most effective to help users discover your content and direct users to your site. It is the default behaviour spelled out as an instruction. A page sending it has told Google exactly what Google was going to do anyway, which means the count of pages in this corpus that have used the documented AI Mode lever to reduce anything is three.

The three are worth naming individually, because each used a different mechanism. iitb.ac.in, the Indian Institute of Technology Bombay, sent index, follow, nosnippet, noimageindex, notranslate, max-image-preview:standard in a single meta named robots. It is the only nosnippet in the whole corpus, and under Google's documented behaviour it is the only home page here whose text is withheld from AI Overviews and AI Mode as a direct input, while still asking to be indexed and followed. derstandard.at sent max-snippet:160 in a meta robots tag, on a home page carrying 6,047 words of extractable text. france24.com sent max-snippet:300, not in a meta tag at all but in an X-Robots-Tag response header, on a page carrying 3,077 words.

Nobody sent max-snippet:0. Google's page lists 0 as a special value meaning no snippet is to be shown, equivalent to nosnippet, so there were two documented routes to the same outcome and 1,083 pages took the first route once and the second route never. The same page notes that where rules conflict the more restrictive applies, giving the example that a page carrying both max-snippet:50 and nosnippet has the nosnippet applied. No page in this corpus created that conflict, because no page sent two different snippet values.

The distribution across the sampling strata is the first clue about why the figure looks the way it does. The wordpress-smb stratum sent a snippet directive on 31 of its 37 readable pages, the highest rate anywhere in the corpus by a wide margin. media-local sent one on 16 of 30 and news on 15 of 62. At the other end, the framer, webflow and shopify-dtc strata sent a snippet directive on none of their 31, 42 and 34 readable pages respectively. That is not a story about editorial policy on AI. It is a story about which content management system writes the tag for you, and it is the same shape this blog found when counting what meta tags for AI search 1,083 home pages actually sent.

Why 129 sites set max-snippet to -1

Because something else wrote it. This is an inference rather than a measurement of intent, and the evidence for it is strong enough to state with its limits attached. The 136 occurrences of max-snippet in the corpus are not 136 independently chosen values. 122 of them carry the identical set of five directives, index, follow, max-image-preview:large, max-snippet:-1 and max-video-preview:-1, differing only in the order of the tokens and the presence of spaces after the commas. 79 occurrences are the same string byte for byte: index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1.

To test where that string comes from, every one of the 129 hosts sending max-snippet:-1 was fetched a second time and its HTML searched for platform markers. 98 of the 129 carried WordPress markers. 89 carried a marker for one of four WordPress SEO plugins: 73 for Yoast, 15 for Rank Math, one for All in One SEO and one for SEOPress. 67 of those 89 sent the byte-identical canonical string. The marker proves the plugin is present on the page, not that the plugin wrote the directive, and that is the honest limit of the claim. But a directive that appears as the same five tokens in the same order on 79 pages, overwhelmingly on one platform, is generated output rather than a decision taken 79 times.

This is the part that matters for anybody reading their own markup. A max-snippet:-1 in your head is not evidence that somebody considered AI Mode and chose to allow unlimited extraction. It is considerably more likely to be the default your generative engine optimization stack shipped, in the same way that the 233 of 241 max-image-preview values this blog counted as set to large in its 5 October 2026 census were a default rather than an act. The directive is doing nothing, which is fine if nothing is what you want. The failure mode is believing it is doing something.

Four pages sent max-snippet:-1 to the wrong audience, which is a smaller finding but a clean illustration of markup copied rather than written. highlandparkveterinarian.com, cri.dev, metalbear.com and amref.org each sent it inside a meta named bingbot. Google reads a meta named robots, googlebot or googlebot-news, so a directive addressed to bingbot is not a Google instruction and was excluded from the counts above. It is the same texture of inherited, unexamined markup that this blog documented when 232 of 1,059 robots.txt files carried a defect, and it is why a count of pages sending a directive is never the same as a count of pages exercising a control.

Where a snippet directive never gets read at all

Google's robots meta tag page states the precondition before it defines a single directive: these settings can be read and followed only if crawlers are allowed to access the pages that include these settings. A snippet directive is an instruction inside a response body. A crawler that is refused the response never holds the instruction. The two surfaces compose in one direction, the gate first and the page second, and the group selection rules that decide the gate are specified in RFC 9309.

That ordering is not theoretical in this corpus. 217 of the 1,419 hostnames answered HTTP 403 to a plain crawler and 57 answered 503, so 274 hosts served no page at all to this client and whatever directives sit in their heads were unreadable from here. A further 34 never returned a status. None of those 308 hosts appears in any rate above, and a host that refuses an identified crawler outright is exactly the kind of host most likely to have opinions about snippet extraction, so the surviving 1,083 lean toward sites that admit crawlers. The direction of that bias is worth stating: it probably undercounts restrictive configurations rather than overcounting them.

The timing matters too, in the other direction. A directive added to a page today is read the next time the page is fetched, which is a different question from when a robots.txt edit reaches a crawler, and both are slower than a dashboard toggle. There is also a text-level version of the same control that this measurement treats separately. 52 of the 1,083 pages carried a data-nosnippet attribute somewhere in the body, which marks individual spans rather than the page, and 12 of the 132 pages sending a page-level directive also carried one. The attribute has its own failure mode, which this blog measured when it found 76 of 225 data-nosnippet attributes sitting on an element Google does not support, since Google's documentation restricts it to span, div and section elements.

One more asymmetry deserves naming. Of the 432 pages sending any crawler directive, the overwhelming majority ask for more presence rather than less, which is the same conclusion the noarchive census reached from a different angle five days ago. Only a handful of directives in this corpus withhold anything, and the ones that do are often doing housekeeping rather than making a statement: this blog found that five of 391 home pages sending X-Robots-Tag noindex were all a captcha, and the lesson transfers. Counting the presence of a directive is easy. Reading intent from it is not available, and this post does not try. You can check what your own site serves with the robots.txt tester, see what an AI crawler is actually handed with what GPTBot sees, and read the token reference on the AI crawlers page.

What this measurement does not show

No crawler was observed. Nothing here is evidence that Google honoured a nosnippet, that any page was or was not used as a direct input to an AI Mode answer, or that the three sites limiting their snippets achieved anything by it. The statements about what the directives do are Google's published claims about its own products, read at source on 7 October 2026 and reported as claims, which is the only standing they have in this post. Lantad does not score these directives either: the composite grade is built from parity, access, structure and schema, so a clean report from this scanner says nothing about whether a page carries nosnippet, exactly the gap the Microsoft AI opt out post named and which has not closed.

The scope limits are specific. One page was read per hostname, the home page. A publisher that sets max-snippet on its articles and leaves the front page open is invisible to this run, and for a news organisation that is the more likely configuration, so the news and media strata are probably undercounted here. No JavaScript was executed, so a directive injected client side is absent, though a snippet directive added after load is of doubtful value given that the crawler reads the served HTML. The word counts quoted for derstandard.at and france24.com are extractable words from the served HTML with script and style content removed, not a character count of what Google would select, so they are context for the size of the cap rather than a measure of what the cap withholds.

The corpus is also not a sample of the web. It is an editorial sampling frame assembled for platform and industry coverage, with 392 hostnames in ten platform strata and 1,027 in eight industry strata, so every rate above describes these 1,419 hostnames on one date and nothing wider. The strata are listed on the crawlability study page for anybody who wants to judge the frame before trusting a rate, the scanner's own classification rules are on the methodology page, and what this crawler sends is documented at the bot page. Readers who want the vendor-side version of the question rather than the census should start at how to get cited in Google AI Overviews, and those auditing their markup more broadly will find the structured data reference closer to what they need than this post is.