What Is a Redirect Chain? How to Find and Fix Redirect Chains and Loops

What is a redirect chain in SEO?

A redirect chain is a sequence of redirects where a URL passes through one or more intermediate URLs before it reaches its final destination. For example, if page A redirects to B and B redirects to C, you have a chain with two hops. Every extra hop slows visitors down and wastes crawler requests.

I have run technical SEO audits since 2012, and a redirect chain is one of the quiet problems I find on almost every older website. The site works, pages load, and nobody sees an error. Behind the scenes, however, each click travels through two, three or even five server responses. In this guide I explain how chains form, how they differ from loops, the official Googlebot hop limit, the impact on speed and crawling, and a step by step fix.

If you want to check a URL right now, paste it into our redirect checker. The tool lists every hop in order, together with its status code.

How does a redirect chain form?

A redirect chain rarely comes from one bad decision. Instead, it grows out of small changes that pile up over the years. Each change makes sense on its own; the trouble starts when old rules and new rules stack on top of each other. So nobody builds a chain on purpose, it simply accumulates as the site grows.

Also, teams change and the reasons behind old rules fade. A new developer hesitates to delete an old rule and adds a fresh one on top. As a result, the chain gains another link every year.

These are the scenarios I see most often in audits:

• Protocol and host layers: the http URL first goes to https, then to the non www version. One rule could do both jobs.
• Trailing slash: the server adds a slash, then another rule converts the path to lowercase.
• Stacked redesigns: a 2019 migration pointed the old URL to B, a 2023 migration pointed B to C, and nobody updated the rule for A.
• Plugin versus server: a CMS plugin applies one rule while the server configuration applies another.
• Short campaign links: a link shortener points to an old campaign URL, which then points to the new page.

In short, every layer adds a hop. Therefore, to fix the chain you need to know which layer wrote which rule.

What is the difference between a redirect chain and a redirect loop?

A redirect chain eventually reaches a destination; the path is just longer than it needs to be. A loop never arrives anywhere. Page A sends the request to B, B sends it back to A, and the cycle repeats. At some point the browser gives up and shows an error.

Chrome reports this as "ERR_TOO_MANY_REDIRECTS". In other words, a loop means the visitor never sees the page, while a chain still delivers it, only later. That is why a loop needs an urgent fix, whereas a chain needs a planned cleanup.

On the other hand, both problems can share a root cause. Conflicting rules may create a chain on some URLs and a loop on others. So when you find one, look for the other too.

In practice, I usually spot loops right after someone pushes a new rule live. For that reason, test the homepage, one category and one product page after every rule change.

How many redirects does Googlebot follow?

Google gives a clear number here. According to Google's documentation on HTTP status codes, Google's crawlers follow up to 10 redirect hops by default. The same page adds that crawlers for specific products may use different limits.

The documentation also stresses one detail: Google ignores any content it receives from the redirecting URL and processes only the final target. So whatever sits on the intermediate URLs does not matter; for Google, only the last stop counts.

So is a limit of 10 hops generous? On paper, yes; in practice, no. Google's site move guide says that although Googlebot can follow up to 10 hops, you should redirect to the final destination directly. If that is not possible, keep the chain short, ideally no more than 3 hops and fewer than 5.

The guide also gives the reason: chained redirects add latency for users, and not all user agents and browsers support long chains. Consequently, your target is not "below 10" but zero intermediate steps.

Let me make one point clear. The 10 hop limit describes a technical ceiling, not a comfort zone. A site that gets close to it already pays a price in speed and crawl cost.

Why do redirects matter even more for robots.txt?

Robots.txt follows its own rules when it comes to chains. According to Google's robots.txt documentation, Google follows at least five redirect hops for this file, then stops and treats it as a 404. When the file counts as a 404, Google assumes there are no crawl restrictions on the site.

That means if your robots.txt sits at the end of a long chain, none of your blocking rules may apply. Moreover, the same documentation says Google does not follow logical redirects for robots.txt, such as frames, JavaScript or meta refresh.

