Referrer Policy in WordPress: What It Is and How to Configure It

If a security scan has flagged your site for a missing referrer policy WordPress setting, you probably want a safe fix—not another header to configure blindly. Start with strict-origin-when-cross-origin, check what your site already sends, and then test the workflows that depend on referral information.

The best policy is the strictest one your real site can tolerate. A more restrictive value can protect private URL details, but it can also remove context that login flows, analytics, forms, embeds, or payment redirects expect.

TL;DR

Start with strict-origin-when-cross-origin: it keeps full detail for same-origin requests, sends only your site origin to secure external sites, and sends nothing when a visitor moves from HTTPS to HTTP.
Check the live response, set the header in one place, and test login, protected content, analytics, embeds, forms, and redirects before choosing a stricter policy.

What Referrer-Policy controls

Referrer-Policy is an HTTP response header. It tells the browser how much information to share about the page a visitor came from when the browser makes another request.

When a visitor follows a link, the browser can send the previous page in a request field called Referer. Depending on the policy, that value may include the full URL, including its path and query string. A path such as /customers/acme or a query string containing ?token=... can reveal more than the destination needs to know.

The spelling is intentional: the request field is Referer with one r, while the response header is Referrer-Policy with two.

Referrer-Policy limits this particular disclosure. It does not remove information already included in a URL, erase data your own site has collected, block malware or cross-site scripting, or improve search rankings. Those are separate security concerns, privacy, and analytics concerns.

🔐 Note: A missing header is not automatically evidence that your WordPress site is compromised. It means the browser has not received this specific instruction. Treat it as a hardening decision, then address the wider WordPress security controls your site needs.

Choose the right policy value

For most WordPress sites, start with:

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

That policy behaves in three useful ways:

• A same-origin request can include the full source address, including its path and query string.
• A secure request to another origin receives only your origin, such as https://example.com.
• A request that moves from HTTPS to HTTP receives no referrer.

Current browsers use this as the default when no valid policy is supplied. Older tutorials may recommend no-referrer-when-downgrade, which was the previous default. That older value can send the full URL to another HTTPS site, so do not copy it into a new configuration without considering what your URLs reveal.

The policy choice is a tradeoff, not a security-score contest:

⚖️ Note: Do not choose no-referrer only because it sounds safest. It removes all referral context and may interfere with password-protected content, login redirects, analytics attribution, forms, embeds, or payment services. Use it when your privacy requirements justify the loss and your site has passed its workflow checks.

Check the effective header first

Before installing a plugin or editing a server file, find the header visitors actually receive. WordPress core, a plugin, theme or application code, the web server, a CDN, or the host may already set it.

• Inspect a normal public response with curl or DevTools: run curl -I https://example.com/, or open browser developer tools, select Network, reload the page, open the document request, and read Response Headers. Check a normal content page, not only the home page.
• Compare the login and admin responses separately: WordPress core sends a referrer policy for administration screens through wp_admin_headers(), and that value can differ from the public response. Developers can adjust the admin behavior through the admin_referrer_policy filter.
• Use an online header scanner as a quick external check: remember that it reports only the response it can reach. It cannot prove what happens on cached pages, protected content, checkout pages, or privileged screens.

Look for a line such as:

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

🔎 Note: The response is the source of truth. A green setting inside WordPress or a passing scan does not prove that a CDN, cache, or later server rule has not replaced the value.

Configure it with a WordPress plugin

A header plugin is usually the practical route when you do not control Apache or Nginx. The current WordPress.org listing for HTTP Headers advertises Referrer-Policy support, but plugin screens and behavior can change between releases. Use WordPress staging when you have it, and confirm the response after saving.

• Create a recovery point before changing a live site: make a backup or confirm that you can restore the current site if another header setting causes a problem.
• Open the plugin installer and check the current listing: go to Plugins > Add New Plugin, search for HTTP Headers, and review its current maintenance and WordPress compatibility details before installing it.
• Find the header controls after activation: open the plugin’s HTTP header or security settings and look for Referrer-Policy. Screen names may differ from older guides and screenshots.
• Enable the setting and choose a tested value: use strict-origin-when-cross-origin as the starting point unless your site’s privacy or compatibility requirements point to another value.
• Save the change and inspect a fresh response: use DevTools or curl, clear relevant caches if necessary, and test the pages and integrations that matter to your site.

