Too Many Redirects: How to Fix ERR_TOO_MANY_REDIRECTS

"Redirected you too many times" means two rules keep bouncing the browser in a circle. Find the loop — HTTPS, www, CDN SSL mode, or a plugin — and break it.

“This page isn’t working — example.com redirected you too many times” is Chrome’s way of saying it followed a chain of redirects, noticed it was going in a circle, and stopped. Firefox says “The page isn’t redirecting properly”; Safari says “Too many redirects occurred trying to open…”. The code underneath is ERR_TOO_MANY_REDIRECTS.

A redirect loop is always two or more rules disagreeing. One says “go to A”, the next says “go to B”, and a third sends the browser back to A. Each rule is reasonable on its own. Together they never produce a page. So the fix is never “remove all redirects” — it is finding the pair that contradict each other and deciding which one is right.

First, confirm it is the site and not your browser

A stale cookie can keep a loop alive after the site has been fixed, and a loop can also be caused by a cookie — a login or language cookie that sends you somewhere that sends you back.

  1. Open the page in a private window. If it loads there, clear cookies for that one site and you are done.
  2. Try another browser or device on a different network.
  3. Run the URL through the website checker. It follows each redirect hop from an independent server and reports a loop when it sees one, so a failure there means the loop is on the server side for everyone.

Trace the chain

Before changing anything, look at the hops. This one command shows every redirect and where it points:

curl -sIL https://example.com 2>&1 | grep -iE '^(HTTP|location)'

A loop looks like this:

HTTP/2 301
location: https://www.example.com/
HTTP/2 301
location: https://example.com/
HTTP/2 301
location: https://www.example.com/

The two alternating location values tell you which two rules are fighting. In this example one rule forces www, another forces the bare domain. Browser DevTools shows the same thing: Network tab, tick Preserve log, and reload.

The common loops, and how to break them

The chain bounces between Usual cause Fix
http:// and https:// CDN connects to the origin over HTTP, origin forces HTTPS Set the CDN’s SSL mode to Full, or stop forcing HTTPS at the origin
www and non-www Two places each enforce a different canonical host Choose one host and enforce it in one place
/page and /page/ Trailing-slash rules in the server and the CMS disagree Align the CMS permalink setting with the server rule
The page and /login Auth or session cookie never sticks Fix cookie domain, Secure flag, or SameSite
/en/ and / Language or geo redirect plus a cookie Stop redirecting when the language cookie is already set
Old URL and new URL Two redirect rules added at different times, pointing at each other Delete the older rule

HTTPS loops behind Cloudflare or a CDN

The single most common redirect loop. Cloudflare’s Flexible SSL mode connects to your origin over plain HTTP. If the origin — or WordPress, or an .htaccess rule — forces HTTPS, it answers every request from Cloudflare with “go to https://”. Cloudflare passes that to the browser, the browser asks Cloudflare for HTTPS, Cloudflare asks the origin over HTTP again, and round it goes.

Fix: install a certificate on the origin (a free Let’s Encrypt or Cloudflare Origin certificate is fine) and set the SSL/TLS mode to Full (strict). Only if you cannot put a certificate on the origin should you remove the origin’s HTTPS redirect instead and let Cloudflare’s “Always Use HTTPS” do the job.

WordPress site URL mismatches

WordPress stores its own address in two settings, WordPress Address (URL) and Site Address (URL), and redirects anything that does not match. If those say http:// while the server forces https://, or they say www while the host strips it, you have a loop — and you cannot reach the admin to fix it.

Fix: set them directly in wp-config.php, which overrides the database:

define('WP_HOME', 'https://www.example.com');
define('WP_SITEURL', 'https://www.example.com');

If WordPress sits behind a proxy that terminates HTTPS, it may not realise the original request was secure. Adding this above the /* That's all */ line tells it:

if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Loops that appear right after moving a site are part of a bigger migration clean-up — broken links after a WordPress migration covers the rest.

Redirect plugins and stacked rules

Redirection plugins, SEO plugins, a host’s own redirect manager, .htaccess, nginx config, and the CDN’s page rules can all redirect the same URL. Nobody remembers every place a rule was added, and a new rule pointing A → B collides with an old one pointing B → A.

Fix: list every place redirects can live on this site, and keep each type of rule in exactly one of them. Host canonicalisation (HTTPS, www) belongs at the edge or server; page-level moves belong in one plugin or one config file.

If the loop only starts after logging in, the app is sending you to a protected page, deciding you are not logged in, and sending you back to the login page — because the session cookie is not being saved. Typical causes are a cookie set for the wrong domain (example.com vs www.example.com), a Secure cookie on an HTTP page, or a SameSite setting that blocks it in an embedded context.

How to confirm the fix

  1. Re-run the curl -sIL trace. A healthy chain has at most one or two hops and ends on a 200.
  2. Test all four variants: http://example.com, http://www.example.com, https://example.com, https://www.example.com. Each should land on the same final URL in one hop, ideally.
  3. Test in a private window, logged out, so cookies cannot hide a remaining problem.

Why redirect chains matter even without a loop

A chain that eventually resolves still costs something. Each hop adds a round trip, and crawlers give up on long chains. Loops are worse: to a crawler, the page simply does not exist. A single misconfigured SSL setting can make every page on a site unreachable to search engines while it looks fine in a browser that cached the old redirect.

SitesRadar’s free plan checks one site on a schedule and alerts you when pages stop resolving — redirect loops, error codes, SSL problems, and broken links included. The related error when a visitor gets no connection at all is covered in this site can’t be reached.

FAQ

What does “redirected you too many times” mean? The browser followed a series of redirects that led back to where it started, so it stopped rather than loop forever. Two redirect rules are contradicting each other.

How do I fix ERR_TOO_MANY_REDIRECTS as a visitor? Clear cookies for that site and try a private window. If it still fails, the loop is on the website’s side and only the owner can fix it.

How do I fix too many redirects in WordPress? Make sure the WordPress Address and Site Address match the protocol and host your server actually uses, set them in wp-config.php if you are locked out, and check the CDN’s SSL mode. Then disable redirect plugins one at a time.

Why do I get too many redirects with Cloudflare? Usually Cloudflare’s SSL mode is Flexible while the origin forces HTTPS. Install a certificate on the origin and switch to Full (strict).

Why does Safari say too many redirects when Chrome works? Safari may be holding a stale cookie or a cached redirect. Clear the site’s data in Safari settings, or test in a private window.

← More from the SitesRadar blog