Primary topic Mobile SEO
On November 12, 2026, Google published a guide to recognizing Search traffic in analytics and server logs. It lists what a click can send from the web, the Google app on Android and the Google app on iOS. If your mobile traffic looks down in analytics but steady in Search Console, start with the request for the page people land on. This is documentation of existing signals, so a correctly classified site needs no migration. A new reporting gap deserves a trace before it prompts changes to content or rankings strategy.
Look for the HTTP Referer header. Search uses the origin policy. In the specification’s example, a link from example.com/page.html to another HTTPS site carries only https://example.com/. The search result URL is trimmed the same way: the host can come through, but the path and search terms don’t. Find the queries in Search Console’s Performance report instead. The request header is spelled Referer; the controlling response header is Referrer-Policy.
| Signal | Check | Action |
|---|---|---|
| Clicks down too | Web report, mobile | Compare pages and queries |
| Only sessions down | First page request | Trace one click |
| Referrer reaches final page | Session report | Check tag and rules |
| First referrer blank | Same phone and app | Retest; leave source open |
What a Google click can leave in the logs
Web Search referrers include https://www.google.com/ and local domains such as https://www.google.co.uk/ and https://www.google.co.jp/. The Google app on iOS uses the same kind of value. A UK host in the header does not tell you the visitor’s country, and the common origin doesn’t tell you whether they came from the iOS app or a browser.
Android can leave a more specific clue. When the Google app opens a browser tab, the app can send the following documented value:
android-app://com.google.android.googlequicksearchbox/https/www.google.comParse the scheme, app authority and path together as an Android Google app signal. A rule that only accepts HTTPS web origins would miss it. The app can also send the ordinary Google origin, so counting app URIs alone will miss some Android Google app traffic.
Count landing requests before counting referrals
If you already use a standard analytics product and Google traffic is classified as expected, leave its channel rules alone. Build a separate count in logs only when you need to trace a missing or mislabeled visit. Use the log layer that actually saw the request. If a CDN answered from cache, an origin log alone can miss the landing entirely.
Filter for requests for the HTML entry pages you want to measure. A phone that lands on an article can then request images, scripts and stylesheets; those requests may carry the article’s own URL as their referrer. Counting every request swells the denominator with assets. Keep redirects and their destinations in the trace, but avoid counting both as separate landings.
For web referrers, compare the parsed origin to an explicit list of Google origins relevant to the sites you operate. For example, accept an exact parsed origin of https://www.google.com and explicitly supported local origins; reject google.com.example.org. A substring test for google.com would accept that unrelated host. Keep the list aligned with your audience’s observed Google domains, rather than assuming these three examples are exhaustive. Handle the documented Android value separately and leave blanks unclassified.
Keep a separate bucket for known paid traffic: a Google origin on its own isn’t evidence that the click was organic. Search Console excludes Google Ads clicks. If a redirect drops ad markers such as gclid, paid visits can lose their paid classification and inflate another channel.
Keep the landing route on HTTPS. The origin policy can send the origin even on an HTTPS-to-HTTP navigation, while strict variants suppress it on that downgrade. Do not weaken the site’s privacy policy to force attribution; inspect the particular redirect that changes the signal.
Follow one click from the phone to the session report
Open the actual result in the app or browser where the change shows up. Record the time with its time zone, the phone OS and app/browser version, and the clicked URL. Keep the complete route, including any result-link wrapper. In a network trace or the matching server/CDN records, compare the Referer on the first document request with the header on the final document that runs your tag. Pay particular attention to region selectors, mobile interstitials and old URLs that send people to replacements. A JavaScript or meta refresh redirect can make your own site appear as the referrer. A stricter policy on a redirect can remove it, and a redirect that discards the query string can lose paid attribution even if the Google host survives.
Next inspect document.referrer in the final page’s browser console, then check whether the analytics tag runs and which channel gets the session. The JavaScript value can be blocked even when a request header was sent; inspect both.
In GA4, open Reports → Acquisition → Traffic acquisition and choose Session source / medium. Look for google / organic and inspect referral or direct rows for the same landing page if it is missing. Those rows identify what GA4 classified, not the source of every unassigned visit. Check custom channels, referral exclusions and report filters before rewriting your log matcher. If the tag behaves differently after a consent choice, replay each consent path in a fresh visit so the previous choice doesn’t carry over.
If the first request already has a blank referrer, the destination site can’t recover the source from that header. Private browsing and anti-fingerprinting, strict settings or extensions, opening results in a new tab in some browsers, and a native search widget handing a link to an external browser can all leave that gap. Repeat the click on the same phone in a normal browsing session. A working control helps isolate the conditions of the gap; it doesn’t identify the source of all the unlabeled visits.
What if Search Console clicks are steady but sessions fall?
Check the landing and measurement path before changing a page’s SEO. Start in the Search results Performance report with Web search and the mobile device filter. Compare the same dates and relevant country and pages on both sides. Align the reporting scope: Search Console normally uses Pacific Time, while GA4 uses its property time zone. Search Console generally credits the canonical page; Analytics sees the tagged destination URL. In GA4, compare google / organic sessions for mobile devices and the corresponding landing pages, not all organic sources or all Google channels. Group parameter variants with their canonical article before comparing totals.
Search Console counts an organic click; client analytics needs the visitor to reach the page and the tracking to run. Closing a tab before the page and tag finish loading can leave a click without a measured session. A small, stable gap is normal; investigate a new or widening divergence rather than trying to make the totals identical.
Also check non-HTML destinations and bot handling before comparing site-wide totals. A PDF can receive Search clicks without running the page’s analytics tag, and raw request counts need their own bot filtering. For a typical article site, start with one affected HTML route so these differences don’t obscure the handoff.
Say a publisher sees 1,000 mobile Search Console clicks in each of two comparable periods, while GA4 shows Google organic sessions falling from 820 to 610. That’s 210 fewer measured sessions, about a 26% drop from the earlier session count. In this example, an Android test records the Google app URI at the first request but the publisher’s own origin at the final page after a newly added JavaScript redirect. Repair that route first by removing the unnecessary client-side hop. Keep required redirects on HTTPS and retain the query parameters your attribution setup needs. Then repeat the same result click, verify the request and JavaScript referrers, and confirm the expected session source under the same consent choice. The test shows a break you can repair; it does not tell you how many of the 210 sessions it explains.
What you can report with confidence
A common Google origin can cover Search, Discover or Google Images. Use the separate Discover performance report for feed traffic and the Image search type for image results; a log matcher cannot split those shared origins. AI Overviews and AI Mode are included in Search Console’s Web data, without a separately documented referrer label in this guide. Report Web Search as a combined total; the common origin cannot produce an AI-only count.
The November 12 documentation gives no minimum browser or app version and no separate US, UK or EU rollout schedule. Test the actual client and consent path serving your audience. It also supplies no correction factor for missing headers or for Android clicks that use the app URI; leave unobserved sources unknown.
When you hand a case to the developer who owns the landing page, give them the original entry URL, the first and final referrer values, the phone and app used, and the session channel if one was recorded. Include the redirect URL if there is one, so they can reproduce the exact route.