X-Content-Type-Options on 27 homepages: 15 send it, and the value was never a choice

FIELD TEST · 2026-09-01 · 27 homepages · one request each · X-Content-Type-Options and Content-Type

Sample and method: the 30-site panel this blog has used since 2026-08-15. Each homepage got one GET on 2026-09-01 with a desktop Chrome user agent, redirects followed, no JavaScript executed. Three sites dropped out — stackoverflow.com and medium.com answered 403, and reddit.com returned an 8,393-byte shell with no page inside it. That leaves 27.

Fifteen of the 27 homepages send X-Content-Type-Options, and all fifteen send the same value, because nosniff is the only value the header defines. There is no dial and no off switch here — the header is present or it is absent. The column next to it turned out to be more interesting: five of the 27 send a Content-Type that names no character encoding at all.

How we measured it

One request per site, sent from a machine whose exit is in Osaka, Japan. We read two fields off the delivered response — X-Content-Type-Options and Content-Type — and did nothing else with them: no second request, no cache-busting, no comparison against a previous day. The user agent was a desktop Chrome string, not Googlebot, so everything below describes what these servers hand a browser.

Only the homepage was requested. We never asked any of these hosts for a JSON endpoint, an XML sitemap, a stylesheet or a script file, and those are exactly the resource types where a browser's type-guessing has consequences. That limit applies to every sentence in this post.

Fifteen sites send X-Content-Type-Options, and the value is not a choice

The header has one directive. The MDN reference page gives the syntax as a single line, X-Content-Type-Options: nosniff, and describes that directive as preventing MIME type sniffing "for all other response types, causing the browser to use the declared Content-Type without examining the response content" (developer.mozilla.org, read 2026-09-01). So the fifteen values carry no information. They are the same word fifteen times, and presence is the only variable this field has.

Most response headers this blog has surveyed come with a value worth arguing about: a max-age number, a policy string, a list of origins. This one has a checkbox. That makes the twelve on the right side of the table an unusually clean signal — nobody chose a weaker setting, because there isn't one. Twelve teams have simply never added the line.

The other half of the same line: five sites declare no encoding

Content-Type does two jobs in one line. It names the media type, and it can name the character encoding. Twenty-two of the 27 do both, sending text/html; charset=utf-8 — spelled in mixed case across the panel, some sites in capitals and some in lowercase. We counted the two spellings as one, and nothing below turns on which one a site picked. Five write text/html and stop.

Those five are about.gitlab.com, astro.build, developer.mozilla.org, www.framer.com and www.wikipedia.org. Nothing is broken. The HTML standard lets a document declare its own encoding, and a <meta charset> near the top of the file settles it — where exactly that declaration sits is what we measured in the charset meta tag survey. What changes is the order in which a client learns things. Read the headers alone and you know the type but not the encoding.

Two sites say don't guess the type, then leave the encoding to be guessed

Cross the two columns and two hosts sit in both. Each of them sends nosniff, which asks the browser to trust the declared type and stop examining the bytes, and each of them sends a Content-Type that stops before the encoding.

This is not a bug. One instruction says do not infer the type; the same line hands the encoding over to be inferred from the document. The two fields are usually set by different people at different times — a security review adds one, a server default writes the other — and neither pass reads the other's field.

nosniff is a switch, not a setting. The part of that line still worth reading is what comes after the semicolon.

Where X-Content-Type-Options sits among the other security headers

Same 27 hosts, same single request, same day. Counting how many sent each header at all, without reading the values:

Fifteen puts it in the middle of the pack and nine sites behind strict-transport-security on the same panel, measured the same afternoon. The headers below it in this table all take configuration you have to think about, and the ones near the bottom can break a page if you get them wrong. This one takes a fixed string and cannot break a page it is attached to. The nine-site gap is the odd part.

What this means for your site

Three checks, and the first one is a single command that covers both fields.

1. Run curl -sI https://yourdomain/ | grep -i content-type. Both field names contain the same string, so one grep prints the media type, the encoding and the nosniff line together.
2. Look at what follows text/html. If the line ends there, your encoding is being declared inside the document instead, and the byte offset of that declaration starts to matter.
3. If the nosniff line is missing, add it. There is one value to add and no tuning to do afterwards. Add it for the files your domain serves to browsers, and don't expect it to show up in a search report.

None of this moves rankings, and this survey is not going to imply otherwise. A crawler that fetches HTML and reads it follows the Content-Type it was handed; it was not guessing to begin with, so telling it not to guess changes nothing it does. The thing upstream of every header here is whether the fetch succeeds at all, which is what the AI crawler check reports, and the manual version of that test is in how to check if AI can read your site.

What this run cannot tell you

Three gaps, and the first one covers the header's actual job.

1. We only requested homepages. No JSON, no XML sitemap, no stylesheet, no script file — the resource types where a missing or wrong media type leads a browser to guess. Whatever nosniff is doing for those fifteen sites, it is not doing it anywhere in this dataset.
2. The user agent was desktop Chrome, and we ran no before-and-after test on any site that added or removed the header. Whether it changes what gets indexed, we don't know, and one request per homepage was never going to show us.
3. One request, one exit, one moment. The machine sits in Osaka, so a CDN that varies headers by region appears here as a single fixed fact.

Common questions

How did you measure this?

One GET per homepage on 2026-09-01 from Osaka, desktop Chrome user agent, redirects followed, no JavaScript executed, reading X-Content-Type-Options and Content-Type off the response as delivered. Twenty-seven of 30 sites answered usefully.

What does nosniff actually do?

It tells the browser to use the declared Content-Type without examining the response content, per the MDN reference page read on 2026-09-01. In practice that matters most for stylesheets and scripts, where the browser blocks the file outright if the declared type is wrong.

Does X-Content-Type-Options help SEO?

No. Nothing in this run shows a connection, and the mechanism argues against one: a crawler taking your HTML already uses the type you declared. Twelve of the 27 sites here send no such header, www.wikipedia.org and www.theverge.com among them.

My Content-Type has no charset. Is that a problem?

Not by itself. Five sites on this panel do the same and render correctly everywhere, because the encoding is declared inside the HTML. It becomes a problem only when the in-document declaration also arrives too late in the file.

Is there any value other than nosniff?

Not one that does anything. The syntax on the MDN reference page is a single line with a single directive, so the choice is whether to send the line, and all fifteen senders on this panel send it identically.