Reading Google Search traffic in analytics and logs

As of November 2026, the answer for anyone auditing ai seo singapore reporting is that Google Search identifies its visits with the Referer header and nothing more. The header carries only a scheme and a host, such as https://www.google.com/ or a local Google domain, so it tells you that a click came from Google Search, never which query produced it. Search Engine Journal reported on 2026-11-14 that Google had published a page listing these values, and the page states the same limit in its opening lines. Treat that as the rule for every organic channel row you read this quarter: the referrer is a diagnostic signal, and the click count belongs to Search Console.

What Google's page actually says

Google Search Central published "Identify Google Search traffic in your web analytics or server logs", a documentation page with no publication date on the version read for this article. It sets out three things: which Referer values Search sends, why a visit can arrive with no header at all, and why the resulting counts do not line up with Search Console.

The page applies the origin referrer policy, which strips the path and the query string. Every click from Google Search on the web therefore shows up as https://www.google.com/ or the corresponding local domain. A click from the Google app on Android can also arrive as android-app://com.google.android.googlequicksearchbox/https/www.google.com when the app opens the link in a browser tab. On iOS the app sends the ordinary https://www.google.com/ value.

The important sentence for a reporting owner sits in a note at the top: the Referer header does not include the search query. Google sends anyone who wants the query to the Performance report in Search Console.

Why an organic visit sometimes arrives with no referrer

Google sets the policy, but the browser or the operating system can still drop the header. The page lists the conditions where this happens by default: private browsing modes and anti-fingerprinting protections, search results opened in a new tab in some browsers, a handoff from a native mobile search widget to an external browser, and visits from people running privacy extensions or strict browser settings.

JavaScript-based tracking has its own blind spots on top of that. Consent management and ad blockers can stop the analytics script from running at all, which means the session is never recorded even when the request reached your server.

This is the first place where the analytics number and the log number diverge from each other, before Search Console is even in the picture. A missing referrer does not mean the visit came from nowhere. It means the client refused to say where it came from, and your analytics tool then classified the session as direct or referral depending on its own rules.

Matching the values in channel rules and server logs

Most analytics tools recognise these values out of the box and file the visit under organic search. When traffic is missing, or when it turns up under referral or direct, the page points at your own configuration: custom channel rules, referral exclusions and filters can reclassify a session that arrived with a perfectly good Referer. A Singapore team exploring best seo singapore services usually starts by checking those rules, because a channel definition is the cheapest thing to correct and the easiest to leave wrong for a year.

For a custom pipeline or a raw access log, the match is a string comparison against the values in the table above. One detail saves a common mistake: the browser also sends a Referer header when it fetches images, CSS and JavaScript from your own pages, and in those requests the value is your page's URL. Filter to requests for the landing page itself, or a log count inflates with every asset the page loads.

Discover and Google Images visits carry the same values

Discover traffic uses the referrer of the surface where the person viewed it, which can be the Google app or Google Search on the web. Google Images is served from the same origins and sends the same values.

That means one google.com line in a log can represent a Search click, a Discover click or an Images click. The page gives no path or parameter that would separate them at the referrer level, which is the kind of detail an agency usually discovers only when a client's best seo singapore report shows a Discover spike that the analytics property never saw. The only published split sits on the other side of the fence, in Search Console's separate Discover and Images reports, so a channel owner who needs the three apart has to accept Search Console as the attribution point for the split, while the log answers the question of whether a click happened at all.

Four reasons your total will not match Search Console

The page names the mechanics of the discrepancy, and each one points to a different place to look.

Privacy settings and client configuration come first. Browser settings, extensions, ad blockers and consent choices can block the analytics script, strip query parameters or suppress the Referer. A session that Search Console counted as a click may never reach your tracker.

Redirects on your site come second. A client-side redirect, such as one written in JavaScript or a meta refresh, can replace the Referer with your own page's URL. A redirect that drops the query string also loses parameters such as gclid, the identifier Google commonly attaches to ad clicks. One that sends a stricter Referrer-Policy header removes the Referer altogether.

The measurement method differs third. Search Console records a click the moment a person selects a link in Google Search. Your analytics tool records a visit or session only after the destination page loads and its tracking code runs. A click on a result that never finished loading is a click in one system and nothing in the other.

Paid traffic is the fourth. Search Console reports organic clicks only, and excludes clicks on Google Ads. Your analytics property may include paid sessions in its totals, depending on how the channel definitions are built.

How should an AI-referral or AI Overview visit be counted when Google Search referrer values carry no query or surface detail

This is the question the documented page leaves open, and it follows directly from the origin policy. A click from an AI Overview or an AI Mode answer inside Google Search comes through the same Google surface, so it arrives with the same google.com referrer and no query, no answer identifier and no surface label. Nothing in the header distinguishes it from an ordinary organic click.

Google's generative AI performance report in Search Console has a scope that makes this harder to resolve from the other end as well. That gap is also why ai seo singapore audits tend to put a first-party identifier in place before they claim any AI referral figure. It covers AI Overviews and AI Mode impressions, and that scope cannot be expanded to full prompts, to the query fan-out behind an answer, or to standalone conversions. So the Search Console side gives you an impression figure for a defined surface set, and your analytics side gives you a session count with no surface detail. Neither one is a clean AI-referral number.

The honest way to count it:

