Trace every hop in a URL's redirect chain. See status codes, timing, loops, HTTPS downgrades and SEO issues, with fixes for flattening chains to one hop.
Paste a URL and this checker follows it hop by hop until it reaches a final response, showing the status code, status text, Location header, response headers, per-hop response time and cumulative time for each step. It detects loops, tells you where the loop closed, and grades the chain across three dimensions — SEO, security and performance — with specific recommendations for each issue it finds.
It is built for the people who inherit redirect messes: SEOs auditing a migration, developers debugging why a link takes two seconds to land, and sysadmins untangling rules that accumulated across a CDN, a load balancer, a framework middleware and a legacy .htaccess file over several years.
You can choose GET or HEAD, set a maximum hop count, and set a timeout. HEAD is faster and lighter; use GET when a server behaves differently for HEAD requests, which some CDNs and application servers do.
http:// if that is what the inbound link uses, and with the trailing slash or without, matching the real link. Redirect behaviour changes with all of those.Latency multiplies. Each hop is a full round trip: DNS if the host changes, TCP handshake, TLS handshake, request, response. On a mobile connection with 150 ms of round-trip time, a three-hop chain can add half a second before the browser has even requested the real page. That delay lands squarely on Largest Contentful Paint, and it is paid by every visitor on every cold entry to that URL.
Link equity leaks and dilutes. Search engines pass ranking signals through redirects, but chains introduce loss in practice: crawlers limit how many hops they will follow before giving up on the target, each additional hop is another chance for a rule to be wrong, and long chains slow down recrawling of the destination. A chain that exceeds a crawler’s hop budget means the final URL is never reached at all, and the signals from every link pointing at the start of that chain go nowhere.
Crawl budget is spent on nothing. Every intermediate hop is a request a crawler makes that returns no content. On a large site with thousands of chained URLs that is a meaningful share of the crawling you get, consumed by 301s.
Chains hide bugs. A chain that ends correctly today can break tomorrow when someone removes a middle rule they believe is unused. Flattening chains removes that class of incident entirely.
This is not theoretical housekeeping. We flattened around 140 redirect chains on this site in a single pass, and the pattern was the same one you will probably find: a rule added for a WordPress migration, a later rule for an HTTPS cutover, and a third for a URL structure change, each individually correct and collectively three hops deep.
One hop, permanent, same scheme, straight to the final canonical URL:
| Hop | URL | Status |
|---|---|---|
| 0 | http://example.com/old-page | 301 |
| 1 | https://www.example.com/new-page | 200 |
Compare that to the chain it usually replaces: http://example.com/old-page → 301 to https://example.com/old-page → 301 to https://www.example.com/old-page → 301 to https://www.example.com/new-page → 200. Same destination, four requests instead of two, and three separate rules that must all keep working.
The fix is to make each rule point at the final destination rather than at the next rule. When you add a new redirect, also update every existing rule whose target is now itself redirected. That single discipline is what keeps a redirect map flat over years.
| Code | Meaning | Use it when |
|---|---|---|
| 301 | Moved Permanently | The URL has moved for good. The default for migrations and consolidations. |
| 302 | Found (temporary) | Genuinely temporary — a maintenance page, a short campaign. Signals are not consolidated. |
| 303 | See Other | Redirecting after a POST so a refresh does not resubmit. |
| 307 | Temporary Redirect | Temporary, and the method must be preserved. |
| 308 | Permanent Redirect | Permanent, and the method must be preserved. |
The frequent mistake is a 302 left in place for a permanent move — often because it was the framework default and nobody set it explicitly. If the destination is permanent, say so.
Once the chain is clean, confirm the final response with the security headers analyzer and validate the destination’s certificate with the SSL checker — an HTTPS redirect target with a broken certificate is worse than no redirect. To resolve a single shortened link without tracing the whole chain, use the URL expander, and look up an unfamiliar code in the HTTP status code reference.
One hop is ideal. Two is tolerable if there is a reason. Three or more should be flattened — the latency and crawl cost is real and the risk of a middle rule breaking grows with each link in the chain.
A single, well-implemented 301 to a closely related page passes signals well. Chains are where loss shows up: crawlers stop following after a limited number of hops, so a long chain can mean the destination is never credited at all.
Two rules that point at each other, usually written in different layers — a CDN rule forcing www while an application rule strips it, or an HTTPS rule fighting a canonicalisation rule. The checker stops when it revisits a URL and reports the hop where the loop closed, which is normally enough to identify the culprit.
HEAD is faster and avoids downloading bodies. Switch to GET if the results look wrong — some servers and CDNs handle HEAD differently, or reject it outright.
Browsers add cookies, cached permanent redirects and a real user agent. A 301 your browser cached is not re-requested at all, so the browser can appear to skip a hop that still exists. This checker makes a fresh request every time.
No. It makes unauthenticated requests, so anything requiring a session will show you the login redirect instead of the protected path.
No. The checker follows HTTP-level redirects via the Location header. Client-side redirects happen after the response is received and are invisible to it — another reason to prefer server-side redirects, since crawlers treat them far more reliably.
Point every rule at the final destination instead of at the next rule, and remove rules made redundant by that change. Then re-run the check to confirm one hop remains.
A redirect chain checker traces the complete path an HTTP request follows from the initial URL to its final destination. When a URL redirects to another URL, which may redirect again, a chain forms. Each hop in the chain adds latency, can lose referral data, and dilutes SEO link equity—making redirect chains a significant performance and search optimization concern.
Redirect chains are common on websites that have undergone redesigns, domain migrations, or URL structure changes. Over time, a page originally at /old-page might redirect to /new-page, which later redirects to /final-page. Each intermediate redirect wastes server resources and slows page load times for users and search engine crawlers.
When a browser or bot requests a URL, the server responds with an HTTP status code. Redirect status codes instruct the client to request a different URL:
| Status Code | Name | Meaning | SEO Impact |
|---|---|---|---|
| 301 | Moved Permanently | Resource permanently relocated | Passes ~90-99% link equity |
| 302 | Found | Temporary redirect | May not pass link equity |
| 303 | See Other | Redirect after POST | Minimal SEO impact |
| 307 | Temporary Redirect | Temporary, preserves method | May not pass link equity |
| 308 | Permanent Redirect | Permanent, preserves method | Passes link equity |
| Meta refresh | HTML-level redirect | Client-side redirect | Poor SEO practice |
A redirect chain occurs when multiple redirects are chained: URL A → URL B → URL C → URL D. Google has stated they will follow up to 10 redirects but recommend keeping chains as short as possible. Each hop introduces 50-500ms of additional latency depending on server response time and geographic distance.
A redirect chain occurs when URL A redirects to B, which redirects to C, creating multiple hops before reaching the final destination. Each redirect adds latency (200-500ms), wastes crawl budget, dilutes SEO value (PageRank), and frustrates users. Google recommends maximum 3-5 redirects. Chains often result from site migrations, HTTPS upgrades, or domain changes without updating intermediate redirects.
301 (Moved Permanently) indicates permanent relocation; search engines transfer SEO value and update indexes. 302 (Found/Temporary) indicates temporary moves; search engines keep original URL indexed and don't transfer full SEO value. Use 301 for permanent changes (domain migrations, HTTPS). Use 302 for A/B testing, maintenance pages, or truly temporary moves. Wrong choice impacts SEO significantly.
307 (Temporary Redirect) and 308 (Permanent Redirect) are HTTP/1.1 successors to 302/301 that preserve the request method (POST, PUT, etc.). Unlike 301/302, which may change POST to GET, 307/308 guarantee method preservation. Use 308 for permanent API endpoint changes requiring method consistency. Browser support is excellent; 307/308 are increasingly preferred for modern applications requiring strict HTTP semantics.
Each redirect adds 200-500ms latency, directly impacting Core Web Vitals (LCP, FID). Redirect chains waste crawl budget, potentially leaving important pages unindexed. 301 redirects pass 90-99% of PageRank, but chains dilute this through each hop. Mobile networks experience worse impact. Minimize redirects: update links directly, avoid chains, use server-side over client-side (meta refresh, JavaScript) redirects when possible.
Redirect loops occur when URL A redirects to B, which redirects back to A, creating infinite cycles. Browsers typically stop after 10-20 redirects. Common causes: conflicting .htaccess rules, HTTPS/non-HTTPS misconfigurations, CDN settings conflicting with origin server, WordPress plugin conflicts. Fix by examining redirect rules systematically, testing with curl or browser developer tools, and eliminating circular dependencies.
Redirect at the earliest possible point to minimize latency. CDN/load balancer redirects are fastest, occurring at the edge before reaching origin servers. Server-level redirects work but add round-trip time. Implement HSTS (HTTP Strict Transport Security) headers to eliminate HTTP requests entirely after first visit. Modern best practice: redirect at CDN, enforce HSTS, include in preload list for maximum security and performance.
Plan redirect mapping carefully: audit old URLs, create 1:1 mappings to new URLs, avoid chains (redirect old URL directly to final destination), test thoroughly before launch. Use 301 redirects for permanent moves. Monitor 404s post-launch and create redirects as needed. Maintain redirects for 1-2 years minimum. Update internal links to avoid redirects. Submit new sitemap to search engines post-migration.
Browser developer tools (Network tab) show redirect chains with status codes and timing. Server tools: curl with -L flag, Screaming Frog SEO Spider for site-wide analysis. Online checkers validate individual URLs. SEO tools (Ahrefs, SEMrush) identify redirect issues. Monitor with synthetic monitoring, log analysis, or RUM (Real User Monitoring). Set up alerts for unexpected redirect patterns or increased redirect latency.
A 301 redirect is permanent and cached by browsers, while 302 is temporary. 307 and 308 are HTTP/1.1 updates that preserve the HTTP method - 307 is temporary like 302, and 308 is permanent like 301. Use 301/308 for permanent URL changes and 302/307 for temporary redirects.