What actually gets leaked
When a visitor clicks a link from your site to somewhere else, the browser tells the destination where the click came from. It does the same when your page loads an image, a font or a script from another domain.
By default that message can include the whole URL. Not just yourshop.com, but the full path and anything hanging off it. That is fine for a homepage. It is less fine for an order confirmation page, a password reset link, an internal search result, or any address with a token or an email in it.
Referrer-Policy is how you decide how much of that gets sent.
The values worth knowing
There are several settings. In practice three matter.
- →strict-origin-when-cross-origin sends the full URL within your own site, only your domain to other sites, and nothing at all when going from HTTPS to HTTP. This is the sensible one.
- →unsafe-url sends the full URL to everyone, always. The name is a warning. It leaks potentially private information out of your HTTPS pages to insecure origins, which is exactly what you do not want.
- →no-referrer sends nothing, ever. It sounds like the safest choice, and it can quietly break things. Some analytics stop attributing traffic, and some payment and fraud flows expect a referrer to be there.
The honest bit: this is low risk and low drama
Browsers made strict-origin-when-cross-origin the default back around November 2020. So if you send no Referrer-Policy at all, modern browsers already behave sensibly.
That means setting it explicitly is not an emergency. It is worth doing for two reasons. It covers older browsers that predate the default, and it satisfies scanners that check for the header rather than guessing at browser behaviour. It is one of the safest headers you can add, because you are mostly writing down what is already happening.
What you should actually avoid is going the other way and setting unsafe-url because a tracking guide told you to.
How to set it
The proper way is a response header. But here is the useful part, and it is genuinely unusual.
Referrer-Policy is the one security header that really works as a meta tag. Not through http-equiv, which is how people usually try it and how it usually fails, but through name="referrer".
Header (the proper way):
Referrer-Policy: strict-origin-when-cross-origin
Meta tag (works, and is the only option on some platforms):
<meta name="referrer" content="strict-origin-when-cross-origin">Note the meta tag uses name=, not http-equiv=. This does not work for other headers. X-Frame-Options as a meta tag has no effect at all, HSTS is header-only, and a meta CSP ignores several of its most important directives.
Why the meta tag matters
Locked-down hosted platforms will not let you set response headers. Shopify and Squarespace are the obvious examples, and at the time of writing neither ships a Referrer-Policy by default.
Because the meta tag really works, this is one of the very few header-level improvements you can actually make on those platforms. You add one line of markup in the head and you are done. That is rare, and it is worth taking.
Not sure whether your site sends one today? Run a free check and see what your pages are sending.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to set Referrer-Policy on your platform