I see this trap most often after domain changes. The robots.txt on the old domain points to the new domain, and the new domain then adds another hop from http to https. As a result, the file ends up at the end of a chain.

So test the robots.txt URL for each main version: http, https, with www and without www. Ideally, the file on the canonical version returns 200 directly. If you need to rewrite the file, my article on common robots.txt mistakes covers the details.

How does a redirect chain affect page speed?

Every redirect forces the browser to send a new request and wait for a new response. If the hop crosses to another domain, a DNS lookup and a new secure connection come on top. The first byte of the page cannot arrive until the last link of the chain completes.

This delay feeds directly into time to first byte. When the first byte arrives late, metrics such as Largest Contentful Paint (LCP) slip as well. On mobile networks in particular, each extra round trip creates a wait that users notice.

Here is a concrete case. Old URLs in ad and email campaigns often carry the longest chains. A user clicks the ad and lands on the page two or three hops later, and some of them give up on the way. Also, if the redirect drops UTM parameters, your campaign tracking breaks too.

If you want to understand how speed affects rankings, read my article on how site speed affects SEO. There I cover measurement methods in detail.

For your own test, open the browser developer tools and check the first requests in the Network tab. Each 3xx row shows time spent before the page even starts loading. That way you see the cost of the chain in milliseconds.

How do redirect chains waste crawl budget?

Googlebot treats every hop in a chain as a separate request. So a chain with three hops means four requests for a single page. On a small site the difference looks trivial. On an online store with tens of thousands of URLs, however, the picture changes.

For example, when filter URLs, old category paths and product variants enter chains, a large share of crawl capacity goes to intermediate steps. Consequently, Google discovers new products and updated pages more slowly. If your server responds slowly, Google already reduces its crawl rate; chains add to that pressure.

In addition, every intermediate URL counts as a separate URL for Google. Google keeps these addresses in its queue and retries them from time to time. Therefore, every old rule you leave in place keeps showing up in your crawl logs for a long time.

To dig into crawl rate drops, read my article on why Googlebot crawls less. There I show how to read the Crawl Stats report step by step.

In short, on small sites a chain is mostly a speed issue. On large sites, it becomes both a speed issue and a discovery issue, so set your priorities by site size.

How do 301, 302, 307 and 308 codes change a chain?

The status code of each link in the chain affects which URL Google picks as canonical. According to Google's redirects documentation, permanent redirects signal that the target should become canonical. With temporary redirects, Googlebot follows the redirect, but the indexing pipeline does not use it as a canonical signal.

Mixed chains cause the most confusion. For instance, a path of 301, then 302, then 301 again sends Google mixed messages. So when you shorten a chain, review the code as well: if the content moved for good, a single 301 or 308 does the job.

Keep one more point in mind. Google handles 303 and 307 like 302, and 308 like 301. Still, the documentation notes that these codes mean different things and asks you to pick the right one for other clients. In other words, equal treatment by Google does not mean you can choose at random.

Why are meta refresh and JavaScript redirects risky?

The problem grows when a link in the chain runs inside the page instead of on the server. Google's order of preference is clear: server side redirects first, meta refresh if that is not possible, and JavaScript only as a last resort. The documentation says to use JavaScript redirects only if you cannot do server side or meta refresh redirects.

The reason is simple. To see a JavaScript redirect, Google has to render the page, and if rendering fails, the redirect may go unnoticed. Meanwhile, Google reads a delayed meta refresh as a temporary redirect, and an instant meta refresh as something close to a permanent one.

The mixed chain I meet most often in audits looks like this: the server sends a 301 to the new URL, then an old theme on that URL fires a JavaScript redirect to another page. In the browser everything looks fine. For the crawler, however, the last link stays uncertain.

In short, move every link of the chain to the server and, where possible, reduce it to a single hop. Treat in page redirects only as a stopgap when you have no server access.

Hosted platforms often limit server access. In that case, use the platform's own redirect manager and remove old redirect scripts from the theme code.

How do you find redirect errors in Search Console?

Search Console tells you directly when a chain breaks the limit. In the Page indexing report, URLs listed under the "Redirect error" reason come first. According to Google's report documentation, this reason covers one of these cases:

