Breaking a WordPress Redirect Loop: Recovery Steps

A WordPress redirect loop is what happens when a request bounces between two or more redirect rules without ever landing on a final page — each redirect sending the browser to another URL that immediately redirects it back. Browsers detect this infinite cycle and stop it, displaying an error like Chrome’s “ERR_TOO_MANY_REDIRECTS” or Firefox’s “The page isn’t redirecting properly.” The WordPress redirect loop can appear sitewide, only on the login page, only when accessing wp-admin, or only when coming from certain URLs — each pattern pointing to a different cause. Fixing a WordPress redirect loop safely means identifying which redirect rule or combination of rules is creating the cycle, correcting the specific misconfiguration, and verifying the fix without introducing new redirect problems in the process. This guide walks through the complete approach: diagnosing the cause, fixing each type of WordPress redirect loop correctly, and testing the resolution before considering the problem closed. For a broader walkthrough, our Complete Guide to WordPress How is a good next read.

What Creates a WordPress Redirect Loop — The Four Main Causes

Understanding the specific mechanism behind each type of WordPress redirect loop is what makes fixing one efficient rather than a guessing exercise. The four causes that account for the vast majority of WordPress redirect loop reports each have a distinct signature that appears in the browser address bar and in the network request trace.

Cause	Where It Appears	Trigger	Fix Direction
WordPress URL mismatch (http vs https, www vs non-www)	Sitewide — all URLs redirect	SSL certificate added without updating WordPress URL settings	Fix WordPress Address and Site Address in Settings → General or wp-config.php
Conflicting .htaccess HTTPS redirect rules	Sitewide — HTTPS URLs redirect to HTTP then back	Multiple redirect rules from plugins, manual additions, or server configuration	Remove duplicate redirect rules, keep only one HTTPS enforcement layer
Security plugin login redirect	Login page only — /wp-login.php or /wp-admin/ loops	Plugin custom login URL conflicting with default login URL	Identify and correct the conflicting plugin login configuration
SSL terminated upstream (Cloudflare, load balancer)	Sitewide — HTTPS loops due to WordPress not detecting SSL termination	WordPress sees HTTP internally despite visitor arriving via HTTPS	Add X-Forwarded-Proto server variable declaration in wp-config.php

The fastest diagnostic tool for identifying which type of WordPress redirect loop is active is the browser’s developer tools network panel. Open DevTools (F12 → Network tab), reload the page showing the loop error, and look at the request chain — each request shows its status (301, 302) and destination. The alternating pattern of URLs in the redirect chain reveals the loop mechanism: an alternating http/https pair suggests an HTTPS configuration conflict; an alternating www/non-www pair suggests a URL setting mismatch; a loop between /wp-login.php and a custom login URL suggests a security plugin conflict. Reading the redirect chain directly is the most reliable way to confirm which type of WordPress redirect loop is present before applying any fix.

Safely Fix the WordPress Redirect Loop Caused by WordPress URL Settings

The URL settings mismatch is the most common cause of a sitewide WordPress redirect loop, and it is the most frequently triggered by SSL certificate additions. When HTTPS is added to the server but WordPress’s own URL settings still reference http://, WordPress generates URLs in http:// and the server redirects them to https:// — which WordPress then processes as http:// again, creating an endless loop. The same pattern occurs with www vs non-www mismatches when the server redirects one to the other but WordPress’s settings reference the pre-redirect form.

1. Because the WordPress admin panel is typically inaccessible during a sitewide WordPress redirect loop, access wp-config.php via FTP or the hosting file manager
2. Add these two lines directly above the line reading “That’s all, stop editing! Happy publishing.”:

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

   Use the exact correct URL — the protocol and domain the site should use as its canonical address, with or without www to match your preference, but consistent with the server’s redirect rules

3. Save wp-config.php and test the site in a fresh browser window (incognito to avoid cached redirects). If the WordPress redirect loop clears, the URL mismatch was the cause and the constants are working correctly
4. Once the admin is accessible, navigate to Settings → General and update both the WordPress Address (URL) and Site Address (URL) fields to match the constants you added
5. After the database values are corrected, remove the WP_HOME and WP_SITEURL constants from wp-config.php — they are no longer needed since the database values now hold the correct URLs
6. Run a full database search-and-replace using the Better Search Replace plugin to update any remaining hardcoded old-protocol URLs that may recreate the WordPress redirect loop through cached content

Test the resolution thoroughly after this fix: load the homepage, load the login page, and load several internal pages. Verify that all URLs use the correct protocol and domain, that the padlock shows clean (if HTTPS), and that no redirect loop returns. If the WordPress redirect loop persists after correcting the URL settings, the cause is in the redirect rules rather than the WordPress URL configuration — proceed to the .htaccess fix.

Fix the WordPress Redirect Loop From .htaccess HTTPS Rules

Conflicting HTTPS redirect rules in .htaccess are the second most common source of a WordPress redirect loop. This happens when multiple redirect layers each enforce HTTPS independently — the WordPress settings force HTTPS, a security plugin adds its own HTTPS enforcement rule, a Cloudflare “Always Use HTTPS” setting is active, and the .htaccess file contains its own RewriteRule for HTTPS — all firing simultaneously and conflicting with each other.

Download the .htaccess file from the WordPress root via FTP (enable hidden files first) and examine its full content. The HTTPS redirect section should contain only one redirect directive. Multiple blocks like these indicate the duplication problem behind the WordPress redirect loop:

