How to Fix ERR_TOO_MANY_REDIRECTS in WordPress (6 Steps)

To fix ERR_TOO_MANY_REDIRECTS, find the rule that sends the browser in circles and remove it or make it agree with the others. On our test site, each fix took under a minute once we knew which layer was at fault.

We reproduced the error on a WordPress 7.1 test site with two rules that pointed at each other and tested every fix in October 2026. The steps below are the ones that cleared the loop, and each shows the real screen.

You get what the error means, the five places a loop starts, six ordered steps with code, and how to stop it coming back. Each step runs from the cheapest check to the riskiest.

What Does ERR_TOO_MANY_REDIRECTS Mean?

ERR_TOO_MANY_REDIRECTS is the error Chrome shows when a page keeps redirecting and never settles on a final URL. The Fetch Standard tells browsers to return a network error once a request reaches 20 redirects. Chrome words it as “redirected you too many times.”

A redirect loop is simple to describe. Page A sends the visitor to page B, and page B sends the visitor back to page A. The browser follows the chain until it hits its limit, as the Fetch Standard’s redirect rules describe. Then it stops. To see where your own loop starts, trace the redirect chain hop by hop with a free checker.

Other browsers word the message differently, but the cause is the same loop. WordPress sites hit too many redirects often, because plugins, server rules, and site settings can each add a redirect.

What Causes a Redirect Loop in WordPress?

A redirect loop starts when two rules disagree about the one correct URL for a page. In WordPress that means cookies, the site URL settings, server rules, plugin rules, or HTTPS settings at the server or CDN. Searches for WordPress too many redirects almost always end at one of these five places.

• Cookies and cache: A stored cookie can send the browser down a path your server no longer uses. Chrome’s own error page suggests deleting your cookies.
• URL settings: The WordPress Address and Site Address can disagree with a server rule about www or https.
• Server rules: An .htaccess rule or an Nginx redirect can fight with WordPress about the preferred hostname.
• Plugin rules: A redirect plugin, an SEO plugin, or a security plugin can add rules that point at each other.
• HTTPS and CDN settings: Cloudflare says redirect loops occur when an origin redirects requests in a way that conflicts with the encryption mode you chose.

Three Redirect Loops We Reproduced

We built three loops on a WordPress 7.1 test site, one for each of the most common causes. Each one produced the same error in Chrome, but each needed a different fix. Seeing them side by side shows why the order of the steps matters.

• Mismatched hostnames: We set both site addresses to the www version. Then we added an .htaccess rule that sends every www request to the bare domain. The site redirected visitors to www, and the rule redirected them back. Setting both addresses to the bare domain ended the loop.
• Two plugin rules: A test plugin redirected one page to a second page, and the second page back to the first. Only those two pages looped, while the home page and wp-admin kept working. Deactivating the plugin fixed it.
• Forced HTTPS at the origin: An .htaccess rule redirected every plain HTTP request to HTTPS. A Flexible SSL setup would meet the same rule on every visit, because Cloudflare sends HTTP to the origin. A rule that trusts the proxy header returned 200 instead.

None of the three was a browser problem. Clearing cookies fixed none of them. That is why Step 1 is a quick test and not the whole fix.

How to Fix ERR_TOO_MANY_REDIRECTS in WordPress

Work through six steps in order. Test in a private window, trace the redirect chain, match the WordPress URLs, reset .htaccess, turn off plugins, and check HTTPS rules. Back up your files and database first, because steps 3 to 6 change live settings, and stop at the first step that clears the loop.

Step 1: Rule Out Your Browser

Open the site in a private window first. If it loads there, the cause is a stored cookie or a cached redirect in your normal browser. You can fix that without touching the site.

To clear cookies in Chrome, follow Google’s cookie instructions for deleting all cookies, which are short:

1. Open the menu: Select More at the top right. Then select Delete browsing data.
2. Pick a time range: Choose Last hour or All time.
3. Select the data: Tick Cookies and other site data.
4. Confirm: Select Delete data. Then reload the page.
   

If the private window shows the same error, skip ahead. On our test site a fresh browser session with no cookies hit the same loop, which told us the cause sat on the server.

Browsers can also remember a redirect. After we removed a 301 rule from our test server, Chrome in the same session still sent us to the new address. A private window or a cleared cache avoids that trap after you fix a loop.

Step 2: Trace the Redirect Chain

A trace shows exactly which URLs bounce. The curl tool follows each redirect and prints where it goes next. That lets you see the loop without guessing. Run it from a terminal with your own address in place of the example:

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

The curl manual says the flags each do one job:

