referrer policy 实测：27 个首页 15 个声明了，3 个还在交出完整 URL

实测 · 2026-08-30 · 27 个首页 · 各请求一次 · Referrer-Policy 响应头与 meta 元素

样本 / 口径：2026-08-15 起沿用的同一批 30 个站，2026-08-30 各请求一次，桌面浏览器 UA，跟随跳转，保留全部响应头。三个站掉出去了 —— stackoverflow.com 与 medium.com 返回 403，reddit.com 只有 8,393 字节，没过这批面板从第一天起就写死的 10,000 字节下限。剩 27 个。

27 个首页里有 15 个用响应头声明了 referrer policy，另外 12 个交给浏览器默认值处理，那个默认值从 2020 年起是 strict-origin-when-cross-origin。三个站至今仍把完整 URL 交给它链出去的那一方，两个站什么都不给。还有两个站自己跟自己打架：响应头写一个值，同一份 HTML 里的 <meta name="referrer"> 写另一个。

怎么测的

2026-08-30 对每个首页发一次请求，跟随跳转，每个站只记两个值：Referrer-Policy 响应头，以及交付的 HTML 里出现的每一个 <meta name="referrer">。两个值来自同一次响应，不依赖第二次访问。

一条限制放在这里说，不放文末。这次读的是每个站声明了什么，不是观察到的请求。我们没有打开浏览器点一条外链、再去对面看 Referer 到底送到了什么。下面每一个数字都是声明，不是实况。

referrer policy 决定的是别人能看见你多少

有人从你的页面点走一条外链时，浏览器可能带上一个 Referer 头，写着他从哪儿来。referrer policy 决定这个地址有多少能活着到对面：整条 URL、只给域名，还是什么都不给。

W3C 的规范列了九个合法值，并写明当多处同时设定策略时「the value of the latest one will be used」。MDN 记着浏览器现在的默认值是 strict-origin-when-cross-origin，而在此之前的默认值是 no-referrer-when-downgrade。

也就是说，27 个里有 22 个只给对面一个域名，不给页面。你的独立站如果被这 22 个中的某一个链到，你在自家统计后台里只能知道是哪个站送来的，永远不知道是哪篇文章送来的。

referrer policy 管的不是你自己的数据，是别人后台里你长什么样。

15 个头，7 种取值

这 15 个头不是一套写法抄了十五遍，而是七个不同的值，其中三个比另外 12 个站白拿的浏览器默认值还要松。

写 no-referrer-when-downgrade 的那三个 —— stripe.com、techcrunch.com、www.bbc.com —— 就是在 HTTPS 到 HTTPS 的链接上仍然交出完整 URL 的那三个。那本来就是几年前的浏览器默认值，所以这一行更像是当年把已有行为抄下来之后再没人回头看过。

github.com 是面板上唯一一个在一个头里写两个值的：origin-when-cross-origin, strict-origin-when-cross-origin。MDN 把这种写法记作回退清单，想要的策略写在最后，认得新值的浏览器用新的，老浏览器退回前一个。整批 27 个站没有一个发 unsafe-url。

两个站的头和 meta 不一致

27 个里有 4 个同时还发了 <meta name="referrer">。这 4 个里有 2 个，元素和响应头说的不是一回事。

slack.com 这条最有意思。它的响应头是整批面板上最严的一个值，meta 元素却是个中间档，而按规范「最后出现的那个生效」，解析文档时读到的 meta 排在响应头后面。所以这批里最严的那个头，很可能在两百字节之后被自家标记覆盖掉了。

notion.com 那一对是同一件事的小号版本：strict-origin 和 strict-origin-when-cross-origin 只在同源链接上有区别，冲突本身看不出代价。但它仍然是同一个开关被两拨人在两个地方各设了一遍。

独立站要做的两件事

两步，第一步只要一次请求。

1. 先读自己的头，再决定别的。curl -sI https://你的域名/ | grep -i referrer-policy 打出来的就是声明值；什么都没打出来说明你跑在浏览器默认上，而这批里有六个站花人力手写的正是同一个值。
2. 再在自己的 HTML 里搜一遍 name="referrer"。两处都有且不一致时，标记那一边生效，响应头就成了摆设 —— 而下一轮排查的人会把它当事实读。

这件事之所以归到效果衡量而不是安全，是因为它最后落在报表上。别人链到你时不带路径，你的统计后台就只能给出域名；一点都不带，这次访问就掉进「无法归因」那个桶里。这和 直接流量里的 AI 来源 是同一种失效，只是从另一个方向来的。同一批面板上的响应头家族还测过 27 个首页的 http 缓存头。页面到底能不能被答案引擎读懂并引用，那是 QueryWin 怎么运转 在管的事。

这次没测出来的几件事

这些声明经不经得起一次真实点击，不知道。我们读的是响应头和标记，没有驱动浏览器点外链、再去对面看 Referer 实际长什么样，所以 slack.com 和 www.notion.com 那两组冲突里今天的 Chrome 到底认哪一个，这次没测。单条链接自己还可以带 referrerpolicy 属性，这一项完全没采集 —— 站级的头只给出下限，给不出每个 a 标签的实际行为。另外这只是一个时刻、一个出口、每个站一次请求；一个会按地域切换这个头的服务器，在这里只会呈现为一个固定值。

常见问题

你们是怎么测的？

2026-08-30 用桌面浏览器 UA 对每个首页发一次请求，从同一份响应里读 Referrer-Policy 响应头和全部 <meta name="referrer"> 元素。

referrer policy 的默认值是什么？

MDN 写的是：没设或者值非法时，默认是 strict-origin-when-cross-origin，此前的默认值是 no-referrer-when-downgrade。这批面板里 27 个有 12 个跑在这个默认值上。

这个头影响 SEO 吗？

这次测的东西证明不了。它改变的是别人的统计后台能把多少流量算到你头上，以及你能把多少流量算到别人头上。抓取和收录都不依赖 Referer。

那我该设哪个值？

没有特别理由就用浏览器给你的那个。这批里 12 个站一个头都不发，落在 strict-origin-when-cross-origin 上；另有 6 个把这个值手写了一遍。整批里只有 no-referrer 会把你自己的站从别人的来源报表里彻底抹掉。

meta 元素会盖掉响应头吗？

规范说最后读到的那个策略生效，而元素是在响应头之后被解析的。这批里有两个站两处都发了，值还不一样。