Redirect Chain Checker Free Tool

Paste one URL per line. Each URL is followed through every HTTP redirect so you can see the full chain, the final destination, the number of hops, and any redirect loops.

Enter one URL per line

About Redirect Chain Checker

What a Redirect Chain Actually Is

A redirect chain happens when one URL redirects to a second URL, which redirects to a third, which redirects to a fourth — and so on — before a visitor or a crawler finally lands on a page that returns a normal 200 OK response instead of another redirect. Each individual hop in that sequence might be perfectly valid on its own. The problem is the sequence itself: every extra hop adds a round trip, and every extra round trip is a small tax paid by both search engine crawlers and real visitors.

A simple example: /old-landing-page/ redirects to /new-landing-page/, which itself redirects to /final-landing-page/. Anyone who lands on the first URL takes two hops to reach the content that actually exists. That's a two-hop chain. Sites accumulate these gradually — a URL gets redirected during one project, then redirected again months later during a different project, and nobody goes back to point the original URL straight at the final destination.

A redirect loop is a related but distinct problem: instead of eventually reaching a stable page, the chain circles back on itself. /page-a/ redirects to /page-b/, which redirects back to /page-a/. There is no final destination — a browser or crawler following that chain either gives up after a fixed number of hops and shows an error ("too many redirects"), or, in a badly written server configuration, never terminates at all. Loops are a hard failure. Chains are a soft, cumulative cost. This tool checks for both, and reports them separately because they call for different fixes.

Redirect Terms at a Glance

These four terms get used loosely, and mixing them up makes it harder to talk precisely about what's actually wrong with a URL. Here's the distinction this tool (and this page) uses consistently:

Term	What it means	Does it resolve to a real page?	Typical fix
Single redirect	One URL redirects directly to a final, live page in one hop	Yes, immediately	Usually nothing to fix — this is the healthy state
Redirect chain	Two or more redirects fired in sequence before reaching a final page	Yes, but only after multiple hops	Collapse it: point the original URL straight at the final destination
Redirect loop	A chain that circles back to a URL it already visited, with no final destination	No — never resolves	Find and remove the rule that points back into the cycle
Broken redirect	A redirect rule that points at a URL which itself now returns a 404 or 5xx error	No — dead end	Update the redirect target or remove the rule entirely

This tool's output maps directly onto this table: the "Redirect chains" table shows single redirects and chains together (a hop count of 1 is a single redirect, 2 or more is a chain), the loop alert box shows loops, and the "No redirect" list shows URLs that already point at a live final page with nothing left to fix.

Why Redirect Chains Hurt SEO

None of the reasons below are dramatic on their own for a single two-hop chain. The damage is cumulative — across a site with hundreds or thousands of chained URLs, or on a handful of high-value pages (your top landing pages, category pages, or anything linked from your main navigation), the cost adds up in ways that are worth fixing deliberately rather than leaving to accumulate further.

Crawl Budget Waste

Google's own developer documentation on managing crawl budget for large sites explicitly flags chained redirects as wasteful for crawling. Every hop a crawler has to follow to reach your actual content is a request that produces no indexable content — Googlebot spent a fetch on a 3xx response instead of on a page it can actually read and rank. For a small site this barely registers. For a large site where Google allocates a limited number of crawl requests per day, a pile of chained URLs means fewer of those requests go toward discovering and re-crawling pages that matter.

Link Equity Dilution Across Hops

Google has said for years that a standard 301 redirect passes the great majority of the ranking signal from the old URL to the new one — not a wholesale loss the way it might have worked in the earliest days of search engines. That's good news for a single, clean redirect. It's less reassuring for a chain, for two separate reasons. First, Google's crawlers don't follow redirect chains indefinitely — very long chains risk not being fully followed at all, meaning the final destination might not get associated with the original URL's signals in the way you'd expect. Second, every hop is another opportunity for something to break: a typo in a later redirect rule, a rule that gets deleted during a later migration, a target page that itself gets removed — each additional link in the chain is one more point of failure for the whole chain to keep working correctly.

