Redirect Chains and Loops: How to Find and Fix Them

Redirect chains happen when a URL reaches its final destination through two or more redirects instead of one. A redirect loop is worse: the redirects point back at each other and the request never lands on a page at all. Both usually build up from small rules added over years.

This guide is about the chains and loops that accumulate on a live site, outside of any formal migration project. If you are planning a full move, our guide to preserving backlink value during a site migration covers that process. Here we focus on how chains form, how to find them, and the order in which to update internal links, sitemaps and backlink targets to the final URL.

What Redirect Chains and Loops Are

A redirect is the server saying "the content you want lives at another address". A single-hop redirect is healthy: the old URL goes straight to the new one. A chain splits that journey into several stops: A redirects to B, B to C, and C to the final page D. The browser or crawler has to make a fresh request at every stop.

A loop is a chain that circles back on itself: A redirects to B, and B redirects to A. There is no final page, so the request bounces until the browser or bot gives up.

Keeping three states apart makes diagnosis easier:

• Single hop: the source URL goes directly to a final page that returns 200. This is the target state.
• Chain: the source passes through at least one intermediate redirect before reaching the final page. It works, but every extra hop adds latency and another point of failure.
• Loop: the redirects circle and the page never loads. Users and search engines both hit a dead end.

Chains are easy to miss because they appear to work; they surface only when they grow long, a hop breaks or someone audits them.

How Chains Form: Protocol, Host and Trailing Slash Rules

Most chains are the result of independent rules firing one after another. Three sources account for the bulk of them:

1. Protocol: a rule that sends HTTP requests to HTTPS.
2. Host: a rule that sends the bare domain to www, or the other way round.
3. URL format: a rule that adds or strips a trailing slash, or lowercases the path.

Written separately, these rules turn one old link (http, no www, no trailing slash) into three hops. Add a content redirect because the page itself moved, and you are at four.

Imagine a fictional B2B software company. Its product pages started under /features/. A rebrand moved them to /product/, and the old URLs were redirected. Two years later, the site moved to HTTPS and standardized on www. Then a new information architecture put everything under /platform/, with each move redirecting only the previous URL to the new one. A link a partner published years ago now passes through five redirects before reaching the live page. None of the rules is wrong on its own. The problem is that nobody ever reviewed them together.

Redirect Types: 301, 302, 307 and 308

Choosing the right redirect type also decides which code you use when you clean chains up. Google's documentation on redirects and Google Search (Opens in a new tab) sorts redirects into two groups:

• Permanent: 301 (moved permanently) and 308 (moved permanently). Google uses a permanent redirect as a signal that the target should be canonical.
• Temporary: 302 (found) and 307 (temporary redirect). Google does not use a temporary redirect as a signal that the target should be canonical, and the source page is typically the one shown in results.

Google's HTTP status code documentation adds that a 301 is a strong signal that the redirect target should be processed and a 302 a weak one, that 307 is equivalent to 302 and 308 to 301, and that the codes are semantically different, so the appropriate one should be used.

The practical rule follows: use 301 or 308 for permanent moves and 302 or 307 only for genuinely temporary ones. Old absolutes like "a 302 passes no value" do not match how Google currently describes these codes; the meaningful difference is which URL Google treats as canonical. During cleanup, watch for temporary redirects that quietly became permanent. Replace them with permanent redirects that go straight to the final URL. Google also recommends using JavaScript redirects only when server-side or meta refresh redirects are not possible.

How Redirect Chains Affect Crawling, Speed and Users

Chains affect three things: crawling, speed and the people using your site.

Crawling. According to Google's documentation on HTTP status codes (Opens in a new tab), Google's crawlers follow up to 10 redirect hops by default. The Page indexing report lists a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the maximum URL length and a bad or empty URL in the chain among the causes of a redirect error. Even well below that limit, every hop is an extra request that draws on the crawl effort Google spends on your site.

Speed. Each redirect means the browser sends a new request and waits for another response. Google's site move documentation notes that chains add latency for users and that not all browsers support long chains.

Users and maintenance. The longer the chain, the more likely one hop breaks.

Chains also have an internal dimension. When links inside your own site point to redirected URLs, every click and every crawl generates an unnecessary hop. As we discuss in our article on internal linking strategy and its SEO impact, internal links that go straight to the final page simplify both navigation and crawling.