• A redirect chain that was too long
• A redirect loop
• A redirect URL that eventually exceeded the max URL length
• A bad or empty URL in the redirect chain

The same report also shows a "Page with redirect" reason. That is not an error; Google simply says the redirecting URL is non canonical and stays out of the index. However, if this list contains URLs that your internal links or sitemap still point to, you have found the starting point of a chain.

To inspect one specific URL, use the URL Inspection tool. It shows the canonical Google picked and the latest status of the page. If you are new to the tool, start with my Google Search Console guide.

How do you find a redirect chain on your site?

Search Console only reports cases that break the limit; to find chains with two or three hops, you need your own crawl. I always run detection in the same order:

1. Single URL check: test the suspect URL with the redirect checker. Note the code and target of every hop.
2. Main version test: try all four versions of your domain (http, https, with www, without www). Each one should reach the canonical version in one hop.
3. Site crawl: follow all internal links with a crawler and list every URL that returns 3xx. Check whether the tool shows chains in a separate report.
4. Broken link check: sometimes the chain ends in a 404. A broken link checker catches those cases.
5. External sources: add ad landing pages, email templates and social profile links to the list.

If you like the command line, curl gives you a quick test as well. That way you see each response header and its Location value in order. Still, for bulk work a crawler tool is far more practical.

Record every chain you find in one table: start URL, intermediate steps, final target and the code of each link. That table becomes the basis for the fix.

What do server logs reveal about redirect chains?

Crawl tools walk through your site the way you see it. Server logs, on the other hand, show what Googlebot actually requests. This difference matters, because Google keeps retrying old URLs it discovered years ago.

Filter the log file for Googlebot requests and move the 301, 302, 307 and 308 responses into a separate table. Then sort the redirecting URLs by request count. The URLs at the top of that list are the intermediate steps that consume most of your crawl capacity.

Also, if you see Googlebot walking the same chain again and again in short intervals, that rule deserves a high priority. Instead of reading the file by hand, you can use our log file analyzer, which groups bot requests and status codes.

Finally, do not run log analysis once and forget it. Repeat it after big changes, especially in the weeks after a migration or redesign. That way you catch new chains early.

On small sites, log access is not always easy. In that case the Crawl Stats report in Search Console makes a good alternative, since it also breaks requests down by response code.

How do you fix a redirect chain?

The core principle of fixing a redirect chain is simple: every old URL should reach the final target in a single hop. I follow these steps:

1. Map it out: write every redirecting URL and its final target into one table.
2. Flatten the rules: rewrite A→B→C as A→C and B→C. Do not delete the rule for B, because some links still point to B.
3. Pick the right code: use 301 or 308 for permanent moves.
4. Verify the target: make sure the final URL returns 200, carries no noindex and has a self referencing canonical tag.
5. Update internal links: point menu, body and footer links straight to the final URL.
6. Test again: recrawl the same list after the change.

If you struggle to find targets for old URLs, the redirect mapping tool makes the job easier. It matches old and new URL lists by similarity. Still, review every suggestion by hand, since automatic matching sometimes proposes an unrelated page.

Above all, avoid the habit of sending old products to the homepage. Google may treat redirects to irrelevant targets as soft 404s. The closest category or the replacement product makes a better target for users and crawlers alike.

Which server rule mistakes create chains?

Most chains come from server rules that someone wrote without knowing about the others. On Apache it is .htaccess, on Nginx the server blocks, and on the CMS side plugins, all touching the same URL at different moments. Watch for these mistakes in particular:

• Rule order: if the general rule (http to https) runs before the specific one, the specific rule adds a second hop.
• Relative targets: a target without protocol or host makes the server go through the default version first.
• Split normalization: three separate rules for https, www and the trailing slash produce three separate hops.
• Duplicate layers: the same redirect may exist in the CDN, on the server and in the CMS.
• Lost parameters: a rule that drops the query string may send a URL with parameters to the wrong target.

