Referrer policy on 27 homepages: 15 declare one, and 3 still hand over the full URL

FIELD TEST · 2026-08-30 · 27 homepages · one request each · Referrer-Policy headers and meta elements

Sample and method: the same 30-site panel this blog has used since 2026-08-15, each homepage requested once on 2026-08-30 with a desktop browser user agent, redirects followed, all response headers kept. Three sites dropped out — stackoverflow.com and medium.com answered 403, and reddit.com returned 8,393 bytes, under the 10,000-byte floor the panel has used from the start. That leaves 27.

Fifteen of the 27 homepages declare a referrer policy in a response header. The other twelve leave it to the browser, which has defaulted to strict-origin-when-cross-origin since 2020. Three sites still hand the destination the full URL of the page the link was on. Two hand over nothing. And two contradict themselves — their header says one thing and a <meta name="referrer"> in the same document says another.

How we measured it

One request per homepage on 2026-08-30, redirects followed, and two values recorded per site: the Referrer-Policy response header, and every <meta name="referrer"> element found in the delivered HTML. Both come from the same response, so nothing here depends on a second visit.

One caveat belongs here rather than at the end. This reads what each site declares. We did not open a browser, click an outbound link and watch the Referer header arrive on the other side. Every number below is a declaration, not an observed request.

What a referrer policy actually decides

It decides how much of your address the next site gets to see. When someone follows a link off your page, the browser may send a Referer header carrying where they came from. A referrer policy sets how much of that address survives the trip: the whole URL, only the origin, or nothing.

The W3C specification lists nine legal values and states that when more than one source sets a policy, "the value of the latest one will be used". MDN records that browsers now default to strict-origin-when-cross-origin, and that the previous default was no-referrer-when-downgrade.

So 22 of 27 give a site they link to a domain and no page. If you run analytics and someone links to you from one of those 22, you learn which site sent the visit and never which article did.

A referrer policy is not a privacy setting on your own traffic. It is a setting on everyone else's analytics.

Fifteen headers, seven different values

The fifteen declared headers are not fifteen copies of one house style. They are seven distinct values, and three of them are looser than the browser default the other twelve sites get for free.

The three on no-referrer-when-downgrade — stripe.com, techcrunch.com and www.bbc.com — are the ones passing the full URL along on an HTTPS-to-HTTPS link. That was the old browser default, so it is what a site gets by writing down the behaviour it already had years ago and never revisiting the line.

github.com is the only site sending two values in one header: origin-when-cross-origin, strict-origin-when-cross-origin. MDN documents that syntax as a fallback list where the desired policy goes last, so a browser that understands the newer value uses it and an older one falls back. Nobody on the panel sends unsafe-url.

Two sites disagree with themselves

Four of the 27 also ship a <meta name="referrer"> element. In two of those four the element and the header say different things.

slack.com is the interesting one. Its header is the strictest value on the whole panel and its meta element is a middling one, and by the specification's "latest one wins" rule the element parsed during the document wins. So the strictest header we found is probably being overridden two hundred bytes later by the site's own markup.

notion.com's pair is a smaller version of the same thing: strict-origin and strict-origin-when-cross-origin differ only in what a same-origin link carries, so the disagreement costs it nothing visible. It is still two people setting the same knob in two places.

What this means for you

Two things to check, and the first takes one request.

1. Read your own header before you decide anything. curl -sI https://yourdomain/ | grep -i referrer-policy gives you the declared value, and an empty result means you are on the browser default, which is already the value six of these sites paid an engineer to write down.
2. Then search your own HTML for name="referrer". If both exist and disagree, the markup wins, and the header is decoration that somebody will read as fact during the next audit.

The reason this belongs in a measurement blog rather than a security one is the reporting side. When a link to you carries no path, your analytics can only tell you the domain, and when it carries nothing at all the visit lands in whatever bucket your tool uses for unattributed traffic. That is the same failure mode as AI traffic showing as direct in GA4, arriving from a different direction. The response-header family this sits in was measured on the same panel in cache-control headers on 27 homepages. Making a page legible to the engines that quote it is what QueryWin works on.

What this run cannot tell you

Whether any of these declarations survive a real click. We read headers and markup; we did not drive a browser, follow an outbound link and inspect the Referer that showed up on the far side, so for slack.com and notion.com we don't know which of the two conflicting values actually applies in Chrome today. Individual links can also carry their own referrerpolicy attribute, which we did not collect at all — a site-wide header tells you the floor, not what every anchor does. And this is one request, from one exit, at one moment. A server that varies this header by region would look like a single fact here.

Common questions

How did you measure this?

One request per homepage on 2026-08-30 with a desktop browser user agent, reading the Referrer-Policy response header and every <meta name="referrer"> element out of the same response.

What is the default referrer policy?

MDN documents strict-origin-when-cross-origin as the default when no policy is set or the value is invalid, and notes the previous default was no-referrer-when-downgrade. On this panel 12 of 27 sites are on that default.

Does referrer policy affect SEO?

Nothing measured here says it does. It changes what other people's analytics can attribute to you, and it changes what you can attribute to other people. Crawling and indexing do not depend on the Referer header.

Which value should I use?

The one your browser already gives you, unless you have a reason. Twelve sites here ship no header and land on strict-origin-when-cross-origin; six more write that exact value down by hand. Setting no-referrer is the only choice on this panel that removes your own site from someone else's referral report.

Can the meta element override the header?

The specification says the latest policy seen is the one used, and the element is parsed after the header arrives. Two sites here ship both with different values.