What a self redirect is
A self redirect happens when a URL responds with a 3xx status and a Location header that points back to the same URL it was just requested at. Request /pricing/, get a 301 to /pricing/, request /pricing/ again, get the same 301, and so on. Browsers cut this off after a handful of hops and show "too many redirects" (in Chrome, ERR_TOO_MANY_REDIRECTS). Crawlers do the same and simply mark the URL as unreachable.
It is worth being precise about "same URL," because that is where these bugs hide. A redirect from http://site.com/x to https://site.com/x is not a self redirect, it is a valid protocol upgrade. A redirect from /x to /x/ is a trailing-slash canonical, also fine. A true self redirect lands on the byte-for-byte identical URL: same scheme, same host, same path, same casing, same query. If the destination equals the source, the loop can never resolve.
Why it is one of the worst redirect bugs
Most redirect problems are about efficiency. This one is about availability. A self-redirecting URL does not load for anyone. Real visitors hit a dead end, so you lose the traffic and any conversion that page was carrying. Googlebot follows the redirect, comes back to the same URL, and after enough hops treats it as an error; the page falls out of the index and takes its rankings with it. If the loop is on a template that powers thousands of URLs, you can knock a whole section of the site offline in one bad deploy.
It also lies to you in monitoring. A self redirect returns a 3xx, not a 5xx, so naive uptime checks that only alarm on 500s will report the site as "up" while every affected page is unusable. I have watched a team stare at a green status dashboard while their top landing page returned nothing but redirect loops. So the honest severity here is critical, even though the fix is usually a two-line change.
The loop, drawn out
How to detect it
- curl: the fastest single check. Run
curl -sIL https://example.com/page/and watch the trail. If you see the same URL return a 3xx to itself over and over, or curl bails with "Maximum redirects followed," you have a loop. - Screaming Frog: crawl, open the Response Codes tab, and look at the "Redirect Loop" filter and the "Redirect URL" column. When the redirect target equals the address, it is a self redirect. Frog also flags loops outright.
- Chrome DevTools: load the page, and if it fails with
ERR_TOO_MANY_REDIRECTS, the Network tab shows the same URL repeating with 3xx status rows. - Google Search Console: the Pages report buckets these under "Page with redirect" or as crawl errors, and URL Inspection will show the redirect it followed.
- Server logs: a spike of 3xx responses on one path from the same client in quick succession is a loop signature.
Common causes and fixes
| Cause | Why it loops | Fix |
|---|---|---|
| Force-HTTPS behind a proxy | App sees http from the proxy, redirects to https, proxy strips it again | Honor X-Forwarded-Proto so the app knows the request is already https |
| Duplicate canonical rules | Two rules each redirect to what the other undoes | Keep one canonical rule; remove the conflicting one |
| Redirect map with an identity row | A row maps a URL to itself | Delete rows where source equals destination |
| Trailing-slash rule misfire | Rule adds and removes the slash on the same request | Pick one form and redirect only the other to it |
| CDN and origin disagree | Both add their own redirect and bounce the request | Set the canonical redirect in one layer only |
How to fix it, step by step
- Reproduce it with
curl -sILso you can read the exact hop chain and confirm the destination equals the source. - Find the layer doing the redirect. Work down the stack: CDN or edge rules, then web server config (
.htaccess, nginxrewrite), then the application or CMS redirect table, then any plugin. - Identify the rule whose target resolves back to the request URL. In a proxy-HTTPS setup this is usually a force-HTTPS block that ignores
X-Forwarded-Proto. - Correct or remove that rule. If a redirect map contains a row where source and destination match, delete the row. If two rules conflict, keep the one that reflects your true canonical and drop the other.
- Deploy, purge CDN and page caches, then re-run the curl check. You want a clean 200, or a single legitimate redirect to a genuinely different URL that then returns 200.
- Once the page loads, request re-indexing in Search Console for the affected URLs so Google recrawls and restores them.
Do and do not
- Confirm the loop with curl before touching config.
- Honor X-Forwarded-Proto behind a load balancer or CDN.
- Keep exactly one canonical redirect per rule set.
- Delete any redirect-map row where source equals destination.
- Re-request indexing once the page loads again.
- Stack force-HTTPS in both the CDN and the app.
- Add a redirect that targets its own source URL.
- Run conflicting slash rules that fight each other.
- Trust an uptime check that only alarms on 5xx.
- Assume it is fixed before purging every cache.
What good looks like
A curl -sIL on the URL returns a single 200, or one clean redirect to a different, correct URL that itself returns 200. No repeated addresses in the chain. The page renders in the browser, Search Console shows it as indexed rather than "page with redirect," and your traffic to it recovers. That is the whole bar. Self redirects are almost never subtle once you look; the trick is looking before a green dashboard convinces you nothing is wrong.
FAQ
Is a self redirect the same as a redirect loop?
Why does my site show a loop only in production?
Does the redirect type, 301 vs 302, matter here?
Will Google deindex a self-redirecting page?
How do I stop this from happening on the next deploy?
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
