Content-Type header doesn't match the actual content

1496 audited sites hit the "Content-Type header doesn't match the actual content" issue; this hub breaks it down by platform, gatekeeper, vertical and country.

1496

audited sites affected

What it means

A Content-Type mismatch means the HTTP Content-Type header a page sends doesn't match the bytes actually in the response body. The commonest case: an HTML page is served with a non-HTML type (text/plain, application/octet-stream) so the browser downloads or mis-handles it instead of rendering it. Related defects are an empty/invalid MIME type, or text/html sent with no charset.

Why it matters

The Content-Type header is the first thing a browser and Googlebot read to decide how to treat a response. If an HTML document arrives as text/plain or application/octet-stream, the browser will not render it as a page — it shows raw source or triggers a download — and Google will not index it as an HTML document, so the URL effectively drops out of search. When no charset is declared on the header, the browser guesses the encoding, which can garble non-ASCII characters (mojibake). The header is authoritative and overrides any <meta charset> in the HTML.

How to fix it

Serve HTML pages as Content-Type: text/html; charset=utf-8 — set it at the app/framework or CDN layer, not per-file
Give every response an accurate type/subtype MIME; never leave the Content-Type empty or malformed
Always include charset=utf-8 on text/html so the encoding isn't left to browser guessing
If you send X-Content-Type-Options: nosniff (recommended), double-check every Content-Type is correct — nosniff turns a wrong type into a hard failure with no sniffing fallback
Check reverse-proxy / CDN rules and static-file handlers that can override or strip the origin's Content-Type

Example

Before — HTTP headers

HTTP/2 200
content-type: text/plain
x-content-type-options: nosniff

<!DOCTYPE html><html>… full page …</html>

After — HTTP headers

HTTP/2 200
content-type: text/html; charset=utf-8
x-content-type-options: nosniff

<!DOCTYPE html><html>… full page …</html>

With nosniff set, text/plain on an HTML body is a hard failure — the browser shows raw source and Google won't index it. Correcting the header to text/html; charset=utf-8 fixes rendering and indexing at once.

When it's not a problem

A deliberate non-HTML response is fine: a JSON API endpoint (application/json), a downloadable file (application/pdf, application/octet-stream), or an image (image/png) should keep its own correct type — those are not mismatches. The check only flags a type that contradicts the body (HTML bytes under a non-HTML type), an empty/invalid MIME, or a missing charset on text/html.

How Crawlinx detects it

For every fetched 200 response with a body, Crawlinx compares the declared Content-Type against the actual bytes. It detects the body's real shape from the leading bytes (a doctype / <html> / XML prolog) independently of the header, so it catches an HTML document served under the wrong type — the exact case where header-based detection is blind. It also flags an empty or malformed (non type/subtype) MIME, and text/html served with no charset. If X-Content-Type-Options: nosniff is present the browser strictly trusts the wrong header and cannot recover, so a mismatch is escalated from warning to error.

How common is it?

1496 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.

FAQ

Does the Content-Type header override <meta charset> in my HTML?: Yes. The HTTP Content-Type charset is authoritative and takes precedence over a <meta charset> tag. If the header declares a charset, that wins; if it declares the wrong one, the meta tag cannot override it. Set charset=utf-8 on the header and keep the meta tag as a fallback.
Why does X-Content-Type-Options: nosniff make this worse?: nosniff tells the browser to trust the declared Content-Type absolutely and never sniff the body to guess a better type. That's good security, but it means a wrong Content-Type can no longer be silently recovered — an HTML page sent as text/plain will download or show as source with no fallback, so the mismatch becomes a hard error.
Is a Content-Type mismatch an SEO problem or just a browser problem?: Both. Googlebot uses the Content-Type to decide whether a response is an indexable HTML document. If HTML is served under a non-HTML type, Google won't treat it as a page, so it won't rank — which is as much an SEO failure as it is a rendering bug.

Breakdowns

CMS

View breakdown →

Audit your own site — free

157 checks, internal PageRank, render-diff. No signup, results in ~30s.

Scan your site →