Redirect Chain Checker
Trace full redirect chains for any URL. Visualize each hop with status codes, detect redirect loops, and find mixed protocol issues.
TL;DR: Redirect chains add unnecessary hops between an original URL and its final destination. Every extra hop costs you page speed, wastes crawl budget, and can dilute the link equity flowing to your pages. This free redirect chain checker traces the full redirect path for up to 25 URLs at once, displaying every status code and flagging loops or mixed-protocol issues so you can fix them fast.
What Is a Redirect Chain?
A redirect chain occurs when one URL redirects to a second URL, which then redirects to a third (or even fourth, fifth, and beyond). Instead of a single, clean redirect from the old address to the new one, the browser and search engine crawlers must follow multiple hops before they finally reach the page that actually serves content.
A single redirect is perfectly normal. You change a URL slug, set up a 301, and move on. The problems start when redirects stack on top of each other over time. Maybe you migrated from HTTP to HTTPS a few years ago. Then you switched from www to non-www. Then you restructured your URL paths. Each change added a new redirect rule, but nobody went back and updated the older ones. Now a visitor clicking an old link bounces through three or four servers before landing on the right page.
The longer the chain, the worse the impact. Google has stated that their crawler will follow up to about 5 hops in a chain, but after that it may simply stop and never reach the final URL. Most browsers cap out at around 20 hops before throwing an error. Either way, you want to keep redirect hops to a minimum.
Why Redirect Chains Hurt SEO
Redirect chains are not just a technical curiosity. They have real, measurable effects on how search engines crawl and rank your site. Here is a breakdown of the main problems.
| Problem | Impact |
|---|---|
| Page speed | Each redirect hop adds roughly 50 to 300 milliseconds of latency. A chain with 3 hops can add close to a full second, directly hurting Core Web Vitals scores. |
| Crawl budget | Googlebot allocates a limited crawl budget to each site. Every hop in a chain counts as a separate request, wasting resources that could be spent indexing actual content. |
| Link equity | Google has confirmed that 301 redirects pass full PageRank. However, stacking multiple redirects introduces practical signal loss, especially when chains mix 301s and 302s. |
| User experience | Visitors on slow connections or mobile devices feel every extra hop. Slow page loads increase bounce rates and decrease conversions. |
| Indexing failures | If Googlebot gives up partway through a long chain, the final page may never get indexed. Orphaned pages lose all organic visibility. |
How to Use This Redirect Chain Checker
- Enter your URLs in the input box, one per line. You can check up to 25 URLs in a single batch.
- Pick a user agent to simulate how Googlebot, Bingbot, or a mobile browser follows the redirects. Different crawlers can receive different redirect responses.
- Click "Check URLs" to start the trace. The tool follows every redirect hop until it reaches a final response or detects a loop.
- Review the chain visualization. Each hop displays the HTTP status code, the target URL, and the response time so you can spot the slowest links.
- Export results as CSV to hand off to your development team with clear instructions on which redirects need updating.
Understanding Redirect Status Codes
Not all redirects are created equal. The HTTP status code tells search engines whether a redirect is permanent or temporary, and that distinction matters for how link equity gets transferred. Here is a quick reference.
| Code | Type | SEO Meaning |
|---|---|---|
| 301 | Permanent Redirect | The standard choice for permanent URL changes. Passes full link equity to the destination. |
| 302 | Temporary Redirect | Tells search engines the move is temporary. May not transfer link equity. Often misused when a 301 is the correct choice. |
| 307 | Temporary (HTTP/1.1+) | Behaves like a 302 but strictly preserves the original request method (GET, POST). Commonly seen during HTTPS upgrades. |
| 308 | Permanent (HTTP/1.1+) | Behaves like a 301 but preserves the request method. Less common but increasingly used in modern server configurations. |
A common mistake is using 302 redirects for changes that are actually permanent. When you see a chain that mixes 301s and 302s, the 302 hops are the first ones to fix. Swap them to 301s if the move is permanent, then flatten the chain. For more details, see Google's official documentation on redirects.
Common Causes of Redirect Chains
Redirect chains rarely happen on purpose. They accumulate gradually as sites evolve. Here are the most frequent culprits.
HTTPS Migrations
Moving from HTTP to HTTPS is the single most common source of redirect chains. The server adds a rule to redirect all HTTP requests to HTTPS. If you also have a www-to-non-www rule (or vice versa), a single request can bounce through two or three hops: http://example.com to https://example.com to https://www.example.com. The fix is to redirect directly from the starting URL to the final canonical version in one hop.
Site Migrations and Redesigns
When you restructure your URL paths or move to a new domain, you add redirect rules. If the old redirects from a previous migration are still in place, new rules stack on top of them. A page that was already redirecting once now redirects twice. After two or three redesigns over several years, it is not unusual to find chains with four or five hops.
CMS and Plugin Changes
Content management systems like WordPress often generate redirects automatically when you change a post slug. Redirect plugins may create their own rules without checking whether a redirect already exists for that URL. Over time, these automated redirects layer on top of each other and create chains that nobody notices until crawl reports start flagging issues.
Redirect Chains vs. Redirect Loops
A redirect chain is linear. URL A sends you to URL B, which sends you to URL C. Eventually you arrive at the final destination. It is slow and wasteful, but it works.
A redirect loop is circular. URL A redirects to URL B, and URL B redirects back to URL A. The browser goes back and forth until it gives up and shows an error like "ERR_TOO_MANY_REDIRECTS." Loops are more severe than chains because the page never loads at all. They typically happen when two redirect rules conflict, such as one rule sending www to non-www and another sending non-www to www. This tool detects both chains and loops, so you can catch either problem in a single scan.
How to Fix Redirect Chains
The core principle is simple: every redirect should point directly to the final destination URL. No intermediate stops. Here is a step-by-step approach.
- Audit your redirects. Use this tool to trace chains across your most important URLs. Start with pages that receive the most backlinks or organic traffic.
- Flatten each chain. Update the first redirect in every chain so it points directly to the final URL. If
A → B → C, change A so it redirects straight to C. - Fix internal links. Search your site for links that still point to old URLs. Update them to link directly to the current, canonical URL. This removes the need for a redirect entirely.
- Update your XML sitemap. Make sure your sitemap only contains final destination URLs. Submitting redirected URLs in a sitemap wastes crawl budget and sends mixed signals to search engines.
- Check your .htaccess or server config. Look for stacked rewrite rules that run in sequence. Combine them into single rules that jump directly to the correct destination.
- Re-test after changes. Run the chain checker again to confirm every URL now resolves in one hop or fewer. It is easy to introduce new chains while fixing old ones.
For Apache servers, Google's guide on HTTP errors and redirects is a useful reference when writing clean rewrite rules. On Nginx, make sure your return and rewrite directives do not cascade.
Frequently Asked Questions
How many redirect hops are too many?
One hop is fine and often unavoidable. Two hops are acceptable during a transition period. Three or more is a chain that you should fix. Google follows up to about 5 hops, but performance degrades with every extra one. Browsers typically stop after 20 hops and show an error.
Do 301 redirects still pass full PageRank?
Yes. Google has officially confirmed that 301 redirects no longer have a PageRank dampening factor. A single 301 passes the same link equity as a direct link. However, stacking multiple redirects in a chain introduces latency penalties and can cause crawl issues that indirectly affect rankings.
Is a 302 redirect bad for SEO?
Not inherently. A 302 is the correct choice when the move really is temporary, like an A/B test or a seasonal promotion. The problem is when 302s are used for permanent moves. Google may not consolidate link signals to the new URL, and the old URL can keep appearing in search results. If the change is permanent, always use a 301.
Should I delete old redirects entirely?
No. Removing a redirect means anyone who visits the old URL will get a 404 error. That is worse than a chain. The correct approach is to update old redirects so they point directly to the final destination. Flatten the chain instead of breaking it.
Can redirect chains prevent pages from being indexed?
Yes. If Googlebot hits a chain longer than about 5 hops, it may stop following and never reach the final page. That page will not get indexed. Even shorter chains waste crawl budget, which means Google spends time on redirects instead of discovering and indexing your actual content.
How often should I check for redirect chains?
Run a check after every major site change: domain migration, CMS update, URL restructuring, or SSL certificate change. For active sites, a quarterly audit is a good habit. Redirect chains tend to accumulate silently, so regular checks catch problems before they snowball.
What is the difference between a server-side and client-side redirect?
Server-side redirects (301, 302, 307, 308) happen at the HTTP level before the page loads. They are what search engines follow. Client-side redirects use JavaScript or meta refresh tags and happen after the page starts loading. Search engines may not follow client-side redirects reliably, so always use server-side redirects for SEO purposes.
Related Free SEO Tools
- HTTP Status Checker: Check HTTP status codes for up to 100 URLs at once. Quickly identify which URLs return 200s, 301s, 404s, or 5xx errors across your entire site.
- Canonical Tag Checker: Verify that your canonical tags are set correctly and consistent with your redirect strategy. Mismatched canonicals and redirects confuse search engines.
- On-Page SEO Analyzer: Run a full on-page audit to check title tags, meta descriptions, headings, and other ranking factors alongside your redirect health.