Permissions-Policy on 27 homepages: five send it, and three of those set one line

FIELD TEST · 2026-09-03 · 27 homepages · one request each · Permissions-Policy and Feature-Policy headers

Sample and method: 30 homepages fetched once each on 2026-09-03 with a desktop Chrome user agent, redirects followed, no JavaScript executed, exit node in Osaka, Japan. Three dropped out — stackoverflow.com, medium.com and www.reddit.com each returned 403 — leaving 27.

Five of the 27 homepages send a Permissions-Policy header. Two others send the older Feature-Policy name instead, and nothing else. The five live headers carry twelve directives between them, and three of the five spend their whole policy on a single line — two of those on browsing-topics=(), which turns off one advertising interface and touches nothing else.

How we measured it

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, every response header recorded with its original casing folded to lowercase. We then read four header names off each response: Permissions-Policy, Permissions-Policy-Report-Only, the deprecated Feature-Policy, and — for the delegation half of the story — every <iframe> opening tag in the delivered HTML.

# The same reading on one of your own pages
curl -sI -A 'Mozilla/5.0' https://example.com/ \
  | grep -iE '^(permissions-policy|feature-policy)'

Three limits. We recorded what the header says, not whether the browser enforced it — nobody here called a camera. Anything a script adds after load is invisible to this pass. And this is one page per site: a CDN can attach the header on some routes and not others, so a homepage that sends nothing is not a site that sends nothing.

Who sends a Permissions-Policy header

Five sites, twelve directives, eight distinct feature names. Only one site treats the header as a policy rather than as a single switch.

Eight feature names appear in total: browsing-topics, camera, geolocation and microphone twice each, then autoplay, fullscreen, display-capture and local-network-access once each. Ten of the twelve directives use the empty allowlist (), which denies the feature everywhere including the page's own origin. TechCrunch is the only site that opens anything up, with fullscreen=* and geolocation=*.

Two of the five use the header for exactly one purpose. browsing-topics=() is the opt-out for the Topics API; MDN states the default allowlist for that directive is * (Permissions-Policy: browsing-topics, read 2026-09-03), so sending () is a deliberate reversal of a default. Netlify and the New York Times both wrote one line, and it is that line.

Nobody on this panel sends interest-cohort=(), the directive that circulated during the FLoC period. Nobody sends Permissions-Policy-Report-Only either. Zero out of 27, on both.

Two sites still send Feature-Policy, and they are the same company

nextjs.org and vercel.com both send Feature-Policy: fullscreen 'self'; camera 'none' — the same two features, the same order, the same quoting, byte for byte. Neither sends the modern header alongside it. Chrome's documentation is direct about the rename: "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, read 2026-09-03).

Two sites, one owner, one config file. That is what a shared platform default looks like from the outside, and it is a useful reminder that header surveys count deployments, not decisions.

A response header tells you what a config file says. It does not tell you that anyone chose it.

The delegation half is almost unused

The header's other job is to hand features down to embedded frames. MDN describes the intended shape: "it is a good idea to specify the widest acceptable support for a feature in the HTTP header, and then specify the subset of support you need in each <iframe>" (Permissions-Policy, read 2026-09-03).

On this panel that pattern does not exist. There are 8 <iframe> tags across 5 sites, and only 2 of them carry an allow attribute — both on webflow.com, both listing the same four features a video embed asks for: autoplay, fullscreen, encrypted-media, picture-in-picture. None of the five sites sending a Permissions-Policy header has an iframe on its homepage at all.

What this means for your site

This header has nothing to do with being crawled, indexed or cited. Neither Chrome's documentation nor MDN's connects it to search, and this data set contains no ranking information at all. If you came here from a checklist that scored your site down for missing it, the checklist was scoring hygiene, not visibility.

1. Decide whether you have a feature to switch off. Two of the five sites here did have one, and their whole policy is that one line.
2. If you already send Feature-Policy, you are sending a name the platform has moved on from. Send the current header too before you remove the old one.
3. Skip it if the answer to the first item is no. An empty policy protects nothing, and a copied six-directive string protects nothing you understand.

The related header that does show up in more toolchains is the framing control, measured in X-Frame-Options across 27 homepages, and the one that genuinely changes what your own page can load is covered in content security policy and SEO. To see the full header set your own pages return on a plain fetch, see how QueryWin reads a page.

Common questions

How did you measure this?

One GET per homepage on 2026-09-03, desktop Chrome user agent, redirects followed, all response headers recorded. Header names were lowercased and read directly; iframe tags were pulled from the delivered HTML with a regular expression. No JavaScript ran. Exit node in Osaka, Japan.

Does Permissions-Policy affect SEO?

No evidence here says it does, and we measured nothing that could show it either way. It governs browser feature access on a page. It is not a crawl directive and it does not appear in Google's crawling documentation.

Should I still send Feature-Policy?

Only alongside the current header, and only while you still care about clients that predate the rename. Two sites in this sample send the old name by itself, which means the modern header is absent for every browser that expects it.

Why do two sites only set browsing-topics?

We do not know their reasoning. What the markup shows is that both chose to reverse a default that would otherwise allow the Topics API, and neither added a second directive while they were in the file.

Is 5 out of 27 low?

Compared with what, is the honest answer. This panel is 27 large, well-staffed sites, so it is a ceiling rather than an average. We have no cross-web baseline to compare it against and did not try to build one.