← The Serse journal

GA4 direct traffic

Why GA4 can label search traffic as direct: a worked referrer diagnosis

Trace where search-source evidence stops reaching GA4. A reusable worksheet and hypothetical region-selector example show why restoring an internal referrer may not fix measurement that starts too late.

The useful investigation is not “How much Direct traffic is really organic?” It is narrower: where did this test journey stop carrying usable source evidence? That question can support an implementation decision. A Direct percentage alone cannot.

The hypothetical example below deliberately includes an unsuccessful fix. It separates losing a referrer during navigation from starting measurement after the search arrival. Those problems can coexist, but repairing one does not necessarily repair the other.

Define the question before blaming Direct

Google describes (direct) / (none) as traffic without an identifiable referral source. The label therefore does not establish that someone typed an address. Google lists missing traffic information, redirects and blocker-related interference as possible contributors; these are investigation leads, not evidence about an individual session. See Google’s explanation of Direct traffic.

Begin with Session source / medium in Traffic acquisition. User-scoped dimensions describe a user’s original acquisition; session-scoped dimensions describe acquisition for sessions; event-scoped dimensions address attribution at the event level. They answer different questions. Google also states that changing the reporting attribution model does not change user- or session-scoped dimensions. An attribution-model switch is therefore not the remedy proposed here. These distinctions come from Google’s traffic-source scope documentation.

Write the investigation question explicitly: “What source evidence did measurement receive when this test session began?” Record the dimension, reporting period and controlled test context. Do not substitute a first-user figure or event-attribution result because it is easier to find.

Keep observation, diagnosis and prediction separate. “The first measured page supplied an empty referrer” is an observation. “Collection started after the external arrival” is a diagnosis requiring evidence from the earlier page. “Entry-page collection should preserve the available search source” is a prediction to test. None establishes that all historical Direct traffic came from search.

Separate the browser handover from analytics collection

A document navigation request can contain an HTTP Referer header. The destination page exposes navigation referrer information to JavaScript through document.referrer. Those are browser observations, not completed analytics classifications. web.dev explains request referrers and their JavaScript counterpart.

GA4 introduces another boundary. Google documents that page_referrer defaults to document.referrer and helps determine traffic source. An implementation can supply an explicit value instead. The ignore_referrer setting tells Analytics not to display the referrer as a traffic source. Browser evidence and collected evidence therefore need separate checks, using Google’s configuration reference.

Referrer information can also be shortened without disappearing. Under strict-origin-when-cross-origin, a cross-origin HTTPS-to-HTTPS request sends the referring origin, rather than its path and query. Same-origin requests retain more URL detail. An HTTPS-to-HTTP downgrade omits the referrer under that policy. By contrast, no-referrer suppresses referrer information regardless of destination. These are the rules documented in MDN’s referrer-policy reference.

A Google origin without a search URL’s full path is therefore not equivalent to an empty referrer. Do not diagnose complete source loss merely because the browser withheld URL detail.

Campaign parameters need a separate column in your notes. They are part of the destination URL, whereas an incoming referrer describes the navigation source. Google’s Direct troubleshooting guidance identifies possible redirect-related information loss; it does not establish that every redirect removes either input. Inspect the actual requests rather than assuming the presence of a redirect explains the result.

Build a four-boundary evidence record

The worksheet below is an editorial diagnostic method derived from the browser, configuration and reporting documentation. It is not an official Google troubleshooting tool. Its purpose is to locate the earliest demonstrable gap before changing a link, tag or privacy policy.

BoundaryEvidence to retainQuestion it answers
Document navigationPublic destination, response status, incoming `Referer`, applicable page or link policyDid source evidence reach this document?
Browser document`document.referrer` on the actual entry and first measured pageWhat evidence could page JavaScript read?
Analytics collectionFirst collected page, supplied referrer, relevant overrides and execution orderDid measurement collect the evidence that was available?
Session reportingSession source / medium, report period and controlled journey contextIs the collected journey being interpreted at the intended scope?

Capture the route before interacting

Use an authorised, consenting test journey and a test property where practical. Record browser version, privacy settings, consent state, route and exact test time. Start each independent comparison with a fresh test browser profile, keeping other conditions consistent. That is an experimental control, not a reason to disable privacy protections.

Open developer tools before the arrival and retain the network history across navigation. Follow the actual unpaid search result where available. Typing the destination into the address bar does not reproduce a search arrival. Inspect document requests and intermediate responses, not merely the final address bar.

On each relevant loaded document, inspect document.referrer. Also inspect the policy governing the onward navigation, including any link-level setting. The distinction between navigation requests, browser-visible referrers and policy controls follows web.dev’s referrer explanation.

Publish only synthetic paths and redacted observations. Keep cookies, identifiers, account details and raw network exports out of the shared diagnostic record.

