Referrer policy meta tag is empty or invalid

This issue reports a <meta name="referrer"> tag that your page declares but the browser cannot apply — so the referrer policy you meant to set is not the one in force.

The content attribute must hold a value from the referrer-policy vocabulary:

• no-referrer
• no-referrer-when-downgrade
• origin
• origin-when-cross-origin
• same-origin
• strict-origin
• strict-origin-when-cross-origin (recommended — the modern browser default)
• unsafe-url

Anything else is not a weaker policy, it is no policy: the browser discards a token it does not recognise and falls back to its own default, while the page still looks deliberately configured to anyone reading the markup.

The tag is reported when:

• its value is outside the vocabulary above, e.g. strict origin, no-referer
• its effective value is unsafe-url, which sends the full URL (path and query string included) to every destination, over plain HTTP as well
• the page declares two referrer meta tags setting different policies — the browser applies the last one, which is rarely the one the author is looking at
• it carries no content attribute, or an empty one, and the page sets its policy some other way — the tag is inert markup beside a policy that works

The tag is not reported when:

• the page has no <meta name="referrer"> at all, or declares one that is empty on a page with no policy anywhere. Both are issue #43 (Referrer-Policy header, under HTTP Security Headers), which asks whether the page has a referrer policy by any route — the Referrer-Policy header, a <meta http-equiv> tag, or this one. Reporting the same missing policy in both places counted it twice.
• it declares a permissive but real policy such as no-referrer-when-downgrade. That is a choice a site is entitled to make; the value is stored on the page record for review.

Example of a correct implementation:

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

The Referrer-Policy is important for privacy and security:

• User experience: Prevents leaking sensitive URL parameters (like tokens, session IDs, or PII) to third-party sites via the Referer header.
• Security: Sensitive information in URLs (like password reset tokens or API keys) should not be sent to third-party sites.
• Privacy: Users may not want the full URL of internal pages to be visible to external sites they visit.
• AI Search / AEO: While not directly related to AI search, protecting user privacy and security builds trust, which is important for overall site quality.

Resolving this issue improves your SEO health score by demonstrating attention to privacy and security best practices, which contributes to overall site quality signals.

Follow these steps to implement a proper Referrer-Policy:

1. Choose your method (HTTP header is preferred over HTML meta):

   Method 1: HTTP Header (Recommended)

   • Configure your web server to send the Referrer-Policy HTTP header
   • Example for Apache (.htaccess):

     Header set Referrer-Policy "strict-origin-when-cross-origin"

   • Example for Nginx:

     add_header Referrer-Policy "strict-origin-when-cross-origin";

   Method 2: HTML Meta Tag

   • Add the meta tag to your HTML <head> section:

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

2. Choose the right policy for your needs:

   • strict-origin-when-cross-origin (recommended): Sends only the origin for cross-origin requests, but full URL for same-origin requests
   • strict-origin: Sends only the origin for all requests
   • same-origin: Sends full URL only for same-origin requests
   • no-referrer: Sends no referrer information

3. Avoid these policies (too permissive):

   • unsafe-url (most permissive: leaks the full URL to every destination, including over plain HTTP). This one is reported as an issue.
   • no-referrer-when-downgrade (the old browser default: leaks the full URL to cross-origin HTTPS destinations). This is a choice you are entitled to make and is not reported, but strict-origin-when-cross-origin is the safer default.

   Check the spelling while you are there: a value outside the eight policy tokens — strict origin with a space, no-referer with one r — is discarded by the browser and leaves the page on its default, which is why it is reported.

4. Verify implementation:

   • Use browser developer tools to check HTTP response headers
   • Test by clicking external links and checking if the Referer header is properly restricted
   • Use security testing tools to ensure sensitive parameters aren't leaked

Note: If your site uses URL parameters for sensitive data (like password reset tokens), this policy is critical for security.

Example 1: Correct Implementation

Scenario: The page declares a policy the browser can apply.

Correct State (Passes):

<head>
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <title>Page Title</title>
</head>

A policy delivered by HTTP header instead also passes, and no meta tag is required:

HTTP/1.1 200 OK
Referrer-Policy: strict-origin-when-cross-origin

Example 2: Tag That Declares Nothing

Scenario: The policy is served by header, and an empty meta tag sits beside it.

Problematic State (Fails):

