Redirect Loop? Here's Why It's Happening and How to Stop It

What a Redirect Loop Actually Looks Like

You type a URL into the browser and get a wall of text: "This page isn't working. example.com redirected you too many times." Chrome, Firefox, and Safari all throw some version of this error (ERR_TOO_MANY_REDIRECTS in Chrome), and it means the site is bouncing the browser back and forth between two or more URLs indefinitely instead of ever landing on actual content.

This isn't a cosmetic bug — it's a full outage. Search engines can't crawl the page, users can't reach it, and if it's happening on a checkout page or login form, you're losing money every minute it stays broken.

The Five Most Common Causes

1. HTTPS Redirect Conflicts with a Reverse Proxy or CDN

This is the single most common cause. Your CDN (Cloudflare, Fastly, etc.) is set to "Flexible SSL" or forces HTTPS at the edge, while your origin server also has a rule that redirects HTTP to HTTPS — or worse, your origin thinks the connection is HTTP because the CDN talks to it over plain HTTP internally, so it redirects again, and the CDN redirects again, forever.

• If you're on Cloudflare, switch SSL mode from "Flexible" to "Full" or "Full (Strict)" so the origin sees an actual HTTPS request.
• Check whether your origin server trusts the X-Forwarded-Proto header instead of the raw connection type — many misconfigured Nginx/Apache setups redirect based on the wrong signal.

2. WWW vs Non-WWW Redirect Fighting Itself

One rule redirects example.com to www.example.com, and another rule (often added later, or by a plugin) redirects www.example.com back to example.com. Classic ping-pong.

• Pick one canonical version (www or non-www) and make sure every redirect rule, CMS setting, and .htaccess entry points toward that single version.
• Search your entire codebase and server config for every instance of a www/non-www rewrite — there's often more than one.

3. WordPress URL Settings Mismatch

If your WordPress "Site Address (URL)" and "WordPress Address (URL)" settings in Settings → General don't match what's actually being served (e.g., one says https, the site is serving http, or there's a stray trailing slash mismatch), WordPress can generate a loop trying to reconcile them.

• Also check wp-config.php for hardcoded WP_HOME and WP_SITEURL constants that might be overriding the database values with conflicting ones.
• A caching plugin or security plugin (Wordfence, iThemes Security) forcing SSL is a frequent second layer of conflict on top of this.

4. Old or Duplicate .htaccess / Nginx Rewrite Rules

Redirect rules pile up over years of migrations. An old rule from a 2019 domain move might still be sitting in .htaccess, contradicting a newer rule added for an SSL migration in 2023.

• Open .htaccess (Apache) or your server block (Nginx) and read every RewriteRule/return line top to bottom. Rules execute in order, and Apache in particular will re-evaluate rules after each internal rewrite, which is a common source of accidental loops.
• Comment out redirect rules one at a time (in a staging environment) to isolate which one is firing incorrectly.

5. Browser or Cookie-Level Caching of a Bad Redirect

Sometimes the server-side issue has already been fixed, but the browser cached the old 301 redirect permanently, so it keeps looping locally even though a fresh request would work fine.

• Test in an incognito/private window first — this rules out local caching immediately.
• If incognito also fails, it's a real server-side loop, not a caching artifact.

Diagnosing the Exact Loop Path

Guessing which of the five causes above applies to you wastes time. What you actually need is the literal chain of redirects, in order, with status codes.

1. Run the URL through a header inspection tool that follows redirects and logs each hop with its status code (301, 302, 307, etc.) and destination URL.
2. Look for a URL that repeats — that's your loop boundary. Whatever rule fires at that exact URL is the one you need to fix.
3. Note the protocol (http vs https) and host (www vs non-www) at each hop — in most loops, one of these two things is flipping back and forth.

AXOX Hub's HTTP Header Checker is built exactly for this — it traces the full redirect chain for any URL and shows you every hop with its status code, so instead of guessing you can see precisely where the loop closes and what's toggling (protocol, host, or path).

Reading a Real Redirect Chain

A typical broken chain looks like this:

• http://example.com → 301 → https://example.com
• https://example.com → 301 → http://www.example.com
• http://www.example.com → 301 → http://example.com

Here the protocol and the www/non-www state are both flipping — a sign that two separate rules (one for SSL, one for canonical domain) are fighting each other rather than being combined into a single, consistent rule.

Fixing It: A Practical Checklist

1. Decide on one canonical URL format: https, and either www or non-www — write it down.
2. Consolidate every redirect into a single rule per concern (one for protocol, one for host) rather than layering multiple partial fixes.
3. If using a CDN, set SSL mode to Full/Full Strict and confirm the origin trusts X-Forwarded-Proto.
4. Clear any application-level cache (WordPress object cache, Varnish, CDN edge cache) after making changes — old redirects can be cached server-side too.
5. Re-run the header trace tool to confirm the chain now ends in a single 200 OK with no repeats.

Redirect Loops After an SSL Migration

If the loop appeared right after installing or renewing an SSL certificate, the cause is almost always #1 above — the server or CDN redirecting to HTTPS before the SSL handshake is actually trusted end-to-end. Confirm the certificate itself is valid and matches the domain (not just installed) before touching redirect rules, since a broken or mismatched cert can produce symptoms that look identical to a redirect misconfiguration. AXOX Hub's SSL Checker will confirm the certificate chain is valid so you're not chasing a redirect problem that's actually a certificate problem.

When the Loop Only Happens for Some Users

If reports are inconsistent — some visitors loop, others don't — look at:

• Geographic CDN edge inconsistency — one edge node has a stale config, others don't.
• Login-state cookies — a logged-in redirect rule (common on WordPress, membership sites) conflicting with a logged-out rule.
• A/B testing or personalization scripts that redirect based on cookies which haven't been set yet, causing a first-visit loop that resolves on the second attempt.

Trace the exact hop sequence with a header checker before and after clearing cookies to isolate whether the loop is server-side or cookie-driven.

Run your URL through AXOX Hub's free HTTP Header Checker right now to see the exact redirect chain causing your loop — it takes seconds and shows you precisely which rule to fix.