Google today added a page to its Search Central documentation that sets out how visits from Google Search can be picked out in web analytics tools and raw server logs, using the HTTP Referer header that a browser sends when someone clicks a result. The page, titled "Identify Google Search traffic in your web analytics or server logs," lists the exact values Google sends from the web, the Android app and the iOS app, describes when that header goes missing, and gives four technical reasons why the visits recorded on a site often fail to match the clicks Google reports.

In Short

Google published a guide today showing which referrer values mark a visit as coming from Google Search, and why that signal is often blank. It matters to anyone who reports organic traffic, because the referrer never carries the search query, Discover and Google Images clicks send the same values as Search, and privacy settings, redirects and ad blockers all cut into the count. Google says analytics and Search Console figures often do not match one to one, while Search visits filed as referral or direct can point to channel rules, referral exclusions or filters inside the analytics setup.

A new page in the monitoring section

The page sits in the "Monitoring and debugging" section of the Search Central documentation, next to existing guides on debugging drops in Search traffic, monitoring with Search Console and using search operators. Its footer records that it was last updated on 2026-11-12 UTC. Today's entry in the Search Central changelog describes it as a new page "about identifying traffic from Google Search using HTTP Referer headers," added "to document how site owners can identify and track traffic from Google Search in their web analytics systems."

The new document is short. It runs to four sections and one table, contains no screenshots and no figures, and makes no claims about how much Search traffic a typical site loses to the gaps it describes. What it does contain is a precise statement of what Google sends, a level of detail that site owners and analytics vendors have largely had to establish from their own logs.

The opening paragraph positions the page as a complement to Search Console, not a replacement for it. A note in the same section makes one limit explicit. "The Referer header doesn't include the search query that the user entered," the page states. For query data, it points readers to the Performance report in Search Console. That limit is not new: search terms have not travelled in Google's referrer data since the company began moving searches to encrypted connections in 2011, the change that filled analytics reports with the "(not provided)" label. The new page confirms the position in writing.

Origin only: what the header carries

The header at the centre of the document has an unusual history of its own. The HTTP specification spells it "Referer," a misspelling preserved for compatibility, while the later Referrer-Policy header that controls it is spelled correctly. Google's page uses both forms.

According to the document, "Google Search uses the origin referrer policy, which means that the Referer header contains only the scheme and host of the referring page, without the URL path or query parameters." In practice, a site receiving a visit from a Google results page sees "https://www.google.com/" and nothing after the final slash.

Under the W3C Referrer Policy specification, the plain origin policy sends that trimmed value on every request, including from a secure HTTPS page to a site still served over unencrypted HTTP. The stricter variants, including the strict-origin-when-cross-origin default that major browsers have applied to pages without their own policy since 2020 and 2021, withhold the referrer entirely in that downgrade case. Google's choice therefore keeps the origin visible to sites that have not moved to HTTPS, while ensuring that nothing about the results page itself, such as the query, leaves Google.

Three surfaces, one set of values

The document's only table lists the values by source:

The Android value is the only one that identifies the app by name. It uses the android-app URI scheme, which carries the package name of the Google app, com.google.android.googlequicksearchbox, followed by the host. A log parser that only looks for strings beginning with "https://" would miss it. The table does not say under which conditions the Android app sends the plain web value rather than the app value, beyond the browser-tab case.

Two sentences below the table matter more to publishers than the table itself. "Traffic from Discover uses the same values as the surface where the user viewed Discover, such as the Google app or Google Search on the web," the page states. And: "Other Google services that are served from the same origins (for example, Google Images) send the same Referer values, so this traffic is also included when you match these patterns."

The consequence is direct. Clicks from Google Discover, the personalised feed that sends readers to many news sites, cannot be separated from web search clicks by the referrer alone. Nor can image search clicks. Any site that matches Google's listed patterns will count all three together as Google Search. The document offers no alternative signal for splitting them, which leaves Search Console's own Discover and search type reporting as the only first-party breakdown Google provides. That reporting has its own gaps: Search Console's Discover data for May 21, 2026 was erased by a logging error, and in October 2025 Search Console performance data froze from October 19.

Why the header goes missing

