Too many redirects error (ERR_TOO_MANY_REDIRECTS): what it means and the fastest fix

“Too many redirects” (Chrome often shows ERR_TOO_MANY_REDIRECTS) is almost always one of two things:

1. a loop (A → B → A)
2. an unstable chain (the URL keeps changing and never lands on a stable 200 page)

If you’re seeing it in Search Console (not just a browser), start here:

• GSC redirect error: fastest fix checklist
• Page with redirect (GSC): what it means

TL;DR (the fix in one sentence)

Pick one canonical URL pattern (protocol + host + trailing slash) and enforce it with one deterministic redirect.

Goal: at most 1 hop to a final 200 OK page that is canonical to itself.

The 10-minute diagnosis

1) Check if it’s a cookie-based loop

Open the URL in:

• a private/incognito window
• another browser (or a new profile)

If it works there but not in your main browser, the loop is often cookie/session related.

2) Record the redirect hops

Use a simple redirect trace (any tool is fine). The goal is to list hops like:

http → https → www → non-www → / → no-slash → …

What you’re looking for:

• the same URL appearing again (loop)
• the URL flipping between variants (unstable canonicalization rules)

3) Identify which rule is fighting which

The most common “duels”:

• http ↔ https
• www ↔ apex
• trailing slash ↔ no trailing slash
• locale redirect ↔ canonical redirect
• app middleware ↔ CDN/WAF redirect

Common causes (and the clean fix)

1) Host canonicalization loop (www vs apex)

Bad pattern:

• CDN redirects www → apex
• app redirects apex → www

Fix:

• pick one (usually apex)
• enforce in one layer only (CDN or app, not both)

2) Trailing slash loop

Bad pattern:

• one rule adds /
• another removes /

Fix:

• pick one convention
• ensure routes, internal links, and canonical tags match it

3) HTTP ↔ HTTPS loop

Bad pattern:

• HTTPS forced at CDN
• app forces HTTP somewhere (rare but happens with proxy misconfig)

Fix:

• force HTTPS at the edge
• ensure app trusts x-forwarded-proto / proxy headers correctly

4) Locale redirects based on cookies

Bad pattern:

• Accept-Language or cookie sends users to /ru
• then another rule sends /ru back to /en (or a different host)

Fix:

• make locale routing deterministic for crawlers
• avoid redirecting bots based on unstable signals

If you run multiple language hosts, make sure canonical/hreflang is consistent:

• Hreflang and canonical: the correct setup

5) “Canonical tag points to a redirect” (SEO footgun)

Even if the browser eventually renders, Google can treat this as messy canonicalization.

Fix:

• canonical should point directly to the final 200 URL
• avoid canonical → 301 chains

Decision rule:

• Canonical tag vs redirect

What to do right now (step-by-step)

1. Pick your canonical URL
   • https
   • apex vs www
   • slash policy
2. Collapse to one redirect hop
3. Make the final destination a clean 200
4. Update internal links to the final canonical URL
5. Validate
   • browser: no redirect error
   • GSC URL Inspection: stable final URL

If you suspect the loop is “legacy cleanup”, don’t redirect junk to a generic page:

• 301 vs 410 (and 404): cleanup after a pivot

Next.js / Vercel note (typical patterns)

In Next.js setups, loops often come from:

• middleware canonicalization + redirects in next.config.js
• middleware rules that depend on query params/cookies
• edge/cdn redirects also enabled in Vercel project settings

Rule: one source of truth for canonicalization.

If you care about 301 vs 308 behavior:

• 301 vs 308 redirect: does it matter for SEO and Next.js?

FAQ

Is “too many redirects” bad for SEO?

Yes, if Googlebot sees it. It blocks crawling and creates indexing noise (redirect errors, unstable canonicals).

Should I just clear cookies and ignore it?

Clearing cookies is a quick test, not a fix. The real fix is removing the conflicting redirect rules.