Updated: November 17, 2025
If you’ve ever stared at your GA4 acquisition report and wondered why half your traffic shows up as Direct when you know people are coming from social media, newsletters, and partner sites — you’re not alone. I’ve seen this confuse a lot of people, and more often than not, the culprit is hiding in plain sight: your Referrer-Policy header.
This tiny HTTP header decides whether your analytics tools see the full URL with UTM parameters, just the domain, or absolutely nothing. Get it wrong, and your attribution data silently breaks.
In this post, I’ll walk through every Referrer-Policy value, explain exactly how each one affects your data, and tell you which one I’d recommend for real-world use.
What is Referrer-Policy, really?
Here’s the simple version. When a user clicks a link on your site and lands on another page — whether it’s on your domain or someone else’s — the browser can send a Referer header (yes, that’s the actual spelling) telling the destination where the user came from.
But how much detail the browser sends depends entirely on your Referrer-Policy.
Some policies send the full URL including query parameters and UTM tags. Some send only the domain name. Some send nothing at all. And some behave differently depending on whether you’re navigating from HTTPS to HTTP or crossing domains.
For anyone working in analytics or marketing, this matters a lot. Because when the referrer information gets stripped, your analytics tool shrugs and labels that traffic as Direct — making it look like someone typed your URL manually when in reality they clicked a link from your carefully crafted campaign.
Complete list of Referrer-Policy values
Here’s every policy value, what it sends, and what it means for your analytics setup.
| Policy | What It Sends | What It Means for Analytics | Risk Level |
|---|---|---|---|
| no-referrer | Sends nothing | Almost all referrals show as “Direct” | 🔒 Safest |
| no-referrer-when-downgrade | Full URL unless navigating HTTPS → HTTP | Mostly complete data | ⚠️ Legacy behavior |
| origin | Sends only domain | UTMs lost, only root-level attribution | 🔒 Safe |
| same-origin | Full URL for same-site links only | Cross-domain referrals lost | 🔒 Safe |
| origin-when-cross-origin | Full URL for same-origin; domain only for cross-origin | Good for internal analytics, weaker external attribution | 🟡 Balanced |
| strict-origin | Domain only; nothing when HTTPS → HTTP | Clean but limited data | 🔒 Safe |
| strict-origin-when-cross-origin (default) | Full URL for same-origin; domain only for cross-origin; blocks insecure downgrade | Best balance for most sites | 🟡 Recommended |
| unsafe-url | Full URL always—including cross-site and HTTPS→HTTP | Perfect attribution… but extremely risky | 🔥 Not recommended |
How policy changes affect your analytics tools
Different policies produce very different acquisition reports. Here’s what actually changes behind the scenes.
- Traffic attribution: Strict policies like no-referrer or same-origin erase cross-site referrers. Your analytics platform then classifies that traffic as Direct, which silently inflates your direct traffic numbers and makes your campaign attribution look weaker than it actually is. Open policies like unsafe-url give you full URLs with parameters — precise attribution, but at a privacy cost.
- Cross-domain tracking: If your site uses multiple subdomains or third-party services like payment gateways and login providers, strict policies break session continuity. You’ll see more “new users” and split sessions than you should. strict-origin-when-cross-origin gives you full same-origin visibility while limiting what leaks cross-origin.
- UTM and query string tracking: UTMs are the backbone of campaign measurement. Strict policies may strip UTMs on cross-site navigation. unsafe-url preserves everything but risks leaking sensitive data — like session tokens or user IDs — to third parties. That’s a hard no for production.
Best practices
- Avoid unsafe-url in production. I know it’s tempting — who doesn’t want perfect attribution? But the privacy and security risks are real. You’re sending full URLs with potential query parameters to every destination. That’s a data leak waiting to happen.
- Use strict-origin-when-cross-origin. It’s the browser default for a reason. It gives you complete referrer data within your own domain, limits cross-origin data to just the origin (no query strings), and blocks insecure downgrades. In my experience, it’s the best balance for most analytics setups.
Final Words
Hopefully, this helped you understand why your Referrer-Policy might be quietly sabotaging your acquisition reports. It’s one of those settings that lives outside your analytics configuration, so it’s easy to overlook — but the impact on data quality is real.