Redirect Errors, Chains & Loops: How to Find and Fix Them

A redirect sends a request for one URL to another. It fails as an SEO tool in four ways: it points to a destination that is irrelevant or broken, it passes through too many intermediate hops, it loops back on itself, or it uses a type (temporary vs permanent) that sends the wrong signal. Each of these has a distinct symptom and a distinct fix, and the fix for one can create another: collapsing a chain onto the wrong destination trades a slow redirect for an irrelevant one.

How Google treats redirect types

Google’s documentation on HTTP status codes describes the server-side redirect codes this way (Google’s HTTP status code documentation):

Google’s redirects guide adds the canonicalization effect: for a permanent redirect, “the indexing pipeline uses the redirect as a signal that the redirect target should be canonical”; for a temporary one, it does not (Google’s redirects guide). Google notes the codes are semantically different even where it treats them the same, and recommends using the code that matches the situation.

Server-side redirects are Google’s preferred method. Its guide also lists meta refresh redirects and JavaScript location redirects, and says to use JavaScript redirects only if server-side or meta refresh redirects are not possible.

On link value, Google’s site move guide states: “301 and other permanent redirects don’t cause a loss in PageRank” (moving a site with URL changes).

Chains

A chain is a redirect that leads to another redirect: A to B to C. Chains build up over time as sites migrate repeatedly and old redirects are left pointing at URLs that later moved again.

Google’s documentation says its crawlers “follow up to 10 redirect hops” by default, though specific crawlers can differ. It also notes that Google’s inspection tools do not follow redirects at all. Beyond the hop limit, Google’s Page indexing report lists “a redirect chain that was too long” as a redirect error.

Even when a chain stays under the limit, every hop adds a request for users and crawlers, and a single broken hop breaks the whole chain. The fix is to point every old URL directly at the final destination.

Loops

A loop is a chain that returns to a URL already in it: A to B to A. Browsers stop with a “too many redirects” error, and Google’s Page indexing report lists “a redirect loop” as a redirect error. Loops come from conflicting rules, for example:

• a rule forcing a trailing slash and another removing it;
• an HTTP-to-HTTPS rule at the server and an HTTPS-to-HTTP rule in the CMS;
• www and non-www rules in different layers (CDN and origin) pointing at each other;
• a redirect from a page to itself with a parameter added and then stripped.

Other redirect errors Google reports

Google’s Page indexing report groups redirect errors as: a chain that was too long, a redirect loop, a redirect URL that eventually exceeded the maximum URL length, and a bad or empty URL in the redirect chain (Page indexing report help). URLs that redirect correctly appear separately as “Page with redirect”, which is not an error: Google says such a URL “will not be indexed” while its target may or may not be.

Irrelevant destinations

A technically clean redirect can still be wrong. Google’s site move guide warns: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error”. A removed product redirected to the home page looks to Google like a missing page with a 200 response. Redirect to the closest equivalent; if no equivalent exists, a 404 or 410 is the honest answer.

How to find chains and loops

1. Check one URL from the command line.

curl -sIL https://example.com/old-page

-I shows headers, -L follows redirects. Each HTTP/ line is a hop; the location: lines show where each hop points. A loop ends with curl’s maximum-redirects error. -I sends a HEAD request, and some servers or CDNs answer HEAD differently from GET; if the result looks wrong, repeat the check with a GET request: curl -sL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}n' https://example.com/old-page.

1. Crawl the site with a crawler that records redirect chains, then export chains longer than one hop and every loop.
2. Check internal links. Links pointing to redirecting URLs create unnecessary hops on every visit. Export internal links whose target returns 3xx.
3. Check the sitemap. Redirecting URLs do not belong in it.
4. Read the Page indexing report for “Redirect error” and inspect example URLs.
5. Check server logs for repeated 3xx responses to Googlebot on the same URLs.

A troubleshooting decision tree

1. Does the URL redirect at all?

• No, but it should (content moved): add a permanent server-side redirect to the new URL.
• Yes: continue.

2. Is the destination relevant and live (200)?

• No, the destination is unrelated: redirect to a relevant equivalent or return 404/410.
• No, the destination is broken: fix the destination or point the redirect to a live equivalent.
• Yes: continue.

3. Is it a single hop?

• No: update the first URL to point directly at the final destination; update internal links and sitemaps to the final URL.
• Yes: continue.

4. Is the type right?

• Permanent move with 302 or 307: change to 301 or 308 so the target is treated as canonical.
• Temporary situation (maintenance, short promotion) with 301: change to 302 or 307 so the original URL keeps its place. Google’s guide gives the example of a temporarily unavailable service redirected to an explanation page “without compromising the original URL in search results”.
• Correct type: continue.

5. Is it a loop?

• Yes: list every rule layer (CDN, load balancer, web server, application, CMS plugin), find the two rules that undo each other, and keep the rule in one layer only.

6. Do protocol and host rules agree?

• Make sure HTTP to HTTPS and non-www to www (or the reverse) happen in one hop, not two consecutive redirects.

Collapsing a three-hop redirect chain

Picture a site that moved from HTTP to HTTPS in 2022 and restructured its URLs in 2025.

• Finding: http://example.com/blog/post-1 returns 301 to https://example.com/blog/post-1, which returns 301 to https://www.example.com/blog/post-1/, which returns 301 to https://www.example.com/articles/post-1/. Three hops.
• Fix: add a rule mapping the original HTTP URL straight to https://www.example.com/articles/post-1/, and point each intermediate URL in the old chain to the same final URL, since external links may still use any of them; update internal links that still point at /blog/ URLs; remove /blog/ URLs from the sitemap.
• Check: confirm that curl -sIL shows one hop; after a recrawl, check that the Page indexing report lists the old URL as “Page with redirect” and the new URL as indexed.
• Keep in place: the old redirects must stay in place; Google’s site move guide recommends keeping redirects “generally at least 1 year”, and from a user’s perspective, indefinitely.

Preventing new chains

• Keep one redirect map, in one layer, with an owner.
• After every migration, rewrite older rules to point to the newest destinations.
• Update internal links to final URLs instead of relying on redirects.
• Test redirects before launch, including protocol and host variants.

A redirect does one job: send people and crawlers from a URL that no longer applies to the one that does, in a single step, with the right status code. Every chain, loop or irrelevant destination is a deviation from that job, and each one has a direct fix.