
A team sits in a monthly review with a slide showing Google traffic at one figure and Search Console open on a laptop showing another, and nobody in the room can say which one to defend. That meeting is where Google's new documentation page earns its keep: the way to see Google Search visits inside your own property is to match the HTTP Referer header the browser sends, either a Google web host such as https://www.google.com/ or a local domain, or the Android app's android-app://com.google.android.googlequicksearchbox/ value. Anything outside that list is not search traffic, and the total you get this way will still sit below Search Console's clicks.
A seo consultant who reports one number without saying which of the two it is ends up defending a figure nobody else can reproduce, and in Singapore, where most SME sites run on a thin marketing team, that gap surfaces in exactly that kind of review. The same holds for any ai seo singapore brief that reports AI referrals without a log check behind them.
Google Search Central published a documentation page titled "Identify Google Search traffic in your web analytics or server logs", announced in its documentation update feed as a new page about identifying traffic from Google Search using HTTP Referer headers. Search Engine Roundtable reported the addition on 13 November 2026.
The page is narrow on purpose. It explains that in addition to Search Console, site owners can identify search visits in their own analytics or log files by inspecting the Referer header, and it sets out four things: how Google Search sets the header, why it is sometimes empty, how to match it in an analytics tool or a log, and why the resulting number will not agree with Search Console. Your seo consultant should treat it as a specification for the reporting set-up, not as news.
Two sentences in it carry most of the operational weight. The first: the Referer header does not include the search query, so query-level analysis still belongs in Search Console's performance report. The second: Google Search uses the origin referrer policy, which means the header carries only the scheme and host of the referring page, with no path and no query parameters.
That second point is why the method works at all. Because the value is reduced to a host, it is stable enough to match against, and because it is reduced, it also throws away everything that would let you distinguish one result from another.
If you run custom analytics or read server logs, the match list is small. Google's page gives it by search surface:
| Where the reader clicked | Referer value to match |
|---|---|
| Google Search on the web | https://www.google.com/ or a local Google domain (the country's own host, in the same scheme-and-host-only form) |
| Google app on Android, opened in a browser tab | android-app://com.google.android.googlequicksearchbox/https/www.google.com |
| Google app on Android, opened otherwise | https://www.google.com/ or a local Google domain |
| Google app on iOS | https://www.google.com/ or a local Google domain |
These are configuration strings, not measurements, and they should be pasted into your rule set exactly as written. Two consequences follow from the table.
First, a Singapore site that receives readers from a regional Google domain needs the local-domain rule as well as the main one, or it loses those sessions to a rule mismatch. Second, other Google services served from the same origins, Google Images among them, send the same values, so image-search traffic is folded into whatever you count as search traffic. If your business cares about the difference between a reader who clicked a blue link and one who clicked a thumbnail, the Referer header cannot tell you.
Discover traffic behaves the same way: it uses the values of the surface the reader was on when they tapped, so it arrives as Google app or Google Search on the web depending on the device path.
The header is set, but the browser or operating system may still drop it. Google's page lists the common situations: private browsing modes and anti-fingerprinting protections, opening a result in a new tab in some browsers, moving from a native mobile search widget into an external browser, and visitors with privacy extensions or strict settings turned on.
JavaScript-based tracking has a second layer of loss on top of that. Consent management platforms, ad blockers and browser privacy settings can stop the analytics script from running at all, which means the visit is never recorded as search, as direct, or as anything else.
For a marketing manager this is the part that decides whether the number is usable. A drop in recorded search sessions can be a drop in visibility, a change in browser behaviour, or a consent banner that was reworded last quarter. The Referer check narrows the question but does not answer it alone.

Most analytics systems already recognise these values and classify the visits as organic search from Google. When they do not, the cause is usually local configuration rather than Google.
Check, in this order:
The final point matters more than it looks. An ai seo singapore review that never opens the redirect chain is auditing the wrong layer; Google's page warns that a client-side redirect, such as a JavaScript or meta refresh redirect, can replace the Referer with your own page's URL. A redirect that drops the query string also removes parameters such as gclid that ad tagging depends on, and a redirect sending a stricter Referrer-Policy header can remove the Referer entirely.
If you analyse logs directly, one more rule applies: the browser also sends a Referer when it fetches images, stylesheets and scripts, and in those requests the value is your own page's URL. Count only the requests for the landing pages themselves, or you will count one visit several times.
Google states plainly that matching by Referer is not exact and that the totals often do not agree with Search Console. Four reasons are given, and each points at a different part of your set-up.
Privacy settings and client configurations: browser settings, extensions, ad blockers and consent choices can block analytics scripts, strip URL parameters or suppress the header.
Redirects on your site: client-side redirects, redirects that fail to preserve the query string, and stricter referrer policies each remove evidence.
Different measurement methodologies: Search Console records a click when a reader selects a link in Google Search, while an analytics tool records a visit or session only once the destination page loads and the tracking code executes. A reader who clicks and leaves before the page renders is a click in one system and nothing in the other.
Paid and organic traffic: Search Console reports only organic clicks from Google Search and excludes clicks on Google Ads, while your analytics total may include paid traffic depending on how it is configured.
The practical reading is that neither figure is wrong. They count different events at different moments, and the honest report states which figure comes from which system.

