Your website just went completely unreachable. Visitors are staring at a blank page and a cryptic error message. Your admin dashboard might not load. Revenue is stopping. And you have no idea where to even start looking.
The ERR_TOO_MANY_REDIRECTS error is one of those problems that sounds vague but is almost always caused by one of five very specific, fixable issues. The browser is not broken. Your server is caught in a loop — sending a redirect, receiving a redirect back, and repeating until it gives up after around 20 attempts.
This guide takes a different approach from most troubleshooting articles. Instead of a flat list of things to try, it starts with a diagnosis framework so you can identify your specific cause before touching a single file. Then it covers the exact fix for every platform and configuration scenario, including the Cloudflare SSL mismatch that causes the majority of these errors, WordPress URL setting conflicts, .htaccess problems, and database issues from site migrations.
| WHAT ERR_TOO_MANY_REDIRECTS ACTUALLY MEANS | When you visit a URL, your browser follows redirects up to a limit (typically 20 in Chrome). ERR_TOO_MANY_REDIRECTS means the browser hit that limit without reaching a final page. The server sent a redirect, the browser followed it, the server sent another redirect back to the original URL — and so on. The browser is not malfunctioning. It correctly detected that the redirect chain has no end and refused to continue. The error appears identically whether the loop involves two URLs bouncing between each other or a longer chain of misdirected URLs. |
What a Redirect Loop Looks Like Technically (And Why Browsers Give Up)
Before jumping into fixes, understanding the exact mechanism of a redirect loop explains why the solutions work. Every scenario below involves the same fundamental problem: two or more systems disagreeing about where a URL should point, each one trying to correct the other.
Why Cloudflare Flexible SSL Is the Leading Cause
Cloudflare’s Flexible SSL mode is the single most common cause of ERR_TOO_MANY_REDIRECTS. When Cloudflare is set to Flexible, it accepts HTTPS connections from visitors but then sends plain HTTP traffic to your origin server. If your origin server (or WordPress) has any rule that forces HTTP to HTTPS — which almost every modern server does — it sees the incoming HTTP request and issues a 301 redirect to HTTPS. Cloudflare receives that redirect, strips it back to HTTP again, and the cycle repeats endlessly.
The fix is changing Cloudflare’s SSL mode from Flexible to Full (Strict). This makes Cloudflare send HTTPS to your origin instead of HTTP, which means the origin server sees an HTTPS connection and has no reason to redirect.
How Browsers Stop a Redirect Loop
Chrome, Edge, Firefox, and Safari each have a redirect limit baked into their request logic. Chrome and Edge stop at approximately 20 redirects and return ERR_TOO_MANY_REDIRECTS. Firefox returns NS_ERROR_REDIRECT_LOOP at a similar limit. Safari displays ‘Too Many Redirects’ with its own Safari-specific language. The same underlying loop produces a different error message depending on which browser the visitor uses — which is why it is important to test in multiple browsers when diagnosing.
A key diagnostic insight: if the error only appears in one browser on your machine, the loop is almost certainly stored in that browser’s cookies or cache rather than on the server. Clearing cookies for the specific domain resolves these cases without any server changes.
Diagnosis First: Identify Your Specific Cause Before Touching Files
Most redirect loop guides list ten or fifteen fixes in no particular order, which is why people spend hours trying things that do not apply to their situation. A ten-second diagnosis step eliminates everything that is irrelevant.
The Single Most Important First Test
Open the site in an incognito window (Chrome: Ctrl+Shift+N, Mac: Cmd+Shift+N). Incognito windows start with a completely clean cookie and cache state. If the site loads in incognito but not in your regular browser, the loop is stored in your browser’s cookies for that domain — clear them and move on. If the site does not load in incognito either, the loop is server-side and needs one of the fixes below.
| ! | Do not start editing .htaccess or wp-config.php until you have confirmed the error appears in incognito mode. Roughly 15-20% of people reporting ERR_TOO_MANY_REDIRECTS are experiencing a browser-cached loop that was already fixed on the server — they just need to clear their cookies. Skipping this test wastes time on fixes that are not needed. |
Using curl to Trace the Exact Loop
Before touching any server file, run this command from your terminal to see exactly what is happening at each redirect hop:
curl -I -L https://yoursite.com
The -L flag follows redirects and -I shows response headers. The output shows every hop with its status code and Location header. Look for the point where a URL you already saw starts appearing again — that is where the loop forms. This output tells you exactly which server component is issuing the looping redirect before you touch a single file.
Fix 1: The Cloudflare SSL Mode Problem (Affects Most Sites Behind Cloudflare)
If your site is behind Cloudflare and you are seeing ERR_TOO_MANY_REDIRECTS, this is the first fix to try. It resolves the majority of Cloudflare-related redirect loops and takes under three minutes.
- Log in to dash.cloudflare.com and click the affected domain.
- In the left sidebar, click SSL/TLS, then Overview.
- Check the current mode. If it says Flexible, that is your problem.
- Select Full (Strict). If your origin server does not yet have a valid SSL certificate, install one first (Let’s Encrypt through your hosting panel is free and takes minutes), then change the mode.
- Go to Caching, then Configuration, then Purge Everything. Old redirect caches on Cloudflare’s network can preserve the loop for minutes or hours even after fixing the SSL mode.
- Open the site in a fresh incognito window. The error should be gone.
If you are not sure whether your origin server has a valid SSL certificate installed, check through your hosting control panel (cPanel, Plesk, or your hosting provider’s dashboard). Most hosting providers offer free Let’s Encrypt installation with one click. Full (Strict) requires a valid, trusted certificate on the origin — self-signed certificates work only with Full (not Strict) mode.
Fix 2: WordPress URL Settings and Post-Migration Database Issues
For WordPress sites where Cloudflare is not involved (or where the Cloudflare fix did not resolve the loop), the most common remaining causes involve WordPress’s internal URL settings and the database values set during a site migration.
Checking and Fixing WordPress URL Settings
WordPress stores Site Address (URL) and WordPress Address (URL) in its database. If these values disagree on protocol (http vs https) or www preference (www.yoursite.com vs yoursite.com), WordPress perpetually redirects between them. Go to Settings, then General to check. Both fields must match exactly.
If the dashboard is inaccessible because the loop blocks wp-admin, add these lines to wp-config.php directly above the require_once for wp-settings.php:
define(‘WP_HOME’, ‘https://yoursite.com’);
define(‘WP_SITEURL’, ‘https://yoursite.com’);
Changes in wp-config.php override the database values immediately. This lets you access the dashboard to make permanent changes. Remove the lines once you have corrected the values in Settings, or leave them in wp-config.php permanently — both approaches are valid.
Isolating Plugin Conflicts via FTP
If fixing URLs does not resolve the loop, a plugin is the likely cause. Redirect management plugins, HTTPS enforcement plugins, SEO plugins like Yoast and Rank Math, and caching plugins all have the ability to generate redirect rules. When two plugins both try to manage redirects, or when a plugin’s redirect rules conflict with server-level rules, the loop forms.
The fastest diagnosis: rename the plugins folder entirely via FTP. Connect to your server, navigate to wp-content, and rename the plugins folder to plugins_disabled. Reload the site. If the loop stops, rename the folder back to plugins and reactivate plugins one at a time from the WordPress dashboard until the loop returns — that is your conflicting plugin. Common offenders include Really Simple SSL, SSL Insecure Content Fixer, WP Force SSL, and any plugin that writes redirect rules.
| ! | After identifying and disabling the conflicting plugin, check whether its SSL or HTTPS redirect functionality was the only thing enforcing HTTPS on your site. If you disable it, ensure your server panel or .htaccess has the HTTPS enforcement rule instead before removing the plugin entirely. |
Resetting .htaccess
If plugin isolation does not fix the loop, a bad .htaccess rule is the next suspect. Connect via FTP to your site root (the folder containing wp-admin and wp-content). Rename .htaccess to .htaccess.bak. Reload the site — if the loop stops, the old .htaccess was causing it.
To regenerate a clean .htaccess, go to Settings, then Permalinks, and click Save Changes without changing anything. WordPress writes a fresh default .htaccess file. The clean WordPress default .htaccess contains only WordPress’s URL routing rules with no HTTPS redirects — those belong at the server level, not in .htaccess.
Fix 3: The SSL Connection and HTTPS Enforcement Stack Problem
One of the most overlooked causes of redirect loops is having HTTPS enforcement set up in more than one place simultaneously. Each system correctly enforces HTTPS, but the enforcement signals conflict with each other — each one redirects traffic that the other has already redirected.
The three most common places HTTPS enforcement lives in a WordPress setup:
- Server-level: your hosting panel has a ‘Force HTTPS’ setting that redirects all HTTP to HTTPS
- .htaccess level: a RewriteRule or Redirect directive forces HTTP to HTTPS
- Plugin level: Really Simple SSL, WP Force SSL, or a security plugin enforces HTTPS via PHP
Having all three active simultaneously means every HTTP request gets redirected by the server, which redirects it again via .htaccess, which gets picked up by the plugin, which redirects it again. The correct approach is to use exactly one method and remove the others. The server-level setting is the most efficient and takes priority. If your hosting panel handles HTTPS enforcement, remove the .htaccess rule and disable any HTTPS-enforcing plugin.
Redirect Loops and SEO: What Google Sees and Why Speed Matters
A redirect loop does not just frustrate visitors — it has concrete, measurable SEO consequences that persist even after the loop is resolved if the episode lasted long enough.
During a Live Redirect Loop
While the loop is active, Googlebot cannot access your pages. It receives the same ERR_TOO_MANY_REDIRECTS response any browser does. If the loop persists for 24-48 hours, Google may start treating the affected URLs as temporarily unavailable. Longer outages can cause pages to be dropped from the index. Search Console will log the crawl errors under Coverage, which you should check after resolving any redirect loop.
Even After the Fix: Redirect Chain Debt
A redirect loop that gets fixed leaves behind no permanent damage to rankings, provided the fix happens quickly. However, many sites that experience redirect loops also have longer redirect chains in their general URL structure that pre-existed the loop. Every hop in a redirect chain adds latency (100-300ms per hop) and dilutes the link equity passed through that redirect. A 4-hop chain from the original URL to the final destination passes roughly 85% of the original PageRank rather than 100%.
After fixing a redirect loop, audit your broader redirect structure using Screaming Frog or Redirect Checker. Any URL taking more than 2 hops to reach its final destination should be updated to point directly there.
Platform-Specific Fixes and Debugging Tools
The exact commands and file locations vary depending on whether you are running Apache, Nginx, a managed WordPress host, or a custom stack. These are the environment-specific fixes and the tools that let you trace the loop before touching anything.
Reading Server Logs to Pinpoint the Cause
If none of the standard fixes resolve the loop, server logs contain the exact redirect chain. For Apache-based servers, access error logs through cPanel under Logs, or directly at /var/log/apache2/error.log via SSH. For Nginx, logs are typically at /var/log/nginx/error.log. The log will show the exact URL being redirected and the Location header it is redirecting to — you will see the loop clearly as the same URL pair appears repeatedly.
For WordPress specifically, enabling WP_DEBUG helps trace redirect calls in PHP:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
Add these to wp-config.php, reproduce the error, then check wp-content/debug.log. Look for wp_redirect() calls or hook callbacks that fire during the request and point to a redirect being issued inside PHP code.
Prevention: The Rule That Eliminates Most Redirect Loop Risk
The single most effective preventive practice is this: manage HTTPS enforcement in exactly one place and document where that place is. Whether it is your server panel, .htaccess, or a plugin, pick one and ensure the others are inactive or not present. Every redirect loop caused by conflicting HTTPS enforcement happens because someone added a second enforcement layer without removing the first.
For sites using Cloudflare, set the SSL mode to Full (Strict) from the day the site is set up and do not change it. Changing Cloudflare’s SSL mode after setup is the most common trigger for a previously working site suddenly developing a redirect loop.
Frequently Asked Questions
What causes ERR_TOO_MANY_REDIRECTS?
The error occurs when a URL redirects to another URL which redirects back to the original (or through a longer chain that never reaches a final page). The five most common causes are: Cloudflare set to Flexible SSL mode while the origin server forces HTTPS; WordPress Site URL and WordPress Address settings disagreeing on protocol or www; HTTPS enforcement active in multiple places simultaneously (.htaccess, plugin, server panel); corrupted or conflicting .htaccess redirect rules; and stale browser cookies storing an old redirect chain that was already fixed on the server.
How do I fix ERR_TOO_MANY_REDIRECTS if I cannot access my WordPress dashboard?
Two approaches work when the dashboard is unreachable. First, add define(‘WP_HOME’, ‘https://yoursite.com’) and define(‘WP_SITEURL’, ‘https://yoursite.com’) to wp-config.php — this overrides the database URL values and may restore dashboard access if a URL mismatch was the cause. Second, connect via FTP and rename the plugins folder from ‘plugins’ to ‘plugins_disabled’ — this disables all plugins and may allow the site to load if a plugin was causing the loop. Once the dashboard is accessible, fix the underlying issue and re-enable plugins one at a time.
Does Cloudflare cause ERR_TOO_MANY_REDIRECTS?
Cloudflare itself does not cause the error, but Cloudflare’s Flexible SSL mode does when combined with a server or WordPress configuration that forces HTTPS. Flexible SSL makes Cloudflare send HTTP to your origin server. If the origin forces HTTP to HTTPS, the resulting loop is infinite. The fix is changing Cloudflare’s SSL mode from Flexible to Full (Strict) in the SSL/TLS > Overview section of your Cloudflare dashboard.
Why does the error appear in Chrome but not Firefox, or vice versa?
If the error appears in only one browser, it is almost certainly a browser-specific cookie or cache issue rather than a server problem. Different browsers store redirect information in their cookies independently. Clear the cookies and cache specifically for the affected domain in the browser showing the error. Test in an incognito window first — if incognito works, clearing cookies resolves it.
Can ERR_TOO_MANY_REDIRECTS hurt my SEO?
Yes, if it persists for more than a few hours. While a redirect loop is active, Googlebot cannot crawl or index the affected pages. Extended loops (24-48+ hours) can cause pages to be dropped from the index. After fixing the loop, check Google Search Console under Coverage to see if any crawl errors were logged. Submit a URL inspection request for the affected pages to prompt Google to re-crawl them. Rankings typically recover within days of the loop being resolved, but index recovery depends on how long it was active.
How do I prevent redirect loops from happening after an SSL certificate installation?
The key is using exactly one HTTPS enforcement method after installing SSL. When you install an SSL certificate, your hosting panel typically adds a ‘Force HTTPS’ setting. If you previously had an .htaccess rule or a WordPress plugin enforcing HTTPS for a different reason, you now have two enforcement layers that can conflict. After SSL installation, check: your server panel for Force HTTPS setting, your .htaccess file for any RewriteRule that redirects HTTP to HTTPS, and your WordPress plugins for any SSL enforcement plugin. Keep exactly one and remove the others.
What is the difference between a redirect loop and a redirect chain?
A redirect loop is circular — URL A redirects to URL B which redirects back to URL A (or eventually back to something already in the chain). The browser never reaches a final destination and returns ERR_TOO_MANY_REDIRECTS. A redirect chain is linear — URL A redirects to URL B redirects to URL C which finally loads. Chains do not cause this error but do reduce page load speed and dilute SEO link equity with each additional hop. Best practice is to keep chains to one or two hops maximum by updating old redirects to point directly to the final destination URL.
