Last verified: February 11, 2026
Overview
A "too many redirects" error means the browser is being sent in circles between two or more URLs. It keeps following redirect instructions — URL A sends it to URL B, URL B sends it back to URL A — until it gives up. The result: your website is completely inaccessible to everyone. Visitors, customers, and search engine crawlers all see a blank error page.
This is one of the most common causes of sudden website outages, and it almost always comes down to redirect rules that contradict each other.
Why This Happens
Modern websites typically have redirects configured at multiple layers:
- Hosting platform (Vercel, Netlify, Cloudflare, AWS) — handles domain-level routing like www vs. non-www and HTTP vs. HTTPS
- Application code (middleware, server config, .htaccess) — handles page-level redirects like authentication flows, old URLs, and vanity routes
- DNS provider — can add its own forwarding rules
- CDN — may cache and enforce redirect responses
Problems arise when two layers issue contradicting instructions. The most common scenario:
- The hosting platform redirects
example.com→www.example.com - The application code redirects
www.example.com→example.com - The browser bounces between them indefinitely
This often happens after an SEO fix, a platform migration, or a well-intentioned change made without checking what the other layer is already doing.
How to Diagnose It
Check the Redirect Chain
The fastest way to diagnose a redirect loop is to inspect the HTTP headers directly, rather than relying on a browser. Use a terminal command like:
curl -sI -L --max-redirs 5 https://example.com
This shows each redirect in the chain — the status code (301, 302, 307, 308), the location header (where it sends you), and whether it loops back to a URL already visited.
What to Look For
- Alternating URLs — if you see the same two URLs taking turns, you have a redirect loop between two layers
- Status codes — a 301 or 308 is permanent (cached by browsers), while 302 or 307 is temporary
- Response headers — headers like Content-Security-Policy or custom security headers usually indicate the response is coming from your application code, not your hosting platform
Identify Which Layer Owns Each Redirect
Each redirect in the chain is issued by a specific layer. Match them:
| Redirect | Likely Source |
|---|---|
| HTTP → HTTPS | Hosting platform or CDN |
| non-www → www (or reverse) | Hosting platform domain settings |
| /old-page → /new-page | Application code |
| /login → /dashboard | Application middleware |
If two redirects point in opposite directions, they are the loop.
How to Fix It
Step 1: Pick One Canonical Domain
Decide whether your site lives at www.example.com or example.com. Not both. The modern convention for most B2B brands is the non-www version, but either works as long as it is consistent everywhere.
Step 2: Assign Each Redirect to One Layer
Domain-level routing — www vs. non-www, HTTP vs. HTTPS — should be handled by your hosting platform. It runs before your application code and is purpose-built for this.
Application middleware should only handle application concerns: authentication redirects, role-based access, page-level routing.
Step 3: Remove the Conflicting Rule
If your hosting platform redirects non-www → www, remove any www → non-www redirect from your application code (or vice versa). They cannot coexist.
Step 4: Verify the Fix
After deploying, check the redirect chain again:
curl -sI -L --max-redirs 5 https://example.com
You should see at most one redirect (e.g., non-www → www), followed by a 200 OK response. No loops.
Step 5: Clear Cached Redirects
If you previously issued a 301 (permanent redirect), browsers may have cached it. Tell users to clear their browser cache, or wait for the cache to expire naturally.
SEO Impact of Redirect Loops
Redirect loops are not just an uptime issue. They directly affect search visibility:
- Crawl failures — Googlebot and AI crawlers (GPTBot, ClaudeBot, PerplexityBot) cannot access your pages during a loop, which can trigger de-indexing if the outage persists
- Duplicate content signals — conflicting www and non-www redirects tell search engines you have two versions of every page with no clear canonical
- Lost link equity — redirect chains dilute PageRank with each hop
- Stale AI training data — AI models that encounter repeated crawl failures may deprioritize your domain in future responses
Google Search Console will report these under "Page indexing" as redirect errors. Recovery typically takes days to weeks depending on how long the loop persisted.
Prevention
The One-Layer Rule
Every type of redirect should be owned by exactly one layer. A simple policy:
| Redirect Type | Owner |
|---|---|
| HTTP → HTTPS | Hosting platform |
| www → non-www (or reverse) | Hosting platform |
| Old page → new page | Application code (next.config, .htaccess, etc.) |
| Auth flows (login, logout) | Application middleware |
| Vanity URLs | Application code or hosting platform (pick one) |
Audit After Changes
After any deployment that touches redirects — domain settings, middleware, hosting config — run a quick redirect chain check on your primary URLs before walking away.
Monitor Uptime
Most uptime monitors check for 200 OK responses. A redirect loop returns a redirect status code, not a 200, so basic monitoring will catch it. Tools like UptimeRobot, Better Uptime, or even a simple cron job with curl can alert you within minutes.
Sources
- MDN Web Docs: HTTP Redirections
- Google Search Central: Avoid redirect chains and loops
- Vercel Documentation: Domain Configuration
- Cloudflare: Redirect Loop Troubleshooting
Context Memo · The AI Visibility Platform for B2B Teams
Related Reading
- How to Optimize Your Site for LLM Training Data and AI Search
- What is GEO (Generative Engine Optimization)? The Complete Guide