A redirect chain checker follows a URL through every HTTP redirect until it reaches a final response, recording each hop’s status code, destination, and response time. GrowthGPT’s Redirect Chain Checker does this for any public URL, flags redirect loops, and shows exactly which hop to fix so users and crawlers land in one step.
Redirects are invisible until they break. A link that worked last year now bounces through three servers, an HTTPS rule fights a www rule, and a migration you shipped quietly turned every old URL into a two-hop detour. This guide walks through how to run the Redirect Chain Checker, how to read every part of the result, and how to fix the chains and loops it finds. If you are planning a move to new URLs, read it alongside the site migration SEO checklist, which covers the planning this tool verifies.
What does a redirect chain checker do?
When a server answers with a 3xx status and a Location header, the client asks for the new address. A browser does this silently, which is why chains go unnoticed. The checker does it one step at a time with automatic redirects switched off, so it can record what each server actually said.
For every hop it captures the URL requested, the HTTP status code, where the redirect points (relative Location values are resolved against the current URL), how long that hop took in milliseconds, and the Server header when one is sent. It stops when it reaches a response that is not a 301, 302, 303, 307, or 308, when it sees a URL it has already visited, or after ten hops.
Why do redirect chains and loops hurt SEO?
- Crawlers have a hop limit. Google’s documentation on HTTP status codes and crawling says Googlebot follows up to 10 redirect hops. Beyond that, the destination is treated as unreachable and the page is not indexed from that path.
- Every hop is a round trip. Each redirect means another DNS lookup, connection, and TLS handshake if the host changes. On mobile networks a three-hop chain is noticeable before the page even starts loading.
- Crawl effort goes to empty URLs. Requests spent on intermediate hops are requests not spent discovering or refreshing real pages. On a small site that is minor; on a large one after a migration it slows recovery. How to get pages indexed faster covers the rest of that picture.
- Loops make pages unreachable. A loop never resolves. Browsers give up with a “too many redirects” error, and crawlers drop the URL. A loop on a template rule can take out an entire section at once.
- Mixed signals weaken consolidation. A chain that mixes a temporary 302 with permanent 301s sends conflicting instructions about which URL should be canonical.
How do I check a redirect chain?
The tool takes a single input and returns the full chain in one pass. Here is the process.
Step 1: Enter the exact URL people and links actually use
Open the Redirect Chain Checker and paste the URL. Test the version that exists out in the wild: the old URL in a backlink, the link in an email footer, the address printed on packaging. Testing only the clean final URL tells you nothing about the chain in front of it.
Step 2: Include the protocol when it matters
If you type a bare domain such as example.com, the tool assumes https://. That skips the HTTP to HTTPS hop entirely. To test your protocol rule, type http:// explicitly. The quick-check buttons under the input use http:// URLs for exactly this reason, so you can see a real multi-hop chain before testing your own.
Step 3: Test all four host variants
Run http://example.com, http://www.example.com, https://example.com, and https://www.example.com. Each should reach your canonical host in at most one hop. The most common chain on the web is http to https on one hop and non-www to www on the next, which is two hops where one rule would do.
Step 4: Read the summary, then the hops
The summary banner shows the total number of hops (every URL fetched, including the final page), the total time across the chain, and how many of those hops were redirects. Below it, each hop appears as a numbered card with its URL, status badge, response time, and server. When the chain resolves cleanly, a Final Destination card shows where it ended.
Step 5: Copy the chain into your ticket
The Copy Chain button puts a plain-text version on your clipboard: one numbered line per hop with its status code and URL, the hop count and total time, and a warning line if a loop was detected. Paste it into the issue for whoever owns the server config, then re-run the same URL after the fix and paste the new chain underneath as proof.
How do I read the redirect checker results?
Each hop carries a color-coded status badge. Permanent redirects are yellow, temporary ones orange, success green, and errors red. Here is what each one means and what to do about it.
| Badge in the checker | What it means | What to do |
|---|---|---|
| 200 OK | The final page loaded | Confirm it is the page you intended, not a homepage catch-all |
| 301 Moved Permanently | Permanent move, strongest consolidation signal | Correct for retired URLs; make sure it points at the final URL directly |
| 308 Permanent Redirect | Permanent move that keeps the request method | Treated like a 301 by Google; fine to keep |
| 302 Found | Temporary move | Change to 301 or 308 if the old URL is not coming back |
| 307 Temporary Redirect | Temporary move that keeps the request method | Same rule as 302; check whether your platform issues it by default |
| 303 See Other | Points to a different resource, fetched with GET | Normal after form posts; unusual on content URLs |
| 4xx or 5xx code | The chain ended on an error page | Repoint the redirect to a live URL or restore the page |
| Error | The hop could not be fetched at all | Read the Connection Issue message above the chain |
Any status the tool does not label, such as a 404 or 503, is shown as the raw code. Only 301, 302, 303, 307, and 308 with a Locationheader are followed; everything else is treated as the end of the chain. MDN’s guide to HTTP redirections and the status code definitions in RFC 9110 are the references if you need the exact semantics.
What do the connection errors mean?
When a hop fails before any HTTP response arrives, the chain stops, that hop shows an Error badge, and a Connection Issue panel explains why. The messages map to specific causes:
- Request timed out (5s). Each hop gets five seconds. A redirect that slow usually means an overloaded origin or a rule evaluated by slow application code instead of the edge.
- SSL/TLS certificate error. The certificate is expired, does not cover that hostname, or is incomplete. Common on old subdomains that still receive links but were left off the new certificate.
- Domain not found (DNS resolution failed). The hostname in that hop does not resolve. Often a typo in a redirect rule or a retired domain whose DNS was dropped while links to it still exist.
- Connection refused. Nothing is listening on that host and port, typically an old server that was switched off.
- Private or disallowed address. A hop pointed at localhost, a private network, or a cloud metadata address. The tool blocks these on every hop for safety. On a public site this almost always means a misconfigured rule leaking an internal hostname.
How do I fix a redirect chain?
Flatten it. If A redirects to B and B redirects to C, change A to point straight at C and leave B pointing at C as well. Google’s guide to redirects and Google Search covers how to implement permanent redirects on common servers. Then work outward:
- Merge protocol and host rules. One rule that sends any http or non-canonical host straight to the final https host removes the most common two-hop chain on the web.
- Update old redirect maps. Each migration adds a layer. When you add new redirects, rewrite the older ones to the newest destination instead of stacking.
- Fix internal links at the source. Internal links should point at final URLs, not at anything that redirects. The Internal Linking Optimizer helps you plan that pass, and internal linking for AI search explains why clean links matter to assistants too.
- Fix canonicals and sitemaps. A canonical tag or sitemap entry that points at a redirecting URL contradicts the redirect. Check canonicals with the Canonical Checker and sitemap entries with the Sitemap Validator; only final 200 URLs belong in either.
- Re-run and keep the proof. Check the same URL again and confirm it is one redirect and a 200, then paste the copied chain into the ticket.
How do I fix a redirect loop?
When the tool requests a URL it has already visited in the same chain, it stops and shows a red Redirect Loop Detected panel. The hop cards show the cycle, so you can see which two rules are fighting. The usual culprits:
- CDN and origin disagree on HTTPS. The CDN talks to the origin over HTTP, the origin redirects to HTTPS, the CDN forwards the request over HTTP again. Fix the CDN’s origin protocol setting.
- Trailing slash rules in two places. The framework adds a slash and the server strips it. Pick one layer to own the rule.
- CMS settings against server config. The CMS site URL says www, the server rule says non-www. Align them.
- Two redirect map entries that point at each other. Common after a rollback. Search the map for both URLs and delete one entry.
Loop detection matches exact URLs. A loop that adds or changes a query parameter on every pass never repeats exactly, so it shows up as a chain that runs to ten hops instead. Treat ten hops with a redirect still on the last card as a loop until proven otherwise.
What can the redirect checker not detect?
- JavaScript and meta refresh redirects. The checker reads HTTP responses; it does not render pages. A page that redirects with script or a meta refresh tag appears as a final 200.
- Crawler-specific rules. Requests identify as the GrowthGPT redirect checker, not as Googlebot. If your CDN or bot manager treats crawlers differently, check those rules separately.
- Bulk lists. It checks one URL per run. For a migration, test a sample from each URL pattern in your redirect map plus every high-value page, rather than every row.
- Private environments. Staging behind a VPN or on a private address cannot be reached.
When should I run a redirect check?
Run it before and after any change to redirect rules, HTTPS setup, CDN configuration, or URL structure, and on launch day of every migration for your top pages. The site migration SEO checklist lays out the full sequence. Run it again when you merge or retire posts during a content refresh, since every merge creates a redirect.
For a broader health pass, the Website Grader scores the site as a whole (see how to use the Website Grader). After any redirect change on important pages, watch positions with the Google Ranking Tracker for a few weeks, and keep in mind that AI crawlers have to follow the same chains to reach your content, and you cannot assume every one of them follows as many hops as Googlebot does.
Frequently Asked Questions
How many redirects is too many?
One hop is the target for any URL you control. Two is tolerable during a migration, three or more is a chain worth fixing. Google documents that Googlebot follows up to 10 redirect hops before giving up, and the Redirect Chain Checker stops at the same limit, so a chain that reaches ten hops is broken for crawlers, not just slow.
Does a 301 redirect lose PageRank?
Google has stated that 3xx redirects do not lose PageRank, so a single permanent redirect is not a ranking penalty. Chains still cost you in other ways: every hop adds a full round trip for users, spends crawl requests on URLs that hold no content, and moves you closer to the hop limit where crawlers stop following.
Is a 302 redirect bad for SEO?
Not when the move really is temporary. Google treats a 302 as a weak signal that the target should be canonical, so the old URL may stay indexed. The problem is a 302 used for a permanent move: signals consolidate slowly or not at all. If the old URL is never coming back, use a 301 or 308.
Why does the checker show a different result than my browser?
Browsers cache 301 and 308 responses, remember HSTS upgrades from HTTP to HTTPS, and send cookies, so they often skip hops the server still serves. The checker makes a fresh server-side request with no cache or cookies, which is closer to what a crawler sees. Rules keyed on country, user agent, or login state can also produce different chains.
Can the redirect checker test staging or localhost URLs?
No. The checker only fetches public addresses and re-validates every hop, so a URL that resolves to localhost, a private network range, or a cloud metadata address is blocked and the chain stops with an error. Test staging rules with a local tool such as curl, then run the public URLs through the checker after launch.