HTTP/1.1 200 OK
Referrer-Policy: strict-origin

<head>
  <meta name="referrer" content="" />
  <title>Page Title</title>
</head>

Why it fails: An empty content declares no policy. The page is protected by the header, so the tag does nothing but suggest to the next person reading the template that the policy is set here — and an edit to it will have no effect.

Corrected State (Passes): give the tag a value, or remove it.

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

Note: an empty tag on a page with no policy anywhere is reported by issue #43 instead — that page has no referrer policy at all, which is #43's question.

Example 3: A Value No Browser Defines

Scenario: The policy is spelled in a way the vocabulary does not contain.

Problematic State (Fails):

<meta name="referrer" content="strict origin" />

Why it fails: strict origin (a space, not a hyphen) is not a referrer policy. The browser discards the token and falls back to its default — the tag has no effect at all.

Corrected State (Passes):

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

Example 4: unsafe-url

Scenario: A checkout page carries session tokens in the URL and sets the most permissive policy there is.

Problematic State (Fails):

<!-- URL: https://shop.example.com/checkout?session_id=abc123&return_token=xyz789 -->
<head>
  <meta name="referrer" content="unsafe-url" />
</head>

Why it fails: unsafe-url sends the full URL — session_id and return_token included — in the Referer header of every outbound navigation, and over plain HTTP as well.

Corrected State (Passes):

<meta name="referrer" content="no-referrer" />

Example 5: Two Tags, Two Policies

Scenario: A template sets one policy and a plugin appends another.

Problematic State (Fails):

<head>
  <meta name="referrer" content="no-referrer" />
  <meta name="referrer" content="unsafe-url" />
</head>

Why it fails: The browser applies the last one, unsafe-url — not the strict policy the first tag appears to set.

Corrected State (Passes): keep one tag.

<meta name="referrer" content="no-referrer" />

Example 6: No Tag at All — Not This Issue

Scenario: The page declares no referrer policy anywhere.

<head>
  <meta charset="UTF-8" />
  <title>Page Title</title>
</head>

This is reported by issue #43 (Referrer-Policy header), which reads the HTTP header, <meta http-equiv> and <meta name="referrer"> together. Issue #37 stays silent so one missing policy is not counted twice.

The check reads the tag the page declares, and nothing else:

1. Collect the tags: every <meta name="referrer"> in the document is read, not just the first, and the content attribute is kept exactly as written — "no content attribute" and content="" are different edits and are described as such.

   The name attribute is matched case-insensitively, so name="Referrer" and name="REFERRER" are read as well as name="referrer". All three are valid HTML and several CMS templates emit the capitalised form. Only the exact lower-case spelling used to match, so a page declaring name="Referrer" content="unsafe-url" was invisible to this check and to issue #43 — neither reported it.

2. Parse the value the way a browser does: the value is a comma-separated fallback list, lower-cased and trimmed. Tokens outside the referrer-policy vocabulary (no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url) are discarded, and the last recognised token is the policy actually in force.

3. Report a declared policy that cannot work:

   • no recognised token — the whole tag is discarded by the browser
   • a recognised token that the browser ignores, named alongside the fallback that does apply
   • an effective policy of unsafe-url
   • two tags declaring different policies, naming the one the browser will use
   • a tag that declares nothing (no content, or an empty one) while the page's policy arrives through the Referrer-Policy header or a <meta http-equiv> tag

4. Stay silent on absence: a page with no referrer meta tag produces no finding here, and neither does an empty tag on a page with no policy at all — that page has no policy, which is exactly what issue #43 reports. The two checks between them cover every state exactly once:

   State	Reported by
   No tag, no header	#43
   No tag, header present	neither
   Empty tag, no header	#43
   Empty tag, policy set elsewhere	#37
   Tag with a value that cannot apply	#37

5. Record the value: the declared value is stored on the page record (referrerMetaValue) whether or not it is valid, so a permissive-but-valid policy can be reviewed without being reported as a defect.

Storage Level

Page Level — This issue is evaluated for each individual URL.

Database Table / Prisma Model

PageHtmlHeadAudit

Stored Fields

Detection Dependencies

• The following data sources are required to evaluate this issue:
• HTML Document — The crawler parses the HTML head section to find the referrer meta tag
• Meta Tag Extraction — The <meta name="referrer"> tag is extracted