Gap filled: g1
That question sits in the People-Also-Ask box under this news, and it is the wrong shape of question. Expertise claimed on a talk circuit cannot be checked; expertise visible in a client's own property can. The expert worth hiring here is the one who can walk into your analytics, state what "Google Search traffic" means in your report, and reconcile the figure with Search Console without inventing a number. Here is the reconciliation that separates the two, run before any strategy or budget decision, in four steps.
Step 1. Pin the definition. Write down what "Google Search traffic" means in this report: which Referer values, which local domains, whether the Google app is included, and whether Discover sits inside or outside the number. A definition nobody wrote down cannot be audited.
Step 2. Check the channel rules against that definition. Read the custom channel rules, referral exclusions and filters in your analytics property and confirm none of them reclassify Google hosts. This is the cheapest fix available, and it is the one Google's page names first. That single edit is also the fastest way to judge whether whoever set the property up knew what they were doing.
Step 3. Compare like with like. Put Search Console clicks and analytics search sessions side by side for the same date range (a seo consultant usually has both exports already), then subtract sessions that could not be recognised (blocked tags, stripped headers) and clicks that never became sessions (bounced before the tag fired). What remains is the part worth explaining.
Step 4. Trace the redirect path on the pages that matter most. Land on your top service page from a search result and watch the Referer in the browser's network panel through every redirect. A single meta refresh in the path is enough to erase the attribution.
A team that runs these four steps gets no corrected total. What it gets is a written statement of what its data can and cannot show, and a ranking report should be read against that statement rather than on its own.
Topkee's SEO reports are built on the client's own accounts and the site data that is actually available, and they keep completed work, search performance, visits and business opportunities in separate layers so that a movement in one period is not credited to a single edit. In that set-up, and for any ai seo singapore client as much as a Hong Kong one, Google Search Console supplies impressions and average position, while site-wide tagging in Topkee Analytics tracks visitor behaviour, page views and the sources visitors arrived from. The Referer check belongs exactly between those two: it is a complementary verification step for the visit layer, not a substitute for Search Console and not a replacement for query-level data.
Topkee SEO's review step combines completed work, ranking movement and available site data, which is where a Referer-based count of search sessions would be reconciled with a ranking report before either reaches a client. When the search and paid numbers sit on one ledger rather than two, as the AI-powered Google Ads conversion reporting page sets out, a figure that only one system can reproduce stops being an argument.
A figure that only one system can reproduce stops being an argument once the AI-Powered Google Ads retail campaign view is read on the same ledger.
The caution that follows is worth stating in the report itself. No analytics set-up identifies every Google Search visit, and AI browsing analysis covers retrieval sources and cited pages rather than actual site visits, so real crawler visits, referral traffic and conversion analysis still have to be connected to site data or logs. A team that wants to claim AI search is bringing traffic needs precisely the kind of evidence this Google page describes, gathered from its own property.
Start with the rule set, not the dashboard. A seo consultant can do this in an afternoon; the order is confirm the host list, then confirm that no exclusion quietly converts Google hosts into direct traffic, then walk one high-value landing page through its redirect chain.
After that, draw the line in the report. Sessions that were recognised, sessions that could not be, and clicks that never became sessions are three different rows with three different owners: analytics configuration, consent, and page performance. When one of them cannot be measured, say so.
What I would watch next quarter is whether recorded search sessions keep tracking Search Console clicks after a browser or consent change. Both numbers move when a privacy setting is rolled out or a consent banner is reworded, and nothing in the Referer list tells you which of the two moved first. Put the two figures on one line month by month, note the date of any browser or consent change beside it, and the diverge-and-recover pattern will show itself without anyone arguing over a single review deck.

No. Google's page states that the Referer header does not include the query. Because Google Search uses the origin referrer policy, the header carries only the scheme and host of the referring page, with no path and no query parameters. Query-level analysis stays in Search Console's performance report.
The most common causes are configuration, not Google: referral exclusions that list Google domains, custom channel rules that route the host elsewhere, or filters that drop the session. Google's page also notes that the header may be absent because of browser privacy settings, anti-fingerprinting protections or extensions, in which case the session may appear as direct.
It rarely will, and Google says so on the page. Search Console counts a click when a reader selects a link, while an analytics tool counts a visit once the destination page loads and the tracking code runs. Privacy settings, redirects on your site, and whether paid traffic is included in the analytics total all widen the gap.
Yes, if you receive readers from them. Google's page lists https://www.google.com/ alongside local domains, naming the UK and Japan hosts as examples. For a Singapore site serving regional readers, a rule that only matches the main host will undercount.
No. It shows which sessions were recognisably referred by a Google search surface. Sessions with blocked tags or stripped headers are not measured, and image or Discover traffic can arrive under the same values. The honest output of the check is a measured number plus a stated portion that could not be attributed.