1. Keep the visit where the data puts it. A google.com referrer is an organic search visit. Rewriting it as an AI referral on the assumption that an answer page was involved is a guess presented as a measurement.
2. Record AI surfaces separately, from the source that can see them. Impressions from Search Console's generative AI report and citations from a fixed question sample belong to their own records, with their own denominators.
3. Use a first-party identifier for anything that must survive the referrer loss. A persisted click identifier attached to the session and carried into the CRM keeps the source recoverable when the header is blank.
4. State the definition whenever the number leaves the team. An "AI referral" figure without its source, its period and its qualification standard is not comparable with any other team's figure.

The distinction to hold on to is between being retrieved, being cited in an answer, arriving on site and producing an enquiry. They are four stages with four kinds of evidence, and the transition from one to the next is not something the referrer header can prove.

How Topkee reads search and AI referral data

Topkee Media's reporting splits these numbers before anyone adds them up. Its three-layer performance observation separates delivery and execution, brand and source, and visits and business opportunity, and each layer carries its own evidence rather than a causal claim from the layer above. A visit with a Google search referrer is recorded as an organic search visit under visits and engagement. An AI visit is recorded as an identifiable AI referral visit, and the word identifiable is deliberate: when the referrer or the log cannot name which AI platform sent the visit, that session stays in organic search or direct and is not rewritten. Topkee's AI browsing analysis is scoped to retrieval sources, cited pages and site readability, and the knowledge base states plainly that it is not an actual site visit; real crawler visits and referral traffic need separate site data.

For the part of the chain the referrer cannot carry, Topkee's TTO stack relies on first-party identifiers instead of referrer strings. The TTO Tag generates a unique ttoclid that bundles the UTM parameters with visit time, dwell time and browser information, and pushes events back to Google Analytics, Facebook Pixel, Google Ads Conversions and Bing UET. A lead enters the CRM with the advertising attribution fields attached, and sales-stage changes are fired against the same identifier for offline conversion and bidding. Google Analytics becomes the reporting endpoint of that identifier, not the source of truth. Leadbox adds source and channel statistics, site-wide tagging and lead quality reporting by channel. Topkee Media Limited started in Hong Kong and now also runs a Singapore office, which is the market these reporting rules are written for.

A reconciliation checklist for this week

1. Export one week of Google Search clicks from Search Console and one week of organic sessions from your analytics property for the same pages.
2. Compare totals by landing page rather than site-wide. A site-wide gap hides pages where consent is broken and pages where nothing is wrong.
3. Open the channel definitions and look for custom rules, referral exclusions and filters that could move Google sessions into referral or direct.
4. Pull a sample of raw requests and confirm the landing pages carry the expected Referer, and that asset requests are excluded from the count.
5. Check every redirect between the landing URL and the final URL, and confirm the Referrer-Policy header on each hop.
6. Write down which questions each figure answers: clicks in Search Console, sessions in analytics, AI surface impressions in the generative AI report, enquiries in the CRM.
7. Fix one of them at a time and re-measure before changing the next.

Where to start

If your organic channel row has been treated as the count of people Google sent, the first useful change is to label it as sessions and to keep the click count in Search Console. For teams that want the keyword, page and site-structure work that produces those clicks in the first place, Topkee's ai seo singapore service page sets out the workflow: keyword clusters mapped to pages, index and structure checks, and tracking by engine, region, language and device.

The related reading on the same site covers how to spot Google Search traffic in your own analytics, which walks through the identification work from the site owner's side, and AI search analytics tools for marketing teams, which compares the platforms that hold a fixed question sample rather than a referrer string.

FAQ

Why does Google Search send only a domain in the referrer?

Google Search uses the origin referrer policy, so the header contains the scheme and host of the referring page but not the path or the query string. The query is available in Search Console's Performance report instead.

Can I tell a Discover click from a Google Search click in my log?

Not from the referrer alone. Discover traffic is recorded with the values of the surface where the person saw it, and Google Images sends the same values. Search Console's Discover and Images reports are the published place where those surfaces are separated.

Does a missing referrer mean the visit was not from Google?

No. Google sets the policy, but browsers and operating systems can still omit the header in private browsing, when results open in a new tab in some browsers, when a native search widget hands off to a browser, and with privacy extensions. Analytics scripts can also be blocked by consent choices or ad blockers.

Why is my organic session count lower than my Search Console clicks?

Search Console counts a click when a person selects a link, while analytics records a session only after the page loads and the tracking code runs. Blocked scripts, client-side redirects that overwrite the referrer, and consent choices all widen the gap.

How should an AI Overview click be counted?

As an organic search visit, because it arrives through Google Search with the same referrer and no surface detail. AI surface impressions belong to Search Console's generative AI performance report, and anything that must survive referrer loss needs a first-party identifier carried into your CRM.

Can I fix this by changing my analytics configuration?

Partly. Custom channel rules, referral exclusions and filters can reclassify a session that arrived with a valid referrer, and correcting them recovers those visits. Sessions where the header never arrived cannot be recovered from configuration.

Sources

1. "Google Explains How To Find Search Traffic In Analytics & Logs", Search Engine Journal, 2026-11-14. https://www.searchenginejournal.com/google-search-traffic-analytics-logs/597382/
2. "Identify Google Search traffic in your web analytics or server logs", Google Search Central, undated. https://developers.google.com/search/docs/monitor-debug/identify-google-search-traffic