Fix Redirect Loops: Comprehensive Guide to ERR_TOO_MANY_REDIRECTS (htaccess)

If you are seeing an error screen that says something like ERR_TOO_MANY_REDIRECTS, or if your site seems to be stuck in a perpetual loop of bouncing back and forth, I need you to hear this right now: Your website is not permanently broken. What you’re dealing with is one of the most common - and often most confusing - technical hiccups across the entire web.

I have spent years fixing these exact issues for hundreds of clients across every major platform imaginable, from massive enterprise Magento builds requiring complex cache invalidations to simple WordPress blogs that just need a minor setting adjusted. I know how stomach-dropping it feels when your site simply… refuses to load and throws up a cryptic error code. Rest assured, however, because we are going to walk through this methodically, much like an experienced mechanic diagnosing an engine failure point by point.

The good news is that ERR_TOO_MANY_REDIRECTS doesn’t mean anything is fundamentally shattered; it means some piece of logic - a rule written in code, a setting flipped in the dashboard, or perhaps even just a misplaced line of text - is instructing your browser to go somewhere, and then another conflicting instruction is telling it to immediately go back again, over and over. This cycle continues until the browser gives up and throws that error message at you.

This guide isn’t designed merely to give you a quick fix; we are going to teach you exactly why this occurred so that you understand how to prevent it from happening in the future. We will address every potential point of failure, whether you are sitting comfortably in a graphical control panel or deep into the command line via SSH.

---

Before You Start: The Essential Safety Protocol

DO NOT TOUCH ANYTHING until this warning has sunk in. When dealing with live production websites - the ones your customers rely on - making changes carries an immediate and potentially catastrophic risk. If anything goes wrong because of an edit you made under stress, we must be able to revert the entire system instantly. This is .

1. BACKUP EVERYTHING: Before even considering touching .htaccess, modifying SSL settings, or running any database commands:

• Files: Use FTP or your hosting File Manager to download a complete, zipped copy of your root directory (the entire website folder). This gives you an immediate rollback point for file structure.
• Database: Use phpMyAdmin or your host’s dedicated backup tool to export the site’s entire MySQL/MariaDB structure. This protects all content and settings stored in tables.

2. TEST ENVIRONMENT: If at all possible, replicate your entire website on a staging environment. This is hands down the safest approach because it allows you to intentionally break the system and experiment with fixes without impacting real visitors or revenue streams.

---

Understanding The Symptom: What is ERR_TOO_MANY_REDIRECTS?

If you are seeing this error, I know it’s incredibly frustrating and frankly, alarming. It feels like your website has completely broken logic. But please try not to stress; this specific error means that something on the site is giving itself conflicting instructions - it’s stuck in a digital loop. Think of it less like a catastrophe and more like calling a friend who immediately calls you back, which makes you call them again, until both people are talking in circles indefinitely. No one ever gets to the actual conversation or destination.

When this looping behavior occurs on a website, it is nearly always tied directly to how the site is instructed to handle its address (the URL) or how it manages security protocols (specifically, the jump between HTTP and HTTPS).

What Your Site Should Be Doing

To help you visualize what’s going wrong, here is the ideal sequence of events that should happen when a user lands on your page:

1. A user types in http://example.com (This address signals an unsecured connection).
2. The server correctly identifies this and intercepts it, stating: “Wait a minute, you need to be secure!” It then automatically redirects the user safely over to https://www.example.com.
3. The HTTPS security process completes its handshake. However, the site’s theme or one of your installed plugins immediately checks the rules again and says, “Hold on - did they forget the ‘www’?” And it attempts to redirect back to an insecure version like http://example.com (or sometimes it just drops the entire protocol structure).
4. This cycle repeats endlessly $\rightarrow$ The dreaded Error.

Common Causes: Where Do These Redirect Loops Originate?

When your site starts bouncing between pages - that endless redirect loop - it feels like a nightmare. Please know that even if it looks complicated, these issues are rarely caused by one single failure point. Instead, they usually stem from an interaction conflict between two or three different systems on your site that disagree fundamentally on what the correct address should be. Understanding where those conflicts live is really half the battle in getting you back online.

