Severity: Critical · Fix time: 5–15 min · Skill level: Intermediate

The WordPress HTTPS redirect loop — displayed as “ERR_TOO_MANY_REDIRECTS” or “This page isn’t working — redirected you too many times” — is a specific variant that occurs when WordPress’s HTTPS enforcement configuration conflicts with a CDN, a server-level redirect rule, or itself. Unlike the broader ERR_TOO_MANY_REDIRECTS (which covers any looping chain), the HTTPS loop has a narrower cause set: WordPress is configured to force HTTPS, but the mechanism creates a circular chain that never resolves.

The most common scenario: Cloudflare “Flexible SSL” combined with any WordPress HTTPS redirect. Cloudflare Flexible sends HTTPS to visitors but HTTP to the WordPress origin. WordPress sees HTTP, redirects to HTTPS, Cloudflare forwards it back as HTTP, WordPress redirects again — until the browser gives up. This is distinct from the WordPress login redirect loop (an authentication cookie issue at wp-login.php) and from the general ERR_TOO_MANY_REDIRECTS, which covers all redirect chain types.

Need a quick map of every WordPress error? See our 70+ WordPress Errors Guide → for a categorized reference of every common WordPress issue.

[Image: Browser showing “ERR_TOO_MANY_REDIRECTS” or “This page isn’t working — redirected you too many times” error]

How the WordPress HTTPS Redirect Loop Works

For HTTPS to function correctly end-to-end, every component — from visitor’s browser to CDN to WordPress server — must agree on whether the current request is HTTP or HTTPS. When any component disagrees and WordPress is configured to redirect HTTP to HTTPS, a loop forms.

Common conflict points:

  • Cloudflare Flexible SSL + WordPress HTTPS redirect — The most common cause. Flexible SSL serves HTTPS to visitors but forwards HTTP to the origin. WordPress’s HTTPS redirect sees HTTP and redirects to HTTPS. Cloudflare converts the response back to HTTP. The loop repeats.
  • FORCE_SSL_ADMIN with HTTP WordPress URL — Adding define('FORCE_SSL_ADMIN', true) forces wp-admin to HTTPS, but if WP_HOME and WP_SITEURL are still set to http://, WordPress may redirect back to HTTP immediately after, creating a loop for admin pages.
  • Duplicate HTTPS redirect rules — An .htaccess redirect, a WordPress plugin enforcing HTTPS, and a Cloudflare Page Rule all forcing HTTPS can create conflicting chains if they don’t coordinate.
  • Reverse proxy not forwarding X-Forwarded-Proto — A load balancer terminates SSL and forwards HTTP to WordPress without the X-Forwarded-Proto: https header. WordPress doesn’t know the original request was HTTPS and redirects to HTTPS, creating a loop.
  • Post-migration URL mismatch — WP_SITEURL is https:// in wp-config.php, but siteurl and home in wp_options still contain http://. Conflicting directives produce unpredictable redirect behavior.

Check This First — 2-Minute Diagnostic

  1. Clear browser cookies and cache for the domain — Browser-cached redirect chains persist even after the server-side configuration is fixed. Press Ctrl+Shift+Del, select “All time,” clear cookies and cached files. Retry in incognito.
  2. Test in an incognito window — Incognito doesn’t use cached redirects. If the error disappears in incognito, the problem is a browser-cached redirect, not an active server-side loop.
  3. Check Cloudflare SSL mode — If your site uses Cloudflare, log in and check SSL/TLS settings. If it’s “Flexible,” this is almost certainly the cause.
  4. List all active redirect mechanisms — Every place an HTTP→HTTPS redirect could be happening: .htaccess, wp-config.php, WordPress SSL plugins (Really Simple SSL, etc.), and Cloudflare Page Rules. Multiple active redirects create loops.
  5. Check WP_HOME and WP_SITEURL — In wp-config.php, are both set to https://? Are they consistent with the actual URL? A mismatch here is a common trigger.

