Redirect and referrer loss
The referrer tells analytics where a visit came from, but it is fragile. A redirect hop can replace the original referrer with the redirector's URL, and Referrer-Policy or HTTPS-to-HTTP downgrades can suppress it entirely. When the referrer is empty, the visit falls into direct; when it is the redirector's domain, it can look like a self-referral. This page explains referrer loss in transit.
How redirects and policy strip referrers
When a click passes through a redirect (a link shortener, an interstitial, a tracking hop), the browser may set document.referrer to the redirector rather than the original page — or drop it if the redirector sends a strict Referrer-Policy. Separately, a navigation from an HTTPS page to an HTTP page drops the referrer for security, and Referrer-Policy values like no-referrer or strict-origin change what (if anything) is sent.
Downstream attribution effects
An empty referrer means analytics has no source signal, so the visit is bucketed as direct — the same bucket as bookmarks and untagged traffic. A referrer that shows the redirector's own domain can be misread, and if that domain is in your property's family it can register as a self-referral.
Mitigations: prefer tagged campaign links so attribution does not depend on the referrer at all; minimize redirect hops on inbound links; and understand your and your partners' Referrer-Policy settings.
- Redirect hops can overwrite or drop document.referrer
- HTTPS→HTTP navigations drop the referrer
- Referrer-Policy (no-referrer/strict-origin) trims it
- Empty referrer → direct bucket; tag links to avoid reliance
How it appears in analytics and logs
A surge of direct or unexpected-referrer traffic after adding a redirect step usually means the original referrer was stripped or overwritten in the hop.
Diagnostic use case
Explain why traffic from a known source arrives as direct, or why a redirect service appears as the referrer instead of the real origin.
What WebmasterID can help detect
WebmasterID records the referrer it actually receives first-party, so you can see when redirects or policies have already stripped it rather than guessing.
Common mistakes
- Relying on the referrer instead of tagging inbound campaign links.
- Adding redirect hops that strip the original source.
- Ignoring Referrer-Policy when diagnosing missing sources.
Privacy and accuracy notes
Referrer policies exist partly to protect users; full-URL referrers can leak context, so trimming is often intentional. This page is educational, not legal advice.
Related pages
- Dark traffic in analytics
Dark traffic (or dark social) is genuine human traffic whose source is lost, so it falls into the Direct bucket. It comes from links opened inside apps and messaging clients, email programs, documents, and secure-to-insecure transitions that strip the Referer header. The result is an inflated Direct channel that hides real acquisition. This page explains the mechanisms that erase the referrer.
- Direct traffic as a catch-all bucket
Direct traffic is often misread as 'people who typed the URL'. In practice it is a catch-all for any session with no usable referrer or campaign: untagged links, stripped referrers, app and messaging clicks, and redirects that lose data. When other attribution fails, direct swells. This page explains what really lands in the direct bucket and how to shrink it.
- GCLID stripping and loss
The gclid is the Google Ads click identifier appended by auto-tagging. If anything between the ad and the page removes the parameter — a redirect that drops query strings, a CMS canonical rewrite, a link shortener, or a privacy tool — the landing page never sees the gclid and the click cannot be attributed. This page explains where gclid loss happens and how to detect it.
- Campaign link docs
Tag links so attribution survives referrer loss.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.