HTTP Header Checker

How to use the HTTP header checker

Enter a URL, with or without https://, and press Check headers. The checker follows up to 10 redirects and lists the status code, time and response headers of every hop, so it works as a redirect checker and an HTTP status checker in one pass. An audit then grades the security, caching and indexing headers of the final response.

GET asks for the page the way a browser does; HEAD asks for headers only. The checker never downloads the body either way, so HEAD mainly shows how a server handles it. The user-agent list lets you check response headers as a desktop browser, an iPhone, Googlebot or Bingbot would receive them.

What status codes mean for SEO

• 301 and 308 are permanent: a strong signal to Google that the target should be indexed in place of the old URL. 308 also keeps the request method, which matters for forms and APIs rather than pages.
• 302 and 307 are temporary, a weak signal, so the old URL may stay in the index. Use them for short-lived moves and switch to 301 or 308 once a move is permanent.
• 404 and 410 both say the page doesn't exist. Google handles all 4xx codes except 429 the same way: it ignores their content and removes the URL from the index. 410 adds that the removal is deliberate.
• 5xx and 429 tell crawlers the server is struggling. Google slows its crawling, keeps indexed URLs for a while, and drops the ones that keep failing. For planned maintenance, answer 503.
• Soft 404s are error or empty pages served with 200 OK. A header check only sees a healthy 200, so return a real 404 or 410 for content that is gone.

Redirect chains and why to shorten them

A chain is a redirect that lands on another redirect, for example http://example.com to https://example.com to https://www.example.com/. Google's crawlers follow up to 10 hops, so a short chain still works, but every hop costs visitors a round trip and crawlers an extra fetch, and a new host adds a DNS lookup and TLS handshake. Chains grow by accident: a site moves to HTTPS, then to www, then restructures its URLs, and each rule is stacked on the last.

Send every old URL straight to its final address in one 301 or 308, merge the scheme and host rules, and update internal links, canonical tags and sitemaps to point at final URLs. A loop, where the chain returns to a URL it already visited, ends in a "too many redirects" error.

Security headers check: recommended values

The audit grades each of these headers. The values below are sensible starting points.

Caching headers

Cache-Control decides who may store a response and for how long: max-age sets the lifetime in seconds, s-maxage overrides it for CDNs, private keeps it out of shared caches, no-cache requires a check with the server before each use, no-store forbids storing, and immutable skips revalidation of fingerprinted files like app.3f9a1c.js.

ETag and Last-Modified let a cache ask whether its copy is current and get a small 304 Not Modified back. Expires is the older way to set a lifetime; max-age wins when both are sent. Vary lists request headers that change the response, usually Accept-Encoding. Age, cf-cache-status, x-cache and x-vercel-cache show whether a CDN answered from its cache (HIT) or went to your server (MISS).

X-Robots-Tag vs meta robots

The X-Robots-Tag header accepts the same rules as the robots meta tag, such as noindex, nofollow, none and nosnippet. The meta tag only works in HTML; the header works for any file, including PDFs and images. It can also target one crawler: X-Robots-Tag: googlebot: noindex applies to Google only. When rules conflict, Google applies the more restrictive one.

When robots.txt blocks a URL, crawlers never read its noindex header, and the URL can still be indexed from links alone. Check your crawl rules with the Robots.txt Tester as well.

Testing as Googlebot, and its caveats

A Googlebot user-agent shows what a site sends to anything that claims to be Googlebot, such as a different redirect, a noindex header or a block page. It doesn't prove what Google itself receives. Sites that guard against fake crawlers verify Googlebot by reverse DNS: the IP address must resolve to a host under googlebot.com, google.com or googleusercontent.com that resolves back to the same IP. Requests from this checker fail that test, so a protected site may block them or treat them as an ordinary visitor. To see what Google really gets, run a live test in the URL Inspection tool of Google Search Console.

Limits of this checker

• Requests come from a cloud server in the US or EU, not from your browser or country. Sites that redirect by location or show region-specific consent pages may answer differently for you.
• Bot protection and web application firewalls often block cloud IP addresses, so a 403, 429 or 503 here may come from that layer rather than your application.
• The checker speaks HTTP/1.1, sends no cookies, and doesn't download the page or run JavaScript. It can't see meta refresh or JavaScript redirects, robots meta tags, or soft 404s.
• Each request times out after 10 seconds, and private, loopback and internal addresses are refused.