Redirect Loops and the Symptoms in a Browser

A loop is the most severe form of chain because the page never loads. Browsers such as Chrome show an error along the lines of "ERR_TOO_MANY_REDIRECTS" with a message that the page redirected you too many times. On the search side, the Page indexing report in Search Console counts a redirect loop under the "Redirect error" reason.

The usual causes are:

• Conflicting host rules: the server redirects to www while a CMS setting redirects to the bare domain.
• Protocol mismatch: a CDN or load balancer passes HTTPS traffic to the origin as HTTP, and the origin redirects it back to HTTPS, forever.
• Trailing slash rules: one rule adds a slash, another removes it.
• Reciprocal content redirects: two pages redirect to each other, often after a half-finished rollback.
• Session or language redirects: cookie or locale detection that re-triggers itself under certain conditions.

The first diagnostic step is seeing each hop. A command-line request that prints response headers, or the network tab in browser developer tools, shows the status code and Location header returned at every step. Google's Page indexing help suggests using a web debugging tool such as Lighthouse for more detail on a redirect. Because a loop in a sitewide rule can take the whole site offline, test changes to protocol and host rules in a staging environment before release.

Finding Chains with a Crawler and Server Logs

There are two complementary ways to find chains. A crawler shows how your site is structured today; server logs show the paths real requests actually take.

Finding chains with a crawler

A desktop or cloud SEO crawler records every redirect it meets while following internal links, and most tools list chains in a dedicated report with the source URL, each hop and the final URL. Do not rely on the site crawl alone; feed the crawler these URL lists as well:

• Every URL in your sitemaps.
• Linked-to URLs exported from your backlink tool.
• Every source URL in your redirect map.
• Protocol and host variants of your start URL: http, https, with and without www.

Finding chains in server logs

Logs show which redirected URLs Googlebot and users actually request, and how often. Filtering for 3xx responses and sorting source URLs by request volume tells you which chains to fix first. If the crawler reports a chain but the logs show no requests for it, it can wait. For methods of reading log data with an SEO lens, see our guide to server log analysis for SEO.

Updating Internal Links and Sitemaps to the Final URL

Breaking a chain takes two moves, and you need both: collapse redirect rules into a single hop, and fix links that point to redirected URLs at the source. Start with the links you control, because those fixes are fastest and safest.

A sensible order for internal links:

1. Template links: navigation, footer, breadcrumbs and category cards. One template fix corrects thousands of links at once.
2. In-content links: links added by hand inside articles and product descriptions. A database search and bulk replace usually works; take a backup first.
3. Canonical and hreflang values: if these point to a redirected URL, replace it with the final one.
4. Sitemaps: list only final URLs that return 200. Google's site move documentation also asks you to make sure sitemaps are updated with the new URLs.

For a full checklist on removing redirected and erroring URLs from sitemaps, use our XML sitemap audit and error fixes guide.

Once these updates are done, return to the redirect rules themselves and rewrite every source URL to point straight at the final URL rather than at an intermediate one. That way old external links and any internal links you missed still reach their destination in one hop.

Managing Redirects on URLs That Earn Backlinks

URLs that have earned external links are the most sensitive part of redirect management, because you do not control where those links come from. Every URL change leaves a backlink one more hop behind.

Apply these principles to backlinked URLs:

• Redirect the linked URL straight to the final URL. The old address a backlink points to should reach the live page through a single permanent redirect.
• Make sure the target is a topical match. Choose a final page that genuinely replaces the old content; redirecting to an unrelated page throws away the context the link provided.
• Ask for the link itself to be updated where possible. You can ask the linking publisher to change the URL to the final address. That change is entirely up to the publisher, and not every publisher will agree.
• Track lost links separately. Links pointing to URLs whose redirects broke, or that now return 404, need to be recovered.

For a structured approach to recovering broken or misdirected backlinks, read our guide to link reclamation and recovering lost backlinks.

For new links, prevent the problem up front: confirm that every target URL is a permanent, final address and plan for it not to change during the campaign. Our article on distributing backlink target URLs across a package builds that check into planning.

Keeping Server and CMS Rules in Order