Purpose & Benefits

1. Understanding the HTTPS Loop vs. the General Redirect Loop

The HTTPS redirect loop is specifically caused by HTTPS enforcement misconfiguration — almost always a Cloudflare SSL mode mismatch or a conflict between multiple HTTPS-forcing mechanisms. The general ERR_TOO_MANY_REDIRECTS covers any looping chain, including plugin redirect conflicts and .htaccess errors unrelated to HTTPS. If your loop started after adding Cloudflare, installing an SSL certificate, or configuring HTTPS settings, you’re dealing with this specific variant.

2. Diagnosing Which Layer Creates the Loop

Redirect loops involve multiple layers — browser, CDN, server, WordPress application — and the fix belongs to only one of them. Clearing browser cookies eliminates the browser layer. Checking Cloudflare SSL mode eliminates the CDN layer. Disabling SSL plugins eliminates the WordPress application layer. Renaming .htaccess eliminates the server layer. This systematic approach resolves loops faster than guessing.

3. Protecting SEO During the Fix

A redirect loop returns ERR_TOO_MANY_REDIRECTS to Googlebot, making your pages uncrawlable. After resolving it, check Google Search Console for crawl errors and verify your SSL certificate is valid for your HTTPS URLs. A properly configured HTTPS redirect post-fix is an SEO improvement over the loop that preceded it.

Examples

1. Cloudflare Flexible SSL — The Classic HTTPS Loop

A site owner adds Cloudflare with SSL mode “Flexible” (the default) and activates the Really Simple SSL plugin. Visitors immediately see ERR_TOO_MANY_REDIRECTS. Cause: Cloudflare Flexible sends HTTP to the origin; the plugin redirects HTTP to HTTPS; Cloudflare forwards that back to the origin as HTTP; the loop repeats. Fix: in Cloudflare’s SSL/TLS settings, change from “Flexible” to “Full” or “Full (Strict).” This resolves the loop immediately without touching WordPress or .htaccess.

2. FORCE_SSL_ADMIN Loop With Mismatched URLs

A developer adds define('FORCE_SSL_ADMIN', true) to wp-config.php, but WP_HOME and WP_SITEURL are not defined in wp-config.php and the siteurl in wp_options still reads http://. The HTTPS redirect conflicts with the HTTP site URL setting. Fix:

// Add to wp-config.php BEFORE "That's all, stop editing"
// Ensures all WordPress URL references use HTTPS consistently
define( 'WP_HOME', 'https://yourdomain.com' );
define( 'WP_SITEURL', 'https://yourdomain.com' );

// FORCE_SSL_ADMIN is no longer conflicting once URLs are set to HTTPS
define( 'FORCE_SSL_ADMIN', true );

Clear the browser cache after saving, then retry.

3. Reverse Proxy Not Forwarding Protocol Header

A load balancer terminates SSL and forwards HTTP to WordPress without the X-Forwarded-Proto: https header. WordPress’s .htaccess HTTPS redirect fires on every request because WordPress sees HTTP. Fix: configure the load balancer to add the header, then tell WordPress to trust it in wp-config.php:

// Add to wp-config.php — tells WordPress the original request was HTTPS
// even though the proxy forwards it as HTTP
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}
// Then remove the .htaccess HTTPS redirect — the proxy handles SSL

Common Mistakes to Avoid

  • Clearing cache without clearing cookies — Redirect loops store state in both. Clearing cache alone leaves cookie-based redirect chains intact. Clear both cookies and cache for the domain — not just general browser history.
  • Adding HTTPS redirect rules on top of existing ones — Adding an .htaccess HTTPS redirect when a plugin already enforces HTTPS, and Cloudflare is also redirecting, creates three simultaneous mechanisms. Identify all active redirects first, then consolidate to one.
  • Using Cloudflare “Flexible” SSL with any WordPress HTTPS enforcement — Flexible SSL and any origin-level HTTP→HTTPS redirect are fundamentally incompatible. Flexible is designed to send HTTP to the origin. The only fix is changing Cloudflare to “Full” or “Full (Strict)” — never “Flexible” when WordPress redirects HTTP.
  • Not regenerating .htaccess after renaming it — If renaming .htaccess resolves the loop, regenerate a clean version by going to Settings → Permalinks → Save Changes before considering the fix complete. Leaving .htaccess renamed breaks WordPress pretty permalinks.

