You flipped the switch to HTTPS this morning, expecting nothing more dramatic than a tidy green padlock and a small bump in trust signals. Instead, your homepage refuses to render, Chrome throws ERR_TOO_MANY_REDIRECTS, and the contact form your customers actually use is invisible behind an endless loop. For a small business that runs on its website, every minute in this state is a minute of lost leads, abandoned carts, and rising anxiety about what just broke.
The good news is that this particular failure is one of the most common and most fixable problems in WordPress. The culprit is almost always a mismatch between how WordPress thinks it should serve pages and what your .htaccess file (or your host’s proxy, or a caching plugin) is telling the browser to do. Once you understand the moving parts, the repair is usually a few lines of code and a careful save.
This article walks through what a redirect loop actually is, why the HTTPS migration triggers it so reliably, and how to confirm whether .htaccess is the real source of the problem. From there, you’ll get the default WordPress .htaccess fix, a frank comparison of the DIY route versus calling a developer, and a short checklist for preventing the next loop before it starts.
What a Redirect Loop Actually Is
A redirect loop is what happens when your website tells the visitor’s browser to go somewhere, and that somewhere immediately tells the browser to go back. URL 1 points to URL 2, URL 2 points back to URL 1, and the cycle repeats until the browser gives up and shows an error page. For a small business owner, the practical result is identical to the site being offline: a customer clicks your link, sees a broken page, and goes to a competitor. Search engines that crawl the loop walk away with the same impression.
The most common trigger after an HTTPS migration is a mismatch between two layers of configuration. One layer tries to push every visitor from HTTP to HTTPS, while another quietly forces them back from HTTPS to HTTP. The browser bounces between the two versions of the same address forever. As WPThrill explains in its breakdown of post-HTTPS redirect failures, even one conflicting layer is enough to send the entire site into a tailspin, because multiple systems all touch URL rewriting at once.
What Your Browser Is Actually Telling You
When the loop trips, Chrome and Edge users typically see ERR_TOO_MANY_REDIRECTS along with a plain-English variation that reads “This page isn’t working. domain.com redirected you too many times.” Firefox phrases it slightly differently, but the meaning is the same. Kinsta’s reference on the error classifies it as a browser-side code error and lists the “redirected you too many times” wording as the standard customer-facing message. In other words, the browser is not broken and the visitor’s internet connection is fine. The browser is acting as a referee that finally blew the whistle after watching the same play run too many times in a row.
The Server-Side Version of the Same Story
If you or your developer pull up the server error log, you will likely see a related message: “request exceeded the limit of 10 internal redirects due to probable configuration error.” That ten-redirect cap is Apache’s safety valve. Specifically, the web server is admitting that something in its own rule set is sending requests around in circles, and it has stopped processing the request before it brings the whole site down. The server-side log and the browser-side error are two views of the same underlying problem.
Why These Don’t Fix Themselves
Redirect loops are unusual among WordPress errors because they almost never clear on their own. A flaky plugin update might resolve when the developer pushes a patch. A memory error might pass when traffic dies down overnight. However, a redirect loop is a logic problem baked into your configuration files or database settings, and logic problems sit there until somebody changes the logic. Furthermore, the loop often traces back to a single change: a new SSL plugin, an edited .htaccess file, a swap in site URL, or even a small code snippet added to functions.php. One developer on the WordPress Stack Exchange traced his loop to a custom wp_login action that was missing an exit call after the redirect. Therefore, fixing the loop is rarely about waiting it out and almost always about identifying which layer changed and putting it back in line with the others.
Why HTTPS Migrations Trigger the Loop
An HTTPS migration looks like a single decision from the outside: flip the switch, get the padlock, move on. Inside WordPress, it is anything but. Multiple layers each carry their own opinion about which URL is canonical, and a clean migration depends on every layer agreeing. The .htaccess file in your web root, the siteurl and home values in the database, your hosting control panel’s SSL redirect, a caching layer like Cloudflare, and any “Really Simple SSL”-style plugin all want to weigh in. As one guide on the issue puts it, when you migrate to HTTPS multiple layers control URL rewrites, and if even one layer conflicts the redirect becomes incorrect. That is the entire problem in one sentence.
The Ping-Pong Pattern
The classic loop looks like this. A visitor hits http://yoursite.com. Your .htaccess rewrites that to https://yoursite.com. Your reverse proxy or a plugin then sees a request it thinks is still HTTP (because the X-Forwarded-Proto header is missing or being ignored) and rewrites it back to HTTP. The browser follows the redirect, hits HTTPS again, and the cycle repeats until Chrome or Firefox gives up and shows ERR_TOO_MANY_REDIRECTS. A DigitalOcean community thread captures the symptom exactly: alternating 301 Moved Permanently and 302 Found responses, bouncing the browser back and forth until it abandons the request. Consequently, neither the visitor nor the search engine crawler ever lands on a real page.
The Mixed-Content Cousin
Sometimes the migration looks like it worked. The homepage loads over HTTPS, the padlock shows up, and you breathe out. Then you notice broken images, missing stylesheets, or a console full of warnings. That is mixed content: the page itself is secure, but assets are still being requested over plain HTTP, and modern browsers block them by default. It is not a redirect loop, but it shares the same root cause — one layer of the stack still has the old HTTP URLs baked in, usually inside the database where post content and widget settings live.
What This Means for Your Business
While the loop persists, the practical damage is severe and immediate. Visitors get a scary browser error instead of your homepage. Shopping carts cannot complete checkout because the cart page itself is unreachable. You may even get locked out of /wp-admin, which means you cannot deactivate the plugin or edit the setting that caused the problem in the first place. Therefore, an HTTPS migration that goes sideways is not a cosmetic SEO issue — it is a full outage, and for an e-commerce or lead-generation site, every hour of loop equals abandoned customers who will not come back to retry.
Here is the short version of what tends to cause it, with the trade-offs of each fix path:
- Conflicting
.htaccessrules — Pros: easy to inspect, easy to revert by restoring the default WordPress rules. Cons: requires SFTP access and a steady hand if you are not used to Apache syntax. - An SSL helper plugin doing too much — Pros: deactivating it usually resolves the loop in seconds. Cons: if
/wp-adminis already trapped in the loop, you have to deactivate over SFTP by renaming the plugin folder. - Hardcoded
siteurl/homevalues inwp-config.php— Pros: overrides anything the database says, useful as a temporary unblock. Cons: easy to forget you set it, which causes confusion months later when settings appear to ignore the admin UI.
How to Tell If .htaccess Is the Culprit
Before you start rewriting Apache directives, you need to confirm that .htaccess is actually the file causing your redirect loop. A surprising number of small business owners spend a Saturday afternoon editing rewrite rules only to discover the real problem was a stray plugin or a hardcoded URL in wp-config.php. The good news is that .htaccess issues leave a fairly distinctive fingerprint once you know what to look for.
Symptoms That Point at .htaccess
A corrupted or misconfigured .htaccess file rarely fails silently. WPBeginner notes that the most common signs include broken links and unexpected 404 pages where your content used to live, often appearing without warning after a plugin update or a manual edit. If your homepage loads but every internal link kicks visitors to a 404, or if /wp-admin redirects endlessly while the front page is fine, the rewrite rules are a strong suspect. Another telltale sign: the loop began immediately after you edited the file, switched hosts, or toggled an SSL-related setting.
Reading the Network Tab for Clues
Open your browser’s developer tools, load the failing URL, and watch the Network tab. A classic .htaccess loop produces a chain of 301 responses where each redirect target is itself redirected. However, if you see alternating 301 and 302 responses, the cause is often code rather than configuration. One WordPress developer on Stack Exchange traced exactly that pattern to a custom wp_login action that called wp_redirect() without an exit afterward, letting WordPress continue executing and issue a second, conflicting redirect. Specifically, admin access worked initially, then broke the moment cookies were cleared.
Ruling Out Plugins, Themes, and Hosting
To separate .htaccess from other suspects, rename the file to .htaccess_old over SFTP and reload the site. If the loop disappears, you have your answer. If it persists, deactivate plugins by renaming the /wp-content/plugins folder and try again.
- Pros of the rename test: fast, fully reversible, requires no code knowledge, and isolates the variable in under five minutes.
- Cons: pretty permalinks will break until you regenerate the file from Settings → Permalinks, and aggressive caching at the host or CDN layer can mask the result for several minutes.
Furthermore, if neither rename fixes the loop, the cause is likely upstream — a host-level proxy forcing HTTPS, a CDN edge rule, or hardcoded siteurl values. What this means for your business: spending fifteen minutes on these three isolation tests will save you hours of guesswork and let you tell your developer exactly where the problem lives.
The Default WordPress .htaccess Fix
The .htaccess file is a small, plain-text configuration file that sits in your site’s root directory and tells the Apache web server how to handle incoming URLs. For WordPress specifically, it controls the rewrite rules that turn pretty permalinks like /about-us/ into the underlying index.php?page_id=12 request your database actually understands. When that file gets corrupted, contains conflicting redirect directives, or has been edited by a plugin that didn’t clean up after itself, the symptoms range from broken links to the dreaded infinite redirect loop. As WPBeginner notes in its beginner’s guide, the .htaccess file can sometimes get corrupted without warning, and broken links or 404 pages are common signals that something has gone wrong at this layer.
The Known-Good Baseline
WordPress ships with a default .htaccess block that you can always fall back to. Restoring this exact content wipes out any stray redirect rules a plugin or a previous developer might have added. Here is the canonical version:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
That’s it. Notably, the default file contains zero HTTPS redirect logic. If your loop began after switching to HTTPS, any extra RewriteCond %{HTTPS} off lines stacked on top of the default are prime suspects worth removing.
A Safe Replacement Workflow
Do not edit .htaccess in place without a safety net. The file controls every request to your site, and a single typo can take the whole thing offline. Follow this sequence:
- Connect via SFTP or your host’s file manager and download a copy of the current
.htaccessto your local machine. Rename the backuphtaccess-backup-2026-05-19.txtso you can restore it if needed. - Replace the contents of the live
.htaccesswith the default block shown above and save. - Log into WordPress, go to Settings → Permalinks, and click Save Changes without modifying anything. This forces WordPress to regenerate its rewrite rules cleanly.
- Open your site in a private browser window and test both the homepage and an interior page.
Pros of the default-file reset:
– Reversible in seconds if you kept the backup
– Eliminates plugin-added rules without uninstalling anything
– Costs nothing and requires no developer time
Cons:
– Will not fix loops caused by host-level proxies, CDN rules, or a wrong siteurl in the database
– Custom rules you actually need (caching plugin directives, security blocks) will be wiped and must be re-added
When to Stop and Call a Developer
However, if you have restored the default file, re-saved permalinks, and the loop persists, stop editing. As discussed in a DigitalOcean community thread on post-migration redirect loops, the problem at that point usually lives above the .htaccess layer — at the host, the load balancer, or in the database itself. Therefore, blindly adding more rewrite rules to compensate tends to make diagnosis harder, not easier. What this means for your business: a ten-minute file swap is a reasonable DIY step, but a second hour of trial-and-error is a false economy. Pay for thirty minutes of a developer’s time and protect the revenue your downtime is costing.
Small Business Decision: DIY vs. Call a Developer
The honest question every owner faces during a redirect loop is not “can I fix this?” but “should I be the one fixing this right now?” Your time has a real hourly cost, your customers are seeing a broken site, and every minute spent in cPanel is a minute not spent on the work that actually pays the bills. The good news: a meaningful share of HTTPS redirect loops are genuinely DIY-friendly. The bad news: a stubborn one can swallow an entire afternoon and still not resolve.
When DIY Makes Sense
If the loop started immediately after you flipped an SSL setting or installed a redirect plugin, and you have FTP or file manager access to your site, you are in DIY territory. Restoring the default .htaccess block is a documented, reversible step. The WPBeginner guide to fixing the WordPress .htaccess file walks through renaming the current file and regenerating a clean one from the Permalinks screen, which is the same playbook a developer would run in the first five minutes of an engagement. Clearing your browser cache and trying an incognito window, as covered in the Kinsta walkthrough of ERR_TOO_MANY_REDIRECTS, is another zero-risk step worth attempting before you pick up the phone.
Pros of fixing it yourself:
– No invoice, no scheduling delay, site can be back in under an hour
– You learn the moving parts of your own site, which pays dividends later
– The default .htaccess swap is fully reversible if it doesn’t help
Cons of fixing it yourself:
– Time away from sales, operations, and customers
– Risk of compounding the problem by stacking rewrite rules you don’t fully understand
– No second set of eyes on the database, hosting panel, or CDN
When to Call Someone
Specifically, call a developer when the loop persists after a clean .htaccess, when the Site URL fields in the database look wrong, or when you suspect the host, a load balancer, or a CDN is involved. These layers sit above the file you can edit, and trial-and-error there is how small businesses accidentally take their site fully offline. Furthermore, if the site is actively generating leads or transactions, the math almost always favors paying for help: thirty to sixty minutes of professional time is cheaper than a half-day of lost orders.
A short engagement for an incident like this typically covers diagnosing where the redirect originates, checking wp-config.php and the wp_options table for hardcoded URLs, reviewing hosting-level SSL or proxy settings, and leaving you with a clean configuration plus brief notes on what was wrong. That is a tight, well-scoped piece of work — not an open-ended project — and most developers will quote it that way.
What this means for your business: set a personal timer. If you have not restored service within sixty minutes of starting, stop, document what you have tried, and hand it off.
Preventing the Next Redirect Loop
The best redirect loop is the one that never happens. Once you have restored a broken site, the lesson is not to celebrate and move on. It is to capture what just went wrong and build a small amount of process around it so the same outage does not return the next time you flip a setting, add a snippet, or change hosts. HTTPS migrations and authentication tweaks look like one-click toggles in a modern dashboard, but underneath them sit several layers that all want to rewrite your URLs, and as WPThrill explains, it only takes one of those layers to disagree before the browser starts ping-ponging between protocols.
Build a pre-migration checklist
Before you touch the HTTPS switch, write down the layers that touch your URLs and confirm each one is set the way you expect. At minimum that list should include your WordPress Site Address and Home URL, your .htaccess rewrite block, any HTTPS-forcing plugin, your hosting panel’s redirect rules, and any CDN or proxy sitting in front of the origin. Furthermore, walk through a logged-out browser, a logged-in browser, and the /wp-admin path before you announce the change is done, because the symptoms described in the Stack Overflow case only appeared after cookies were cleared.
Keep a known-good .htaccess and document custom snippets
Treat your .htaccess file the way you would treat a contract. Keep a clean copy of the default WordPress block somewhere outside the site, and every time you add custom rules, write a one-line comment in your own notes describing what the rule does and why it exists. The same discipline applies to functions.php. The original login hook that caused the loop was only three lines long, but it was missing an exit after wp_redirect, and that single omission turned a helper into an infinite loop. If you cannot explain in plain English what a snippet does before you paste it, do not paste it.
Pros and cons of a written pre-migration checklist:
- Pros: forces you to look at every rewrite layer, makes handoff to a developer trivial, gives you a rollback point, and turns a panic event into a routine task.
- Cons: adds thirty minutes to a migration that “should” take five, and requires you to update the checklist each time your stack changes.
Treat HTTPS as a project, not a toggle
What this means for your business is straightforward. A redirect loop is not a freak event. It is the predictable outcome of layering rewrites without coordination, and as Kinsta documents for the ERR_TOO_MANY_REDIRECTS error, these failures rarely resolve themselves. Therefore, scope the next HTTPS migration like a small project: schedule a low-traffic window, take a full backup, list the layers you will touch, and decide in advance who fixes it if the site goes dark. Consequently, the difference between a thirty-minute planned change and a three-hour outage is almost entirely the checklist you wrote before you started.
Need Help with Your WordPress Site?
If your WordPress site needs maintenance, a security audit, or a performance overhaul, we’d be happy to discuss your specific needs. Monir Tech Solutions specializes in WordPress maintenance, security, and performance optimization for small businesses across the Boston area and beyond — including security hardening, speed optimization, and ongoing maintenance.
Reach out anytime at info@monirtechsolutions.com and we’ll respond within 24 hours.
The Bottom Line
A redirect loop after switching to HTTPS is almost never a broken WordPress site. It is a configuration conflict between the layers that decide how your URLs are rewritten, and once you understand which layer is fighting which, the fix is usually a small edit rather than a rebuild. That distinction matters because it changes the question from “do I need a new site?” to “which of three or four files needs to agree with the others?”
What to take away
The most important takeaway is that .htaccess is fixable. A corrupted or conflicting file feels catastrophic when every URL bounces a visitor into oblivion, but the file is plain text and WordPress ships with a known-good default that you can paste back in as a safe starting point. As WPBeginner walks through in its beginner’s guide, restoring a default .htaccess is one of the standard first moves when links break or visitors hit 404s instead of your content. Furthermore, the underlying cause is rarely mysterious: when you migrate to HTTPS, multiple layers control URL rewrites, and if even one layer conflicts, the redirect becomes incorrect. That framing, drawn from WPThrill’s walkthrough of HTTPS redirect issues, is the mental model worth keeping.
The cost of leaving the loop unresolved is also worth restating in plain business terms. Visitors who hit ERR_TOO_MANY_REDIRECTS do not file a support ticket. They close the tab, and you lose the sale, the trust, and eventually the search visibility that brought them to you in the first place.
Quick comparison before you act
If you are weighing whether to touch .htaccess yourself or hand it to a developer, the trade-offs are short:
- DIY edit, pros: fast, free, and you learn the file you will inevitably need to know.
- DIY edit, cons: one wrong directive can take the whole site offline until you revert.
- Hand it to a developer, pros: lower risk during business hours, and they will usually back up before they edit.
- Hand it to a developer, cons: costs money and adds a scheduling delay while the loop keeps running.
Your next step this week
Do one thing this week: open your site over SFTP or your host’s file manager, locate the .htaccess file in your WordPress root, and save a copy named .htaccess.backup next to it. Do not edit anything yet. That single low-friction step means the next time a plugin, a host setting, or a hurried HTTPS toggle sends your site into a loop, you already have a known-good file to restore in under a minute.
