HTTPS-to-HTTP referrer loss
A long-standing browser rule removes the referrer when navigating from a secure HTTPS page to an insecure HTTP page, to avoid leaking a secure URL into an unencrypted request. With most of the web on HTTPS this is less common than it once was, but it still explains specific cases of missing referrers — and it is a reason to serve your own site over HTTPS.
The secure-context downgrade rule
Browsers follow a referrer rule tied to transport security: when a request goes from an HTTPS (secure) origin to an HTTP (insecure) origin, the referrer is not sent. The purpose is to avoid leaking the full secure URL into an unencrypted request that could be observed in transit.
This is independent of, and layered on top of, the site's Referrer-Policy. Even a permissive policy will not send a referrer across a secure-to-insecure downgrade.
- HTTPS source to HTTP destination drops the referrer
- Protects a secure URL from leaking unencrypted
- Applies regardless of a permissive Referrer-Policy
Why HTTPS fixes it
If your own site is still served over HTTP, every visitor coming from an HTTPS page — which is now most of the web — will reach you with no referrer, inflating direct. Serving your site over HTTPS removes the downgrade, so the referrer is preserved subject only to the referring site's Referrer-Policy.
With the web now predominantly HTTPS-to-HTTPS, this specific loss is less frequent than before, but it remains a clear, fixable cause of missing referrers. MDN's Referer documentation describes this behaviour.
- HTTP destinations lose HTTPS referrers
- Serving HTTPS preserves the referrer
- Less common now the web is mostly HTTPS
How it appears in analytics and logs
If your site is served over HTTP, browsers strip the referrer from any HTTPS source linking to you, so those visits arrive in direct. Serving HTTPS preserves the referrer subject to the referring site's Referrer-Policy.
Diagnostic use case
Explain a missing referrer caused by an HTTPS-to-HTTP transition and recognise serving HTTPS as the fix for losing inbound referrers.
What WebmasterID can help detect
WebmasterID treats HTTPS-to-HTTP referrer loss as an expected cause of direct traffic, and the practical remedy — serving your site over HTTPS — is also what lets inbound referrers survive.
Common mistakes
- Running a site on HTTP and blaming analytics for missing referrers.
- Assuming a permissive Referrer-Policy overrides the secure-downgrade rule.
- Confusing this transport rule with policy-based trimming.
Privacy and accuracy notes
Dropping the referrer on a downgrade to HTTP protects users from leaking a secure URL over an unencrypted connection. WebmasterID reads whatever the browser sends and never reconstructs a referrer withheld for this reason.
Related pages
- Referrer-Policy and missing referrers
Referrer-Policy is the web standard that controls how much of the referrer a browser sends with a request. Site owners set it via an HTTP header or a meta tag, and modern browsers default to a privacy-leaning value. Understanding the policy values explains why so many referrers arrive trimmed to the origin or missing entirely.
- Direct traffic: what it really means
Direct traffic is the bucket analytics uses when no referrer is available. It includes genuine type-ins and bookmarks, but also a large share of visits whose referrer was stripped — app opens, HTTPS-to-HTTP transitions, shorteners, and privacy settings. Treating 'direct' as a single intent is the classic analytics mistake.
- Website observability
Spot direct-traffic spikes that trace back to referrer-loss conditions.
Sources and verification notes
- MDN — Referer headerDescribes the no-referrer-when-downgrade behaviour.
- MDN — Referrer-Policy
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.