1. The SSL Protocol Conflict (HTTP vs HTTPS)

This is, without a doubt, by far the most common culprit we encounter. Think of this as having multiple layers of security handling your connection, and those layers are actively fighting each other:

• The Load Balancer/CDN Layer (e.g., Cloudflare): This specialized service sits in front of your site like a traffic cop. When you set up SSL here, it handles the initial secure handshake for visitors.
• The Pitfall: Here is where most people get tripped up. If you configure this layer to communicate with your actual web server (the origin) using unsecured HTTP instead of HTTPS, the moment that traffic hits your server, your server thinks something is wrong and attempts to redirect it back to HTTPS. This attempt immediately restarts the loop process, causing failure.
• The Server Layer (.htaccess): Your server might have a rule in its configuration file (like .htaccess) that says: RewriteCond %{HTTP_HOST} !^www\. [NC]. This is a standard way to force users who visit without “www” to add it. But if this specific rule runs after an SSL redirect has already happened, it can conflict violently with your primary protocol rewrite rules (the ones that handle the http to https switch).

2. The WWW vs Non-WWW Conflict

Some visitors and clients prefer addressing a site as example.com, while others are trained to use www.example.com. Both of these formats technically point to the same website, but they create technical headaches for servers.

• The Problem: You absolutely must choose one single, authoritative version. If your server has rules forcing traffic from A to B, and a completely separate set of rules (perhaps generated by an aggressive caching plugin) forces traffic from A back to A while simultaneously trying to apply an SSL rule on top of everything, you are guaranteed instant failure.
• The Fix Principle: You need to pick one standard - for example, always forcing non-www links (example.com). redirect and internal link across the entire site must point exclusively to that chosen single version.

3. CMS and Database Misconfigurations (The Silent Killer)

Sometimes the problem isn’t a piece of bad code; it’s something deeper - the data itself is corrupted or misleading, which acts exactly like broken code. This is often the “what the manual doesn’t tell you” issue.