For that reason, I recommend keeping normalization rules in one place and always writing the target as a full URL. That way an http request with www reaches the canonical version in one hop. Back up the rule file before any change; one wrong rule can put the whole site into a loop.

Why should internal links and sitemaps point to the final URL?

Shortening the chain on the server is only half the work. The other half is making sure the site itself stops linking to redirecting URLs. After all, every internal link tells Googlebot that the address deserves a crawl.

If old URLs remain in the menu, the body or product cards, at least one hop stays no matter how clean your server rules are. Moreover, that hop repeats on every page view. For users it is a small delay; for crawlers it is constant waste.

For sitemaps, the rule is even clearer: list only canonical URLs that return 200. Leaving a redirecting URL in the sitemap sends Google a mixed signal. If you need to rebuild the file, the XML sitemap generator produces a clean list.

Also check your canonical tags. If a canonical tag points to a redirecting URL, you give Google two different messages at once. So internal links, the sitemap and the canonical tag should all meet at the same final URL.

On large sites, updating links by hand gets hard. That is why a bulk search and replace in the database is often the fastest route. Back up the database first.

How do you prevent redirect chains during a site migration?

The longest chains come from migrations that follow one another. For example, a site that first moved to HTTPS, then changed domains and finally switched platforms sends old URLs through three generations of rules. When you plan a new migration, map not only today's URLs but every URL you redirected in the past. Otherwise, you add a new link to the end of an old chain.

My approach looks like this. Before the migration I export every existing redirect rule. Then I set the final target on the new site for each old URL, one by one. As a result, even a URL from years ago reaches the new site in a single hop.

In addition, I crawl the redirect list in a staging environment before launch day. If I see a loop or a three hop chain, I fix it before going live. After launch, I watch the logs and Search Console daily for the first two weeks.

For a full list covering the whole migration process, read my website migration SEO checklist. There I go through domain, HTTPS, platform and URL structure changes one type at a time.

How long should you keep old redirects?

When you shorten a chain, you may feel tempted to delete the old rules. However, Google's site move guide recommends keeping redirects for as long as possible, generally at least one year. That period lets Google recrawl the new URLs and reassign links from other sites to them.

So the answer is to flatten the rules, not delete them. If you remove the rule for B in an A→B→C chain, sites that link to B show a 404. Instead, point both A and B straight to C.

In practice, I keep redirects for URLs with external backlinks much longer. An old news link to a valuable page can still bring visitors years later. By contrast, cleaning up intermediate URLs with no links and no traffic after a year usually carries little risk.

When you make this call, look at the logs and at backlink data. That way the decision rests on data, not on guesswork.

Also note the date you removed each rule in a change log. If 404 errors rise a few weeks later, you find the cause right away.

A short checklist for regular redirect audits

You do not clean up redirect chains once and for all; every new campaign, category change or plugin update can create a new one. So I recommend these checks every quarter:

• Do all four main versions of the domain reach the canonical URL in one hop?
• Do robots.txt and the sitemap return 200 directly?
• Does a site crawl show any URL with two or more hops?
• Has the number of "Redirect error" URLs in Search Console grown?
• Which redirecting URLs does Googlebot request most in the logs?
• Do ad and email landing URLs go straight to the final page?
• Do canonical tags and internal links point to the final URL?

I log these checks in a table and compare them every quarter. That way you see at a glance whether the problem grows. For other technical areas, see my list of technical SEO tips.

How does my team handle redirect cleanups?

In technical SEO projects, redirect cleanup is one of the tasks that delivers fast, measurable results. My team and I always start with data: a site crawl, log analysis and the Search Console report. Then we collect every rule in a single map and flatten the chains.

The slowest part is rarely the technical fix. Instead, it is understanding why someone wrote each old rule in the first place. So before we delete any rule, we review its traffic, its backlinks and its business meaning together.

We test changes in staging first, then push them live. After that, we monitor the logs and the indexing report for several weeks. I remain responsible for strategy and results, while experienced specialists on my team handle the implementation.

If you want a similar audit for your site, reach us through our SEO consulting page. If you prefer to work on your own, the steps in this guide and our free tools give you a solid start.