X-Content-Type-Options Header Missing: How to Fix It

An audit flagged your site as missing the X-Content-Type-Options response header. This is a one-line server tweak that hardens how browsers interpret the files you serve. Below is what the header does, why its absence is a risk, how it touches SEO, and exactly how to add it on Apache, Nginx, and WordPress.

What the header is (and what nosniff means)

Every file a server sends carries a Content-Type header that declares its MIME type, for example text/html, text/css, or application/javascript. Historically, browsers did not always trust that declaration. If the declared type looked wrong, they would inspect the actual bytes of the response and guess a type instead. This behavior is called MIME sniffing.

The X-Content-Type-Options header has exactly one valid value: nosniff. According to MDN Web Docs, sending nosniff tells the browser to respect the declared Content-Type and never override it by sniffing. For requests destined to be a script or a stylesheet, the browser will block the response entirely if the declared type does not match an expected type. For everything else, it uses the supplied Content-Type as-is.

Why MIME sniffing is a risk

Sniffing exists to be forgiving, but forgiveness creates attack surface. MDN notes that without nosniff, a server response sent as text/plain can still be interpreted as HTML if the body contains HTML markup. On sites that accept user uploads, that is the classic opening for a MIME confusion attack: an attacker uploads a file that is nominally an image or text file but contains HTML and script. If a browser sniffs it as HTML, the script executes in your origin, which is a stored cross-site scripting (XSS) vulnerability.

The OWASP HTTP Headers Cheat Sheet recommends setting X-Content-Type-Options: nosniff precisely to reduce this class of risk. Security scanners such as OWASP ZAP and the crawlers built into tools like Screaming Frog and Sitebulb report the missing header as a hardening finding, which is why your audit surfaced it.

SEO relevance

The header is not a direct ranking factor, and adding it will not lift positions on its own. Its SEO value is indirect but genuine. Security hardening protects you from the kind of compromise (injected scripts, defacement, malware) that can trigger Google Safe Browsing warnings or a manual action, both of which devastate visibility. Technical-SEO crawlers also count security headers as part of a site-health score, so clearing this item improves your audit grade and removes a recurring warning from future reports. A clean, well-configured server is part of the overall signal that your site is trustworthy and maintained.

How to diagnose

Check any URL from the command line. The header should appear in the response. If it is absent, the page is unprotected.

curl -I https://seoprocheck.com/

# Look for this line in the output:
# x-content-type-options: nosniff

You can also open your browser developer tools, go to the Network tab, reload the page, click the document request, and read the Response Headers. Re-run an audit crawl afterward to confirm the finding clears across every template.

How to fix

Apache (.htaccess or vhost)

Add the snippet near the top of your .htaccess, above the WordPress rewrite block. It requires mod_headers, which is enabled on almost all hosts.

<IfModule mod_headers.c>
    Header set X-Content-Type-Options "nosniff"
</IfModule>

Nginx

Add this inside the relevant server or location block, then reload Nginx. The always keyword ensures the header is sent on error responses too.

add_header X-Content-Type-Options "nosniff" always;

# Then test and reload:
# nginx -t && systemctl reload nginx

WordPress

The cleanest fix is the Apache .htaccess snippet above, since most WordPress hosts run Apache or LiteSpeed (which reads .htaccess). If you prefer not to touch server files, a security plugin such as a headers-management or hardening plugin can set the header sitewide from the dashboard. As a last resort you can hook it in PHP via your theme or a small must-use plugin:

add_action('send_headers', function () {
    header('X-Content-Type-Options: nosniff');
});

Use only one method. Setting the header in both .htaccess and PHP can produce a duplicate header, which some scanners flag.

Common mistakes

Wrong value. The only valid value is nosniff. Anything else is ignored by browsers and still counts as missing.

Header set on the homepage only. It must apply to every response, including assets, error pages, and API endpoints. Setting it at the server or virtual-host level guarantees full coverage.

Incorrect underlying MIME types. Because nosniff makes browsers trust your declared types, a stylesheet or script served with the wrong Content-Type will now be blocked instead of rescued by sniffing. Verify your server sends correct MIME types before deploying, then re-test that CSS and JS still load.

Forgetting to reload. Nginx changes need a config reload; CDN or caching layers may need a purge before the header appears on live responses.

FAQ