Best Practices

1. Consolidate to One HTTPS Redirect Mechanism

Choose one layer for HTTPS enforcement and disable all others:

  • Cloudflare “Full (Strict)” handles SSL at the CDN layer
  • A server-level .htaccess redirect handles HTTP→HTTPS at the server layer
  • WordPress URLs set to https:// ensures WordPress generates HTTPS URLs

With these three in place, no additional plugin-based enforcement is needed. Using Really Simple SSL on top of Cloudflare Full/Strict is redundant and introduces loop risk.

2. Set All WordPress URL References to HTTPS Consistently

Verify these three locations all use https://: WP_HOME and WP_SITEURL in wp-config.php; siteurl and home in the wp_options table (visible in phpMyAdmin); and Settings → General → WordPress Address and Site Address. When wp-config.php defines these constants, they override the database values — making wp-config.php the authoritative source.

3. Use .htaccess for HTTPS Redirect When Not Behind Cloudflare

For sites not behind an SSL-terminating proxy, a clean .htaccess redirect is reliable single-layer enforcement:

# WordPress .htaccess — HTTPS redirect before the WordPress rewrite block
RewriteEngine On

# Force HTTPS (remove this block if using Cloudflare Full/Strict)
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# BEGIN WordPress
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

4. Test Redirect Chains With curl Before Pushing Changes Live

Before deploying redirect configuration changes, test the redirect chain directly:

# Follow redirects and show response codes at each step
curl -L -I https://yourdomain.com 2>&1 | grep -E "HTTP/|Location:"

# Expected for a healthy HTTPS site (no redirect loop):
# HTTP/2 200 (single response, no redirects)
# A loop shows alternating 301 redirects between HTTP and HTTPS versions

Frequently Asked Questions

What causes the WordPress HTTPS redirect loop most often?

Cloudflare “Flexible” SSL mode combined with any WordPress HTTPS redirect. Flexible SSL sends HTTP to the WordPress origin; WordPress redirects to HTTPS; Cloudflare sends that back as HTTP — a loop. The fix is always changing Cloudflare to “Full” or “Full (Strict).”

How is this different from the general ERR_TOO_MANY_REDIRECTS error?

The HTTPS loop is specifically caused by HTTPS enforcement misconfiguration — a CDN SSL mode mismatch, conflicting redirect mechanisms, or a proxy not forwarding the protocol header. The general ERR_TOO_MANY_REDIRECTS covers any looping chain, including plugin conflicts and .htaccess errors unrelated to HTTPS.

How is this different from the WordPress login redirect loop?

The WordPress login redirect loop is an authentication cookie issue affecting only wp-login.php. The HTTPS redirect loop affects the entire site and is caused by conflicting redirect rules — different symptoms, different causes, different fixes.

Can the HTTPS redirect loop hurt SEO?

Yes. An active loop blocks Googlebot from crawling your pages. Extended outages can cause pages to be dropped from Google’s index. After resolving it, verify in Google Search Console that HTTPS pages are crawlable.

Related Glossary Terms

How CyberOptik Can Help

Still broken? Our team fixes WordPress errors like this in under 30 minutes for maintenance clients. An HTTPS redirect loop takes your entire site offline — and the cause is often a one-setting fix in Cloudflare or a two-line change in wp-config.php once the conflicting layers are identified. We handle Cloudflare SSL configuration, WordPress HTTPS migration, .htaccess redirect audits, and reverse proxy configuration as part of our WordPress maintenance services. Contact us to get your site back online.