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

What this check flags

This audit hint fires when an internal page URL sits inside a chained redirect that eventually circles back to where it started. Instead of a clean hop from an old address to a live page, the crawler follows URL A to URL B, B to C, and C right back to A. The request never reaches a 200 response, so the URL never resolves to actual content. Note that this is the page-level version of the problem: a separate check covers resource files such as scripts, stylesheets and images caught in loops. Here we are talking about pages that your internal links, sitemaps or menus point to, which makes the damage far more direct.

Why it matters for SEO

A looping page is effectively dead to search engines. Googlebot will follow a limited number of redirect hops (up to ten) before giving up; when the hops form a loop, it abandons the URL and reports it under Redirect error in the Page indexing report of Google Search Console. The page cannot be crawled, cannot be rendered and cannot be indexed, no matter how good the content behind it would have been.

There is a link equity cost too. Every internal link pointing into the loop passes PageRank toward a destination that never exists. That authority is simply wasted instead of strengthening a live page. And users hit the same wall: browsers detect the cycle and throw an error such as ERR_TOO_MANY_REDIRECTS or a "this page redirected you too many times" message, which is a hard dead end for anyone clicking through from your navigation or from an old bookmark.

What causes redirect loops

Conflicting rules across layers

Redirects can be issued by the CDN, the server config (.htaccess or nginx), a CMS plugin and the application itself. When two layers disagree, for example the server forcing a trailing slash while a plugin strips it, each one "corrects" the other forever.

Migration maps that point both ways

After a site migration or URL restructure, it is common to find an old map sending old-URL to new-URL while a later cleanup rule sends new-URL back to old-URL. Each rule looked correct when it was written; together they form a perfect loop.

Normalization rules fighting each other

Lowercase enforcement, trailing-slash policies, www and HTTPS canonicalization can collide. A rule that lowercases the path can hand off to a rule that redirects to a mixed-case canonical, which gets lowercased again, and so on.

How to diagnose it

The fastest way to see the loop is a curl trace that follows redirects and prints each hop:

$ curl -IL https://example.com/services/audit
HTTP/1.1 301 Moved Permanently
location: https://example.com/seo-audit/

HTTP/1.1 301 Moved Permanently
location: https://example.com/audits/seo/

HTTP/1.1 301 Moved Permanently
location: https://example.com/services/audit

curl: (47) Maximum (50) redirects followed

The final line is the giveaway: curl gave up because the chain never terminated, and the last location header points back to the URL you started with. Cross-check in Google Search Console with the URL Inspection tool; a looping URL typically shows as not indexed with a redirect-related failure, and the Page indexing report will list it under Redirect error. Your crawler report completes the picture by showing which internal pages still link into the loop.

How to fix it

Work through the loop methodically rather than deleting rules at random:

1. Map the loop. Use the curl trace to write down every URL in the cycle and identify which layer (CDN, server, plugin, application) issues each hop.

2. Decide the one final URL. Pick a single canonical destination that returns 200, with the exact case, slash and protocol you want. Everything else in the cycle becomes a source, never a target.

3. Rewrite all rules to point there directly. Every URL in the former loop should 301 straight to the final URL in one hop, with no intermediate steps.

4. Remove reciprocal rules. Delete any rule that redirects the final URL anywhere, and any leftover migration entry that points new back to old.

After the fix, the same trace should look like this:

$ curl -IL https://example.com/services/audit
HTTP/1.1 301 Moved Permanently
location: https://example.com/seo-audit/

HTTP/1.1 200 OK
content-type: text/html; charset=UTF-8

Finish by updating internal links and the XML sitemap to reference the final URL directly, then request reinspection in Search Console so the Redirect error entries can clear.

Common mistakes

The classic error is breaking the loop in one layer while another layer still holds the opposing rule, so the loop reappears after a cache flush or plugin update. Another is fixing the redirect but leaving internal links pointing at a former loop URL, which keeps funneling crawl budget through a hop. Teams also forget the CDN: edge rules cached at the CDN can keep serving the old redirect long after the origin is fixed, so purge after deploying. Finally, do not "fix" a loop with a 302; use a 301 so the final URL inherits the signals.

FAQ