BlogFindings
AI Mode traffic: Google's new referrer page documents one value for all of Search, and 13 of 887 redirecting sites remove it
Google added a page to Search Central on 12 November 2026 telling site owners to identify Search visits by the HTTP Referer header, and documenting that Search sends it under the origin referrer policy, so it carries a host and nothing else. That is one value for every Google surface served from those hosts, and the page never names AI Mode or AI Overviews. Lantad then followed the home page redirect chain of 1,375 corpus hosts the same day: 887 redirected, 938 of the 1,037 redirect responses carried no referrer policy at all, and 13 sites sent one that removes the header before the landing page is reached.
Everything below about Google's documentation was read at that page on 13 November 2026 and is reported, not measured here. The measurement that follows it is Lantad's own, made the same day, and it tests one specific caveat the page raises: that a redirect can remove the header the whole method depends on. Every request was sent as LantadBot/1.0, the agent described on the bot page, with a twenty second timeout and no JavaScript executed. The corpus is the stratified sampling frame this repository commits for its crawlability study: 392 hostnames across ten platform strata and 1,027 across eight industry strata, 1,419 in total.
In short
- Google's new Search Central page, added 12 November 2026 and titled Identify Google Search traffic in your web analytics or server logs, states that Google Search uses the origin referrer policy, so the Referer header contains only the scheme and host of the referring page, without the URL path or query parameters.
- AI Mode traffic is not separable from classic Search traffic by that header, because the documented values are per surface rather than per feature: the page lists three values, says other Google services served from the same origins send the same ones, and never mentions AI Mode, AI Overviews or Gemini anywhere in its text.
- Lantad followed the home page redirect chain of 1,375 corpus hosts on 13 November 2026 and 887 of them redirected at least once, 865 of those onto a different host, across 1,037 redirect responses of which 938 carried no Referrer-Policy header at all.
- 13 of the 887 redirecting sites sent no-referrer or same-origin on a redirect response on 13 November 2026, which the W3C referrer policy specification defines as sending no referrer on a cross-origin request, and 9 of the 13 sent it on the very first response.
- Of the 1,060 corpus home pages that answered with HTML on 13 November 2026, 729 declared no Referrer-Policy on the landing response and 190 declared strict-origin-when-cross-origin, a value that preserves the host Google sends.
| Source | Documented Referer value | What it does not carry |
|---|---|---|
| Google Search on the web | https://www.google.com/ or a local Google domain | path, query, and so the feature that produced the link |
| Google app on Android | android-app://com.google.android.googlequicksearchbox/https/www.google.com when the app opens a browser tab, or https://www.google.com/ | path, query, and so the feature that produced the link |
| Google app on iOS | https://www.google.com/ or a local Google domain | path, query, and so the feature that produced the link |
What Google published on 12 November 2026
The page explains which Referer values to look for, how to match them in analytics and logs, and why the resulting numbers will not agree with Search Console. It opens by pointing at the Referer request header the browser or app sends when a user clicks a link in Google Search, and then states the design decision that governs everything else: Google Search uses the origin referrer policy, which means the header contains only the scheme and host of the referring page, without the URL path or query parameters.
Three consequences follow in the page's own text. The first is that the header does not include the search query, which the page marks as important and answers by sending the reader to the Performance report in Search Console instead. The second is the table reproduced above, which gives one value for the web, two for the Google app on Android and one for the Google app on iOS. The third is the sentence that does the most work: other Google services served from the same origins, Google Images among them, send the same Referer values, so that traffic is also included when you match these patterns. Traffic from Discover is handled the same way, taking the values of the surface where the user viewed it.
The page also tells you to count only requests for landing pages. A browser sends a Referer when it fetches images, CSS and JavaScript too, and for those the value is your own page's URL, so a log analysis that counts every request will inflate itself with its own subresources. None of this is new behaviour. What is new is that it is written down in first-party documentation: the page itself carries no date, and the 12 November 2026 date used throughout this post is the one Search Central's own documentation updates log gives for adding it. It arrives into a reporting gap this blog has measured before: Search Console's generative AI report counts impressions and nothing else, with no clicks column at all.
- Referrer policy used by Google Search origin, so the header carries scheme and host only
- Search query included in the header stated explicitly: use the Performance report in Search Console for queries
- Path or query parameters included excluded by the origin policy the page names
- Other Google services on the same origins send the same values, so they are counted in when you match the patterns
- Discover traffic distinguishable uses the same values as the surface where the user viewed Discover
- Subresource requests to be excluded images, CSS and JavaScript send your own page URL as the Referer
Can you separate AI Mode traffic from classic Search traffic?
Not with this header, and the reason is structural rather than an omission. The origin referrer policy discards the path and the query string, and the path and the query string are where a Google URL carries any indication of which feature built the result. What survives is the host. A click from a plain list of results, a click from an AI Overview and a click inside AI Mode all leave the same value in your log, because all three are served from the same origin, and the page states in its own words that traffic from other services on those origins is included when you match these patterns.
So matching the documented values gives a Google bucket, not a breakdown of one. The page is not framed as a limitation of AI reporting and it does not discuss AI at all: it never mentions AI Mode, AI Overviews, Gemini or anything generative anywhere in its text, which was checked across the whole page on 13 November 2026. The only Google surface it singles out by name is Discover, and it singles it out to say that Discover is not distinguishable either.
That is worth stating precisely, because the gap is easy to overstate in either direction. Lantad has not measured AI Mode referrals, holds no data on their volume, and makes no claim about how many there are. What can be said from the documentation is narrower and still useful: the method Google published on 12 November 2026 for identifying its own traffic in your logs does not resolve a Google referral to a Google feature, and nothing in the header it describes could. Anyone sizing an AI surface from server logs is sizing the host. The citation side has the same shape, where AI Mode and AI Overviews gained five link changes in October 2026 and not one published number to attach to them, and where an AI Overview citation is not the same thing as a page one position. Measuring whether a page can be read and cited at all, which is what AI visibility means here and what the guide to getting cited in Google AI Overviews sets out, does not depend on the referrer and is not affected by any of this.
Sample Illustrative, not a measurement of any real site.
What the header establishes
- the visit came from a Google origin
- which Google host or app surface
- that it was a landing page request
- enough to class the visit as Google organic
What it leaves open
- AI Mode, AI Overview or plain result
- Google Images or Google Search
- Discover or the surface it was viewed on
- the query, which the page excludes by design
Why the Referer arrives blank even when Google sends it
Google's page is candid that setting a referrer policy is not the same as the header arriving. It lists four situations in which the browser or operating system omits the Referer, or blocks JavaScript access to document.referrer, by default: private browsing modes and anti-fingerprinting protections, opening search results in a new tab in some browsers, moving from a native mobile search widget to an external browser, and visits from users running privacy extensions or strict browser settings. It adds that JavaScript-based visitor tracking may miss visits for a further set of reasons, naming browser privacy settings, consent management and ad blockers.
None of those four is exotic, and the third is specific to mobile. A referrer that never existed is indistinguishable in a log from a direct visit, which is why referrer-derived channel reporting understates whatever arrives without one. This is the same measurement problem from the other end of the pipe as Cloudflare's published crawl to refer ratio, where traffic from Claude's native app carries no Referer header at all and the vendor says its own number may therefore overstate by an amount it describes as unclear. When a channel is defined by a referrer match, a missing referrer is not a small error. It is a visit assigned to the wrong bucket.
The classification layer above the header has the same fragility. Google's page notes that most analytics systems recognise these values automatically and categorise the visits as Google organic, and tells you to check custom channel rules, referral exclusions and filters if Search traffic shows up as referral or direct instead. That is the layer where GA4 files a visit under its AI Assistant channel when the referrer matches a list Google does not publish, and an unpublished list is not something a site owner can audit. For anyone working on generative engine optimization, the practical reading is that the referrer tells you a visit came from Google and the tool above it decides what that gets called.
-
Private browsingheader omitted private modes and anti-fingerprinting protections, by default -
Result in a new tabheader omitted in some browsers, stated without naming them -
Native search widgetheader omitted moving from a native mobile widget to an external browser -
Privacy extensionsheader omitted users with privacy extensions or strict browser settings -
JavaScript trackingvisit may be unlogged privacy settings, consent management and ad blockers
What a redirect does to the header, and how often it happens
One line in Google's list of reasons your data will not match Search Console names a mechanism a site controls itself: a redirect that sends a stricter Referrer-Policy header can also remove the Referer. The page puts it beside client-side redirects, which it says may replace the Referer with your own page's URL, and redirects that drop the query string, which lose parameters such as gclid.
The standard behind that sentence is specific about it. The W3C referrer policy specification, a Candidate Recommendation dated 26 January 2017, defines no-referrer as sending no referrer information with the request, with the header omitted entirely, and same-origin as sending a referrer for same-origin requests only, so a cross-origin request gets none. Its section 8.2 is the part that puts the risk in the redirect: when a redirect response carries a non-empty Referrer-Policy header, the request's referrer policy is updated to that value for what follows. A visit arriving from a Google host is cross-origin to every site in this corpus, so either of those two values on a redirect response removes the header Google sent before the request reaches the landing page. The origin-preserving values do not: Google already reduced the referrer to an origin, so a policy that keeps an origin costs nothing.
That is a mechanism worth counting rather than assuming, because a home page redirect is close to the normal case rather than an edge one. Lantad requested robots.txt for all 1,419 corpus hostnames on 13 November 2026; 1,102 answered with a plain 200 and 1,032 parsed into at least one user-agent group with the matcher in core/src/robots.ts, and resolving the site root for the token LantadBot left 1,375 hosts with a route to the home page. Following each of those 1,375 chains without automatic redirect following, one response at a time, 887 redirected at least once and 488 did not. 865 of the 887 finished on a different host from the one requested, overwhelmingly the www twin, which is the same apex and www split that makes robots.txt differ across subdomains and that this blog has measured before as the reason redirect following has to be counted rather than presumed. 755 chains were a single redirect, 116 were two, 15 were three and one ran to five.
Flow: Google sends origin only to Site redirects the URL; Site redirects the URL (938 responses) to No policy on the response; Site redirects the URL (86 responses) to Other policy sent; Site redirects the URL (13 responses) to no-referrer or same-origin; No policy on the response (default applies) to Header reaches the page; Other policy sent (origin preserved) to Header reaches the page; no-referrer or same-origin (cross-origin: none sent) to Header removed.
The 13 sites that removed the referrer before the landing page
Across those 887 redirecting hosts there were 1,037 redirect responses, and 938 of them carried no Referrer-Policy header at all. That is the first finding and it is the reassuring one: on the large majority of redirects nothing overrides the policy Google set, so the origin it sent survives the hop. 797 of the 887 hosts declared no policy on any redirect response in their chain, and 90 declared one somewhere.
Of the values that did appear on a redirect response, most are harmless to this header. 54 responses sent strict-origin-when-cross-origin, 18 sent no-referrer-when-downgrade, 7 sent strict-origin, 4 sent origin and 3 sent origin-when-cross-origin, and none of them removes an origin that Google has already reduced to an origin, the downgrade value only stripping if the hop drops from HTTPS to HTTP, which none of these did. 13 responses did not: 9 sent same-origin and 4 sent no-referrer. Those 13 responses belong to 13 distinct hosts, listed in full below, and on 9 of the 13 the stripping response is the very first one, the response a searcher's browser receives when it follows a Google result to that address. All 9 were re-read individually later the same day and all 9 returned the same status code and the same policy on the second read.
What the 13 have in common is their sector rather than their stack. Twelve of the 13 are universities, research institutes, hospitals, public health agencies, national statistics offices, state railways or a central government portal. The thirteenth is a commercial software company. No motive is observable from a response header and none is claimed here: a site may send same-origin as a considered privacy position, as a platform default, or because nobody chose it at all. The consequence is the same either way, and it is narrow. These sites lose the Google referrer on arrival, so their own logs will under-report Google as a channel, while the rest of the corpus keeps it. The failure resembles the one behind 171 of 1,047 sites dropping a utm tag during a redirect: the attribution evidence is destroyed by the site's own infrastructure, in a hop nobody looks at, and the method pages for any measurement built on it inherit the hole.
| Host | Stripping policy | On the first response | First response status | Sector from the domain |
|---|---|---|---|---|
| rijksoverheid.nl | no-referrer | yes | 301 | central government portal |
| iisc.ac.in | no-referrer | yes | 301 | research institute |
| acibadem.com.tr | no-referrer | yes | 301 | hospital group |
| technion.ac.il | same-origin | yes | 302 | university |
| sbb.ch | same-origin | yes | 301 | state railway |
| ns.nl | same-origin | yes | 301 | state railway |
| open.ac.uk | same-origin | yes | 301 | university |
| amsterdamumc.nl | same-origin | yes | 301 | university hospital |
| airtable.com | same-origin | yes | 301 | commercial software |
| karolinska.se | no-referrer | no | 301 | university and hospital |
| rki.de | same-origin | no | 302 | public health agency |
| insee.fr | same-origin | no | 302 | national statistics office |
| destatis.de | same-origin | no | 302 | national statistics office |
What to check on your own site, and what this run did not measure
The check is cheap and it is not the one most sites run. Request your own home page and your most-landed-on pages without following redirects, read the status code and the Referrer-Policy header on every hop, and confirm that no hop sends no-referrer or same-origin. The landing response matters less than the hops before it: a policy on the final response governs the requests that page goes on to make, not the referrer that already arrived with it. For the record, across the 1,060 corpus home pages that answered with an HTML content type on 13 November 2026, the landing response carried no Referrer-Policy on 729, strict-origin-when-cross-origin on 190, no-referrer-when-downgrade on 74, same-origin on 22, strict-origin on 13, no-referrer on 12, origin on 9, origin-when-cross-origin on 8 and unsafe-url on 3.
Four limits on all of the above, and they are real rather than decorative. This run sent LantadBot/1.0, not a browser arriving from a Google host, so what is measured is the policy each server attached to a redirect, not an observed Google referral; a site that varies the header by user agent would not be caught by this method. No JavaScript was executed, so the client-side redirects Google's page names, including the meta refresh pragma 14 of 1,069 corpus home pages were found carrying, are outside the count entirely and can only make the real figure larger. Only one URL per host was followed, the site root, so a stripping policy on a deeper landing path is not represented. And the sector pattern in the 13 is an observation about 13 domains, not a rate for any sector.
The wider point is the one worth keeping. Attribution and readability are different problems, and only one of them is fixed by a header. A site can be perfectly readable to an AI crawler and still be unable to tell where its visitors came from, which is why what GPTBot sees and what your analytics reports are separate questions with separate evidence. Referrer-based reporting answers the second, imperfectly, and Google's new page is a clear statement of exactly how imperfectly. It is also a reminder of how fast this evidence decays: between 50 and 83 percent of AI citations measured were gone by day two, and the published studies behind figures like those are collected on the research index. The one thing a site owner can act on today is in the hops, and it takes one request to find out.
Lantad
Published .
Google added a page to Search Central on 12 November 2026 that tells site owners how to find Search visits in their own records. It is a short, practical document: identify Google Search traffic in your web analytics or server logs, offered in addition to Search Console, and built entirely on one request header. The interesting part for anyone measuring AI Mode traffic is not what the page says but what it cannot say, and the page is honest about the mechanism that causes it.
Common questions
Does the Referer header show which Google feature sent a visit?
No. Google's Search Central page added on 12 November 2026 states that Google Search uses the origin referrer policy, so the header carries only the scheme and host, with no path or query parameters. The same page says other Google services served from those origins send the same values, and it does not mention AI Mode or AI Overviews anywhere, so matching the documented values produces one Google bucket rather than a breakdown by feature.
What Referer value does Google Search send?
Three values, per Google's documentation read on 13 November 2026. Google Search on the web and the Google app on iOS send https://www.google.com/ or a local Google domain such as https://www.google.co.uk/. The Google app on Android sends android-app://com.google.android.googlequicksearchbox/https/www.google.com when it opens the link in a browser tab, or the same web value otherwise. None of them includes the search query.
Can a redirect remove the Referer header?
Yes. The W3C referrer policy specification, a Candidate Recommendation dated 26 January 2017, says in section 8.2 that a non-empty Referrer-Policy header on a redirect response updates the policy for the request that follows, and it defines no-referrer as omitting the header entirely and same-origin as sending nothing on a cross-origin request. Lantad found 13 of 887 redirecting corpus hosts sending one of those two on a redirect response on 13 November 2026, 9 of them on the first response.
Does a Referrer-Policy on my landing page affect traffic Google sends me?
No. A policy on the landing response governs the referrers that page sends on requests it goes on to make, not the referrer that arrived with the visit. The responses that matter are the redirect hops before it, because section 8.2 of the specification lets a redirect response change the policy for the next request. Of 1,060 corpus home pages measured on 13 November 2026, 729 declared no policy on the landing response at all.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
AI visibility
AI visibility is whether AI systems can access, read, and faithfully represent your web pages, the prerequisite for being cited in an AI answer.
Generative Engine Optimization (GEO)
Generative Engine Optimization (GEO) is the practice of structuring and publishing content so that generative AI engines can fetch it, read it in full, and cite it when they answer a question.
AI crawler
An AI crawler is an automated bot, such as GPTBot, ClaudeBot, or PerplexityBot, that fetches web pages so an AI system can read, train on, or cite what those pages contain.
Gemini UTM parameters: 171 of 1,047 sites dropped the tag during a redirect
Lantad asked all 1,419 hostnames in this repository's two committed corpus seed files for a home page carrying utm_source=gemini on 24 October 2026, as LantadBot with redirects followed and no JavaScript executed. 1,047 answered HTTP 200. Of the 749 that reached the page through at least one redirect, 171 arrived with both parameters gone, and every one of the 298 that made no redirect kept them.
GA4 AI Assistant channel: 2 of 6 assistant hosts answered a scan
Google's new channel files a visit under AI Assistant when the referrer matches a list it does not publish. Lantad fetched the six assistant hosts in its own referrer list on 9 September 2026: two returned a readable page, and both declare a policy that sends the host and discards the path.
Search Console's generative AI report counts impressions and nothing else
Google's generative AI performance report, read at its Search Console help documentation on 14 August 2026, offers one metric and four dimensions. There is no clicks column, no click-through rate, no average position and no query dimension, and the Search and Discover versions count an impression by opposite rules.
