Your origin server can send a perfectly correct security header that a CDN sitting in front of it quietly strips before it ever reaches a visitor or Googlebot. Check the headers your live URL is actually sending, not the ones you assume are still there.
Every time a browser or a crawler requests a page, your server sends back a set of headers controlling how the content gets cached, indexed, secured, and parsed. None of this shows up in the rendered page, which is exactly the problem: a header can be wrong for months before anyone notices, because nothing about the page itself looks broken.
The part most setups miss entirely is that the origin server and the live URL aren't always sending the same thing. A CDN, a reverse proxy, or an edge function sitting in front of the origin can add headers, strip them, or quietly overwrite them on the way out. The origin can be configured perfectly and the public-facing response can still be missing a header that someone confirmed was there, just at the wrong layer of the stack.
Server-level header problems are often invisible and high-impact. Here's how to address the most common issues systematically.
This can be set at the CDN edge (Cloudflare, Fastly, CloudFront rules), in the server config (add_header X-Robots-Tag in Nginx, Header set X-Robots-Tag in Apache's .htaccess), or by a WordPress security or SEO plugin. Check all three, since the header you're seeing on the live URL might not match what's set at the origin. Remove it, then verify with this tool and the Noindex Checker.
If your server config genuinely sets HSTS, CSP, or X-Frame-Options but this tool isn't seeing them on the public URL, the CDN or reverse proxy in front of the origin is the likely culprit. Check its header rules specifically, separate from the origin server settings, since the two layers don't automatically agree.
Add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, in the HTTPS server block on Nginx, via Header always set on Apache, or under SSL/TLS settings on Cloudflare. Start with a short max-age to test, since browsers enforce HSTS even after the header is removed, making mistakes here slow to undo.
Even a basic policy stops the most common attacks: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';, tightened later as you audit inline scripts. Google's CSP Evaluator scores it before you deploy. Pair it with X-Frame-Options: SAMEORIGIN and X-Content-Type-Options: nosniff.
gzip on; in Nginx, or the ngx_brotli module for better compression; mod_deflate on Apache. On Cloudflare, compression is on by default, but check that a cache rule isn't quietly bypassing it. Recheck afterward for Content-Encoding: gzip or br in the actual response.
A manual check tells you what's true right now. It says nothing about whether a server update, a CDN rule change, or a CMS plugin push next month quietly undoes it.
What makes header misconfiguration genuinely dangerous is that it's invisible by default. A developer fixes a CORS issue and accidentally drops the HSTS header in the process. A CDN rule change strips the Content-Security-Policy without anyone flagging it. A plugin update adds an X-Robots-Tag: noindex sitewide. None of these throw a visible error, so the damage sits there until someone happens to check headers specifically, which on most teams is rarely.
A single update can remove a security header, add a noindex directive, or disable compression at any layer of your stack, origin or CDN, without anyone noticing until rankings move.
✓ 30-day Premium Trial · ✓ No credit card required · ✓ Full header monitoring access
