Redirect Chains, Explained
After reading this you will be able to trace a URL through every redirect hop, tell permanent redirects from temporary ones, count the cost of a chain, and spot loops and downgrades before they waste crawl budget or leak ranking signals.
What a redirect chain is
A redirect is a server response that tells the client "the thing you asked for lives somewhere else." Instead of a page, the server returns a status code in the 3xx range and a Location header pointing at the next URL. The client then requests that URL. If it too redirects, you have a chain.
One hop is normal. Five hops is a problem. Consider a request for http://github.com. The server does not answer with a page. It answers with 301 and sends you to https://github.com/, which finally returns 200 OK. That is a two hop sequence: one redirect, then the destination.
The Redirect Chain Checker follows this sequence hop by hop from our server, recording each status code, each target and the response time of each request, so you can see the whole path rather than just the final address your browser lands on.
Permanent versus temporary, and why it matters
The status code is not decoration. It tells a search engine what to do with the old URL.
- 301 Moved Permanently
- The resource has a new home for good. Search engines drop the old URL and pass ranking signals to the target.
- 308 Permanent Redirect
- Like 301, but the request method is preserved. Also permanent, also passes signals.
- 302 Found
- Temporary. The old URL stays indexed. Signals stay with the old URL.
- 303 See Other
- Temporary, tells the client to fetch the target with GET. Common after form submissions.
- 307 Temporary Redirect
- Temporary, method preserved. Old URL stays indexed.
The common mistake is using a 302 for a move that is actually permanent. If you retire /old-page and send visitors to /new-page with a 302, Google keeps /old-page in its index and does not consolidate the signals onto /new-page. Google does eventually treat a long lived 302 as permanent, but you have no control over when, and you carry the ambiguity in the meantime.
A 302 that has been in place for two years is still telling every crawler "this is temporary, keep the old URL." If the move is permanent, change it to 301. The fix costs one line of server config and stops the guessing.
The cost of each hop
Every hop is a full network round trip: DNS lookup (sometimes), connection, request, response. The total time a user or crawler waits before seeing the page is the sum of every hop plus the final fetch.
Here n is the number of hops including the final 200, and t_i is the response time of hop i in milliseconds. If a chain has three redirects of 90 ms, 110 ms and 80 ms before a final fetch of 120 ms, the user waits 90 + 110 + 80 + 120 = 400 ms just on redirect overhead, and 280 ms of that is pure redirect waiting that a single hop would have avoided.
Google follows up to 10 redirect hops in a chain before giving up. It will still reach a page at the end of a long chain, but each extra hop spends crawl budget and delays indexing. For a large site, thousands of two hop chains that could be one hop add up to real crawl waste.
A worked example: following http://github.com
Two hops to a 200
Enter http://github.com and run the check. The scheme matters here because the first redirect exists precisely to upgrade the insecure scheme.
- Request
http://github.com. The server responds301 Moved PermanentlywithLocation: https://github.com/. This is the https upgrade, done correctly with a permanent code. - Request
https://github.com/. The server responds200 OKand returns the page.
The result is one redirect and one final response: two entries in the table. The chain is short, the redirect is permanent, and the scheme goes from http to https, which is the safe direction. Nothing to fix.
| Hop | URL | Status | Type | Time (ms) |
|---|---|---|---|---|
| 1 | http://github.com | 301 | Permanent | 95 |
| 2 | https://github.com/ | 200 | Final | 140 |
Total wait on this trace is 95 + 140 = 235 ms, of which 95 ms is the redirect. Times vary run to run; the status codes and targets do not.
Reading and interpreting the trace
Read the trace top to bottom and ask four questions at each hop.
- Is the code permanent or temporary? A
301or308in a chain that should be permanent is correct. A302or307for a permanent move is a leak. - Does the scheme go up or down?
httptohttpsis an upgrade.httpstohttpis a downgrade and a security regression: never redirect a secure URL to an insecure one. - Does the chain revisit a URL? If hop 4 points back to the URL from hop 2, you have a loop that never ends.
- How many hops before the 200? One is ideal, two is acceptable, three or more usually means chained rules that should be collapsed.
When you find a chain like A -> B -> C -> D, edit the rules so A, B and C all point straight to D with a single 301 each. Point every stale URL at the final destination, not at the next link in the chain.
Loops and the hop limit
A redirect loop happens when the path returns to a URL it already visited. The classic case is a rule that forces https while a second rule forces a trailing slash, and the two disagree: /page goes to /page/ goes to /page forever. Browsers stop after their own limit and show an error. Google stops at 10 hops and treats the chain as unreachable, so the page never gets indexed.
Use the widget below to see how quickly a chain crosses the point where it costs more than it is worth, and where the 10 hop ceiling sits.
Common mistakes
Four errors account for most of the redirect problems you will find.
- 302 for a permanent move. Signals stay on the old URL. Use
301. - Chaining instead of collapsing. After a redesign, old rules point at newer old rules. Point every legacy URL directly at the live one.
- Mixing the www and https redirects into two hops.
http://example.comtohttps://example.comtohttps://www.example.comis two hops for one intent. Combine them so the first response lands on the final canonical form. - https to http downgrades. Often a bad canonical rule. Always redirect toward the secure scheme, never away from it.
One more subtle case: a redirect that returns 200 but injects a client side redirect via JavaScript or a meta refresh. Our checker follows HTTP redirects, so a JavaScript redirect shows up as a 200 with no further hop. If a page reaches its final URL only in the browser, treat that as a hidden hop and prefer a server side 301.
Related tools
Redirects are one part of how crawlers navigate your site. If a redirect target sits behind a disallow rule, the crawler never reaches it, so check both together. The robots.txt Tester shows which URLs a robots file blocks, rule by rule. Once your live URLs redirect cleanly to their canonical forms, list those canonical URLs with the XML Sitemap Generator so search engines fetch the final destinations directly instead of discovering them through redirects.
Frequently asked questions
Does a 301 pass all of the ranking signals?
A 301 and 308 pass ranking signals to the target and Google treats them as canonical hints. Google has said permanent redirects do not lose PageRank. The old URL is dropped from the index over time and the target takes its place.
How many redirects is too many?
One hop is ideal, two is fine. Google follows up to 10 hops, but every hop after the first is a wasted round trip and a delay for the user. Treat three or more as something to collapse.
Why does the scheme matter in the URL I enter?
Many sites redirect http to https as the first hop. If you enter https:// directly you skip that hop and may miss a misconfiguration on the insecure version. Entering the exact scheme you want to test shows the real path.
Can this tool check URLs behind a login?
No. The check runs from our server, so it only reaches publicly accessible URLs. Pages behind authentication, a firewall, or an internal network are not reachable.
My browser reaches the page fine, so why worry about the chain?
Browsers hide chains from you: you see only the final page. Crawlers pay the full cost of every hop, and a temporary code in the chain can keep the wrong URL indexed. The trace shows what your browser conceals.
Related tools
robots.txt Tester
Test which URLs a robots.txt blocks, rule by rule.
XML Sitemap Generator
Turn a list of URLs into a valid XML sitemap.
Keyword Density Checker
Word and phrase frequencies of any text, with stopword filter.
Meta Tag & Open Graph Generator
Generate meta tags and preview the Google, Facebook and X cards.
SERP Snippet Preview
Pixel-accurate preview of your Google result on desktop and mobile.
UTM Campaign URL Builder
Build tagged campaign URLs with correct encoding.