Keep one deliberate owner for this header. If a plugin, server, CDN, and theme all set it, the final response may contain a duplicate, blank, or unexpected value. A dashboard setting is not proof that the header reached visitors.

Configure it on Apache or Nginx

Server configuration is a good fit when you manage the web server and want the policy applied before WordPress handles the request. The correct file and section depend on your host.

Apache and .htaccess

Apache can set the header through its mod_headers module. If your host allows that module in .htaccess, use a rule like this:

<IfModule mod_headers.c>
    Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

The same module can also set an X-Frame-Options security header.

• Back up the active .htaccess file before editing: it contains live server settings, and a syntax error can make the site unavailable.
• Add the rule to the existing header section when possible: avoid creating a second competing directive, then save the file and clear relevant hosting or CDN caches.
• Inspect the fresh response after the edit: if the header is still missing, confirm that mod_headers is enabled and that your host permits custom headers in .htaccess.

Nginx

Nginx can set the header in the correct server or request-routing block:

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

• Locate the active Nginx configuration block first: do not paste this directive into .htaccess or a WordPress setting.
• Validate the configuration before reloading the server: on a server you control, run nginx -t, fix any reported error, and reload only after the check passes.
• Ask the host to apply the change when you lack server access: a maintained header plugin may be simpler, but a CDN can still add, replace, or cache the value afterward.

⚠️ Note: Keep a copy of the last working server configuration. If the site returns a 500 error after an Apache edit, restore that file before investigating the syntax. Recovery comes before fine-tuning the policy.

Verify the change with real workflows

A passing header scan proves only that a reachable response contains a policy. It does not prove that the site still works or that every response uses the same value.

• Start with a fresh public-page response: confirm the exact header value and check more than one page type if your cache or CDN treats them differently.
• Compare login and admin behavior before calling the change complete: check the login page and an admin response separately, because WordPress core may manage those screens independently.
• Walk through protected content and redirects as a visitor would: open password-protected pages, log in, follow redirects, and confirm that the intended flow still completes.
• Exercise the external services your site depends on: test analytics attribution, chat widgets, forms, embeds, payment services, checkout, redirect handlers, and custom scripts where they are relevant.
• Compare representative request contexts when it is safe: check a same-origin request, a secure request to another site, and an HTTPS-to-HTTP request against the behavior promised by your chosen policy.
• Clear caches only after checking the configuration layer: page, CDN, hosting, and browser caches can make an old value appear to be the current one.

Troubleshoot common failures

The header is missing

Trace every possible header owner in the request path: check the CDN, cache, host, server, plugin, theme, and application code. A setting may be enabled in WordPress but removed or replaced later.

The response has duplicate, blank, or invalid values

Find and remove competing rules before trying another value: a blank or invalid policy can produce a browser warning such as “Failed to set referrer policy.” Inspect the final response after correcting the source instead of trusting one settings screen.

A page or integration stops working

Compare the failing workflow with the previous response and review the request that changed: pay special attention to password-protected pages, login redirects, traffic reports, embeds, forms, payment redirects, and custom scripts.

If no-referrer removes context that a workflow needs, consider same-origin or strict-origin-when-cross-origin if they meet the site’s privacy requirements. A compatibility report is a reason to test that workflow, not proof that every WordPress site will fail.

The site returns a 500 error after an .htaccess edit

Restore the last working file before making another change: then confirm that Apache supports mod_headers, check the formatting, and change one server rule at a time.

Conclusion

For most WordPress sites, strict-origin-when-cross-origin is the right starting point. Check the header your site already sends, choose one configuration owner, and verify public, login, and admin responses after making the change.

Then test the workflows that use referral information. If a stricter value causes a problem, choose a policy that protects privacy without removing information your site needs. Referrer-Policy is one layer of a wider security plan, and MalCare can help with broader WordPress security work such as malware scanning, firewall protection, monitoring, and cleanup. It does not set this header or replace the WordPress, server, CDN, or hosting setting that controls it.