What is Referrer-Policy?

The Referrer-Policy HTTP header controls how much information about the originating page is included in the Referer request header when a user navigates from your site to another, or when your page loads resources from external sources. Every time someone clicks a link, every time an image is loaded from a CDN, every time an analytics script fires, the browser potentially sends the URL of the current page to the destination server. Referrer-Policy lets you decide how much of that URL to share.

(A quick note on spelling: the HTTP header is spelled "Referer" with one "r" due to a misspelling in the original HTTP specification from the early 1990s. The policy header uses the correct spelling "Referrer" with two r's. Both spellings are intentional.)

What the Referer Header Contains and When It Is Sent

By default (without a Referrer-Policy), the browser sends the full URL of the current page as the Referer header with most outgoing requests. This includes:

• Navigation: When a user clicks a link to another website, the destination receives the full URL of the page they came from.
• Subresource requests: When your page loads images, scripts, stylesheets, or fonts from external domains, each request includes the Referer header.
• Form submissions: When a form submits data to an external URL, the Referer header is included.
• AJAX and Fetch requests: API calls to external services also include the Referer header by default.

Let's say a visitor is on this URL on your WordPress site:

https://yoursite.com/members/dashboard?session=abc123&plan=premium

If that page contains an embedded image from an external analytics provider or advertising network, that provider's server receives the full URL in the Referer header, including the query parameters with the session token and plan information. This is the privacy concern that Referrer-Policy addresses.

All Referrer-Policy Values Explained

The Referrer-Policy header supports eight distinct values. Each one defines a different level of information sharing:

• no-referrer: Never send the Referer header at all. The destination gets no information about where the request came from. This is the most private option, but it can break functionality that depends on referrer data (some CSRF protections, for example).
• no-referrer-when-downgrade: Send the full URL, but strip the Referer when navigating from HTTPS to HTTP (a "downgrade"). This was the browser default for many years. It protects against leaking URLs when leaving a secure context but shares everything in HTTPS-to-HTTPS navigation.
• origin: Only send the origin (scheme, host, and port) but not the path or query string. So https://yoursite.com/members/dashboard?session=abc123 becomes just https://yoursite.com/. The destination knows which site the visitor came from, but not which specific page.
• origin-when-cross-origin: Send the full URL for same-origin requests (links within your own site) but only the origin for cross-origin requests. This gives your own analytics and internal tools full referrer data while limiting what external sites see.
• same-origin: Send the full URL only for same-origin requests. For cross-origin requests, send no Referer at all. This is very private for external navigation but means external services get zero referrer data.
• strict-origin: Send only the origin (like the origin value), but strip the Referer entirely on HTTPS-to-HTTP downgrades. Combines the privacy of origin with the downgrade protection of no-referrer-when-downgrade.
• strict-origin-when-cross-origin: The most commonly recommended value. It sends the full URL for same-origin requests, only the origin for cross-origin HTTPS-to-HTTPS requests, and nothing for HTTPS-to-HTTP downgrades. This is the best balance between privacy, security, and functionality. Modern browsers (Chrome 85+, Firefox 87+) have adopted this as their default even when no Referrer-Policy header is present.
• unsafe-url: Always send the full URL, regardless of the destination or security context. This is called "unsafe" for a reason. It sends query parameters, paths, and everything else even to HTTP destinations. Never use this unless you have a very specific need and understand the risks.

Privacy Implications of the Referer Header

The Referer header is a significant privacy concern that many site owners overlook. Consider what information your URLs might contain:

• Search queries: If your site has a search function, the URL might be /search?q=sensitive+health+topic. Any external resource loaded on the search results page receives that query.
• User identifiers: URLs like /user/john-doe/profile or /order/12345 leak user and order information to external parties.
• Tokens and session data: Some applications put tokens in URLs for password resets, email confirmations, or share links. These could be leaked via the Referer header.
• Internal URL structure: Even just the path structure (/wp-admin/, /members-only/, /internal-dashboard/) reveals information about your site's architecture.

Every third-party resource on your page is a potential recipient of this information: Google Fonts, analytics scripts, social media buttons, embedded videos, advertising networks, CDN-hosted libraries, and external images. Each one receives the Referer header with their requests.

GDPR and Data Protection Relevance

Under the GDPR and similar privacy regulations, URLs that contain personal identifiers or sensitive information can constitute personal data. If your URLs contain usernames, email addresses, or other identifying information, sharing those URLs via the Referer header with third parties could be a data protection issue.

Setting a Referrer-Policy is a straightforward technical measure that reduces unnecessary data sharing with third parties. While it is not explicitly required by the GDPR, it aligns with the principles of data minimization (Article 5(1)(c)) and privacy by design (Article 25). If your data protection officer or privacy audit asks what technical measures you have in place to limit data leakage, a proper Referrer-Policy is a concrete item you can point to.

WordPress Default Behavior and Common Plugins

WordPress core does not set a Referrer-Policy header by default. This means your site relies on whatever the browser's built-in default is. For modern browsers, that default is strict-origin-when-cross-origin, which is actually a reasonable policy. However, there are a few things to note:

• Older browsers may still default to no-referrer-when-downgrade, which sends the full URL on all HTTPS-to-HTTPS requests.
• Explicitly setting the header is better than relying on browser defaults, because it communicates your intent clearly and covers all browser versions.
• Some WordPress security plugins (like Sucuri or iThemes Security) include a Referrer-Policy option in their hardening settings.
• WordPress 4.7.4 introduced the wp_get_referer() function improvements, but this is a server-side function that reads the Referer header for CSRF protection. It is not related to the Referrer-Policy response header.

Impact on Website Analytics

Your Referrer-Policy choice directly affects what referrer data your analytics tools receive, and what data other sites receive about traffic from your site:

• Your own analytics: If you use Google Analytics, Matomo, or a similar tool with a tracking script on your site, same-origin requests will always include the full referrer regardless of policy (most policies only restrict cross-origin referrers). So your on-site analytics data is unaffected by most policy values.
• Inbound traffic tracking: The Referrer-Policy you set affects what other sites see when your visitors come from your site. It does not affect what you see about traffic coming to your site (that depends on the referring site's policy).
• Affiliate and partner tracking: If you run an affiliate program or need to track outbound clicks, a very restrictive policy like no-referrer will break referrer-based tracking. The recommended strict-origin-when-cross-origin sends the origin (domain) to partners, which is usually sufficient for attribution.

Setting Referrer-Policy for WordPress

The recommended value for most WordPress sites is strict-origin-when-cross-origin:

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

To set it in Apache:

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

In Nginx:

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

Via PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

If your site handles particularly sensitive data (medical information, financial records, legal documents), you might consider a stricter policy like same-origin or no-referrer. Just be aware that this will remove referrer information for all cross-origin requests, which may affect external services that depend on it.

What InspectWP Checks

InspectWP checks whether your WordPress site sends a Referrer-Policy header and reports the configured value. If the header is absent, your site depends on each visitor's browser default, which varies across browser versions. Explicitly setting a Referrer-Policy ensures consistent behavior and demonstrates that you have made a deliberate decision about how much URL information your site shares with third parties. For the vast majority of WordPress sites, strict-origin-when-cross-origin is the recommended value.