See the full redirect chain of any address, the status code of every hop and the response headers of the final page, explained: X-Robots-Tag and canonical headers for search engines, caching and compression for speed, and HSTS, CSP and the other security headers with a grade.
Every time a browser or search engine asks for a page, the server answers with a status code and a set of headers before the page itself: whether the page exists or has moved, whether it may be indexed, how long it can be cached, whether it's compressed and which security rules apply. You normally never see them. This tool shows the whole answer for any address: each redirect in the chain with its status and time, every header of the final response, and plain explanations of what they mean for search, speed and security.
Tip: Check the variations of your address too: http and https, with and without www, with and without a trailing slash. Each should reach the same final address in one redirect.
X-Robots-Tag works like the robots meta tag but in the header, so it also applies to PDFs, images and other files. noindex there removes the page from results even if the HTML says nothing, which makes it a common cause of pages mysteriously disappearing. A Link header with rel="canonical" sets the preferred address for files that have no HTML head. Content-Type should match the file and include charset=utf-8 for HTML. Content-Language is a language hint that Bing uses.
Redirect chains matter too. Each hop adds a round trip for visitors, and while Google follows up to ten hops, long chains waste crawling and can leave old links pointing at intermediate addresses. Update redirects so every old address goes to the final one directly.
Cache-Control tells browsers and CDNs how long they may reuse a response. For HTML, no-cache or a short max-age with revalidation is usual, so visitors see updates; for images, scripts and stylesheets with version numbers in their names, a year (max-age=31536000, immutable) is best. ETag and Last-Modified let a browser or crawler ask whether a file has changed and get a tiny 304 answer if not, which Google uses to crawl large sites efficiently. Content-Encoding shows compression: Brotli (br) and zstd are the most efficient, gzip is universal, and text sent uncompressed is usually several times larger than it needs to be. CDN headers such as cf-cache-status or x-vercel-cache show whether the response came from the edge cache.
Six headers are graded: Strict-Transport-Security (HSTS), which makes browsers always use https; Content-Security-Policy, which limits where scripts and other resources may come from; X-Content-Type-Options: nosniff; protection against framing with X-Frame-Options or CSP frame-ancestors; Referrer-Policy; and Permissions-Policy. Each present header earns a point, and half a point when it's weak, such as a short HSTS max-age or a CSP that allows unsafe inline scripts. A+ means all six are set well; a page without https gets an F.
The tool also warns when Server or X-Powered-By headers reveal software versions, and when cookies lack the Secure, HttpOnly or SameSite flags. Security headers don't affect rankings directly, but they protect visitors, and a hacked site loses rankings fast.
Old addresses, http and non-www versions should each reach the final page in a single redirect.
Staging settings copied to production often leave an X-Robots-Tag: noindex behind.
Use versioned file names and cache them for a year; keep HTML short-lived.
Start with Content-Security-Policy-Report-Only, fix what it reports, then enforce.
CDN and firewall rules can change headers or block crawlers without anyone noticing.
If they differ, the server or a plugin is treating requests inconsistently.
A series of redirects between the address you request and the final page, such as http to https to www to the final path. One hop is ideal.
A firewall or bot protection is blocking automated requests. Make sure it allows search engine crawlers.
Not directly. https is a light ranking signal; the other headers protect visitors and your site from attacks.
The server may not compress responses, or a proxy removed the header. Check your server or CDN compression settings.
A standard request from our server. Sites that serve different headers to Googlebot may answer it differently.
No. The address is requested once and the answer is shown to you; nothing is kept.
Updated