What Is a Redirect Chain?
A redirect chain occurs when a URL redirects to another URL, which then redirects again, forcing browsers and crawlers through multiple hops before reaching the final page. For example, URL A points to B, which points to C. Each extra hop adds latency, wastes crawl budget, and can dilute the ranking signals passed along. Chains usually accumulate over time as sites change, and the fix is to point every redirect directly at the final destination.
- Definition
- Two or more consecutive redirects between the requested URL and the final page (industry-typical)
- Google's tolerance
- Googlebot follows up to about 10 redirect hops before giving up on a URL (Google Search Central)
- Performance cost
- Each hop adds a full network round trip, compounding on slow connections (industry-typical)
- Related issue
- A redirect loop is a chain that circles back on itself and never resolves (industry-typical)
What exactly is a redirect chain? #
A redirect chain is a sequence of two or more redirects that a request must pass through before landing on the final, live page. Instead of a clean single hop where an old URL points straight to the destination, the request bounces: the first URL redirects to a second, the second to a third, and so on until it finally reaches a page that returns a 200 status. Chains rarely get built on purpose. They accumulate over the life of a site as changes stack on top of one another, an old page redirected during a 2020 redesign, then that target redirected again during a 2023 platform switch, then once more when HTTPS was enforced. Each individual redirect seemed reasonable when it was added, but together they form a chain nobody intended. Because visitors still reach the right page, the problem hides in plain sight, which is why regular technical audits like those in /services/care-plans exist to catch chains before they compound further.
Why are redirect chains bad for SEO? #
Redirect chains harm a site in several compounding ways. First, they waste crawl budget: search engines must follow each hop, so on a large site thousands of chained redirects mean crawlers spend time bouncing between URLs instead of discovering and indexing fresh content. Second, they slow down real users, since every hop is a separate network round trip that adds delay, an effect that worsens on mobile connections and can nudge Core Web Vitals in the wrong direction. Third, while modern search engines pass ranking signals through redirects, long chains introduce risk and inefficiency, and if a chain grows past roughly ten hops, Googlebot may stop following it entirely and never reach or index the destination. Finally, chains make maintenance fragile, because a single broken link anywhere in the sequence can turn the whole path into a dead end. The speed dimension alone connects this issue to /services/speed-optimization and the broader guidance in /wiki/website-speed-guide.
What is the difference between a redirect chain and a redirect loop? #
A redirect chain has a beginning and an end: it passes through several intermediate URLs but eventually arrives at a real page returning a 200 status. A redirect loop, by contrast, never resolves, because the URLs point back at one another in a circle, A redirects to B and B redirects back to A, or a longer ring that closes on itself. A loop is a hard failure. Browsers detect it and display an error such as too many redirects, and crawlers abandon the URL, so the content becomes completely inaccessible. Loops most often arise from conflicting rules, for example an HTTPS redirect fighting a www redirect, or a CMS setting clashing with a server config. While a chain degrades performance and efficiency, a loop takes a page fully offline, which is why our /tools/website-down-checker treats a redirect loop as a critical availability problem rather than a mere optimization opportunity. Both are fixed by simplifying and reconciling the underlying redirect rules.
How do redirect chains form over time? #
Chains are almost always a byproduct of history rather than a single decision. Consider a typical local business site. In its first redesign, several old pages are redirected to new URLs. A couple of years later the business rebrands and moves to a new domain, so those already-redirected URLs get pointed onward again. Then the site enforces HTTPS, adding another automatic hop from the insecure version. Later, a trailing-slash normalization rule is introduced, tacking on yet another. None of these steps updated the earlier redirects to point at the newest destination, so each request now walks through the full accumulated history. Multiply this across hundreds of URLs and you have a web of chains that no one designed and few notice. The pattern is so common that any /services/website-migrations engagement begins by crawling existing redirects, because inheriting a predecessor's chains and then adding new ones is the fastest way to build a genuinely slow, hard-to-crawl site.
How do you find redirect chains? #
You find chains by crawling your site with a tool that records the full redirect path for every URL, not just the final destination. Desktop crawlers and cloud auditing platforms both report chains, showing each hop and its status code so you can see exactly where a request bounces. For spot checks on individual URLs, browser developer tools reveal the sequence of requests in the network tab, and command-line tools like curl with follow-redirects print every intermediate location. Search Console's crawl stats and coverage reports can hint at redirect problems at scale. Our own /tools/website-grader and /tools/broken-link-checker surface redirect issues alongside other technical findings, which is often the fastest starting point for a busy owner. The key is to audit periodically rather than once, because chains regenerate every time the site changes. Catching them early, before another layer of redirects is added on top, keeps the cleanup manageable instead of turning it into an archaeology project.
# -I fetches headers only, -L follows every redirect,
# and -s silences the progress meter.
curl -sIL https://example.com/old-page/ \
| grep -Ei 'HTTP/|location:'
# Sample output revealing a 3-hop chain:
# HTTP/1.1 301 Moved Permanently
# location: http://example.com/new-page/
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/new-page/
# HTTP/1.1 301 Moved Permanently
# location: https://www.example.com/new-page/
# HTTP/1.1 200 OK <-- final destinationHow do you fix a redirect chain? #
The fix for a chain is simple to state and worth the effort to execute: point every redirect directly at the final destination, collapsing the whole sequence into a single hop. Using the earlier example, instead of A to B to C, you rewrite the rule so A goes straight to C, and B also goes straight to C. This eliminates the intermediate stops for every future request. Start by exporting all your redirects, tracing each to its true endpoint, and rewriting the source rules to target that endpoint. At the same time, update your internal links so your own navigation points at the live URL rather than relying on a redirect to catch it, which removes internal hops entirely. Then reconcile conflicting rules, such as HTTPS and www normalization, so they resolve in one combined step rather than several. After cleanup, recrawl to confirm each old URL now returns a single redirect to a 200. Ongoing vigilance through /services/care-plans keeps new chains from silently reappearing.
How many redirects are too many? #
The honest answer is that the ideal number of hops is exactly one: a single redirect from the old URL to the final destination. Anything beyond that is a chain and should be flattened. Google has indicated its crawler will follow a limited number of consecutive redirects, on the order of ten, before giving up, so a chain that grows past that threshold risks having its destination never crawled or indexed. But you should not aim for nine hops just because ten is the ceiling. Each hop costs a round trip for users and a step for crawlers, and the risk of a broken link somewhere in the chain rises with length. Treat two or more hops as a defect to fix, not a tolerance to spend. On performance-sensitive local sites, where mobile visitors are often on slower connections, even a two-hop chain on a key landing page is worth collapsing, which is the standard our /services/conversion-optimization work applies to high-value pages.
How do redirect chains hurt local business sites? #
For a local business, the most valuable pages are usually service and location URLs that rank for high-intent searches, and these are exactly the pages that accumulate chains after every redesign or platform change. A prospect searching for an emergency plumber or an urgent dentist appointment is impatient, and a page hidden behind three redirects loads slower on mobile, which raises the chance they bounce to a competitor. Worse, if a chain grows long enough that crawlers stop following it, a page that once ranked can quietly drop out of the index, taking its local visibility with it. Because these sites change hands and platforms fairly often, they are prone to inheriting a previous developer's chains and stacking new ones on top. Teams building for high-urgency verticals such as /web-design-for-plumbers and /web-design-for-hvac-companies audit redirects at every handoff, pairing clean redirect maps with strong /services/local-seo so the pages customers need load in a single, fast hop.
FAQ
How many redirect hops will Google follow?
Googlebot follows up to roughly ten consecutive redirects for a single URL before giving up. A chain longer than that risks having its final destination never crawled or indexed. This is a ceiling, not a target; you should aim for a single hop, since every extra redirect costs performance and adds fragility.
Do redirect chains lose link equity?
Modern search engines pass ranking signals through 301 redirects even in a chain, so equity is not automatically lost hop by hop. However, longer chains add risk: a broken link or an exceeded hop limit can sever the path entirely, and the crawl inefficiency slows how signals are processed. Collapsing chains to one hop removes that risk.
What causes a redirect loop?
A redirect loop is caused by rules that point URLs back at each other in a circle, so the request never reaches a real page. Common triggers are conflicting HTTPS and www rules, a CMS setting clashing with a server config, or a misconfigured plugin. Browsers show a too-many-redirects error and the page becomes inaccessible.
How do I fix a redirect chain?
Trace each redirect to its final destination, then rewrite every rule in the chain to point directly at that endpoint, turning multiple hops into one. Also update your internal links to reference the live URL instead of an old redirected one. Recrawl afterward to confirm each URL now returns a single redirect to a 200 page.
Can redirect chains slow down my website?
Yes. Each hop in a chain is a separate network round trip that adds latency before the final page loads, an effect that compounds on slower mobile connections. On important landing pages this delay can raise bounce rates and nudge Core Web Vitals in the wrong direction, which is why collapsing chains improves both speed and user experience.
How often should I audit for redirect chains?
Audit after every site change that touches URLs, such as a redesign, migration, HTTPS enforcement, or platform switch, and then periodically as ongoing maintenance. Chains regenerate whenever new redirect rules stack on old ones, so a one-time cleanup is not enough. Regular crawls catch new chains while the cleanup is still small and manageable.
Was this helpful?