Too Many Redirects Error (ERR_TOO_MANY_REDIRECTS): How to Fix It

What is the too many redirects error (ERR_TOO_MANY_REDIRECTS)?

The too many redirects error is an endless loop: your browser goes from address A to address B, then back to address A. After a set number of tries, however, the browser gives up. Chrome shows ERR_TOO_MANY_REDIRECTS. In practice, the cause usually sits in the site's redirect settings, not on your device.

First, a redirect is the server saying that the content you asked for lives at another address. So it sends a 3xx status code and a Location header. RFC 9110 defines these codes. It also expects clients to detect cyclical redirects and step in. In short, the Chrome error screen is exactly that safeguard.

A loop rarely comes from a single rule. Instead, it comes from two rules that undo each other. For example, one rule sends HTTP to HTTPS, while another layer turns HTTPS back into HTTP. As a result, the visitor bounces between the two. In this guide, we show how to find the layer that builds the loop and how to break it.

We cover the SEO side of long chains in a separate article: what is a redirect chain and how to fix it. That article deals with chains that run long but still end on a page. This one, however, deals with loops that never end.

Who should fix it: the visitor, the site owner, or the server admin?

Naming the right owner saves time, because each role holds a different switch. The table below shows who should look where when a redirect loop appears.

In a small business, these four roles are often one person. Even then, keep the order. First rule out the visitor side, then check the layers from the outside in. If other people see the same error, your browser is not the problem.

How do browsers show this error?

The wording changes by browser, but the meaning stays the same. Chromium browsers such as Chrome and Edge say the page redirected you too many times and show ERR_TOO_MANY_REDIRECTS. They also usually suggest deleting cookies.

Firefox reports that the page is not redirecting properly. Safari says it cannot open the page because too many redirects occurred. Exact text can change between versions, so watch the behavior instead of the words. In both cases, the page never loads, and the address bar flips between the same addresses.

• Blank page: no content ever appears.
• Sometimes the error shows on one address only, while some subpages still open.
• If the error disappears in a private window, cookies or cache are the likely cause.
• If every browser and device shows it, the server or CDN is the cause.

These four clues shorten the first half hour of diagnosis. You can tell the visitor side from the server side before you type a single command.

What should a visitor try when ERR_TOO_MANY_REDIRECTS appears?

If you hit the error on someone else's site, your options are limited. Still, they are worth a try. First, open the page in a private window. A private window ignores your current cookies, so a broken session cookie can no longer cause the loop.

1. Open the address in a private window and note the result.
2. Delete cookies for that site only, not your whole browsing history.
3. Clear the cache, because browsers store some redirects.
4. Try another browser, or your phone on mobile data.
5. Turn off browser extensions, especially privacy and redirect tools.

If the error continues after these steps, then the problem most likely sits on the site itself. Then tell the site owner which address, which browser, and what time you saw the error. A note like that, for example, shortens diagnosis a lot.

How do you trace the redirect chain with curl -I?

Browsers hide redirects from you, so to understand a too many redirects error, you need to see the chain, and curl shows every step. First, the command below follows the address and prints each response's status line and Location header. We cap the hops with --max-redirs so the command cannot run forever.

curl -sIL --max-redirs 8 https://example.com/ | grep -iE '^(HTTP|location)'

If the output lists the same two addresses again and again, you have caught the loop. Note which address points to which. Next, test the HTTP and HTTPS versions, and the www and non-www versions, one by one.

curl -sI http://example.com/ | grep -iE '^(HTTP|location)'
curl -sI https://www.example.com/ | grep -iE '^(HTTP|location)'
curl -sL -o /dev/null --max-redirs 8 -w '%{num_redirects} %{url_effective}\n' https://example.com/

The third command prints only the redirect count and the final address. In a loop, therefore, curl stops with an error once it reaches the limit. These commands are examples, so replace the domain with your own. The command line also has another benefit: cookies and cache cannot interfere.

If you prefer not to use a terminal, our redirect checker tool shows the same chain step by step in your browser.

How do you see a redirect loop in browser developer tools?

If you prefer the browser to the command line, developer tools also work. In Chrome, press F12 and open the Network tab. Before you reload, tick the Preserve log option. Otherwise, the log clears on every redirect and you cannot see the chain.

