Technical
Referrer-Policy
Referrer-Policy is an HTTP header, or meta tag, that controls how much of the previous page's URL the browser sends in the `Referer` header on the next request.
How it is measured
`curl -I` shows the header. Common values are `no-referrer`, `same-origin`, `origin`, and `strict-origin-when-cross-origin`, which is the modern browser default. Test by clicking a link from your page to a server you control and reading the Referer it receives: full URL, origin only, or nothing.
Check same-origin and cross-origin links separately. A downgrade from HTTPS to HTTP drops the header under most policies.
Worked example
An account page at `https://app.example/reset?token=9f3a` links to a help site. A plugin set `unsafe-url`, so the help site's log shows the full address, token included. After the site sends `Referrer-Policy: strict-origin-when-cross-origin`, that log shows only `https://app.example/`.
Now the partner portal, which credited signups to article paths, sees just `https://partner.example/`, and its per-article report collapses to one row per partner.
How it differs
Referrer-Policy governs what the browser sends. The referrer is the value that arrives. The linking site sets the policy and the destination reads the result, so a strict policy leaves the destination with less or nothing.
Common errors
Using `no-referrer` and losing partner attribution. Using `unsafe-url` and leaking paths and tokens. Spelling the header `Referer`, when the request header has the typo and the policy header does not. Expecting it to affect server-to-server calls. Setting a meta tag that conflicts with the header. Forgetting per-link `rel=noreferrer`.
In practice
Set `strict-origin-when-cross-origin` site-wide, keep secrets out of URLs, and check what your partners and your own analytics see after the change.