URL Redirect Chain Checker
Enter a URL to trace its redirect chain and analyze HTTP status codes, redirections, and total load time throughout the journey.
How to use URL Redirect Chain Checker
- 1
Enter a URL
Type or paste the full URL you want to inspect, including http:// or https://.
- 2
Check the redirects
Click 'Check Redirects' to trace the URL and follow every hop to its final destination.
- 3
Read the redirect chain
Review each step, its HTTP status code (such as 301 or 302), and the total time across the chain.
- 4
Act on the SEO assessment
Use the SEO Impact panel, which flags too many hops, slow chains, temporary redirects, and error codes, to fix issues.
Understanding Redirects and Why Chains Hurt
What a redirect is and how a chain forms
A redirect is a server's instruction telling a browser that the URL it requested now lives somewhere else. The server answers with a 3xx status code and a Location header naming the new address, and the browser automatically requests that address instead. A redirect chain forms when the destination of one redirect is itself a redirect: the browser asks for A, is sent to B, then from B is sent to C, and only at C finds the actual page. Each arrow in that path is a separate round trip to a server.
Chains usually accumulate by accident over time. A site moves from http to https, later switches from non-www to www, then restructures a URL path, and if each change is layered on top of the last without consolidation, a single old link can end up bouncing through three or four hops before landing. This checker traces every hop and shows the full path so you can see exactly how long the chain has grown.
301 versus 302: permanent and temporary
The two most common redirect codes mean very different things. A 301 is a permanent redirect: it tells browsers and search engines that the move is final, so they should update bookmarks, pass the old URL's accumulated ranking signals to the new one, and index the destination. A 302 is a temporary redirect: it says the original URL will return, so search engines generally keep the original indexed and are cautious about transferring ranking signals. Using a 302 for a move that is actually permanent is a classic SEO mistake that leaves link equity stranded on the old URL.
The rule of thumb is simple. If the change is permanent, such as a retired page or a migrated domain, use 301. If it is genuinely temporary, such as a seasonal promotion, an A/B test, or a maintenance page, use 302. When in doubt about a long-lived redirect, 301 is almost always the right choice.
307 and 308: the strict modern codes
HTTP later added 307 and 308 to remove an old ambiguity. The original 301 and 302 codes were widely implemented in a way that could change a POST request into a GET on redirect, which is usually convenient for page moves but wrong for form submissions and APIs. 308 is a permanent redirect like 301 but guarantees the HTTP method and body are preserved, and 307 is the temporary equivalent of 302 with the same guarantee. For ordinary page redirects the practical SEO effect of 308 mirrors 301 and 307 mirrors 302.
You will mostly encounter 307 in two places: as the redirect emitted by HSTS preloading when a browser upgrades http to https internally, and in API traffic where preserving the request method matters. For content URLs, sticking to 301 for permanent moves remains the conventional and well-understood choice.
Why chains and loops are harmful
Every hop in a chain is a full request-response cycle, and that latency stacks up, especially on mobile networks with high round-trip times where each extra redirect can add hundreds of milliseconds before the user sees anything. Chains also waste crawl budget: search engines have a finite appetite for requests per site, and spending it following A to B to C to D means fewer resources left to crawl real content. There is also evidence that ranking signals can dissipate slightly across a long chain rather than flowing cleanly to the final page.
A redirect loop is the pathological case: A points to B and B points back to A, so the browser cycles until it gives up and shows an error like ERR_TOO_MANY_REDIRECTS, making the page completely unreachable. The checker flags chains that are too long, chains that are slow, temporary redirects that may be unintended, and error status codes in the path, so each of these failure modes is surfaced rather than hidden.
Flattening chains to a single hop
The fix for a chain is to make every starting point redirect directly to the final destination in one hop. If A goes to B goes to C, you update the rule for A so it goes straight to C, eliminating the B stopover. On Apache this means editing the redirect rules in your .htaccess or server config so the source maps to the final target; on Nginx it means updating the rewrite or return directives. The goal is that no redirect's destination is itself a redirect.
Audit redirects periodically, because chains creep back in as a site evolves. After any migration, HTTPS rollout, or URL restructuring, re-trace your most important entry URLs and confirm they each resolve to the canonical page in a single 301. Pay special attention to URLs that appear in external backlinks, since those carry the most link equity and benefit most from a clean, direct redirect.
Canonicalization: the redirects every site needs
Most redirect issues trace back to canonicalization, the practice of funneling every variant of a URL to one canonical form. The four dimensions are protocol (http versus https), host (www versus non-www), trailing slash (a path with or without a final slash), and case. If your site is reachable at all combinations of these, search engines see duplicate content and your link signals fragment across the variants. The cure is a set of 301 redirects that collapse each variant onto the single preferred URL.
The crucial detail is to combine these into one hop rather than chaining them. Sending http://example.com to https://example.com to https://www.example.com is two redirects where one would do. Configure the rules so that any non-canonical request, regardless of how many dimensions are wrong, lands on the fully canonical URL in a single 301. That is the cleanest possible result, and the one the checker labels as good practice.
Meta refresh and JavaScript redirects
Not all redirects happen at the HTTP level. A meta refresh redirect uses an HTML meta http-equiv="refresh" tag to send the browser elsewhere after a delay, and a JavaScript redirect changes window.location from a script. Both work for users, but they are inferior for SEO: they are slower, search engines treat them less reliably than a server-side 301, and a delayed meta refresh can be jarring or even flagged as a poor experience. They also will not appear in an HTTP-level redirect trace, because the redirect is decided after the page body loads.
Whenever you control the server, prefer a real HTTP 301 over a meta refresh or JavaScript redirect. Reserve client-side redirects for cases where you genuinely cannot configure the server. Because this checker follows server-issued 3xx responses, a page that appears to redirect in a browser but shows as a direct 200 here is a strong hint that the redirect is happening client-side and should be moved to the server.
Frequently asked questions
What does the redirect chain checker show me?
Why are redirect chains bad for SEO?
What is the difference between a 301 and a 302 redirect?
Do I need to enter the full URL with http or https?
Is the tool free, and does it send the URL to a server?
Related tools
Keep going with these handy tools