Establish what collection actually supplied

Identify the first page from which analytics collection occurs. Inspect the supplied referrer through the implementation’s collection-inspection or debugging method. If that value cannot be established, mark it unverified. Do not populate the cell from the tag’s intended configuration.

In particular, the HTTP Referer on an analytics collection request is not the incoming referrer on the landing-document request. They are different requests. web.dev distinguishes navigation and other browser requests; GA4’s supplied page_referrer is a further field to check through Google’s configuration documentation.

Review explicit page_referrer configuration, ignore_referrer and execution timing. If the browser has useful evidence but collection differs, changing navigation may address the wrong boundary.

No observed collection is a separate outcome—not a demonstrated Direct session. Google mentions blocker-related attribution interference, but that does not establish that a completely blocked request creates a Direct row. If collection uses infrastructure that browser inspection cannot establish, the worksheet remains incomplete until that route is checked separately.

Work through an unmeasured region selector

Everything in this example is hypothetical. The paths, observations and report expectations are teaching assumptions. No experiment has been performed, and no Serse or customer traffic is represented.

Assume an unpaid Google result opens an HTTPS page at /roof-repairs. Its browser-visible referrer identifies Google. This entry page contains a region selector but collects no GA4 data. Choosing Australia opens /au/roof-repairs on the same origin, where collection begins.

The region link uses referrerpolicy="no-referrer". Neither destination contains campaign parameters. Consent is valid. Each independent run has a fresh test identity with no eligible earlier source; no manual campaign values or referrer overrides affect it. For the proposed repair, assume collection and session continuity between the pages, then verify those conditions rather than inferring them from the shared hostname.

These inputs isolate two separate issues: internal referrer suppression and measurement beginning after the external arrival.

Run A: reproduce the evidence gap

Follow the search result and pause on /roof-repairs. Under the assumptions, the incoming document request and document.referrer identify Google. No analytics collection occurs there.

Choose Australia. Because the link specifies no-referrer, the expected navigation to /au/roof-repairs carries no referrer information. The destination’s document.referrer is empty. With default configuration, its first analytics collection also supplies an empty page_referrer.

Those browser expectations follow MDN’s policy rules, while the collection expectation follows Google’s documented referrer default.

The intermediate finding matters more than the channel label: Google evidence existed on an earlier document, but measurement did not collect there. At the first measured page, that evidence is absent.

Direct is a plausible report outcome under these controlled assumptions, consistent with Google’s definition of traffic lacking an identifiable source. It remains a prediction, not a guaranteed classification. Complete the session-report boundary before calling the reproduction successful.

Run B: test the appealing but unsuccessful fix

For a separate fresh-identity run, leave the entry page unmeasured. Change only the region link’s policy to strict-origin-when-cross-origin. Because both pages share an origin, the expected onward referrer can include the entry page’s path and query, following MDN’s same-origin policy behaviour.

Repeat the journey. The entry still receives Google evidence without collecting it. The first measured destination can now receive the site’s own /roof-repairs address as its referrer. Its browser referrer is no longer empty, and default collection can preserve that value.

This intervention succeeds at transmitting an internal referrer but fails at supplying the original external search referrer. The browser referrer describes the preceding document; it is not an automatically preserved history of earlier sources. That interpretation follows the request-source model explained by web.dev.

Do not prescribe a final channel for Run B. The narrower conclusion is sufficient: the collected value identifies the intermediate page, not Google. A changed headline metric would not, by itself, prove that the missing search arrival had been measured correctly.

This is why “remove the restrictive policy” is an inadequate implementation ticket. It describes a code change without specifying which source evidence the change must recover.

Run C: measure the actual entry

Restore the region link’s original no-referrer policy. Change collection so that, with valid consent, the entry page is measured before the visitor leaves. This run tests coverage and timing rather than weakening the internal link’s privacy setting.

Follow the search result again. Confirm the Google referrer on /roof-repairs, then confirm that the first collection contains that evidence. Only then choose Australia. Record destination collection and verify that the journey remains within the intended measured session.

Under the stated assumptions, google / organic is the expected session classification. Google’s traffic-source documentation includes an unpaid Google Search session example, while its configuration reference explains the referrer input. Together they support the expectation; neither turns this hypothetical implementation into an observed success.

The actionable outcome is conditional: if the worksheet confirms that collection starts too late, implement appropriate entry-page measurement and repeat the controlled route. A published tag does not close the task. The collected evidence, execution order and eventual session result must support the proposed repair.

RunControlled changeExpected first collected referrerLimited conclusion
ANone; reproduce the assumed setupEmpty on the regional destinationExternal evidence existed before measurement but was absent when collection began
BAllow the internal link to send a referrerThe site’s own entry-page addressRestoring an internal referrer does not recreate the original search input
CCollect appropriately on the actual entryRecognisable Google referrerThe missed input is collected; session classification still needs verification

