permissions-policy 实测 27 个首页：只有 5 个在发，其中 3 个只写了一行
permissions-policy 在 2026-09-03 抓取的 27 个首页里只有 5 个发，一共 12 条指令。两个站整份策略只有 browsing-topics=() 一行，另有两个站还在发它的旧名 Feature-Policy，值一个字节都不差。
实测 · 2026-09-03 · 27 个首页 · 每站一次请求 · Permissions-Policy 与 Feature-Policy 响应头
样本 / 口径：2026-09-03 当天对 30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，不执行 JavaScript，出口在日本大阪。stackoverflow.com、medium.com、www.reddit.com 三个站返回 403，剔除后纳入 27 个。
27 个首页里，5 个发了 permissions-policy，一共 12 条指令。另有 2 个站发的是它的旧名 Feature-Policy，并且只发旧名。5 个站里有 3 个整份策略只写了一行，其中两个写的是同一行：browsing-topics=() —— 关掉一个广告接口，别的一概没碰。
怎么测的
每个站一次 GET，用桌面 Chrome UA 而不是 Googlebot，跟随跳转，响应头全部按小写记下。然后从每份响应里读四个名字：Permissions-Policy、Permissions-Policy-Report-Only、已改名的 Feature-Policy，以及投递 HTML 里全部 <iframe> 开标签 —— 委派那半边靠它。
# 在你自己的页面上读同一组头
curl -sI -A 'Mozilla/5.0' https://example.com/ \
| grep -iE '^(permissions-policy|feature-policy)'三条局限。我们只记了头的字面，没有验证浏览器真的执行了策略 —— 这一轮没有人去调摄像头。脚本在页面加载后插进来的东西，这一遍看不见。还有，一个站只测了首页：CDN 完全可以在别的路径上挂这个头，所以首页没发不等于这个站没发。
permissions-policy 在这 27 个站上长什么样
5 个站、12 条指令、8 个不重复的功能名。只有一个站是把它当策略写的，其余都是当开关用。
| 站点 | 指令数 | 值 |
|---|---|---|
| techcrunch.com | 6 | autoplay=(), camera=(), fullscreen=*, geolocation=*, display-capture=(self), microphone=() |
| www.cloudflare.com | 3 | geolocation=(), camera=(), microphone=() |
| www.netlify.com | 1 | browsing-topics=() |
| www.nytimes.com | 1 | browsing-topics=() |
| arstechnica.com | 1 | local-network-access=() |
出现过的功能名一共 8 个：browsing-topics、camera、geolocation、microphone 各两次，autoplay、fullscreen、display-capture、local-network-access 各一次。12 条指令里有 10 条用的是空白名单 ()，含义是这个功能在任何来源上都不许用，本站自己的来源也算在内。只有 TechCrunch 反过来放开了两项：fullscreen=* 和 geolocation=*。
Netlify 和纽约时报只写了一行，而且是同一行。browsing-topics=() 是 Topics 接口的退出开关，MDN 写明这条指令的默认名单是 *（Permissions-Policy: browsing-topics，2026-09-03 访问）—— 也就是说，发 () 是主动把一个默认值反过来，不是顺手抄的模板。
另外两个数是零：没有一个站发 interest-cohort=()，那是 FLoC 那阵子流传的写法；也没有一个站发 Permissions-Policy-Report-Only。两边都是零。
两个还在发 Feature-Policy 的站，是同一家公司
nextjs.org 和 vercel.com 发的都是 Feature-Policy: fullscreen 'self'; camera 'none'：同样两个功能、同样的顺序、同样的引号，一个字节都不差。两个站都没有同时发新名字的那个头。Chrome 文档把改名这件事说得很直白：「Permissions Policy, formerly known as Feature Policy, allows the developer to control the browser features available to a page, its iframes, and subresources」（Permissions Policy，2026-09-03 访问）。
两个站、一个东家、一份配置。这就是平台默认值从外面看过去的样子，也提醒了一件事：头部普查数出来的是部署数，不是决策数。
响应头告诉你配置文件写了什么，不告诉你有没有人真的选过它。
委派那半边，这个面板上几乎没人在用
这个头的另一半职责是把功能权限交给嵌进来的 iframe。MDN 给的写法是：在 HTTP 头里给出你能接受的最宽范围，再在每个 <iframe> 上收窄到实际需要的子集（Permissions-Policy，2026-09-03 访问）。
这个面板上没有这种写法。27 个首页一共只有 8 个 <iframe> 开标签，其中带 allow 属性的只有 2 个，都在 webflow.com 上，列的是视频嵌入常见的那四项：autoplay、fullscreen、encrypted-media、picture-in-picture。而发了 Permissions-Policy 的那 5 个站，首页上一个 iframe 都没有。
| 声明面 | 站数 | 条数 |
|---|---|---|
Permissions-Policy 头 | 5 / 27 | 12 条指令 |
Feature-Policy 头 | 2 / 27 | 4 条指令 |
Permissions-Policy-Report-Only | 0 / 27 | — |
<iframe allow=> | 1 / 27 | 8 个里的 2 个 |
这对你意味着什么
这个头和被抓取、被收录、被引用没有关系。Chrome 文档和 MDN 都没有把它和搜索连起来，这份数据里也没有任何排名信息。如果你是被某份体检清单扣了分才找过来的，那份清单扣的是工程卫生分，不是可见性分。
- 先想清楚你有没有一个真要关掉的功能。这里 5 个站中有 2 个确实有，它们的整份策略就是那一行。
- 如果你现在发的是
Feature-Policy，那你发的是一个已经改过名的头。先把现名那个也发上，再考虑撤掉旧的。 - 第一条的答案是「没有」就别加。空策略保护不了任何东西，抄来的六条指令保护的也不是你理解的东西。
同一批里另一个和它常被放在一起的头，量在 X-Frame-Options 实测 27 个首页；真正会挡住你自己页面加载的那个，写在 内容安全策略怎么写才不挡住自己。想看自己的页面在一次普通请求下到底回了哪些头，可以 看看 QueryWin 是怎么读一个页面的。
常见问题
你们是怎么测的
2026-09-03 当天，30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，全部响应头落盘。头名统一转小写后直接读；iframe 开标签用正则从投递 HTML 里取。全程不执行 JavaScript，出口在日本大阪。
permissions policy header 会影响 SEO 吗
这份数据说明不了它影响，也说明不了它不影响 —— 我们没测任何能回答这个问题的东西。它管的是浏览器功能在页面上的可用性，不是抓取指令，也没有出现在 Google 的抓取文档里。
控制台报 permissions policy violation 是怎么回事
那说明当前文档的策略里没有允许这个功能，调用被挡下了。要定位是谁写的，先看响应头里有没有这条指令，再看这个功能是不是在 iframe 里被调用的 —— 后一种情况下，父页面的 allow 属性才是决定方。
那两个站为什么只设 browsing-topics
它们的理由我们不知道。markup 能说明的只有一件事：两个站都主动把一个原本放开的默认值改成了关，而且写到文件里的时候都没顺手加第二条。
5 / 27 算不算低
和什么比才算低，这是老实的回答。这 27 个是大站、有专门的前端团队，所以它更像一个上限而不是平均值。我们手里没有跨站基线，也没去建一个。