Slower Page Load for Real Visitors

Every redirect hop requires a full round trip to the server before the browser even starts fetching the actual destination page — DNS resolution (if the hop crosses domains), a new HTTP request, a new response, and only then the next request in the chain. A two-hop chain roughly doubles the network latency before any real content starts loading, compared to a direct link. On a fast connection that might mean an extra 100-300 milliseconds; on a slow mobile connection it can be a full second or more. That delay counts directly against page-experience signals like Largest Contentful Paint (LCP), one of Google's published Core Web Vitals metrics — Google's own thresholds classify an LCP at or under 2.5 seconds as "good" and anything past 4 seconds as "poor," and a redirect hop's added round-trip time comes entirely before the browser even starts fetching the actual page content that LCP measures. A chain doesn't need to add a full 4 seconds to matter; it just needs to be the difference between comfortably clearing the "good" threshold and sliding into "needs improvement," and that's a delay a visitor feels even if they never look at a technical audit report.

Broken or Confusing Analytics Data

Redirect hops can also interfere with the data you use to judge whether a page is actually working. If a redirect rule doesn't explicitly preserve the query string, tracking parameters like UTM tags get silently dropped at whichever hop strips them — a campaign link that should show up cleanly in your analytics as "paid social" traffic can arrive looking like unattributed direct traffic instead, because the parameter never survived the chain. Multiple hops can also reset referrer information between requests, which matters if you're trying to trace where a visitor actually came from rather than just which of your own URLs they landed on last. None of this breaks analytics outright, but it quietly degrades the accuracy of attribution data for exactly the pages that took the most work to redirect correctly.

What Google's Own Guidance Actually Says

Google's crawl-budget documentation for large sites lists "having redirect chains" among the concrete factors that negatively affect crawling, right alongside other technical hygiene issues like soft 404s and low-value URL parameters. Google representatives have also repeatedly recommended keeping redirects to a single hop wherever a site owner has the ability to fix the original link, rather than relying on the crawler to patiently follow a long chain. None of this means a two-hop chain will tank your rankings overnight — it means chains are a real, documented technical debt item that Google explicitly asks site owners to clean up, not an urban legend from an old SEO forum thread.

Common Causes of Redirect Chains

Almost nobody sets out to build a redirect chain on purpose. They accumulate as a side effect of normal site maintenance, usually because a new redirect gets added without checking whether the URL it points at already redirects somewhere else. The most common real-world causes:

