Skip to content
Browse all guides

Issue #139 · standard

Issue 139

What is this issue?

This issue checks whether your website declares a Referrer-Policy to control what referrer information is sent when users navigate to linked external sites.

What this issue checks

  • The Referrer-Policy HTTP response header is present (preferred method)
  • OR a <meta name="referrer"> tag is present in the HTML <head> (alternative method)
  • The policy value is a recognized valid directive
  • The policy is not set to unsafe-url (which leaks full URLs to all destinations)

What is considered a passing implementation

A passing implementation means:

  • The Referrer-Policy header is present with a valid directive
  • The policy is not unsafe-url
  • The policy protects user privacy by controlling referrer information

Real-world example

A properly configured Referrer-Policy header looks like:

Referrer-Policy: strict-origin-when-cross-origin

This tells browsers to send the full URL when navigating to same-origin destinations, but only send the origin (domain) when navigating to cross-origin destinations. This protects sensitive query parameters from being leaked to external sites.

Why does it matter?

Referrer-Policy is important for privacy and SEO:

Crawlability

If sensitive URL parameters are leaked to external sites, it could potentially expose private content or allow unauthorized access if those parameters are meant to be secret.

Indexability

Similar to crawlability, leaking sensitive URL parameters could affect how search engines index your pages if those parameters contain session or tracking data.

Rankings

While not a direct ranking factor, protecting user privacy and demonstrating security best practices contributes to overall site quality signals that search engines value.

User Experience

Without a referrer policy, browsers may send the full URL (including sensitive query parameters like password reset tokens, session IDs, or promotional codes) to external sites when users click links. This can expose user data to third parties.

AI Search / AEO

AI-powered search engines and assistants prioritize sites that respect user privacy and follow security best practices.

SEO Health Score Impact

Resolving this issue improves your overall SEO health score by protecting user privacy and preventing unintentional information leakage to external sites.

How to fix it

Follow these steps to implement Referrer-Policy properly:

Step 1: Choose an appropriate policy

Choose an appropriate policy based on your needs. For most sites, strict-origin-when-cross-origin provides the best balance of privacy and functionality.

Step 2: Set the HTTP header (preferred method)

Set the HTTP header on your web server, CDN, or load balancer:

Referrer-Policy: strict-origin-when-cross-origin

Step 3: Alternative - Use meta tag

Use meta tag in your HTML <head> if you cannot set HTTP headers:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Step 4: Avoid unsafe-url policy

Avoid unsafe-url policy, which sends the full URL to all destinations regardless of protocol or origin. This leaks sensitive query parameters to external sites.

Step 5: Test your configuration

Test your configuration to ensure the policy is applied correctly. Use browser developer tools to check the Referer header on outbound links.

Step 6: Consider your use case

  • Use no-referrer if you never want to send referrer information
  • Use same-origin if you only want to send referrer to same-origin destinations
  • Use strict-origin-when-cross-origin for most sites (recommended)
  • Use unsafe-url only if you explicitly need to send full URLs everywhere (not recommended)

Examples

Example 1: Missing Referrer-Policy

Problem: No Referrer-Policy is declared.

What fails:

No Referrer-Policy header or meta tag present

What passes:

Referrer-Policy: strict-origin-when-cross-origin

Example 2: Unsafe Policy

Problem: The policy is set to unsafe-url, which leaks full URLs.

What fails:

Referrer-Policy: unsafe-url

What passes:

Referrer-Policy: strict-origin-when-cross-origin

Example 3: Using Meta Tag

Scenario: Setting Referrer-Policy via meta tag instead of HTTP header.

What passes:

<meta name="referrer" content="same-origin" />

This is an acceptable alternative if you cannot set HTTP headers.

How PixyScan detects this

PixyScan checks whether your website declares a Referrer-Policy to control what referrer information is sent when users navigate to linked external sites.

Detection process

PixyScan follows these logical steps to identify Referrer-Policy issues:

  1. Check for Referrer-Policy declaration - PixyScan looks for the Referrer-Policy HTTP header in the response.

  2. Check for meta tag alternative - If the HTTP header is not present, PixyScan checks the HTML <head> section for <meta name="referrer"> tags as an alternative method.

  3. Determine effective policy - If both the HTTP header and meta tag are present, the HTTP header takes precedence. PixyScan uses the effective policy value for validation.

  4. Validate policy directive - PixyScan checks if the effective policy value is a recognized valid directive:

    • no-referrer
    • no-referrer-when-downgrade
    • origin
    • origin-when-cross-origin
    • same-origin
    • strict-origin
    • strict-origin-when-cross-origin
    • unsafe-url

  5. Check for unsafe policies - PixyScan flags the policy as unsafe if the effective policy is unsafe-url, which sends the full URL to all destinations.

When the issue is flagged

The issue is flagged when any of these conditions are met:

  • No Referrer-Policy is declared (neither HTTP header nor meta tag)
  • The effective policy is unsafe-url (which leaks sensitive information to all destinations)

When the issue passes

The issue passes when:

  • The Referrer-Policy header is present with a valid directive
  • The policy is not unsafe-url
  • The policy protects user privacy by controlling referrer information

References