# Added by WordPress security plugin
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Added manually
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Added by Really Simple SSL
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Keep only the redirect rule appropriate for the server configuration and delete all others. On a standard Apache server without upstream SSL termination, keep one instance of the RewriteCond %{HTTPS} off redirect. On Cloudflare or load-balanced environments, use the X-Forwarded-Proto version only. On servers where Cloudflare’s “Always Use HTTPS” setting handles the redirect, remove all .htaccess HTTPS redirect rules entirely and let Cloudflare handle it at the network level — this eliminates the conflict that creates the WordPress redirect loop from redundant enforcement. After editing .htaccess, save and reload the site in incognito to test whether the WordPress redirect loop has cleared.

Plugin-Caused WordPress Redirect Loops and How to Break Them

Security and redirect-management plugins are the most common plugin sources of the WordPress redirect loop. Login protection plugins that change the login URL, redirect manager plugins with circular rules, and plugins that enforce HTTPS through WordPress hooks rather than .htaccess can each create loops when their configuration conflicts with other active redirect layers.

The cleanest diagnostic approach for plugin-caused WordPress redirect loops is bulk plugin deactivation via FTP — navigate to wp-content/plugins/ and rename the folder to plugins_disabled. Reload the site. If the WordPress redirect loop clears immediately, a plugin is responsible. Rename the folder back to plugins and reactivate plugins one at a time, testing after each reactivation until the loop returns — the last plugin activated before the loop returned is the source. Within that plugin’s settings, look for redirect-related configuration: custom login URL settings, forced HTTPS options, redirect rules, or maintenance mode toggles. Correcting the specific conflicting setting within the plugin is the targeted fix that allows the plugin to remain active without creating the WordPress redirect loop.

Redirect manager plugins (the Redirection plugin, Simple 301 Redirects, etc.) occasionally create the WordPress redirect loop through user-configured circular rules — a rule redirecting URL A to URL B combined with another rule redirecting URL B back to URL A. After identifying the redirect manager plugin as the source, review its redirect list for circular patterns. Look for any redirect where the source URL and destination URL could create a chain that leads back to the source. Deleting the circular rule from the plugin’s redirect list immediately ends the WordPress redirect loop without affecting any other redirects the plugin manages.

Clear Cached Redirects That Sustain the WordPress Redirect Loop

After fixing the underlying configuration that caused the WordPress redirect loop, cached versions of the redirect response can sustain the loop in the browser even after the server-side cause is resolved. A 301 permanent redirect is cached aggressively by browsers — once a browser has cached a redirect from URL A to URL B, it continues following that redirect for a significant period without checking the server. This means that even after a perfect fix, a browser session that cached the redirect before the fix still experiences the WordPress redirect loop from the cached data.

Clearing browser-cached redirects requires a hard cache clear — not just a normal cache clear. In Chrome: Settings → Privacy and security → Delete browsing data → change the time range to “All time” → check Cached images and files and Cookies → Delete data. Then close all browser tabs and windows and open fresh. In Firefox: Settings → Privacy & Security → Cookies and Site Data → Clear Data → clear both Cached Web Content and Cookies. After clearing, navigate to the previously affected URL in a brand new browser window. If the server-side fix was correct and complete, the WordPress redirect loop does not recur in the fresh session.

CDN-cached redirects are the other persistence mechanism. Cloudflare caches redirect responses at its edge nodes — clearing the Cloudflare cache (Cloudflare dashboard → Caching → Configuration → Purge Everything) removes any cached WordPress redirect loop responses from the CDN layer. After purging the CDN and clearing the browser cache, the resolution of the WordPress redirect loop is confirmed across all caching layers and the fix is complete.

Test and Verify the WordPress Redirect Loop Is Fully Resolved

A thorough post-fix verification confirms the WordPress redirect loop is resolved across all URL variants and all browser environments before the issue is closed.

1. Test the homepage in incognito: navigate to yoursite.com — confirm it loads without redirecting more than once (a single http-to-https redirect is correct; any subsequent redirects indicate a remaining loop)
2. Test all URL variants: visit http://yoursite.com, https://yoursite.com, http://www.yoursite.com, and https://www.yoursite.com. All should end on the same canonical URL without looping
3. Test the login page: navigate to /wp-login.php and /wp-admin/ — both should load without triggering the WordPress redirect loop
4. Use an HTTP redirect checker tool: enter your domain at redirect-checker.org or httpstatus.io and trace the redirect chain. The tool shows every step in the chain and the HTTP status code at each step. The correct result is a single 301 redirect from http:// to https:// (or from non-www to www if that is the canonical), then a 200 OK on the final destination. Any additional redirect steps indicate a remaining WordPress redirect loop element
5. Check the WordPress admin: log in and navigate to Settings → General. Confirm both the WordPress Address and Site Address match the correct canonical URL without any mix of http/https or www/non-www
6. Monitor for 24 hours after the fix: some WordPress redirect loop causes recur after plugin updates or cron-triggered redirects. A return of the loop indicates a plugin is recreating the conflicting rule — investigate the plugin that updated most recently in the period before the recurrence

Our guide on fixing the WordPress too many redirects error covers the same issue from a diagnostic-first perspective — the complementary Fixes and Errors guide that pairs with this How-To approach for understanding both why the WordPress redirect loop happens and exactly how to resolve each variant. Our guide on how to add SSL to WordPress safely covers the HTTPS migration process that — when done correctly — prevents the most common cause of the WordPress redirect loop arising from conflicting HTTP and HTTPS configuration. The Chrome DevTools documentation covers the Network tab redirect chain view used to diagnose the type of WordPress redirect loop before applying targeted fixes. Related: How to Fix WordPress Stuck in Maintenance Mode Safely With Proven Steps.