Google sets the policy, but it does not control what the browser does with it. "Even though Google Search sets its referrer policy to origin, the user's browser or operating system might still omit the Referer header (or block JavaScript access to document.referrer) for privacy and security reasons," the document states. It lists four scenarios where this happens by default:

  • private browsing modes and anti-fingerprinting protections in the browser
  • opening search results in a new tab, in some browsers
  • moving from a native mobile search widget to an external browser
  • visits from users with privacy extensions or strict browser settings turned on

A visit with no referrer has no source to report. Most analytics tools file such sessions under direct traffic, alongside typed addresses and bookmarks. The document does not estimate how often any of the four scenarios occurs, and it names no browsers.

A second layer of loss sits on top of the first. "Additionally, JavaScript-based visitor tracking might not log all visits because of browser privacy settings, consent management, and ad blockers," according to the page. Here the visit is not misattributed but absent. A tag that never fires records nothing, whatever the referrer says. Google's own Consent Mode, which adjusts how Google tags behave when a visitor declines cookies, is one of the mechanisms that shapes what reaches Google Analytics in such cases, although the page does not name it.

Server logs are not subject to that second layer. A web server records every request it answers, whether or not a script runs in the browser. That difference is why log-based counts of Google Search visits can exceed what a JavaScript tag records on the same site.

Matching the values in practice

For most sites, the document suggests, nothing needs to change. "Most web analytics systems automatically recognize these Referer values and categorize the visits as organic search traffic from Google," it states.

The page then identifies where configuration can break that recognition. "If Google Search traffic is missing or shows up as referral or direct traffic, check whether custom channel rules, referral exclusions, or filters in your analytics configuration are reclassifying it," the document reads. Custom channel definitions have multiplied as analytics teams try to isolate traffic from AI assistants. In 2025, Google's Analytics Help Center suggested creating a custom channel group for AI chatbots using a regular expression, and on May 13, 2026 Google Analytics added an AI Assistant channel to its default channel group. Every such rule is evaluated against the same referrer and parameter data, and a pattern that is too broad can pull Google visits out of organic search.

For teams that analyse logs directly or run their own analytics, the page adds a technical caution. "The browser also sends a Referer header when it fetches resources such as images, CSS, and JavaScript files, but for those requests, the value is your own page's URL," it explains. "To count visits from Google Search, only look at requests for the landing pages themselves." A page that loads dozens of assets after a single click from Google generates one request carrying a Google referrer and dozens carrying the site's own address. Any share calculation built on all requests, rather than on page loads, would understate Google's contribution.

Four reasons the numbers diverge

The final section is the one most likely to be cited in client reports. "Identifying Search traffic on your site using the Referer header isn't exact, and the data recorded in your web analytics system or server logs often doesn't match 1:1 with the clicks reported in Search Console," according to the page. It lists four common technical reasons.

Privacy settings and client configurations

Browser privacy settings, extensions, ad blockers and consent choices "can block analytics scripts, strip URL query parameters, or suppress the HTTP Referer header," the document states. Parameter stripping has been a recurring theme in paid search measurement. In April 2026, a LinkedIn post put the share of sessions affected by Safari's removal of the gclid parameter at roughly 20%, and a diagnostic run on July 30, 2026 showed Google Ads clicks losing paid attribution when GBRAID and gad_ parameters were stripped.

Redirects on the destination site

This is the reason most within a site owner's control. According to the page, client-side redirects using JavaScript or meta refresh "may replace the Referer with your own page's URL." A visitor who arrives from Google at a page that then forwards them with a script reaches the final page carrying the first page's address as referrer, and the session is attributed to the site itself.

Server-side redirects have a different failure mode. Redirects "that don't preserve the query string drop URL parameters such as gclid (which is commonly used for ad-tagging)," the document states. The gclid value is appended by Google Ads auto-tagging, and analytics tools use it to recognise a visit as a paid click. Lose it in a redirect, and a paid visit can be counted as organic. The page adds that "a redirect that sends a stricter Referrer-Policy header can also remove the Referer."

Different measurement methods

"Search Console records a click when a user selects a link in Google Search, whereas web analytics tools record a visit or session only after the destination page loads and executes the tracking code," according to the document. A visitor who clicks and then closes the tab before the page finishes loading is a click in Search Console and nothing in analytics. Slow pages widen that gap.

