A redirect chain is a series of two or more redirects between the URL someone requests and the page they finally reach. For example, a link to http://example.com/services might redirect to https://example.com/services, which then redirects to https://www.example.com/services, which redirects again to https://www.example.com/our-services. That's three hops before the visitor sees anything.
For a business, redirect chains quietly slow down pages and make search engines work harder to reach your content. They usually build up over years of site redesigns, platform moves and URL changes. Each one is small, but together they can affect load times, crawling and how cleanly ranking signals move to your current pages.
What is a redirect chain?
A redirect sends a browser or crawler from one URL to another, usually with a 3xx HTTP status code such as 301 (moved permanently) or 302 (found, used for temporary moves). A single redirect is normal and often necessary. A chain happens when the destination of one redirect is itself redirected, so the request has to hop through several URLs before reaching a page that returns 200 OK.
Chains are almost never planned. They form when:
- A site moves from HTTP to HTTPS, then later from a non-www to a www domain, and each change adds its own rule
- A page is renamed more than once, and each old URL redirects to the next old URL instead of the newest one
- Trailing slash, uppercase or tracking-parameter rules stack on top of other redirects
- A CMS migration adds new redirect rules without cleaning up the old ones
A redirect loop is the extreme case, where URLs redirect back to each other and the request never reaches a final page.
Why redirect chains matter
They slow pages down. Google's web.dev guidance says redirects slow page load because each one requires the browser to make an additional HTTP request. Every hop adds time before the server can even start sending the final page, which pushes up Time to First Byte (TTFB) and the loading metrics that follow it.
They make crawling less efficient. Google's crawl budget documentation tells site owners to avoid long redirect chains, which have a negative effect on crawling. For small sites this is rarely a crisis. For large sites, every wasted request is time Googlebot isn't spending on new or updated pages. See crawl budget.
Long chains can stop crawlers entirely. Google's documentation says its crawlers follow up to 10 redirect hops by default, and some crawlers may use different limits. Past that point, Google won't reach the final content. Search Console's Page indexing report can show a "Redirect error" when a chain is too long or loops.
AI crawlers face the same hops. AI search tools and the crawlers that feed them also have to follow your redirects to reach your content. Short, direct paths are the safest way to make sure the version you want is the one they find.
How redirect chains work
What happens at each hop
When a browser requests a URL that redirects, the server sends back a 3xx code and a new location. The browser then makes a fresh request to that location. If that URL also redirects, the cycle repeats. Only when a URL returns real content does the page start loading. Google says that once it reaches the final destination, it processes that URL's content and ignores the content of the redirecting URLs.
Permanent and temporary hops
Google treats 301 and 308 redirects as a strong signal that the target should be the canonical URL, and 302 and 307 redirects as a weak signal. A chain that mixes types sends mixed messages about which URL is the real one. Google recommends permanent server-side redirects whenever possible when you move a page for good.
Same-origin and cross-origin chains
Some hops happen within your own domain, such as /services to /our-services. Others cross domains, such as an ad link that goes through a tracking domain before reaching your site. web.dev suggests focusing on same-origin redirects first, because those are fully in your control. It also gives a common example to avoid: an ad that links to an HTTP page, which then redirects to its HTTPS version.
How to fix redirect chains
- Crawl your site. Use a site crawler to list every internal URL that redirects and the full path each one takes. Most crawlers have a dedicated redirect chain report.
- Point every old URL straight to the final page. Update redirect rules so each legacy URL goes to its current destination in one hop, rather than passing through older URLs.
- Update internal links. Change menus, footers and in-content internal links to point to the final URL directly, so visitors and crawlers skip the redirect altogether.
- Clean up your sitemap and canonicals. Your XML sitemap and canonical tags should list final URLs that return 200, never URLs that redirect.
- Use HSTS for HTTPS. web.dev notes that the Strict-Transport-Security header enforces HTTPS on the first visit to an origin, which avoids HTTP to HTTPS redirects on later visits.
- Fix the links you control elsewhere. Update ads, email templates, social profiles and listings to use the final URL.
- Recheck after every migration. Redesigns and platform changes are when chains appear. Crawl again after launch.
Common mistakes and misconceptions
- "Google follows 10 hops, so a few hops are fine." The limit is a ceiling, not a target. Every hop still adds load time and wasted crawling.
- "Deleting old redirects cleans things up." Removing a redirect that still receives links or traffic breaks those visits. Shorten chains instead of deleting rules that are still used.
- "Redirecting everything to the homepage solves it." Sending old URLs to an unrelated page can be treated as a soft 404. Redirect to the closest matching page.
- "Internal links don't matter if redirects work." Links that point at redirecting URLs create avoidable hops on every click and every crawl.
Redirect chain vs. redirect loop
A redirect chain eventually reaches a working page, just slowly. A redirect loop never does: URL A redirects to URL B, which redirects back to A, or a longer cycle repeats forever. Browsers stop and show an error such as "too many redirects," and crawlers give up. Chains are a performance and efficiency problem. Loops are an outage for every affected URL and need fixing right away.
How Butter approaches redirect chains
At Butter, redirect chains are part of the indexing strategy work in our plans. We crawl the site, map every redirect path and collapse chains so each old URL lands on its final page in a single hop. We also update internal links, sitemaps and canonical tags so they point to final URLs.
We look hardest at the pages that matter most for leads and sales, and at URLs with outside links pointing to them, since those are the paths people and crawlers use most. After any redesign or migration, we check again before small chains can pile up.
Frequently asked questions
How many redirects is too many?
Aim for one hop at most between any linked URL and its final page. Google's crawlers follow up to 10 hops by default, but every extra hop adds load time and wasted crawling.
Do redirect chains hurt rankings?
A short chain on its own is unlikely to cause a big ranking drop, but chains slow pages and make crawling less efficient. If a chain goes past Google's hop limit or loops, Google can't reach the content at all.
How do I find redirect chains?
Run a site crawler that reports redirect paths, and check Search Console's Page indexing report for redirect errors. You can also test a single URL with a browser's developer tools by watching the network requests.
Should I use 301 or 302 redirects to fix a chain?
For pages that have moved for good, use a permanent redirect such as a 301 or 308. Google recommends permanent server-side redirects when you change a page's URL, and treats temporary ones as a weaker signal.