Website Health Guides

Referrer-Policy Header: Why It Matters

Learn what the Referrer-Policy header does, how it protects URL privacy, which policy value to use, and how it affects analytics and website security.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

Referrer-Policy is an HTTP security and privacy header that controls how much referrer information the browser sends when a visitor clicks a link, loads an image, opens a script, or moves from one page to another.

Without a clear policy, browsers decide how much of the current page URL is shared with other sites. This can expose unnecessary information such as full URLs, query strings, campaign parameters, search paths or private-looking page paths. A good Referrer-Policy helps balance privacy, analytics and compatibility.

Quick answer

Quick answer

Referrer-Policy controls whether browsers send the full URL, only the origin, or no referrer information when users navigate or load resources. A common safe default is strict-origin-when-cross-origin because it keeps useful origin-level analytics while reducing full URL leakage to other sites.

Referrer-Policy

The Referrer-Policy header tells browsers what information to include in the Referer header.

How referrer data is sent 
A visitor is on:
https://example.com/account/settings?token=abc

They click a link to:
https://partner.com

Depending on the policy, the browser may send:
- the full URL
- only https://example.com
- nothing

The HTTP header is spelled Referer historically, but the policy header is spelled Referrer-Policy.

Why referrer data matters

Referrer data is useful, but it can also leak information.

Useful for

  • analytics
  • attribution
  • debugging traffic sources
  • affiliate tracking
  • security logs
  • understanding user paths

Risky when it exposes

  • private page URLs
  • search terms
  • query parameters
  • session-like values
  • campaign IDs
  • user identifiers
  • internal paths
  • admin URLs
  • checkout or account routes

Referrer-Policy helps prevent unnecessary URL sharing without fully breaking analytics.

Policy values

no-referrer

Send no referrer information.

no-referrer-when-downgrade

Send referrer unless moving from HTTPS to HTTP.

origin

Send only the origin, such as https://example.com.

origin-when-cross-origin

Send full URL on same-origin requests, but only origin to other sites.

same-origin

Send referrer only within the same site.

strict-origin

Send only origin, and do not send referrer from HTTPS to HTTP.

strict-origin-when-cross-origin

Send full URL on same-origin requests, only origin to other HTTPS sites, and no referrer to HTTP.

unsafe-url

Always send the full URL. Usually not recommended.

Analytics impact

If too strict

  • external sites may not see your site as a referrer
  • attribution may become less detailed
  • some partner or affiliate tracking may lose context
  • debugging traffic paths may be harder

If too loose

  • full URLs may be shared unnecessarily
  • query parameters may leak
  • private-looking paths may be exposed to third parties

Referrer-Policy does not directly improve rankings, but it can affect analytics visibility and privacy posture.

Same-origin vs cross-origin

Understanding origin helps explain how Referrer-Policy behaves.

Same-origin means

Same protocol, same hostname and same port. Example: https://example.com/page-a to https://example.com/page-b

Cross-origin means

The destination differs by protocol, hostname or port. Example: https://example.com to https://partner.com

Many policies allow more detail for same-origin navigation and less detail when sending information to another site.

Why this matters

Why this matters

Referrer-Policy matters because URLs can contain more information than expected. Even if a page is public, its path or query parameters may reveal campaign details, account flows, search terms or internal structure.

A good policy reduces unnecessary data sharing while preserving enough information for normal analytics and debugging.

How to check it

Use HTTP Header Checker to inspect the final HTTPS response for your site.

Check:

  1. Final response — Follow redirects and check the final page users load.
  2. Header presence — Look for Referrer-Policy.
  3. Policy value — Confirm the value matches your privacy and analytics needs.
  4. Important pages — Check homepage, login, checkout, account, blog and landing pages.
  5. CDN/origin behavior — Confirm the header is not missing or overwritten by CDN rules.
  6. Browser behavior — Test external clicks if analytics or partner tracking matters.

Check your policy

Use HTTP Header Checker to inspect the final HTTPS response for Referrer-Policy.

Run HTTP Header Check →

Common problems

Referrer-Policy missing

Medium

Browser defaults control referrer behavior instead of your explicit policy.

Next step: Add a clear policy such as strict-origin-when-cross-origin.

Policy too loose

Medium

Full URLs may be shared with external sites.

Next step: Avoid unsafe-url and use a stricter policy.

Policy too strict for analytics

Low

Traffic attribution or partner tracking may lose useful referrer context.

Next step: Test analytics before using no-referrer everywhere.

Header only on some pages

Medium

Sensitive pages may behave differently from the rest of the site.

Next step: Apply the policy consistently across important routes.

CDN overwrites the header

Medium

The origin sends one policy but CDN rules change or remove it.

Next step: Decide whether CDN or origin manages the header.

Multiple conflicting headers

Medium

Different layers may send different Referrer-Policy values.

Next step: Remove duplicates and keep one intentional policy.

Private URLs contain query data

High

Sensitive-looking query parameters may leak if policy is too loose.

Next step: Use stricter policy and avoid putting sensitive data in URLs.

External integrations depend on referrer

Low

Some partner tools may expect referrer information.

Next step: Test integrations after changing the policy.

How to configure it

  1. Step 1: Audit current policy

    Run HTTP Header Checker and see whether Referrer-Policy is present.

  2. Step 2: Choose a safe default

    For most sites, start with strict-origin-when-cross-origin.

  3. Step 3: Review sensitive pages

    Use stricter rules for account, checkout, admin or private pages if needed.

  4. Step 4: Check analytics needs

    Confirm attribution and partner tracking still work as expected.

  5. Step 5: Configure in one place

    Set the header at the server, CDN, hosting panel or application level.

  6. Step 6: Avoid conflicting rules

    Make sure CDN and origin do not send different policy values.

  7. Step 7: Re-test important pages

    Check final HTTPS responses after deployment.

  8. Step 8: Monitor analytics

    Watch traffic attribution after the policy change.

Example configurations

Policy values 
Recommended general default:
Referrer-Policy: strict-origin-when-cross-origin

More privacy-focused:
Referrer-Policy: same-origin

Maximum privacy:
Referrer-Policy: no-referrer

Origin only:
Referrer-Policy: origin

Avoid for most sites:
Referrer-Policy: unsafe-url

Examples are illustrative. Choose a policy based on your privacy, analytics and integration needs.

Server and CDN examples 
Nginx:
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache:
Header always set Referrer-Policy "strict-origin-when-cross-origin"

HTML meta fallback:
<meta name="referrer" content="strict-origin-when-cross-origin">

The HTTP header is usually preferred because it applies consistently before the page content is parsed.

Syntax may vary by server, hosting panel, CDN and framework.

Referrer-Policy example 
Current page:
https://example.com/pricing?campaign=partner-2026

External destination:
https://partner.com

Policy: unsafe-url
Sent referrer:
https://example.com/pricing?campaign=partner-2026

Policy: origin
Sent referrer:
https://example.com

Policy: no-referrer
Sent referrer:
none

Policy: strict-origin-when-cross-origin
Sent referrer to HTTPS partner:
https://example.com

This example is illustrative. Browser behavior may also depend on destination protocol and policy support.

Stricter policies

Consider stricter policies when your site handles:

  • account dashboards
  • checkout flows
  • private documents
  • internal tools
  • medical/legal/financial content
  • sensitive search pages
  • admin portals
  • URLs with meaningful query parameters
  • user-specific pages

Referrer-Policy helps reduce leakage, but sensitive data should not be placed in URLs in the first place.

Frequently asked questions

What does Referrer-Policy do?

It controls how much referrer information the browser sends when navigating or loading external resources.

What is the best Referrer-Policy value?

For many sites, strict-origin-when-cross-origin is a good default balance between privacy and analytics.

Can Referrer-Policy affect analytics?

Yes. Stricter policies may reduce referrer detail in analytics or partner tracking.

Does Referrer-Policy improve SEO?

Not directly. It mainly affects privacy, browser behavior and analytics visibility.

Is no-referrer safest?

It is the most private, but it can reduce attribution and break some workflows that rely on referrer data.

Should sensitive data be placed in URLs if Referrer-Policy is set?

No. Avoid putting sensitive tokens, IDs or private data in URLs whenever possible.

Where should I configure Referrer-Policy?

Usually at the server, CDN, hosting panel or application level. The HTTP header is preferred over only using a meta tag.

Use these free tools to verify your configuration after applying changes.

HTTP Header Checker Website Status Checker SSL Checker Domain Health Checker DNS Lookup
Security Headers You Should Know 9 min read Using an HTTP Header Checker to Audit Your Site 8 min read Content-Security-Policy (CSP): Setup and Common Mistakes 8 min read HSTS Explained: Strict Transport Security for Browsers 8 min read Implementing Browser Caching for Better Performance 10 min read
Browse all Website Health guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.