• Database siteurl: Many Content Management Systems (CMS), especially WordPress, store a core setting in the database that defines the site’s primary URL. If this value was manually edited or changed to use HTTP (http://example.com) while your server is running mandatory HTTPS redirects globally, the core piece of code responsible for generating links thinks it’s operating on unsecured HTTP. Because it detects this discrepancy, it triggers an immediate redirect loop in a desperate attempt to fix itself.
• Hardcoded URLs: Similarly, plugins or theme options might have stored the site address internally in a way that bypasses all standard rewrite rules you’ve set up, forcing the system into error state.

Step-by-Step Troubleshooting: The Fix Protocol (From Easiest to Hardest)

Please know that encountering these kinds of loops is incredibly stressful, and it feels like the whole site has simply vanished. Take a moment; we are going to approach this systemically. We will use an elimination process - we start by disabling everything non-essential and then reintroducing functionality piece by piece until we pinpoint exactly where the loop is originating.

Phase 1: Isolation and Reset (The First Things to Check)

Step A: The .htaccess Neutralization (Critical First Move)

Since redirect issues are almost always caused by a poorly written or conflicting rule, this is our starting point. We must temporarily remove the variable that holds those rules so we can test the core function of your site without interference.

Instructions:

1. Via FTP client or your hosting File Manager interface, navigate to your site’s root directory (public_html).
2. Find the file named .htaccess.
3. Rename it. Change it to something like .htaccess_BROKEN. Please do not delete this file. Renaming it is crucial because it ensures that if we need to restore those rules later, they are still safely stored, and critically, removing the live file forces the server to use its default, non-redirecting behavior for testing purposes.

Test: Try loading your site now.

• If the site loads perfectly: This means the problem was 100% contained within that .htaccess file (it is most likely a conflicting SSL or www rule). You can confidently proceed to Phase 2.
• If the error persists: The issue lies deeper - it’s likely residing in your server configuration, database, or core CMS files, not just the simple redirect rules. In this case, skip down and move directly to Step B.

Step B: Cloudflare and SSL Settings (The External Check)

If you are using a Content Delivery Network (CDN) like Cloudflare, remember that it introduces an entire layer of potential failure points that exist outside of your actual hosting control panel. We need to check its configuration carefully.

Instructions (Via Cloudflare Dashboard):

1. Go to the SSL/TLS tab within the dashboard.
2. Set the encryption mode to Full (Strict). This setting tells Cloudflare not only to enforce HTTPS but also confirms that the connection between Cloudflare and your origin server must be secure, which is critical for resolving loops.
3. Check the Edge Certificates section thoroughly to ensure the SSL certificate is correctly installed and valid for all domains and subdomains you use on your site.

Niche Expert Anecdote (Cloudflare Battle Scar): I remember one client who had the perfect .htaccess rules, but their redirect loop was secretly caused by Cloudflare’s Origin Pull setting. They were forcing a specific header that directly contradicted the protocol being enforced at the server level, making the error look like it came from the server when the true source of conflict was actually the CDN.

Phase 2: Deep Dive and Correction (The Technical Fix)

If Phase 1 did not resolve the redirect loop, we must now address the structural elements that make up your site. This is where many people get overwhelmed, but - we will go through this step by step.

Step C: Fixing Database URLs (The CMS Core Check)

This crucial step requires dedicated access to your database management tool (phpMyAdmin). If you are running WordPress, pay extra attention here; this check is mandatory for proper operation.

Instructions:

1. Export your complete database backup first (as we prepared earlier in the process).
2. Open the resulting SQL file in a text editor or utilize phpMyAdmin’s query tab directly.
3. Search for all instances of http:// and replace them systematically with https://.
4. Specifically, dedicate time to checking the following critical tables/options:

• The main site options table (you must look specifically for entries labeled siteurl and home).
• Any custom plugin settings that store URLs directly in the database, as these are often overlooked.

5. CLI Method (For Advanced Users): If you have SSH access and prefer running a script to search/replace in the database - which is generally safer than manual queries for large sites - you can use this structure:

# Example command structure - please ensure you replace these bracketed items
mysql -u [username] -p [database_name] "UPDATE wp_options SET option_value = REPLACE(option_value, 'http://', 'https://');"

Step D: Rebuilding the Rules (The Controlled Implementation)

Once you are absolutely confident that your database and SSL settings now point exclusively to https://www.example.com (or whatever your desired primary URL is), we can safely restore or create a clean .htaccess file, knowing the structural foundations are sound.

Instructions:

1. Create a brand-new, clean .htaccess file in the root directory of your website.
2. Add only these rules first (This block acts as our standard “secure” template):

# BEGIN SSL Security Rules
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP:Protocol} !https [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END SSL Security Rules

3. Test the site immediately after saving this file. If it functions correctly, you can now proceed to add your specific www rules below this secure block in a controlled manner.

Common Mistake Alert: You must not try to mix protocol enforcement (i.e., fixing http to https) and path enforcement (i.e., fixing non-www to www) within separate, sequential blocks of code without proper separation. They need to be handled cleanly by the server structure itself, or we will unfortunately fail again.

Phase 3: Advanced Troubleshooting (If Nothing Else Works)

If your site is still looping after completing all the steps detailed above, it indicates that the issue has moved beyond simple configuration files and resides in a deeper caching layer or an extremely aggressive plugin conflict.

• Server-Level Caching: Check whether your host utilizes advanced systems like Varnish Cache or Redis Object Cache. If these deep caches are holding onto old, broken redirect rules (which is very common), you must manually flush them via your hosting control panel’s cache management tools or through an SSH command (for example: redis-cli FLUSHALL).
• Theme/Plugin Conflict: This is the final test. Deactivate all plugins completely and immediately switch to a default, simple “Hello World” theme. Test the site right away. If it works perfectly, you have isolated the problem area. Now, reactivate the plugins one by one - testing the site after each activation - until the error returns. The last plugin you activated is your culprit.

---

Five Common Mistakes That Make Redirect Loops Worse

When we’re dealing with broken redirects and loops, it can feel like troubleshooting a magic trick - you fix one thing only to break three others. Before we dive into the fixes, though, you need to know what common pitfalls are making your current redirect loop situation worse. Knowing what not to do is just as crucial as knowing how to actually correct the problem. Please watch out for these five specific traps:

1. Using “Both” SSL: Setting rules in your .htaccess file that enforce both http and https simultaneously is a near-guarantee for conflict. You must choose one definitive method of enforcement. Typically, it is far better to let the server handle HTTPS redirection through dedicated hosting settings (like within cPanel or Plesk) rather than trying to force it using a general Apache rule in your file.

2. Caching Overload: A common assumption is that simply clearing out the cache plugin inside WordPress is sufficient. This is rarely the case. For a truly clean slate, you must clear all layers of caching: the CDN edge cache (tools like Cloudflare), any server object cache (like Redis or Varnish), and finally, the client-side browser cache (always test by opening your site in an Incognito/Private browsing window).

3. Manual Protocol Editing: Never edit raw PHP files just to hardcode a redirect path. Instead, you must utilize dedicated, tested functions provided either by your specific framework or the CMS core itself. Manually editing core logic is inherently brittle and drastically increases your risk of introducing subtle, hard-to-find errors later on.

4. The “Copy-Paste” .htaccess: This rule is absolute: Never take a generic, copied .htaccess file found floating around Google or forums. You must adapt the rules specifically to match both your chosen protocol (www/non-www) and your required security level (HTTPS). These files are hyper-specific and require custom tailoring.

5. Ignoring HTTP Headers: Sometimes the redirect instruction isn’t visible when you simply load a page in your browser; it is often hidden deep within the server response headers. For advanced debugging, the professional method involves running specific command-line tools like curl -I [your site URL]. This action allows you to view all incoming header instructions from the server and pinpoint exactly where the loop is being generated.

‍ When To Call a Professional Site Recovery Specialist

Sometimes, even after diligently following every step in a troubleshooting guide, you hit a wall - a point where the problem feels too deep for simple fixes. That’s okay. The issue might simply be more complex than standard self-help can address.

When the complexity of the break exceeds what basic troubleshooting can resolve, it’s time to bring in someone who specializes in diagnosing the underlying structure. You should connect with a professional site recovery specialist immediately if any of these scenarios sound familiar:

1. The Error is Intermittent: The problem isn’t constant; sometimes the site works perfectly, but other times it randomly breaks into an infinite loop or fails without any clear trigger - no obvious plugin update, no recent content change. This pattern strongly suggests underlying server instability, perhaps stemming from things like a load balancer misconfiguration or deep network routing issues that are invisible to users and basic diagnostic tools.
2. Your Hosting Environment is Inherently Complex: You are running on a shared hosting plan, but the environment itself involves multiple layers of proxying, aggressive caching mechanisms, and security firewalls managed by your host provider. Peeling back these layers requires internal access and deep knowledge that only an expert who has dealt with that specific infrastructure can possess.
3. The Conflict Exists Between Two Major Systems: This happens when you have a highly custom PHP application running behind WordPress, or any other integrated service layer. If both systems are independently trying to enforce different URL structures, rewrite rules, or security parameters simultaneously, they will inevitably conflict with each other.

We don’t just apply bandaids for redirects; we diagnose the entire plumbing system of your digital storefront. Our process involves examining server logs - both the access and error logs - reviewing database schema integrity at a structural level, and analyzing network packet flow to pinpoint the exact instruction point where conflicting commands are being issued.

Your online presence deserves more than just a quick patch applied under pressure; it demands foundational, structural stability. If you have followed these steps and still feel stuck, that is precisely when bringing in an expert guarantees not only full restoration but also preventative architectural advice that keeps future failures from happening.