X-XSS-Protection on 27 homepages: eight still send it, and five of the eight send it to turn the feature off

FIELD TEST · 2026-09-04 · 27 homepages · one request each · a deprecated security header

Sample and method: 30 homepages fetched once each on 2026-09-04 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.

Eight of 27 homepages still send X-XSS-Protection, a header MDN marks both deprecated and non-standard. Five of the eight send the value 0, which switches the feature off. The other three send 1; mode=block, the value MDN attaches a security warning to — and all three of those also ship a Content-Security-Policy, which is the documented replacement.

How we measured it

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, every response header recorded lowercased. We read the value of x-xss-protection verbatim and cross-tabulated it against content-security-policy on the same response. Counts are sites, not header instances.

# The same reading on one of your own pages
curl -sIL -A 'Mozilla/5.0' https://example.com/ \
  | grep -iE '^(x-xss-protection|content-security-policy):'

# Two lines back means you are shipping both the old one and its replacement

The usual limits apply. Homepage only, one request each, and a header absent here may be present on an application subdomain we never touched. We also did not test any browser behaviour: nothing in this measurement shows what a given browser does with these values today, only what the servers said.

What the eight actually send

Two values, and they point in opposite directions.

MDN gives four possible values and their meanings: 0 "Disables XSS filtering"; 1 enables it and "the browser will sanitize the page"; 1; mode=block means "the browser will prevent rendering of the page if an attack is detected"; and 1; report=<reporting-URI>, marked Chromium only (X-XSS-Protection, MDN, read 2026-09-04). On this panel the middle two values never appear. Nobody sanitizes, and nobody reports.

Five of the eight send X-XSS-Protection in order to turn it off

That is the shape of the result and it is worth stating plainly: on 2026-09-04, across 27 homepages, the most common thing anyone does with X-XSS-Protection is send 0. Five sites spend a header on switching a feature off; three spend one switching it on; nineteen spend nothing at all and get whatever the browser does by default.

MDN's warning explains why sending 0 is a position rather than a mistake: "Even though this feature can protect users of older web browsers that don't support CSP, in some cases, X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites." The same page ends with a recommendation: "It is recommended that you use Content-Security-Policy instead of XSS filtering."

A header sent as 0 is not configuration. It is someone answering a scanner.

We cannot tell from a response why any of these five chose the explicit off switch rather than removing the header. Answering an automated security report is one plausible reason, and so is overriding a default set by a platform or a proxy. We did not ask anyone, and we are not going to guess which.

The three that keep it on already have its replacement

Crossing the two headers on the same 27 responses gives the sharpest reading in this measurement.

All three sites keeping the legacy filter switched on are already sending the header MDN says to use instead. That is not a contradiction — an old header can sit under a new one for years without anyone noticing — but it does mean the case for keeping it is thinner than it looks. Its documented benefit is for browsers that do not support CSP, and these three are serving a CSP to everyone.

Across the whole panel, Content-Security-Policy is on 17 of 27 responses, which is more than five times the adoption of the header it replaced. How a CSP can also block things you wanted crawled is a separate problem, covered in how a content security policy affects SEO.

What this means for your site

No search dimension here at all. This changes nothing about crawling or indexing, and the data set contains no ranking information. It matters as a maintenance signal: a deprecated header in your response is usually the visible end of a config file nobody has opened in a while.

1. Look at what you send before deciding anything. One curl -sI settles it, and about seven in ten sites here send nothing.
2. If you send 1; mode=block, read MDN's warning and check whether you also send a CSP. Three of three sites in that position on this panel already do.
3. If a scanner is asking for this header, 0 is the answer the five sites here gave. Removing the line entirely lands in the same browser behaviour, and the difference is only whether the scanner sees a value.
4. Do not add this header to a new site. It is deprecated, non-standard, and its own documentation points somewhere else.

The neighbouring header that is not deprecated is measured in X-Content-Type-Options across 27 homepages, and the same 27 responses were also read for third-party code verification in subresource integrity across 27 homepages. To see every header your own page returns in one pass, see how QueryWin reads a page.

Common questions

How did you measure this?

One GET per homepage on 2026-09-04, desktop Chrome user agent, redirects followed, all response headers recorded and lowercased. Values were read verbatim and cross-tabulated against Content-Security-Policy on the same response. Site counts. Exit node in Osaka, Japan.

Should I remove X-XSS-Protection or set it to 0?

Both land in the same browser behaviour as far as the documentation describes. Five sites here chose the explicit 0. If nothing in your pipeline is asking for the header, removing the line is one less thing to explain later.

Is 1; mode=block dangerous?

MDN warns that this header can create vulnerabilities in otherwise safe sites, without naming a value. We did not reproduce any such case and we have no measurement of our own here, so we will report the warning and stop there.

Does this header affect SEO?

Nothing here shows that it does. This measurement has no ranking data in it, and the header acts on how a browser renders a page, not on what a crawler receives.

Why do nineteen sites send nothing?

We cannot tell whether that is a decision or an absence, and one response will never distinguish the two. What the number does say is that sending this header is now the minority behaviour on this panel.