1. Open the Network tab and tick Preserve log.
2. Reload the address in a private window.
3. Confirm that the same two addresses repeat with 3xx codes in the status column.
4. Click a row and read the Location header under Response Headers.

Next, the Location header tells you where the server sent you at that step. Two rows that give the same header, in other words, are the full picture of the too many redirects error. For example, if the header says HTTP, an HTTPS rule is missing. If you see a www difference, the canonical address is inconsistent. You can also send the support team a screenshot of this view.

In which order do you find the layer that causes the loop?

First, a request travels through the browser, DNS, a CDN or proxy, the web server, and the application. One of these layers builds the loop, and you have to rule them out in order. Also, changing settings at random only makes the cause harder to find.

1. Rule out the browser layer with a private window and a second device.
2. If you use a CDN or proxy, switch it to DNS-only for a moment and compare the result.
3. Ask the server directly: use curl with --resolve to bypass the CDN.
4. Inspect web server rules, meaning .htaccess or the Nginx configuration.
5. Inspect application settings, such as WordPress addresses, plugins, and cache.

Then the command in step three forces the domain to a specific server address. The example address comes from a documentation block, so replace it with your own server address.

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | grep -iE '^(HTTP|location)'

If the loop disappears when you ask the server directly, the CDN layer adds it. If the loop continues, then look for the rule on the server or in the application. To confirm which address the domain points to, our DNS lookup tool helps.

Why does an HTTP and HTTPS conflict cause a redirect loop?

The most common cause is simple: two layers disagree about HTTPS. A CDN or load balancer talks HTTPS to the visitor, but it may talk plain HTTP to your server. The server sees an HTTP request and says "go to HTTPS." The CDN asks again over HTTP, and the loop closes.

In practice, the Apache documentation describes this case clearly. That %{HTTPS} variable queries mod_ssl directly. If a load balancer or reverse proxy ends the SSL connection, the variable reports off even though the client used HTTPS. So the fix is to check the X-Forwarded-Proto header that the proxy adds.

• If the server only looks at its own connection, the proxy in front of it hides the truth.
• Trust the proxy header, but only from a proxy that overwrites it on every request.
• If the server also has a certificate, you can use full encryption on the CDN and keep the server redirect.

The Apache documentation says to trust that header only if you control the upstream proxy. Otherwise, an attacker could connect to the server directly and forge it. We explain certificate basics in what is an SSL certificate, so we do not repeat them here.

What do the 301, 302, 307, and 308 redirect codes change in a loop?

RFC 9110 splits redirect status codes into two families. Codes 301 and 308 announce a permanent move, while 302 and 307 announce a temporary one. Both 307 and 308 keep the request method. By contrast, 301 and 302 allow the method to change. In all four codes, the new address arrives in the Location header.

The type of code matters, and so does the order. If you see a loop that starts with a 301 and ends with the same 301, you need to find a permanent rule. That rule, however, is usually written at server or CDN level.

How does a www and non-www conflict build a loop?

A site cannot have two canonical addresses, so you pick one and redirect the other to it. A loop appears when two different layers pick different addresses. The hosting panel says "go to the non-www address," while the application setting says "go to the www address." The two sides meet each other forever.

Here is a typical scenario, for example. You moved the domain to a new hosting account. Then the panel kept a redirect rule with the old preference. WordPress, however, was set up with the new preference. The first rule drops www, and the second rule adds it back.

The fix is to choose one canonical address and enforce it in one place only. For host name redirects, the Apache documentation recommends the Redirect directive in a virtual host instead of mod_rewrite. For the basics of the address itself, read what is www.

How do you fix the too many redirects error in WordPress?

In WordPress, the first suspects are the WordPress Address and Site Address fields on the General settings page. If one says HTTP and the other says HTTPS, or if www differs between them, WordPress redirects itself over and over. So both fields must match and be correct.

If you cannot log in, you can set the values in wp-config.php. The official WordPress documentation shows the WP_HOME and WP_SITEURL constants for this. It also warns that this method only hard-codes the values and locks the General settings fields.

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

If you have WP-CLI access, you can run the same check by command. The first two commands read the values, and the last two update them. Take a backup first.

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

