How to Fix: Referrer-Policy configured

Referrer-Policy configured is an important SEO check in the Security & Trust category. This is a lower-priority optimization. Address it after handling more critical issues.

This is a five-minute hardening task that signals you run a tidy, security-conscious site. The Referrer-Policy header controls how much of your URL gets passed along when a visitor clicks a link to another site. Set it well and you protect your users’ privacy and stop leaking internal paths; leave it unset and the browser falls back to a default that may be more generous than you want. Here is the sensible setting and how to apply it in WordPress.

What this check is actually about

When a browser follows a link from your site to another, it normally sends a Referer header telling the destination which page the click came from. The Referrer-Policy response header lets you decide how much of that information leaves your site. The check fails when no explicit policy is set, which means you are relying on browser defaults instead of a deliberate choice. It is filed under Security & Trust because it is part of the same family of response headers that harden a site.

Why it matters

• Privacy. Without a policy, full URLs — including query strings that may carry tokens, IDs, or search terms — can be handed to any external site your users click through to.
• Information leakage. Internal admin, staging, or parameterised URLs can end up in a third party’s analytics logs. A sane policy stops that.
• Trust signals and audits. Security scanners and Mozilla Observatory-style graders check for this header. A clean security header profile is part of looking professional to anyone who inspects your site.

Which policy I would set

For the vast majority of WordPress sites, strict-origin-when-cross-origin is the right default — and it is what modern browsers already lean toward. It sends the full referrer to your own pages, sends only the origin (not the full path) to other sites over HTTPS, and sends nothing when downgrading to HTTP. You keep useful same-site referrer data, and external sites learn only your domain, not your paths. If you want to be stricter, strict-origin or no-referrer are options, but they can blind your own analytics to internal navigation, so I would not reach for them without a reason.

How to Fix This in WordPress

Difficulty Level: EASY – This fix is straightforward and can typically be completed by anyone with basic WordPress knowledge.

Estimated Time: 5 min

The header can be set at the server level, by a security plugin, or in WordPress via a filter. Pick the one you can maintain.

Option A: A security plugin (easiest)

Plugins that manage HTTP security headers — many all-in-one security suites include this — let you set Referrer-Policy from a settings screen with no code. If you already run one, add the header there and you are done.

Option B: Server config

On Apache, add to your .htaccess or vhost:

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

On Nginx, in the server block:

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

Option C: A WordPress filter

If you cannot touch the server, send the header from WordPress with a small snippet on the send_headers hook. It is the least robust of the three — it only covers requests that boot WordPress — but it works when server access is off the table.

Then verify

1. Load the site and check the response headers in browser dev tools (F12, Network tab) for Referrer-Policy.
2. Or run the domain through a free security-header scanner to see it graded.
3. Re-run the SEO Roadmap audit to confirm the check clears.

Recommended Tools & Plugins

These tools can help you fix and prevent this issue:

• Yoast SEO – Comprehensive SEO plugin with built-in checks
• Rank Math – Feature-rich SEO plugin with detailed analysis
• Google Search Console – Free tool to monitor your site’s search presence
• SEO Roadmap – Complete SEO audit and action plan tool

Mistakes I would avoid

• Setting no-referrer globally and then wondering why your analytics can no longer see internal navigation paths.
• Adding the header in two places — plugin and server — so they conflict or duplicate. Pick one source.
• Forgetting the always flag on Nginx, so the header is missing on error responses.
• Treating this as a ranking lever. It is a trust-and-privacy hardening step, not a traffic driver.

Need More Help?

If you are still stuck, consider:

• Consulting with a WordPress developer or your host’s support for server-level headers
• Reviewing the MDN documentation on Referrer-Policy values before choosing a stricter one
• Setting the other common security headers at the same time while you are in there
• Running a complete site audit with SEO Roadmap for a prioritized action plan

This guide is part of the SEO Roadmap knowledge base – your complete resource for WordPress SEO optimization.