Internal URL Redirects Back to Itself: Fixing the Self-Redirect Loop

What this means

A redirect is meant to send a request from one URL to a different one. A self-redirect is broken by definition: the URL points the request straight back at itself. The server answers a request for /page/ with a 301 or 302 to /page/, the browser obeys, the server answers identically, and the cycle repeats. Browsers and crawlers cap the number of hops they will follow, so after a handful of identical responses they stop and report the loop. The page is never delivered.

Why it matters

This is one of the few SEO issues with no partial outcome. A slow page still loads. A page with a thin title still ranks somewhere. A self-redirecting URL returns nothing usable at all.

• Users see an error screen. The visitor gets ERR_TOO_MANY_REDIRECTS instead of your content and leaves.
• Search engines cannot index it. Googlebot hits the same hop limit, abandons the URL, and treats the loop as a dead end. An indexed page caught in a loop effectively drops out of the index.
• Crawl budget burns. Every loop attempt consumes requests the crawler could have spent on real pages.
• Link equity evaporates. Any internal or external link pointing at the looping URL passes its value into a black hole.

How it gets flagged

A crawler requests the URL, receives a 3xx response, and reads the destination in the Location header. When that destination resolves back to the original address, the crawler records a redirect loop rather than following it forever. In Screaming Frog this surfaces under Response Codes as an Internal Redirect Loop, and the Reports > Redirects > Redirect Chains export shows the hop count and the looping source URL. You can also confirm it directly: a curl -I request that returns a 301 whose Location equals the requested URL, or server access logs that show the same URL requested and redirected over and over within milliseconds, both point to the same fault.

How to fix it (common loop causes)

The fix is to find the rule that fires when it should not. Almost every self-redirect comes from a normalization rule missing the condition that tells it the URL is already correct.

Trailing slash

A rule that adds a slash to every request also matches URLs that already end in a slash, so it redirects them to themselves. Exclude already-correct URLs first. In Apache, gate the rule with a condition such as RewriteCond %{REQUEST_URI} !(.+)/$ so it only fires when the slash is genuinely missing, and confirm you are working with a real directory rather than a file before appending.

HTTP to HTTPS

A force-HTTPS rule that cannot read the real protocol redirects HTTPS requests to HTTPS again. This is common behind a load balancer or CDN that terminates SSL: the server sees plain HTTP internally and never registers that the visitor is already secure. Check %{HTTP:X-Forwarded-Proto} instead of %{HTTPS} when a proxy sits in front.

www and non-www

Two rules that disagree are the classic trap: one forces www, another strips it, and the request bounces between them until it loops. Pick one canonical host and keep a single rule. Stacking separate rules for slash, www, and HTTPS is what produces loops; combine the checks so a single redirect corrects the URL in one hop.

Letter case

A rule that lowercases paths can match an already-lowercase URL and redirect it to the identical address. Add a condition that the requested path actually contains an uppercase character before rewriting.

After editing, test the exact flagged URL with curl -I and confirm it returns a single 200, or a single 301 to a genuinely different address. For the difference between a permanent and temporary redirect, see 301 vs 302 redirects, and for the wider pattern of multi-hop and looping redirects review redirect chains and loops.

False positives

Genuine self-redirects rarely have an innocent explanation, but a few situations can look like one in a report. A URL may redirect to a near-identical address that differs only by a query string, session ID, or tracking parameter the crawler stripped before comparing, which is a redirect chain rather than a true loop. Some servers redirect by geography or device and may send your crawler in a circle while real users are routed correctly. And a loop can be temporary, caused by a deployment or a half-applied cache rule that has since cleared. Always re-test the live URL with a fresh request before assuming the rule is still broken, and compare the requested address against the Location header character for character. If they truly match, it is real. A related but distinct symptom is a 5xx response under load; see 5xx server errors and SEO.

FAQ