• -s: Silent mode hides the progress meter and other messages.
• -I: It sends a HEAD request and curl gets only the headers of each page.
• -L: It follows redirects, and together with -I it shows the headers from every page.
• –max-redirs 5: It stops after five redirects. Curl’s default limit is 50.

On our test site the output alternated between two addresses. The www version of the site sent visitors to the bare domain, and the bare domain sent them back to www.

Read the pattern before you fix anything. Two hostnames that swap places point to a URL setting or a server rule. A scheme that flips between http and https points to an HTTPS setting or a CDN.

A loop that only affects a few pages, while the rest of the site loads, points to a redirect rule that matches those paths. That is a plugin or a server rule.

Step 3: Match the WordPress Address and Site Address

Open Settings > General and compare WordPress Address and Site Address with the URL your visitors use. Both should match it exactly, including https and the www choice. A mismatch is an easy way to create a loop because WordPress redirects every request to the address it has stored.

If you cannot reach the dashboard, set both addresses in wp-config.php instead. WordPress says setting these constants overrides the database values without changing them. Add the lines above the comment that says to stop editing:

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

On our test site the loop cleared after a short wait. Both fields in General Settings turned gray and could not be edited while the constants were set. The docs add that the URL reverts to the database value if you remove the lines. Keep them or fix the database values too.

To read what WordPress has stored, run the two WP-CLI commands below. You can also open the home and siteurl rows in the wp_options table.

wp option get home
wp option get siteurl

You can fix the stored values with WP-CLI as well:

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

Step 4: Reset the .htaccess File

On Apache, an old rule in .htaccess can fight with WordPress. Rename the file to .htaccess-old in your hosting file manager or over FTP. Then reload the site. On our test site the loop was a rule that forced the bare domain. Renaming the file ended it.

Go to Settings > Permalinks and press Save Changes. On WordPress 7.1 that wrote a fresh .htaccess file with the default rules on our test site. If you cannot reach the dashboard, create the file by hand with the default WordPress rules:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Nginx has no .htaccess file. Ask your host to check the server block for return 301 and rewrite rules that point back at each other.

Step 5: Turn Off Plugins and Test the Theme

Plugins that add redirects are the next suspect. Open the Plugins screen, switch off every plugin, and reload the site. If the loop stops, switch them back on one at a time and test after each one until the error returns.

If you are locked out, rename the plugins folder to plugins_disabled over FTP, and the loop should stop. On our test site, opening wp-admin while that folder was renamed cleared the active plugin list.

After we renamed the folder back, every plugin was inactive. We turned them on one at a time. Our guide to checking for plugin conflicts covers the full routine.

If no plugin is the cause, switch to a default theme, because a theme can also add redirects.

Step 6: Fix HTTPS Rules and the Cloudflare SSL Mode

HTTPS loops come from one layer forcing HTTPS while another layer undoes it. Cloudflare says that in Flexible mode it sends unencrypted requests to your origin over HTTP. A loop follows if your origin then redirects every HTTP request to HTTPS.

Cloudflare lists more loop causes, and each one comes down to the origin or a rule fighting the setting:

• Full or Full (strict): Loops occur when the origin redirects HTTPS requests back to HTTP.
• Always Use HTTPS: Loops occur when the origin redirects HTTPS requests to HTTP.
• HSTS: Loops occur if the origin redirects HTTPS to HTTP, or if the encryption mode is Off.
• Redirect rules and Page Rules: Conflicting rules can send requests back and forth between hosts.

We reproduced the origin side of this on our test site. An .htaccess rule that forces HTTPS sent every plain HTTP request to the same https address, again and again. That is what a Flexible setup would see on every visit.

Cloudflare’s troubleshooting page lists two fixes. You can remove the HTTPS redirects from the origin. Or you can switch the encryption mode to Full or Full (strict), which needs an SSL certificate on the origin.

Cloudflare also says to enforce HTTPS at its edge instead of at the origin. We did not test Cloudflare itself, since that needs an account and a live domain.

If you must keep the rule, make it trust the header that tells your server the visitor used HTTPS. Cloudflare says X-Forwarded-Proto identifies the protocol the visitor used to reach Cloudflare. This rule skips the redirect when that header says https:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

With the header, our test site returned 200. Without it, the same request still got the 301. That is right for a visitor who reaches the server directly over HTTP. Anyone can send that header to a server that accepts direct traffic. Use this rule only when your server sits behind a proxy.

If the browser shows a handshake error rather than a loop, read how to fix ERR_SSL_PROTOCOL_ERROR.

Trace a Redirect Loop With Chrome DevTools

Chrome DevTools can show the same redirect chain without a terminal, and it works on any computer with Chrome. Open the Network panel, tick Preserve log, and reload the page. The Status column then lists each hop, and the repeating URLs show the loop at a glance.

Chrome’s Network panel reference says to check the Preserve log box to save requests across page loads, which keeps every redirect on screen. Look for a run of 301 or 302 rows that bounce between two addresses.

We traced our test loop with curl, which also works on a server with no browser. Use whichever tool you already have open.

Which Symptom Points to Which Fix

Match what you see to the likely cause, and jump to the right step. The table below lists the six patterns we met while testing, with the step that fits each one. Start with the row that looks most like your site.

What you see	Likely cause	Step
The site loads in a private window	Browser cookies or a cached redirect	Step 1
Two hostnames swap places in the trace	WordPress URL settings or a server rule	Steps 3 and 4
The scheme flips between http and https	An HTTPS rule or a CDN setting	Step 6
Only a few pages loop	A plugin or server rule for those paths	Steps 4 and 5
It began after you turned on Cloudflare	Flexible SSL with an origin redirect	Step 6
It began after a domain change	The WordPress Address or Site Address	Step 3

How to Confirm the Fix

Confirm the fix by running the curl trace again, opening the site in a private window, and testing the pages that matter most. The trace should end in a 200 response after one redirect at most. Test the login page, the cart, the checkout, and a post, because a loop can hit single paths.

On our test site, the bare domain returned 200 straight away once the rules agreed. The www address returned one 301 and then 200, which is a normal redirect and not a loop.

Common Mistakes When Fixing Redirect Loops

Most failed fixes come from changing one layer while another layer keeps the loop alive. Five mistakes caused most of the dead ends we hit while testing on our WordPress 7.1 site. Avoid them and you save at least one round of testing.

• Editing inside the WordPress block: WordPress overwrites the lines between BEGIN WordPress and END WordPress in .htaccess, as the comment in the file it wrote on our test site says. Put your own rules above or below the markers.
• Leaving the constants behind: WP_HOME and WP_SITEURL override the database, and the URL reverts to the database value if you remove them. Fix both places, or write down that the constants are there.
• Testing only the home page: A loop can hit single paths, as our plugin test showed. Trace the exact URL that fails.
• Fixing two layers at once: Change one thing and trace again. Otherwise you cannot tell which change worked.
• Skipping the backup: Copy .htaccess and wp-config.php before you edit them.

How to Prevent Redirect Loops

Prevent redirect loops by keeping one rule for each decision. One layer should own the https choice, and one layer should own the www choice. When two layers both try to decide the same thing, a loop is only a matter of time.

• One HTTPS rule: Pick the server, a plugin, or the CDN to force HTTPS, and remove the others.
• One hostname choice: Make the WordPress Address, Site Address, and server rules agree on www or the bare domain.
• Checks after changes: Run the curl trace from Step 2 after any migration, plugin change, or CDN setting change.
• Backups first: Copy .htaccess and wp-config.php before you edit them. A bad rule is then one rename away from gone.
• A written redirect list: Keep a short list of every redirect rule and which layer owns it. The next person then sees the full picture.

Does ERR_TOO_MANY_REDIRECTS Hurt SEO?

A redirect loop hurts SEO because search crawlers also stop following it. Google says its crawlers follow up to 10 redirect hops by default, and a loop never reaches a final URL. Search Console reports failed redirections as 3xx errors.

Google ignores the content of the redirecting URL and processes the final target instead, according to the same Search Central page. A page that never reaches a target has nothing to process. Our guide to the 302 status code covers temporary redirects.

Redirect chains that do end are not loops, but they still cost time. Each hop adds a request before the final page. Shorten chains where you can. Point old URLs straight at their final address.

When to Ask for Help

Ask for help when you cannot reach wp-admin, your files, or your database, or when the loop returns after every fix. A loop that survives all six steps often lives in a host setting or a firewall rule. A CDN dashboard that only the account owner can see is another place to look.

Our team can trace it for you through our WordPress maintenance services. Send the output of the curl trace from Step 2 and we can see the loop at once.

Give your host or developer these four facts so they can start straight away:

• The trace: The curl output from Step 2 for the URL that fails.
• Recent changes: A migration, a new plugin, an SSL change, or a CDN setting.
• Your stack: Apache or Nginx, and whether you use Cloudflare or another CDN.
• Steps taken: The steps above that you completed and what each one changed.

Never send passwords in the same message. A good host will give you a secure way to share access.

Conclusion

ERR_TOO_MANY_REDIRECTS always means two rules disagree. Rule out your browser, trace the chain with curl, and let the pattern point to the layer at fault.

Then fix that layer: the WordPress addresses, the .htaccess file, a plugin, or the HTTPS and Cloudflare settings. Keep one rule for each decision, and run the trace again after every migration or plugin change.

Frequently Asked Questions (FAQs)