HTTP Headers Checker

Why response headers are worth reading

Every page a browser loads comes with a set of headers that never appear on screen but decide how the response is treated: whether it can be cached, whether it may be framed by another site, whether the browser may execute inline scripts, and whether search engines are allowed to index it.

Enter a URL and you get every header the server returned, along with a security assessment covering the headers that matter most. It is the fastest way to confirm what your server is actually sending, which is often not what your configuration file suggests — particularly once a CDN or reverse proxy sits in front of it and adds, strips, or overrides headers on the way through.

The header that silently removes pages from Google

X-Robots-Tag carries the same directives as the robots meta tag, but in the HTTP response. That makes it powerful — it can control indexing for PDFs, images and other non-HTML files that cannot carry a meta tag — and it makes it dangerous, because it is completely invisible in the page source.

A stray X-Robots-Tag: noindex applied at the server or CDN level will de-index pages while the HTML looks perfectly fine, and it is one of the hardest SEO problems to diagnose if you do not know to look for it. It very often arrives when a staging configuration is copied to production. If pages are vanishing from search with no apparent cause, check this header first.

The security headers worth having

These cost nothing to add and close off entire categories of attack:

• Strict-Transport-Security — forces HTTPS for future visits, defeating downgrade attacks. Start with a short max-age, confirm nothing breaks, then raise it; the value is hard to walk back once browsers have cached it.
• Content-Security-Policy — controls which sources may load scripts, styles and frames. The most effective defence against cross-site scripting, and the most involved to configure. Deploy it in report-only mode first to see what it would block.
• X-Content-Type-Options: nosniff — stops browsers second-guessing your declared content type, which prevents an uploaded file being reinterpreted as executable script. One line, no downside.
• X-Frame-Options or CSP frame-ancestors — stops your pages being embedded in a hostile frame for clickjacking. Prefer frame-ancestors, which supersedes the older header.
• Referrer-Policy — controls how much URL information leaks to sites you link to. strict-origin-when-cross-origin is a sensible default that keeps analytics useful without exposing full paths.

Caching headers decide your repeat-visit speed

Cache-Control determines whether a returning visitor re-downloads your assets or reuses them. The standard approach is a long max-age with immutable for fingerprinted static assets — files whose name changes when the content changes — and a short or no-store policy for HTML, so your pages update immediately while your CSS and images are fetched once.

Getting this wrong is expensive in both directions. Caching HTML too aggressively leaves visitors looking at stale pages you cannot easily purge; not caching assets at all makes every repeat visit as slow as the first, which shows up directly in Core Web Vitals.

Reading the status code first

Before the headers themselves, check the status. A 301 is a permanent redirect and passes ranking signals; a 302 is temporary and is the wrong choice for a permanent move. Chains of redirects — HTTP to HTTPS to www to a trailing slash — waste crawl budget and lose a little signal at each hop, so collapse them into one.

Also watch for soft 404s: a missing page returning 200 with "not found" in the body. Search engines index those as real pages, which fills your index with error pages. A genuinely missing page must return an actual 404 or 410 status.