How to Fix "Too Many Redirects" Errors on Your Website

A practical guide to diagnosing and fixing "too many redirects" errors. Covers redirect chains, hosting vs. application conflicts, SEO impact, and prevention strategies for marketing teams.

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:

  1. The hosting platform redirects example.comwww.example.com
  2. The application code redirects www.example.comexample.com
  3. 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


Context Memo · The AI Visibility Platform for B2B Teams


Related Reading