HTTP Header Inspector
Inspect, understand, and audit the HTTP response headers for any URL — with a security score, a caching verdict and the redirect chain that got there.
How to use it
- Enter any URL and press Inspect. The headers come back categorised and explained, alongside a security score, a caching verdict and any SEO-relevant headers found.
- Use the category pills to narrow the list to security, caching, SEO or infrastructure headers, and the sort control to group by category or run alphabetically.
- Turn off Follow redirects to inspect a 301 or 302 itself rather than its destination — the headers on the redirect are the ones that decide how it is cached and crawled.
Getting your headers right
- X-Robots-Tag is the only way to control indexing of a file that cannot carry a meta tag. A PDF, an image or a CSV has no <head> to put noindex in — the header is the entire mechanism.
- Security headers are not a ranking factor, but the HTTPS they enforce is one, and a site that gets hacked because it had no CSP loses its rankings the hard way. Treat the score here as hygiene, not as SEO.
- A redirect chain longer than two hops wastes crawl budget and drops a little link equity at each step. Googlebot follows up to five hops in one pass and returns later for the rest, which delays discovery of the destination.
- Brotli beats gzip by roughly 15–20% on HTML and CSS at the same CPU cost, and every browser released in the last eight years accepts it. If Content-Encoding says gzip, switching is usually a one-line server change.
- Vary: User-Agent on a responsive site is almost always a mistake. It splits the CDN cache across thousands of user-agent strings, so most visitors get a cache miss on a page that is identical for all of them.
- Cache-Control: no-store and no-cache are not the same thing. no-store forbids keeping a copy at all; no-cache keeps the copy and revalidates before using it, which is far cheaper and usually what was meant.
- Remove Server version numbers and X-Powered-By entirely. Neither helps a visitor, and both hand an automated scanner the exact version to match against a list of published exploits.
- Check headers with follow-redirects off when you are debugging a redirect. Following the chain shows you the destination's headers, which is not where the Cache-Control or X-Robots-Tag on the redirect itself lives.
Frequently asked questions
What are HTTP response headers?
They are the metadata a server sends back with every response, ahead of the body itself: a status line, then a list of name-and-value pairs describing what the content is, how long it may be cached, what security rules apply, and which infrastructure handled the request. The browser reads them before it reads a single byte of HTML, and most of what it does with a page — caching it, framing it, running its scripts — is decided by them. Nothing in the headers is visible on the page, which is why problems there can survive for years unnoticed.
Which HTTP headers matter for SEO?
X-Robots-Tag matters most, because it controls indexing and crawling at the HTTP level and is the only such control available for non-HTML files. The Location header on a 3xx decides where a redirect sends signals, and whether it is a 301 or a 302 decides whether those signals move at all. A Link header with rel=canonical or rel=alternate hreflang carries the same weight as the equivalent tag in the head. After that, Cache-Control and Content-Encoding matter indirectly: they shape how fast the page loads, and page speed is a ranking signal.
What security headers should every site have?
Four cover most of the risk for most sites. Strict-Transport-Security forces HTTPS for a set period so a connection cannot be downgraded. Content-Security-Policy limits where scripts may come from and is the real defence against cross-site scripting. X-Content-Type-Options: nosniff stops the browser second-guessing a file's declared type. And either X-Frame-Options or a CSP frame-ancestors directive keeps your page out of other people's iframes. Referrer-Policy and Permissions-Policy are quick wins on top, and the three cross-origin isolation headers only matter if you use SharedArrayBuffer.
How do I check HTTP headers for my website?
Paste the URL above and this tool fetches it server-side, which is the only way to see the full set — a browser will not let JavaScript read most response headers from another origin. Outside this page, the browser's own DevTools Network tab shows the headers for anything it loaded, and curl -I does the same from a terminal. The advantage of checking server-side is that you see what a crawler sees rather than what your logged-in session sees, including any header a CDN adds or strips on the way out.
Why do the headers differ between GET and HEAD?
They should not, but in practice they often do. A HEAD request asks for the headers alone, and some servers, caches and CDNs take a shortcut on that path — skipping Content-Length, dropping compression headers, or serving from a different cache entry than the one a GET would hit. Because search engines and browsers use GET, that is the honest default here. Switching to HEAD is useful specifically to find out whether your stack treats the two differently, which is a real bug worth catching.