Referrer Policy: We Measured 466 Public Sector Websites, and 81% Do Not Set One (2026)

Every page you open loads things from elsewhere. A font, an analytics script, a map, a captcha. Each one of those requests carries two facts to a server you never chose: your IP address, and the address of the page you were reading. The second fact is called the referrer, and a site can restrict it with a single header. Most do not.

We wanted a number rather than an impression, so we measured it. On 1 September 2026 we sent one request to each of 600 French public sector domains, and 466 answered. Of those, 88 declare a Referrer-Policy header. That is 19%.

The full dataset, the method and the code are published openly, and the reserves below are part of the dataset rather than a caveat added afterwards.

What we measured, precisely

One GET request per domain, to the homepage only, from a user agent that names itself. For each one we recorded four things:

• whether the site answered over HTTPS at all,
• the value of its Referrer-Policy response header, if any,
• how many distinct third party domains the homepage asks the browser to load,
• whether the site sets a cookie on that first visit, before any interaction.

The results, on the 466 that answered

The most frequent third parties are unsurprising once you see them: googleapis.com on 196 of the 466 sites, gstatic.com on 100, googletagmanager.com on 72, cloudflare.com on 67, hcaptcha.com on 34.

The dashboards above are stock imagery, not our data. Our measurement produced a CSV of 600 rows, one per domain, which is linked at the end of this page.

Four things this measurement does not say

This is the part most write-ups leave out, so it goes before the interpretation rather than after it.

1. It covers the homepage, not the site. A search page, a form or a document viewer may load entirely different third parties. One request per domain buys breadth, not depth.

2. A third party is not a tracker. A font, a map, a captcha and a video player are all third parties, and all can be there for good reasons. The count measures exposure, meaning how many separate operators receive a request. It measures neither intent nor wrongdoing.

3. The third party count is a floor, never a total. We read only the HTML the server sends. Whatever a script injects afterwards, inside the browser, is invisible to this method. Real figures are equal or higher.

4. A domain that did not answer is not a domain at fault. The 134 non-responders are excluded from every rate above and counted separately. They may have blocked our user agent, redirected oddly, or simply been down that morning.

And no conclusion about legal compliance can be drawn from any of this. The file records what a page asks a browser to do. It says nothing about what a data controller declared, consented to, or documented. Anyone using this dataset to claim a breach would be misusing it.

So what does the 19% actually mean?

Less than it looks, and more than nothing.

It means less than it looks because browsers have not been naive since 2021. Chrome, Firefox and Safari now default to strict-origin-when-cross-origin, which already strips the path when the request leaves the site. An absent header is a default accepted, not a door left open. Anyone reading our number as "81% of public sites leak your browsing" would be wrong, and we are not going to write that sentence.

It means more than nothing because a default is a decision made by someone else, and it can change. The 88 sites that set the header have chosen their exposure; the other 378 have inherited it. On a public service, where the visitor has no alternative provider to switch to, that difference is worth naming.

The more telling figure, to us, is the other one: 23% of these sites load no third party at all. It is entirely possible to run a public sector homepage that asks nothing of anyone else. Nearly a quarter already do.

Checking any site yourself, in one command

curl -sI https://example.org/ | grep -i referrer-policy

Nothing returned means no policy is set. To see the third parties, look at the page source for src and href attributes pointing at a domain that is not the site's own:

curl -s https://example.org/ | grep -oE '(src|href)="https?://[^"]+"' | sort -u

That second command is the whole of our method, minus the bookkeeping.

What a VPN changes here, and what it does not

Worth being exact, because these two layers get merged constantly.

A referrer policy controls the page address that travels to third parties. It is set by the site. You cannot change it as a visitor, and no VPN affects it.

A VPN controls the IP address that arrives with those same requests. It is set by you. It does not stop the third party from being contacted, and it does not remove the referrer.

So on a site with no policy and five third parties, a VPN means five operators learn a page address alongside an IP that is not yours. That is a real reduction, and it is not the same as not being seen. If you want the requests themselves to stop, that is a content blocker's job, not a tunnel's.

The data

Three files are served from this site, with nothing held back: the 600 row dataset (one row per domain), the summary, and the Python script that collected it.

Licence. The dataset is published under Creative Commons Attribution 4.0, the script under the MIT licence. Reuse the figures anywhere, including to contradict us. Attribution is the only condition.

Cite this dataset:

Anonymflow, Third-party calls and referrer policy on 600 French public sector homepages, dataset, collected 1 September 2026. https://www.anonymflow.com/en/blog/referrer-policy-public-sites

If you re-run the collection on a later date, the comparison is more interesting than either snapshot alone.

Method note: one GET per domain, 12 second timeout, eight in parallel, a self-identifying user agent, collected 1 September 2026. Rates are computed on responding domains only. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.