The long-term fix is order in your redirect rules. When rules are split between server configuration, a CMS plugin, a CDN and application code, nobody knows exactly which fires first, and conflicts become inevitable.

These principles keep things manageable:

• One source of truth: keep content redirects in a single layer where possible. Protocol and host rules can live at the server or CDN, content redirects in one map.
• One combined normalization rule: merge protocol, host and trailing slash handling into a single rule so every variant reaches the canonical address in one hop.
• Rule order: evaluate specific content redirects before general rules, and point them directly at final URLs.
• Change log: record who added each rule, why and when.
• Testing: test rule changes against a sample URL list before release, with particular attention to loops in sitewide rules.

CMS plugins need extra attention. Many create a redirect automatically whenever a page's URL changes. If a page changes URL several times, each change adds a hop. Check whether your plugin rewrites older rules to the new target or simply stacks a new one on top.

Maintaining the Redirect Map Over Time

A redirect map lists where every source URL ends up. Built once for a migration and then forgotten, it becomes the single biggest source of chains.

A simple routine keeps it current:

1. Update the map with every URL change. When you add a rule, also repoint every existing entry that targeted the old URL.
2. Flatten periodically. At regular intervals, crawl every source URL in the map and collapse anything with more than one hop.
3. Verify targets. Check that every final URL in the map still returns 200; a deleted target is a new broken chain.
4. Record removals. Before deleting a rule, check the logs for requests to the source URL and whether it has external links.

On how long to keep rules, Google's guide to site moves with URL changes (Opens in a new tab) recommends keeping redirects for at least a year, and longer if possible, adding that from a user's perspective they could be kept indefinitely. The same guide recommends redirecting to the final destination directly and, where that is not possible, keeping chains short: ideally no more than 3 hops and fewer than 5. For URLs with external links, keeping redirects in place for the long term is a low-cost, low-risk choice for most sites.

Sample Template: Redirect Chain Fix Table

The sample template below records, for each source URL found in a chain audit, its current path, final URL and the action to take. URLs and hop counts are illustrative values.

Adding a "last checked" column and an owner turns periodic flattening into a routine you can actually track.

Frequently Asked Questions

How many hops count as a redirect chain?

Any path with more than one redirect before the final page is a chain. Google's crawlers follow up to 10 hops by default, while Google's site move guide recommends keeping chains to ideally no more than 3 hops and fewer than 5. The goal is always a single hop.

Does a 302 redirect pass link value?

Google describes a 302 as a weak signal that the redirect target should be processed, and with temporary redirects the source page is typically the one shown in results. So a flat claim that "302s pass no value" is not accurate; the real difference concerns canonical selection. If a move is permanent, a 301 or 308 states your intent clearly.

Can a redirect loop affect the whole site?

It depends on where the loop comes from. Two pages redirecting to each other only affect those pages, but a loop caused by a sitewide protocol or host rule can make the entire site unreachable. That is why sitewide rule changes should be tested in staging first.

When can old redirects be removed?

Google's site move guide recommends keeping redirects for at least a year, and longer if possible. Before removing one, check the logs for ongoing requests and whether the source URL has external links. For backlinked URLs, keeping the redirect long term is usually the safer choice.

Does moving from HTTP to HTTPS create chains?

Yes, if protocol and host rules are written separately. An HTTP to HTTPS rule followed by a bare domain to www rule creates a two-hop chain for old links. Combine them into one rule so every variant goes straight to the canonical address.

What should I do when a backlinked URL changes?

Send the old URL directly to the new final URL with a single permanent redirect and update your redirect map. Where possible, ask the linking publisher to change the link to the new address; that is their decision to make. Then check periodically that the link still resolves correctly.

Conclusion and Next Step

Redirect chains and loops are the residue of every change your site has been through. Rules that look harmless one by one gradually turn into structures that waste crawl effort, slow pages down and sometimes take them offline. The fix order is clear: update internal links, canonicals and sitemaps you control to the final URL, collapse rules into single hops, point backlinked URLs straight at their destination, and treat the redirect map as a living document.

Clean, permanent target URLs that load in one hop are also a solid base for new link building. With that groundwork done, explore our backlink packages that fit your target URL plan, and note in your order that links should point directly at the final, permanent address.