"Search Console reports only organic clicks from Google Search and doesn't include clicks on Google Ads, whereas your web analytics system might include paid traffic in its totals, depending on how you configure it," the page states. The document does not say whether Google Ads clicks reach a site with a Referer value different from organic clicks. Without one, the tagging parameters remain the means by which analytics tools separate paid visits from organic ones, which is why their loss in redirects or through browser stripping moves traffic between channels.

The section closes with a link to an existing Google page, "Understanding data discrepancies between Google Analytics and Search Console," for more detail.

What the page leaves out

For a document published in late 2026, the omissions are notable. The page does not mention AI Overviews or AI Mode, both of which run on Google's own search domains. Does a click on a link inside an AI Mode response carry the same referrer as a click on a standard blue link? The new page could have settled that question, and it does not address it. The issue has a history. In May 2025, links in AI Mode carried noreferrer attributes that stripped referrer data, and Google confirmed on May 23, 2025 that the behaviour was an unintended bug. The following month, Google confirmed that AI Mode clicks and impressions count toward Search Console totals.

Nor does the page mention the google.com/goto redirects that Google now wraps around result links. Those wrapper URLs were first spotted on June 23, 2026, and Google confirmed the rollout on August 26, 2026. The new document describes the Referer value only in terms of the results page and does not say whether a click that passes through the redirect arrives in any different form.

Gemini, Google's assistant, is also absent, even though its referral behaviour has been a measurement problem for weeks. Gemini stopped appending utm_source=gemini to cited links around September 28 and 29, 2026, roughly three weeks after it began, and visits from its iOS app have been reported to arrive with no referrer at all. The new page is scoped to Google Search, so the omission is consistent with its title. But it means Google has now documented its referrer behaviour for classic search while leaving AI referral traffic from its own assistant undocumented.

There are no numbers either. Google does not say what share of Search clicks reach sites without a referrer, how often the Android app sends its app-specific value, or how large the typical gap between Search Console and analytics is.

Why it matters for marketers

The page settles a question that SEO teams and analytics consultants have long answered by inspecting their own data: what exactly does Google send? With the values in writing, a log analysis or a custom attribution model can be built against a documented specification rather than observed behaviour.

It also gives agencies and in-house teams something to cite when the two sets of numbers diverge. A client who asks why Search Console reports more clicks than analytics shows organic sessions from Google can now be pointed to Google's own statement that the data "often doesn't match 1:1," together with the four reasons listed.

For publishers, the Discover passage carries the most weight. Discover traffic matters to news sites, and Google has now confirmed in documentation that, at the level of the HTTP header, it looks identical to web search. Analytics vendors that report Discover separately have to rely on other signals, and Search Console remains the only Google source that splits the two.

The scope of the document is also telling. Google has documented the plumbing of a channel that has existed for more than two decades, at a time when newer surfaces, from AI Mode answers to assistant citations, still lack equivalent documentation. Whether Google extends the page to cover those surfaces, or publishes separate pages for them, is not addressed in the changelog entry.

Timeline

Summary

Who: Google, through its Search Central documentation team, for site owners, publishers, SEO practitioners and analytics teams that measure traffic from Google Search.

What: A new documentation page, "Identify Google Search traffic in your web analytics or server logs," explains that Google Search uses the origin referrer policy, so the Referer header contains only the scheme and host, with no path or query. It lists the values sent from Google Search on the web, the Google app on Android (including an android-app:// value) and the Google app on iOS, and states that Discover and Google Images traffic send the same values. It names four default scenarios in which browsers omit the header, warns that custom channel rules, referral exclusions and filters can reclassify Search traffic, and gives four reasons analytics and log data differ from Search Console clicks: privacy settings, redirects, measurement methods, and paid versus organic traffic.

When: Today, according to the Search Central changelog entry and the page's last-updated date of 2026-11-12 UTC.

Where: In the Monitoring and debugging section of Google Search Central documentation, at developers.google.com.

Why: According to the changelog, Google added the page "to document how site owners can identify and track traffic from Google Search in their web analytics systems." For marketers, it puts in writing what Google sends and why analytics totals will not line up with Search Console, while leaving AI Mode, the goto redirects and Gemini referrals undocumented.