A redirect chain occurs when a URL redirects to a second URL that also redirects (rather than resolving to a final page directly), creating a sequence of hops that dilutes link equity, slows page load for users, and wastes Googlebot crawl budget.
Quick Answer
A redirect chain occurs when a URL redirects to a second URL that also redirects (rather than resolving to a final page directly), creating a sequence of hops that dilutes link equity, slows page load for users, and wastes Googlebot crawl budget.
Each redirect hop dilutes PageRank by ~15% and adds 100-500ms latency — a 3-hop chain delivers 72% of link equity and is meaningfully slower than a direct redirect.
Fix chains by updating the source URL to point directly to the final destination, bypassing all intermediate URLs.
Common chain sources: overlapping HTTP→HTTPS, www→non-www, and URL slug rename redirects that weren't consolidated.
Key Takeaways
Each redirect hop dilutes PageRank by ~15% and adds 100-500ms latency — a 3-hop chain delivers 72% of link equity and is meaningfully slower than a direct redirect.
Fix chains by updating the source URL to point directly to the final destination, bypassing all intermediate URLs.
Common chain sources: overlapping HTTP→HTTPS, www→non-www, and URL slug rename redirects that weren't consolidated.
How Redirect Chain Works
A redirect chain is a series of HTTP redirects where URL A redirects to URL B, which then redirects to URL C, which may redirect further before reaching the final destination. Each hop in the chain has a cost: each redirect requires an additional HTTP round-trip (adding 100-500ms latency per hop for users), PageRank loses approximately 15% with each hop (a 3-hop chain delivers roughly 72% of the original link equity to the final URL), and Googlebot has a crawl budget limit — pages behind redirect chains are crawled less frequently than direct pages because Googlebot may not follow chains beyond 3-5 hops.
Why Redirect Chain Matters for B2B Marketing
The most common causes of redirect chains: URL migrations where old URLs were redirected to intermediate URLs that were later renamed; HTTP to HTTPS migrations that left HTTP→HTTP redirect rules alongside HTTPS→www redirects; platform migrations where old redirects were preserved alongside new content management redirects; and inconsistent URL canonicalization (trailing slash vs. no-trailing-slash combined with www vs. non-www redirect rules). Each redirect type solves a problem in isolation but creates chains when combined without cleaning up the accumulated redirect history.
Redirect Chain: Best Practices & Strategic Application
Detection is straightforward using Screaming Frog (free up to 500 URLs): crawl your site and filter by "Redirect Chains" in the Response Codes section. The tool shows every URL with 2+ hops and the full chain sequence. Ahrefs Site Audit and Semrush also surface redirect chains. The benchmark: any URL accessible to Google should resolve in 1 hop (2xx) or at most 1 redirect hop to its canonical final URL. Chains of 3 or more hops should be treated as bugs.
Agency Perspective: Redirect Chain in Practice
Fixing redirect chains requires updating each intermediate redirect to point directly to the final destination URL. If URL A → URL B → URL C is the chain, the fix is URL A → URL C (bypassing B entirely). This preserves all link equity in a single hop. On WordPress, redirect management plugins (Rank Math Redirections, Redirection) allow bulk editing of redirect rules. For hardcoded .htaccess or Nginx redirects, update the rule source URL to point directly to the final destination and remove intermediary redirects that are no longer entry points. After fixing, verify with Screaming Frog that all formerly-chained URLs now resolve in a single 301.
Frequently Asked Questions: Redirect Chain
A redirect chain occurs when a URL redirects to a second URL that also redirects (rather than resolving to a final page directly), creating a sequence of hops that dilutes link equity, slows page load for users, and wastes Googlebot crawl budget.
The ideal is zero redirects for pages you want indexed — each redirect adds latency and loses link equity. In practice, single-hop 301 redirects are acceptable and have minimal impact. Two-hop chains begin to meaningfully dilute link equity and add latency. Chains of 3 or more hops should be consolidated to a single hop. Google's documentation suggests Googlebot may not follow chains beyond 5 hops, though in practice the crawl cost begins degrading well before that limit.
Yes — each redirect requires an additional DNS lookup and TCP handshake, adding 100-500ms of latency per hop on typical connections. A 3-hop chain adds 300ms-1.5 seconds before any content begins loading. For mobile users on slower connections, redirect chains can add several seconds to time-to-first-byte. This directly impacts Core Web Vitals (LCP) scores and user experience metrics that Google weighs in page experience signals.
Screaming Frog is the most efficient tool: download the free version, crawl your site, then filter Response Codes by "3xx" and use the "Redirect Chains" report. Each chain is shown with the complete sequence of hops. Online tools like httpstatus.io allow checking individual URLs for redirect chains without a full site crawl. For sites over 500 URLs, Ahrefs Site Audit or Semrush automatically detects and reports redirect chains as part of their technical audit modules.
MV3 Marketing helps B2B companies apply these strategies to drive measurable pipeline growth. Our team executes our services for technology, SaaS, and professional services companies.
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked