Your WordPress site was working fine five minutes ago. Now the browser just spins, then throws “ERR_TOO_MANY_REDIRECTS” or “This page isn’t redirecting properly,” and refreshing only makes it worse. A WordPress too many redirects error means the browser is stuck in a loop: it requests a page, gets told to go somewhere else, requests that new URL, gets redirected again, and never actually lands on a page. The good news is that a redirect loop is almost never a WordPress bug, the same way a WordPress white screen of death is rarely a “broken core files” situation. It’s a mismatch between two or more of the site’s moving parts: the WordPress URL settings, a caching or SSL plugin, the .htaccess file, or a service like Cloudflare sitting in front of the host. Fix the mismatch and the loop stops.
What Causes the WordPress Too Many Redirects Error?
The WordPress too many redirects error is almost always caused by a mismatch between how the site’s URL is configured and how a browser, plugin, or proxy expects to reach it. The four most common triggers are: the WordPress Address and Site Address fields not matching in protocol or www format, a caching or SSL-forcing plugin fighting with a server-level redirect rule, a corrupted .htaccess file, or Cloudflare’s SSL mode set to “Flexible” while the origin server forces HTTPS. More than one of these can be active at the same time, so the fastest path to a fix is identifying which layer is actually issuing the redirect before changing anything.
Before touching any settings, it helps to see the redirect chain directly instead of guessing. Running a header check from the command line shows exactly which URL the server is bouncing the request to, and how many times it happens before giving up.
curl -I -L https://yourdomain.comEach Location: header in the output is one hop in the loop. If the URL keeps flipping between http:// and https://, or between the www and non-www version of the domain, that confirms a URL mismatch. If the same exact URL repeats, the problem is more likely a plugin or a proxy layer like Cloudflare.
Fix #1: Check the WordPress Address and Site Address Settings
Mismatched WordPress Address (URL) and Site Address (URL) fields cause more WordPress redirect-loop errors than any other single issue, according to WPBeginner’s troubleshooting guide on the topic. Both fields need to use the exact same protocol and domain format: either both https://www.yourdomain.com or both https://yourdomain.com, never a mix of the two.
If the site is accessible in wp-admin, go to Settings > General and check both fields. If the admin area itself is what’s stuck in the loop, the fix has to happen at the database level instead. Connect via phpMyAdmin or a database client and run this query, replacing the URL with the correct one:
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name IN ('siteurl', 'home');Adding these two lines to wp-config.php forces the correct URL at the application level even if the database value drifts again later, which is a useful safety net on sites where a plugin or import process keeps resetting it.
define('WP_HOME','https://yourdomain.com');
define('WP_SITEURL','https://yourdomain.com');Fix #2: Clear Browser Cache and Cookies First
Old cached redirects or a stale login cookie can keep reproducing a loop on one specific browser even after the actual server-side cause has been fixed. Testing in a private or incognito window is the quickest way to rule this out, because it starts with a clean cache and no stored cookies for the domain.
If the site loads normally in a private window but not in the regular browser, the server-side configuration is fine. Clear cookies and cached files for the domain specifically, rather than the whole browser, and reload. This step alone resolves a surprising share of “it’s still broken” reports that come in after a real fix has already been applied elsewhere.
Why Does Cloudflare Cause a WordPress Redirect Loop?
Cloudflare causes a WordPress redirect loop when its SSL/TLS encryption mode is set to “Flexible” while the WordPress origin server forces HTTPS on every request. According to Cloudflare’s own SSL/TLS troubleshooting documentation, Flexible mode connects to the origin server over plain HTTP regardless of what protocol the visitor used, so a browser request for https://yourdomain.com gets fetched by Cloudflare as http://yourdomain.com, WordPress immediately redirects that HTTP request back to HTTPS, and the cycle repeats indefinitely.
The fix is a one-time setting change in Cloudflare, not a WordPress change. Log into the Cloudflare dashboard, open SSL/TLS > Overview, and switch the encryption mode from Flexible to Full or Full (Strict). Full (Strict) requires a valid SSL certificate installed on the origin server, so confirm the host has one active before switching, then purge the Cloudflare cache and retest.
Fix #3: Reset a Broken .htaccess File
A single malformed rewrite rule in .htaccess can create a redirect loop that overrides every other setting on the site. Resetting the file to the WordPress default clears out any custom rule that might be the culprit, including leftover rules from a plugin that was removed without cleaning up after itself.
Connect via FTP or the hosting file manager, download the current .htaccess as a backup before touching anything, then replace its contents with the default WordPress block below.
# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPressReload the site immediately after saving. If the loop stops, a rewrite rule was the cause and any custom redirects that were needed (like an old domain redirect) should be added back one at a time, testing after each addition. Editing .htaccess directly is also the same technique covered in more detail in this guide to securing a WordPress login page without a plugin, since both fixes rely on server-level rules rather than a plugin.
Fix #4: Disable Plugins to Isolate the Conflict
If the URL settings, browser cache, and .htaccess file all check out, a plugin is the next most likely cause, particularly SSL-forcing, caching, security, or redirect-management plugins. These need to be disabled at the file level via FTP, not through wp-admin, since the loop may be blocking access to the dashboard entirely.
- Connect via FTP or the hosting file manager and navigate to
/wp-content/plugins/. - Rename the
pluginsfolder to something likeplugins-off. This deactivates every plugin at once without deleting any files. - Reload the site. If the loop is gone, rename the folder back to
plugins. - Reactivate plugins one at a time from wp-admin, reloading the site after each one, until the loop returns. That last plugin activated is the conflict.
Once the conflicting plugin is identified, check its settings for anything related to SSL enforcement, HTTP-to-HTTPS redirects, or URL rewriting. Most of these plugins have a toggle for exactly the behavior causing the conflict, and updating the plugin to its latest version resolves the issue in many cases where it was a known bug.
Could a Redirect Loop Mean the Site Was Hacked?
A redirect loop can occasionally be a symptom of a compromised WordPress site, especially if it appeared suddenly with no recent changes to hosting, plugins, or DNS settings. Malware that injects redirect code into .htaccess, theme files, or the database is a known cause of unexplained redirect behavior, though most redirect loops are still ordinary configuration issues rather than an attack.
If none of the fixes above resolve the loop, or if the redirect sends visitors to an unfamiliar external domain rather than looping on the same site, treat it as a possible security incident rather than a configuration bug. A closer look at the broader warning signs your WordPress site was hacked is worth doing before assuming it’s just a settings mismatch.
How to Stop This From Happening Again
Most redirect loops are preventable with a few standing habits rather than a one-time fix. Keeping the WordPress Address and Site Address settings, DNS configuration, and any proxy service like Cloudflare aligned on the same protocol and domain format from the start removes the single biggest cause of this error entirely. Sites on a properly configured managed WordPress hosting plan tend to run into this less often, since SSL and caching are usually handled at the server level instead of stacked through multiple plugins.
- Set the SSL mode to Full or Full (Strict) in Cloudflare (or any similar proxy/CDN) as soon as the origin server has a valid certificate installed, rather than leaving it on Flexible.
- Keep a clean backup of
.htaccessbefore installing any plugin that touches redirects, caching, or SSL. - Test URL or domain changes (like adding www, moving to HTTPS, or switching hosts) on a staging site first, not directly on the live domain.
- Avoid running two SSL-forcing or redirect-management plugins at the same time. One is enough, and a second one is the most common source of a new conflict.
A WordPress too many redirects error looks alarming because the site becomes completely inaccessible, but it’s one of the more mechanical problems to diagnose once the layers are checked in order: browser cache, WordPress URL settings, .htaccess, Cloudflare or proxy SSL mode, and then plugins. Working through that sequence, rather than changing several settings at once, is what actually pins down the cause instead of masking it.
Frequently Asked Questions
It means the browser is stuck in a redirect loop: the server keeps sending it to a new URL that redirects again, and it never reaches a final page. This is almost always caused by a configuration mismatch, not a WordPress core bug.
Start by checking that the WordPress Address and Site Address settings match exactly, then clear the browser cache, reset .htaccess to the WordPress default, check any CDN or proxy SSL settings, and disable plugins one at a time until the loop stops.
This happens when Cloudflare’s SSL mode is set to Flexible while the WordPress origin server forces HTTPS. Switching Cloudflare’s SSL/TLS mode to Full or Full (Strict) resolves it in most cases.
Yes. Caching and SSL-forcing plugins can conflict with server-level redirect rules or with each other, especially if more than one plugin is trying to force HTTPS at the same time. Disabling plugins one at a time isolates which one is responsible.
Usually not, most redirect loops are configuration issues. But if the loop appeared with no recent changes, or it sends visitors to an unfamiliar external site instead of looping locally, it’s worth checking for other signs of a compromised site.
Leave a Reply