Try to disprove the late-collection diagnosis

The diagnosis fails if its central premise is false. If Run A already collects an event containing the Google referrer from /roof-repairs, measurement did not begin where the example assumes. Investigate the later discrepancy rather than adding another entry tag.

Consider a contrasting hypothetical failure. The entry document has a Google referrer and analytics runs there, but an explicit page_referrer setting supplies an empty value. The first gap is between browser evidence and collection—not between entry and region selection. Moving collection earlier does not, by itself, correct that configuration. The relevant capability is documented in Google’s referrer configuration reference.

Run C is also an invalid test of the proposed remedy if navigation happens before entry collection. The implementation may have changed without collecting the intended arrival. If identity or session context changes between pages, the expected session outcome needs a separate investigation. Do not force those observations into a referrer-only explanation.

If Google evidence never reaches the actual entry document, investigate the real incoming route. The region-selector diagnosis no longer fits. The captured web.dev browser-default comparison is expressly dated October 2021; its policy explanations are useful, but that table cannot establish every current browser, extension, app or privacy mode’s behaviour. Reproduce the relevant environment instead.

Choose a repair at the demonstrated boundary

Use the completed evidence record to choose the next action. These branches are diagnostic hypotheses, not universal causal rules.

Observed patternCandidate actionPlausible fix that may failAcceptance check
External evidence reaches an unmeasured entry; collection begins later without itReview consent-respecting entry coverage and timingLoosening an internal referrer policyFirst collection on the entry contains the available external evidence
Browser evidence exists but collection supplies something differentReview configuration and executionMoving collection earlier without correcting the mismatchSupplied values match the intended configuration
Expected evidence is absent on the actual entryInspect the incoming route and applicable policiesInventing a referrer overrideReproduction establishes what reaches the entry and why
Collection appears correct but reporting differsReview scope and journey contextChanging attribution models to repair a session dimensionThe discrepancy is explained or explicitly remains unresolved
Collection cannot be establishedInvestigate collection separatelyCounting the run as a recorded Direct sessionCollection is verified, or its absence is documented

Entry measurement must respect consent and avoid duplicating an existing implementation. If privacy requirements prevent collecting the original arrival, document that boundary rather than bypassing it to improve a chart.

Weakening referrer policy also has costs. More permissive transmission can expose URL information without solving late measurement. web.dev explains the privacy risks of full referrer URLs, and MDN documents the risks of permissive policies.

Campaign tags are not a substitute for the missing investigation. Google’s scope documentation illustrates unpaid search acquisition, so the broad missing-tag guidance should not be read as requiring invented UTMs for every organic arrival. Adding a presumed campaign source changes the test input; it does not establish what the original journey supplied.

Leave historical unattributed traffic unresolved

A reproduction today can demonstrate a current failure path. It cannot identify which earlier Direct sessions followed it. This method offers no recovery, backfill or relabelling of historical attribution. Leave those origins unresolved unless separate evidence supports a narrower statement.

Search Console provides independent search context, not a session-matching ledger. Google documents differences from other tools involving privacy, processing, reporting delays, time zones and JavaScript-dependent measurement. These limitations appear in Search Console’s discrepancy guidance.

Consequently, subtracting GA4 organic sessions from Search Console clicks does not establish the number of search sessions mislabelled Direct. The arithmetic can be correct while the interpretation is unsupported: the inputs are not interchangeable observations.

Before using Search Console as context, check the intended property, report period and collection coverage. Serse’s Search Console integration verification guide develops those checks. They make comparisons more intelligible; they do not reveal the source of an individual historical Direct session.

Keep the implementation record separate from subsequent outcomes in your SEO reporting. A verified collection repair and a later change in channel totals are different observations. Neither permits an unsupported reassignment of earlier traffic.

Finish with a decision someone else can test

For the hypothetical region-selector route, the diagnosis is specific: external search evidence reaches the entry document, but collection starts after that arrival. Restoring the intermediate page’s address does not supply the missing external input. Appropriate entry-page collection is the candidate repair, subject to consent, execution and session-continuity checks.

The next test repeats the same route with only that intervention changed. Record the first collected page, supplied referrer and eventual Session source / medium. If any boundary remains unverified, keep the task open or narrow the conclusion.

After a real test supports it, the reporting statement can be equally specific: “The controlled route reproduced a source-evidence gap. The verified change addresses future collection on that route. Historical Direct traffic has not been reassigned.”

The objective is not a lower Direct share at any cost. It is a located gap, a bounded implementation decision and a repeatable test that can prove the diagnosis wrong.