WordPress behind a reverse proxy or CDN has one more detail. The official HTTPS documentation warns that some SSL options can cause an endless loop at first, if a proxy provides SSL and WordPress runs without it. A small code snippet then teaches WordPress to read the X-Forwarded-Proto header. Back up before you hard-code anything; we cover that in our website backup strategy guide.

What if only the admin dashboard shows the redirect loop?

Sometimes the home page opens, but the admin login still loops. In WordPress, the typical cause is forced HTTPS for the dashboard. Specifically, the official documentation describes the FORCE_SSL_ADMIN constant. It warns that behind a proxy that provides SSL, the constant can cause an endless loop until you teach WordPress about the proxy header.

The first step is to find out whether the connection reaches the server as HTTP. With a CDN or load balancer, the server may see HTTP. Then WordPress decides the dashboard must use HTTPS and redirects. Then the proxy forwards over HTTP again. So the fix is to detect HTTPS from the X-Forwarded-Proto header.

The cookie domain is the second suspect. If the dashboard runs on the www address but the cookie is set on the non-www address, the session keeps disappearing. The login page then sends you back to the login page. So first make your WordPress addresses consistent, and then clear your cookies.

How do you find and fix .htaccess rule conflicts?

On Apache sites, redirect rules usually live in the .htaccess file, because it needs no server access. The hosting panel, a security plugin, a cache plugin, and WordPress itself can all add rules there. Two rules that do the same job, or two rules that do opposite jobs, produce a loop.

Back up the file first, then simplify it. First, the standard WordPress block looks like the one below and contains no redirect. Disable every rule outside this block one at a time, and test the site after each change.

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

If you need to force HTTPS, follow the recipe in the Apache documentation. When you only have .htaccess access, mod_rewrite is the right tool. When you can edit the server configuration, a Redirect in a separate HTTP virtual host is cleaner.

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

Behind a load balancer or CDN, switch the condition to the X-Forwarded-Proto header. Otherwise, the condition is always true and the loop starts. Also, never enable the same HTTPS rule a second time in a plugin, panel, or CDN setting. In short, one rule in one place makes debugging easier.

How does a redirect loop appear in Nginx?

The logic is the same in Nginx: two blocks, or one block and the application, redirect each other in opposite directions. For the cleanest layout, use a separate server block on port 80 for the permanent redirect. Then the 443 block holds no redirect back to HTTP.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

In this example, every HTTP request goes to one canonical HTTPS address. Your HTTPS block may also need one rule that moves the www address to the canonical address. If the HTTPS block sends visitors back to HTTP, a loop is unavoidable.

One more error is easy to confuse with this, though. Nginx has its own internal rewrite cycle, which does not send a redirect to the browser. In that case, you see "rewrite or internal redirection cycle" in the log, and the server returns a 500 error. That is not ERR_TOO_MANY_REDIRECTS, but the log is still the first place to look.

After you edit the Nginx configuration, test the syntax first and then reload. If you do not want to experiment on a production server, leave this job to your server admin.

Why does Cloudflare Flexible SSL cause the too many redirects error?

The best-known cause behind Cloudflare is the Flexible SSL mode, because it hides the real connection. According to the Cloudflare documentation, the loop appears when your origin redirects HTTP to HTTPS while Cloudflare sends unencrypted requests to the origin. Cloudflare asks over HTTP, the origin answers with an HTTPS redirect, and the cycle repeats.

However, the documentation offers two fixes. You can remove the HTTPS redirect at the origin, or you can install a certificate on the origin and switch to Full mode. The second option is healthier for security, because in Flexible mode the link between Cloudflare and your origin stays unencrypted.

Cloudflare also notes that HSTS can cause trouble when the encryption mode is Off, or when the origin turns HTTPS into HTTP. To check your certificate and chain, use our SSL checker tool.

How do you find plugin, CDN, and cache conflicts?

When several layers do the same job, the risk of a conflict rises. For example, an SSL plugin, a cache plugin, .htaccess, and the CDN can all force HTTPS at once. Each one works fine alone, but together they conflict.

1. Temporarily rename the plugins folder inside wp-content, which disables all plugins.
2. If the error disappears, rename the folder back and enable plugins one by one.
3. Start with redirect, SSL, security, and cache plugins, because they touch URLs most.
4. Clear the CDN cache and try the page again.

