Redirect checker

Type http://example.com/shoes into a browser and you may pass through three addresses before anything loads: an upgrade to HTTPS, a hop that adds www, then a move from an old path to a new one. Each hop is another round trip. A redirect checker shows that path step by step, with the status code, Location header and response time of every hop, so you can see what visitors and crawlers go through and cut it down to one.

Paste up to 10 URLs, one per line. For each one the checker follows the chain for up to 10 redirects and reports the final status, the number of hops, loops, temporary redirects on permanent changes, HTTPS downgrades and pages that redirect with a meta refresh. Copy everything as CSV for a spreadsheet or a ticket.

What each hop tells you

• The status code, colour-coded: green for 2xx, blue for permanent redirects (301, 308), amber for temporary ones (302, 303, 307) and red for errors.
• The Location header, resolved to a full URL.
• The response time until the headers arrived, measured from our servers.
• The cache-control and server headers, useful when a CDN and the origin server both add redirects.
• What changed in the URL: HTTP to HTTPS, www added or removed, a trailing slash, letter case, a new path or a different domain.

Which redirect status code should you use?

Use 301 or 308 when a URL has moved for good, and 302 or 307 only when the original URL will come back. Google says it treats 301 and 308 as a strong signal that the redirect target should be canonical, and 302, 303 and 307 as a weak one (Google’s HTTP status code documentation).

The method rules come from RFC 9110; for search, Google treats 308 like 301 and 307 like 302. The glossary entry on 301 vs 302 redirects goes into more detail.

Problems the checker flags, and how to fix them

• Chains of two or more hops. Point the first URL straight at the final one, and update internal links, canonical tags and sitemaps to use the final URL. The classic chain is http → https → www; one rule that sends every variant to the canonical host in a single step fixes it. Our post on redirect chains walks through the usual causes.
• Loops. A URL that redirects back to one earlier in the chain never resolves. Loops usually come from two rules fighting, such as a CDN forcing HTTPS while the origin forces HTTP.
• Temporary codes on permanent changes. A 302 on an HTTP-to-HTTPS or www hop is almost always a mistake. Switch it to 301 or 308.
• Chains that end in an error. A redirect to a 404 wastes the redirect. Send it to the closest live page, or answer 404 or 410 directly if nothing replaces the old URL.
• HTTPS downgrades. Any hop from https to http is reported as an error.
• Meta refresh. Google says it reads an instant meta refresh as a permanent redirect and a delayed one as temporary (redirects documentation). A server-side redirect is clearer for every client.

How the check works

Each hop is requested without following redirects: first with HEAD, and again with GET if the server rejects HEAD (405, 403 and similar). We read the Location header, resolve it against the current URL, confirm it points to a public web address, then request it. The trace stops at a 2xx, 4xx or 5xx response, at a loop, or after 10 redirects, the default limit Google says its crawlers follow.

Limits worth knowing: requests come from our servers with the SeouchBot user agent and no cookies, so redirects based on location, language or login can differ from what you see. JavaScript redirects are not run, although a meta refresh on the final page is detected. A batch stops after about 25 seconds, and response times reflect our servers’ network, not your visitors’.

Redirects are one part of crawlability. The sitemap checker finds sitemap URLs that redirect, and the free SEO audit checks HTTPS, www consistency and canonical tags in one run. For the definition, see redirect chain in the glossary.