What you get
We request the URL from our server, follow up to 10 redirects one by one, and record every response: the status code, where it points next, how long it took and all of its headers. The final response’s headers are grouped so the ones that matter are easy to find:
- SEO and indexing:
X-Robots-Tag,Link(which can carry a canonical or hreflang),Content-Language,LocationandVary. - Caching:
Cache-Control,ETag,Last-Modified,Ageand CDN cache status headers. - Security: HSTS, Content-Security-Policy, frame options, referrer policy, CORS and cookies.
- Content and server: type, length, compression, and the server or CDN that answered.
Headers that quietly break SEO
- A stray
X-Robots-Tag: noindex. Often left over from a staging rule. The page looks fine in a browser and drops out of search. - A canonical in the
Linkheader that disagrees with the one in the HTML. Google sees both. - Redirect chains. http to https to www to a trailing slash is three hops where one would do.
- A 200 on a page that should be a 404 or 301, which creates soft 404s and duplicate URLs.
Reading a redirect chain
Each hop is listed with its status and target. A 301 or 308 says the move is permanent, so search engines transfer signals to the new URL; a 302 or 307 says it’s temporary, and the old URL may stay indexed. Open any hop to see the headers that server sent: a CDN, a hosting platform and your app can each add their own redirect, and the headers show which one did. Time per hop matters too, because every extra round trip delays the first byte of the real page.
For the redirect path alone, the redirect checker is simpler. For a graded view of security headers, use the security headers checker.