Internal URL Part of Chained Redirect Loop: How to Fix It

What a chained redirect loop actually is

A redirect loop happens when a URL sends a crawler or browser on a journey through several intermediate hops that, instead of arriving at a stable destination, circles back to a URL it has already visited. A simple loop is A redirects to B, and B redirects back to A. A chained loop is sneakier: A goes to B, B goes to C, C goes to D, and D points back to B. The first hop looks perfectly normal, so the problem hides several steps deep where a quick manual check rarely reaches.

When SEO ProCheck flags an internal URL as "Part of Chained Redirect Loop," it means that URL sits inside a redirect sequence that never resolves to a single final response with a 200 status code. The page at the end of the chain is effectively unreachable, which means search engines cannot fetch its content, cannot index it, and cannot pass link equity through it.

Why crawlers abandon them: hop limits

Crawlers do not follow redirects forever. They enforce a hard ceiling on how many hops they will chase before they give up. According to Google Search Central, Googlebot follows up to 10 redirect hops in a single chain. If the destination has not resolved by then, Googlebot stops and treats the fetch as an error. Google explicitly recommends keeping chains short, ideally no more than 3 redirects and fewer than 5, because long chains hurt crawling and waste crawl budget.

A loop is the worst case of all. Because the chain never terminates, the crawler is guaranteed to hit the hop limit on every single attempt. The page is dropped from the index, internal link signals dead-end, and any external links pointing into that chain leak their value into nowhere. On large sites this also burns crawl budget that should be spent on pages you actually want indexed.

How a loop differs from a simple chain

A plain redirect chain (A to B to C) is inefficient but it does eventually resolve to a final 200 page, so the destination can still be indexed, just with wasted hops and diluted equity. A loop never resolves. The distinction matters when you triage issues: a chain is a tidy-up job, but a loop is a hard blocker that removes the page from search entirely. In a crawler's redirect report, the giveaway is a Redirect Loop = True flag, which means one of the hops points back to a URL already seen earlier in the same chain.

Common causes

Loops almost always come from two redirect systems fighting each other. The usual suspects:

Conflicting rewrite rules. One .htaccess rule forces HTTPS, another forces a trailing slash, and a third strips www. If their conditions overlap, request A is rewritten to B, then a later rule rewrites B back toward A.

Plugin and server both redirecting. A WordPress redirect plugin (or the canonical logic in WordPress core) points the old URL to a new one, while a server-level rule sends the new URL back to the old one. Neither side knows the other exists, so the request bounces between them.

Stale migration rules. Leftover redirects from an old site move that were never removed after the structure changed again, creating an accidental cycle.

How to diagnose

Start at the command line. curl -IL follows every hop and prints each status code and Location header in order, so you can watch the exact path the request takes and spot where it returns to a URL it already visited.

curl -IL https://seoprocheck.com/old-page/

HTTP/1.1 301 Moved Permanently
Location: https://seoprocheck.com/new-page/

HTTP/1.1 301 Moved Permanently
Location: https://seoprocheck.com/new-page

HTTP/1.1 301 Moved Permanently
Location: https://seoprocheck.com/new-page/
<-- back to a URL already seen: this is the loop

For a site-wide view, run a crawler. In Screaming Frog, the loop surfaces under Reports > Redirects > Redirect Chains; filter the Loop column to True to isolate every chain that cycles back on itself. The report shows the start URL, each hop, the number of redirects, the chain type, and the final indexability, so you can see the entire path at a glance instead of guessing hop by hop.

How to fix

The goal is one hop. Every URL in the chain should redirect once, with a single 301, straight to the final live destination that returns 200. Do not point each hop to the next link in the chain; point every old URL directly at the end of the line.

First, decide which canonical form wins (HTTPS, with or without www, with or without a trailing slash) and apply it consistently. Then remove the conflicting rules. If a plugin and the server are both redirecting, pick one system to own redirects and disable the other's overlapping rule. A clean .htaccess looks like this:

# One canonical: HTTPS + non-www + final path
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://seoprocheck.com%{REQUEST_URI} [R=301,L]

# Single direct hop for the moved page
RewriteRule ^old-page/?$ https://seoprocheck.com/new-page/ [R=301,L]

After editing, re-run curl -IL on the original URL. You should see exactly one 301 followed by a single 200. Re-crawl to confirm the Loop flag is gone, then request indexing for the final URL in Search Console.

Common mistakes

Watch out for these, each of which can quietly recreate the loop:

Pointing each hop to the next URL instead of the final one, which just shortens the chain rather than collapsing it. Leaving both the plugin rule and the server rule active "to be safe," which is exactly what causes the conflict. Mixing 302s into the chain, which signals impermanence and keeps both URLs in contention. And testing only in a browser, where aggressive redirect caching can mask the loop; always verify with a fresh curl -IL or an incognito session.