iSocialWeb

Redirect loop

Why ERR_TOO_MANY_REDIRECTS appears and how to fix it

A redirect loop happens when a URL redirects to another URL that, directly or indirectly, redirects back to the first one, so the page never loads. After a number of attempts the browser stops and shows the ERR_TOO_MANY_REDIRECTS error.

The simplest case is A → B → A, but the cycle can be longer (A → B → C → A). It almost always comes from two conflicting rules that live in different places: the server, the CDN, the CMS or a plugin.

What ERR_TOO_MANY_REDIRECTS means: symptoms

  • Chrome and Edge: "This page isn't working. example.com redirected you too many times", with the code ERR_TOO_MANY_REDIRECTS.
  • Firefox: "The page isn't redirecting properly".
  • Safari: a message saying too many redirects occurred.
  • Googlebot: in Search Console's page indexing report, the URL shows up with the reason "Redirect error".

If the error hits the whole domain, the site is down for everyone. If it only affects some users or one browser, suspect cookies or the local cache.

Common causes of a redirect loop

Conflicting HTTP/HTTPS or www/non-www rules

A rule in the .htaccess file or in nginx forces www.example.com while the CMS, the host or the CDN forces example.com. Each one sends visitors to the other and neither serves the page. The same happens when one layer forces HTTPS and another sends back to HTTP.

CDN on "Flexible" SSL while the server forces HTTPS

This is the classic Cloudflare loop. In Flexible mode the browser talks to Cloudflare over HTTPS, but Cloudflare requests the page from your server over HTTP. The server sees HTTP and redirects to HTTPS, the browser goes back to Cloudflare over HTTPS and Cloudflare asks over HTTP again. Cloudflare documents it in its guide to the too many redirects error.

Wrong site URL in WordPress

If the WordPress Address or Site Address uses http:// or a non-www host while the server forces a different version, WordPress and the server keep bouncing the request. It also happens behind a proxy or load balancer: WordPress does not detect that the original request was HTTPS and keeps redirecting.

Plugins and caching

An SSL plugin forcing HTTPS on top of the server, a redirect plugin with a circular rule, or a cache (plugin, server or CDN) holding an old redirect. 301 redirects also stay in the browser cache, so an error you already fixed can keep showing up.

Cookies

Some sites redirect based on a cookie: language, session or consent. If the cookie is not stored or is corrupted, the login page sends you to the private area and the private area sends you back to login, forever.

How to diagnose a redirect loop

  1. Follow the chain hop by hop. Paste the URL into the redirect checker and see where a URL repeats. The pair that keeps alternating tells you which two rules clash.
  2. Use curl. From the terminal you see every status code and its Location header, with no browser cache or cookies involved:
curl -sIL --max-redirs 10 http://example.com/ | grep -iE "^(HTTP|location)"
  1. Rule out the browser. Open the URL in a private window or clear that domain's cookies.
  2. Isolate the CDN. Pause the CDN proxy briefly and test again. If the loop goes away, the problem is in the CDN's SSL settings or rules.
  3. Isolate the CMS. Disable SSL, caching and redirect plugins one by one until the loop breaks.

How to fix each cause

Cause Fix
Conflicting HTTPS or www rules Pick one version (for example, https with www) and enforce it in a single place, with one rule that sends every variant to it in a single hop.
CDN on Flexible SSL Install a certificate on the server and switch the CDN's SSL mode to Full (strict).
WordPress site URL Match both addresses to the version the server forces. Without dashboard access, define them with WP_HOME and WP_SITEURL in wp-config.php. Behind a proxy, make WordPress read the X-Forwarded-Proto header.
Plugins Let a single layer force HTTPS (ideally the server) and review the redirect plugin's rules.
Caching Purge the plugin, server and CDN caches after every change.
Cookies For users, clear the site's cookies. For developers, make sure redirect logic does not depend on a cookie that may be missing.

Redirect loop vs redirect chain

A redirect chain (A → B → C) ends at a final URL that loads: it is slow and wastes crawl budget, but it works. Googlebot follows up to 10 hops, according to Google's documentation on HTTP status codes. A loop has no end: neither users nor Google ever reach the content.

Both are prevented the same way: every rule should point straight to the final URL, and you should check the full chain after any domain, HTTPS or CDN change, which is when they usually appear. In an SEO migration, that check belongs on the launch-day checklist.

Frequently Asked Questions

  • It is the error Chrome (and Edge) shows when a page is stuck in a redirect loop: the URL redirects to another one that ends up sending you back to the first, and the browser gives up. The fault lies in the server, CDN or CMS configuration, not in your computer, unless the cause is a cookie.

  • Check that the WordPress Address and Site Address (Settings, General) use the same protocol and host the server forces. If you cannot log in, set them with WP_HOME and WP_SITEURL in wp-config.php. If the loop persists, disable SSL, caching and redirect plugins by renaming their folders, and check your CDN's SSL mode.

  • It is almost always a cookie or a redirect stored in the browser cache. Try a private window or clear that site's cookies. If it loads in private mode, the problem is local; if it fails there too, it is on the server.

  • Yes. Googlebot cannot reach the content either, Search Console flags the URL with a redirect error and, if the loop lasts, the page can drop out of the index. Fixing it fast is a priority, especially when it affects the whole domain.