With WP-CLI, the command wp plugin deactivate --all does the same job more cleanly. However, it switches off every plugin on a live site. If a shop or form stops working, for instance, visitors feel it. So try it during a maintenance window.

Also be careful with cache. A cache plugin can store a broken redirect response and keep serving it. After the fix, clear the plugin cache and the CDN cache. Otherwise, you may think the problem is still there.

Why does the browser remember the old redirect after you fix it?

RFC 9110 treats a 301 response as cacheable by default. A browser can store a permanent redirect and go to the old target without asking the server. Even after you fix the server, your own browser may keep showing the error.

So verify with curl, not with the browser. In the browser, use a private window, or clear the cache and cookies for that site. During testing, a temporary redirect (302 or 307) keeps a wrong rule from leaving a permanent trace. Once the right rule is clear, switch to 301 or 308.

HSTS is a separate cached rule. If a site sent HSTS, the browser upgrades HTTP to HTTPS for that domain for a set period. If your server sends HTTPS back to HTTP, the loop ends only after you fix the server rule. Before you enable HSTS, make sure HTTPS works on every subdomain.

Does a redirect loop hurt SEO and rankings?

Yes, it can. An address inside a loop never returns content. A search engine bot also does not follow forever. In its crawling documentation, Google says its crawlers follow up to 10 redirect hops by default. A loop hits that limit, and the content is never reached.

As a result, pages inside the too many redirects error cannot be crawled. If you fix the error quickly, you normally do not expect lasting harm. However, a loop that runs for days can delay updates and the discovery of new content. That is a logical consequence, not a guarantee or a numeric estimate.

• Search Console: look for redirect errors in the crawling and page indexing reports.
• List the addresses that show the error, because a template or folder is often affected.
• After the fix, verify sample addresses with curl again.

For crawl budget and speed topics, continue with how site speed affects SEO. Redirect consistency is always on our technical SEO audit list, so take a look at our SEO consulting service.

Why do loops appear after a site migration?

A domain or hosting change is the moment loops show up most often. The rules of the old environment get copied to the new one, but the defaults of the new environment differ. For example, the old server had a certificate and the new one does not yet. Or the old setup had no CDN and the new setup has one.

Prepare a checklist before the move. Make sure the home and siteurl values in the database point to the new address. Instead of copying the old .htaccess as it is, move only the rules you need. Confirm that the certificate is active in the new environment, and switch DNS only after that.

• Compare the SSL status of the old and new environments before the move.
• Make sure the database holds no leftover old domain.
• Test on a temporary address first, then go live.
• On migration day, collect all redirect rules in one place.

If the server configuration is not yours, run these steps together with your hosting provider. That way, the provider announces its own redirects in advance.

How do you prevent the redirect loop from coming back?

A redirect loop usually appears right after a change: a domain move, an SSL install, a new CDN, or a theme or plugin update. So the prevention is a small checklist before and after each change.

1. Pick one canonical address: HTTPS, and either www or non-www.
2. Enforce that choice in one place only and switch it off in the other layers.
3. Before a change, back up .htaccess or the Nginx file, wp-config.php, and the database.
4. After a change, test all four addresses with curl: HTTP, HTTPS, www, and non-www.
5. Match the CDN SSL mode to the real state of your origin.

Drawing the redirect map in advance also helps. When you launch a new site, write the old and new addresses into a table. Then you can see which rule moves which address where. To verify domain records, a WHOIS lookup is handy too.

We explain what to ask a provider when you first set up hosting in how to choose web hosting.

When should you not do this yourself and leave it to your hosting provider?

To be honest, we are not a hosting company. We are a digital marketing and web team, and this guide rests on official documentation and standards. So where a step looks risky, we send you to your hosting provider.

• On shared hosting, if SSH and server configuration are closed to you, the provider's support team should fix the rules.
• If you have no backup, do not touch .htaccess, wp-config.php, or the database. Take a backup first.
• On managed hosting, the provider may redirect at its own layer, and your rule can clash with it.
• On a live store that loses sales every hour, ask the provider for priority support instead of trial and error.
• Do not make a change that could break DNS records or email settings on your own.

When you contact your provider, the curl output and the time the error began help most. With those in hand, the support team often finds the loop in the first reply. If you want to plan redirects from day one in a redesign or migration project, our web design service covers that plan too.