• Domain migrations. Moving from an old domain to a new one, then later restructuring URLs on the new domain, stacks a domain-level redirect on top of a path-level redirect — the old domain now chains through the new domain's own redirect before reaching the current page.
• HTTP to HTTPS moves. A site that redirects HTTP to HTTPS at the server level, and separately has an old page-level redirect still pointing at an HTTP URL, forces every visitor through an extra hop: HTTP page-redirect, then the HTTP-to-HTTPS redirect, then the final page.
• www / non-www inconsistency. If some internal links, old backlinks, or old redirect rules point at the www version and others point at the non-www version, and the canonical version has changed at some point, you can end up with a redirect from www to non-www that itself gets redirected again by a later rule.
• Trailing-slash redirects stacking on top of other redirects. Many servers automatically redirect a URL without a trailing slash to the same URL with one added (or vice versa). If that automatic rule fires on a URL that's also covered by a manual redirect rule, the two stack into a chain that nobody explicitly created.
• Repeated URL restructures without cleanup. A category gets renamed, so a redirect is added from the old category URL to the new one. Six months later the category gets renamed again, and a new redirect is added from the second URL to the third — but nobody goes back and updates the very first redirect to point straight at the final URL, so it now chains through the middle one.
• CMS or plugin redirect managers layered on top of host-level rules. A redirect plugin (or a page-builder's built-in URL settings) adds its own redirect rule for a moved page, unaware that the hosting environment or `.htaccess` file already has a separate rule affecting the same path — the two rules fire in sequence instead of one replacing the other.

Where Redirect Chains Typically Live (and How to Find Them)

Where you look for the actual rule causing a chain depends on how your site is hosted. The cause is usually one of the patterns above; this section covers where to physically go looking once you know a chain exists.

• WordPress with a redirect-manager plugin. Check the plugin's redirect list first (most show a searchable table of every rule it manages) — sort or filter by target URL to spot cases where one rule's destination is itself the source of another rule.
• Apache via `.htaccess`. Open the file directly and read through `Redirect` and `RewriteRule` lines in order — rules are applied top to bottom, so a chain often shows up as two separate rule blocks a few lines apart, sometimes added months apart by different people.
• Nginx via server config. Look for `return 301` or `rewrite` directives inside the relevant `server` or `location` blocks; unlike `.htaccess`, changes here typically require a config reload to take effect, so confirm the live behavior with this checker after reloading, not just after saving the file.
• CDN or DNS-level redirect rules (e.g. Cloudflare Page Rules, bulk redirects, or a similar edge-redirect feature). These fire before the request even reaches your origin server, which means a chain can exist between an edge-level rule and a separate origin-level rule without either system's own dashboard showing you the combined picture — this is exactly the kind of chain that's easy to miss by reading configs alone and much faster to catch by running an actual URL through a live checker like this one.
• Hosting-panel-level redirects. Some hosting control panels offer their own simple redirect feature separate from both the CMS and any manually edited config file. If a site has ever used more than one of these mechanisms over time, that's a very common, very quiet source of chains — two systems each doing their own job correctly, stacked on top of each other.

301 vs. 302 in a Chain

The HTTP status code used at each hop matters, and mixing status codes inside a single chain sends a genuinely confusing signal about what the correct, permanent URL actually is.

A chain that mixes the two — say, a 301 followed by a 302 followed by the final page — muddies the picture: is the destination permanent or not? Search engines have to guess based on inconsistent signals instead of reading one clear instruction. If every hop in a chain is genuinely permanent, every hop should be a 301. If a 302 shows up anywhere in a chain you intended to be permanent, that's usually a configuration mistake worth fixing on its own, separate from collapsing the chain's hop count.

Redirect Chains vs. Canonical Tags: Not the Same Fix

It's common to see canonical tags reached for as a fix for what's actually a redirect problem, and the two solve genuinely different situations. A canonical tag (<link rel="canonical" href="...">) tells a search engine which version of a page to treat as authoritative when two or more URLs serve very similar or duplicate content — both URLs still work and return 200 OK, and a visitor can land on either one. A redirect, by contrast, actively sends a visitor and a crawler from one URL to another; the original URL doesn't serve content at all anymore, it just forwards the request.

Using a canonical tag on a URL that should really be redirected leaves a dead-end-feeling duplicate page live on your site indefinitely, still consuming crawl attention, still capable of showing up in search results under the wrong URL. Using a redirect on a page that should really carry a canonical tag (two genuinely different-but-similar pages you want both accessible) breaks the page for anyone who actually wanted to view that specific URL. Neither substitutes for the other, and neither one has any effect on the problem this tool checks: chains and loops are strictly a redirect-response issue, and no amount of canonical-tag cleanup will resolve a chain that already exists in your redirect rules.

How the Redirect Chain Checker Works

Paste one URL per line into the box above and submit the form. For each URL, the checker follows the actual HTTP redirect response your server sends — not a guess, not a cached record, but a live request — and keeps following it, hop by hop, until it reaches a response that isn't a redirect. At that point it records the original URL, the final destination it landed on, and the total number of hops it took to get there.

While it's following each chain, the checker keeps track of every URL it has already visited within that same chain. If a redirect ever points back at a URL already seen earlier in the same chain, that's a loop — the checker stops following it (rather than requesting the same URLs forever) and reports it separately, showing the full cycle of URLs involved so you can see exactly where it circles back on itself.

URLs that don't redirect at all — meaning the URL you submitted already returns a normal, final page directly — are reported separately too, so you can see at a glance which of your submitted URLs are already clean and need no action. Anything you paste in that isn't a valid, well-formed URL gets skipped and listed separately as well, rather than silently dropped or causing the whole check to fail.

How to Use This Tool

This is the literal step-by-step process for running a check, separate from the explanation above of what happens technically once you submit.

1. Gather the URLs you want to check. Good candidates: URLs flagged by a site crawl (Screaming Frog, Ahrefs, Search Console) as having a redirect chain, old URLs from a recent migration, or any link you suspect might be routing through more hops than it should.
2. Paste one URL per line into the text box at the top of this page. You can include the protocol (https://example.com/old-page/) or leave it off — either works.
3. Complete the verification step if one is shown, then click the submit button.
4. Read the "Checked" count at the top of the results to confirm every URL you submitted was actually processed. If your list was unusually long, only the first batch may have been processed — check for the truncation notice.
5. Look at the loop alert box first, if one appears. Any URL listed there is a hard failure that needs fixing before anything else, since those URLs never reach a real page.
6. Review the "Redirect chains" table for every other URL. The "Hops" column tells you at a glance which ones are a single clean redirect (1 hop) versus a genuine chain worth collapsing (2 or more hops).
7. Check the "No redirect" and "Skipped" sections too — they confirm which submitted URLs are already fine and which ones weren't valid URLs to begin with.
8. Fix the chains and loops you found at the source (see the fix section below), then paste the same list back into this tool to confirm the hop count for each URL has dropped to 1 or 0.

Reading Your Results

Each part of the output answers a slightly different question. Here's what each section means and what to do with it:

Section in the results	What it tells you	What to do
Loop alert (red box)	One or more submitted URLs redirect in a circle and never reach a real page	Fix immediately — find the rule that points back into the cycle and remove or repoint it
Redirect chains table	Every URL that does reach a final destination, with the destination and hop count shown	Anything with 2+ hops is a candidate to collapse into a single direct redirect
No redirect list	URLs that already point straight at a live final page	Nothing to do — these are already clean
Skipped / invalid list	Entries that weren't recognizable as well-formed URLs	Check for typos in what you pasted; re-submit corrected versions if needed

How to Fix a Redirect Chain Once You Find One

Fixing a chain is usually simpler than finding it in the first place. Once you know the original URL and the true final destination (both of which this tool shows you), the fix is almost always the same core move, adjusted slightly depending on where your redirects live:

• Point the original URL straight at the final destination. Instead of A → B → C, edit the rule so A → C directly, and remove or update the now-redundant A → B rule. This is the single highest-value fix and applies to nearly every chain.
• Audit your `.htaccess` file (or nginx config) for stacked rules. If you're on Apache, open `.htaccess` and look for multiple `RewriteRule` or `Redirect` lines that could be firing on the same path in sequence — consolidate them into one rule per URL wherever possible.
• Check redirect-manager plugins for rules that overlap host-level redirects. If your CMS has its own redirect manager (common on WordPress, for example), confirm it isn't adding a second hop on top of a redirect that already exists at the server level. Pick one place to manage redirects for a given URL, not two.
• Fix www/https inconsistency at the root, not per-URL. If your chains are mostly caused by a www-to-non-www (or HTTP-to-HTTPS) redirect stacking on top of page-specific ones, fix the canonical version site-wide first — that alone can collapse dozens of individual chains at once without touching each URL by hand.
• Update internal links to point at the final URL directly. Even after the redirect itself is fixed, any internal links still pointing at the old URL are relying on a redirect to work at all. Updating those links removes the dependency entirely and gives visitors and crawlers a direct path with zero hops.
• Re-run this checker after each fix. Confirm the hop count actually dropped before considering the URL resolved — a rule edit that looks correct in the config file doesn't always behave the way you expect once it's live.

How Many Redirects Are "Too Many"?

There's no single official hard number Google has published as a strict cutoff, but the practical, widely-followed guidance from Google's own crawl-budget documentation and from search engine representatives is consistent: keep it to one hop wherever you have the ability to fix the original link. A single redirect from an old URL to its current replacement is normal, healthy, and not something to worry about. Two hops is worth fixing when you find it, since it's usually a quick edit. Anything beyond two or three hops is a genuine problem worth prioritizing, both for crawl efficiency and for the compounding page-load delay each additional hop adds.

The practical rule of thumb most technical SEOs work by: treat any chain your crawler or this tool reports with a hop count of 2 or higher as something to schedule a fix for, and treat loops as an immediate priority regardless of how many URLs are affected, since a loop never resolves for anyone — human or crawler.

Related Tools

A few other free tools on this site pair naturally with a redirect-chain check, depending on what you find:

• If your chains trace back to `.htaccess` rules that need rewriting from scratch, the Htaccess Redirect Generator builds clean, correctly-formatted redirect rules so you're not hand-editing regex.
• If www/non-www inconsistency is the root cause behind several of your chains, the www Redirect Checker confirms which version of your domain is actually set as canonical before you go fix individual URLs.
• Once your chains are collapsed, it's worth a pass with the Broken Links Checker to confirm none of the redirect targets you just cleaned up are themselves dead ends.

Frequently Asked Questions

What's the actual difference between a redirect chain and a redirect loop?

A chain eventually reaches a real, final page — it just takes more than one hop to get there. A loop never reaches a final page at all; it circles back to a URL already visited earlier in the same sequence and repeats indefinitely. Chains are a performance and crawl-efficiency problem worth cleaning up. Loops are a hard failure that breaks the URL entirely for anyone who follows it.

How many redirects in a row is considered too many?

See the "How Many Redirects Are 'Too Many'?" section above for the full breakdown — in short: one hop is fine, two is worth fixing, three or more is a real problem.

Will fixing a redirect chain directly improve my rankings?

It's rarely a dramatic ranking lever on its own for a single two-hop chain, but it removes real friction: crawl budget spent on redirect hops instead of real content, extra page-load latency that counts against page-experience metrics, and one more point of failure in the chain. Across a whole site, cleaning up a large number of chains is a legitimate technical-health improvement, even if no single fix produces a visible ranking jump by itself.

Should I use a 301 or a 302 when I collapse a chain?

If the move is permanent — which it almost always is when you're intentionally collapsing a chain down to a direct redirect — use a 301. Reserve 302s for genuinely temporary situations like short-term A/B tests or maintenance pages where the original URL is expected to come back into use.

Why does my site have redirect chains I never created on purpose?

Almost every chain is an accidental side effect of normal maintenance rather than something anyone built deliberately — a domain migration layered on top of an earlier URL restructure, a CMS redirect plugin unaware of an existing server-level rule, or an automatic trailing-slash or HTTPS redirect stacking on top of a manual one. See the "Common Causes" section above for the specific patterns to check on your own site.

Can this tool check URLs that require a login or sit behind a paywall?

No — this checker follows redirects the same way an anonymous visitor or a standard crawler would, without any authentication. URLs that require a logged-in session to reach their final destination won't resolve the same way here as they would for a signed-in user, so results for those specific URLs may not reflect what an authenticated visitor actually experiences.

Is it worth fixing redirect chains on low-traffic pages, or should I only focus on my top pages?

Prioritize by traffic and link value, but don't ignore the long tail entirely. A chain on your homepage or your highest-traffic landing page is worth fixing immediately given how much crawl and link value flows through it. A chain on a low-traffic page still costs a small amount of crawl budget every time it's re-crawled, and those small costs add up across a large site — it's reasonable to batch-fix the long tail on a slower schedule (during a periodic technical audit, for example) rather than treating every single chain as equally urgent.