If you’re seeing WordPress ERR_TOO_MANY_REDIRECTS right after changing SSL settings, turning on Cloudflare, enabling “Always Use HTTPS,” or updating your WordPress Address/Site Address to HTTPS, you’re almost certainly stuck in a redirect loop. The good news: this is one of the most common “site down after SSL” scenarios—and it’s usually fixable in a predictable, step-by-step way.

This guide walks you through the fastest path to identify where the loop is happening (Cloudflare vs. your server vs. WordPress) and exactly what to change so your site loads normally again.

Along the way, I’ll link to relevant WP Fix It resources (for related WordPress troubleshooting) and to official documentation (Cloudflare and WordPress) so you can verify what each setting does.

What WordPress ERR_TOO_MANY_REDIRECTS means (in plain English)

A browser shows ERR_TOO_MANY_REDIRECTS when it keeps getting told “go here instead” over and over until it gives up. On WordPress sites, loops typically look like one of these:

  • http://example.com → https://example.com → http://example.com → …
  • https://example.com → https://www.example.com → https://example.com → …
  • Cloudflare redirects HTTP→HTTPS while your origin (server) redirects HTTPS→HTTP (classic loop). Cloudflare explicitly calls this out as a cause of “too many redirects.” (Cloudflare Docs)

When SSL/Cloudflare changes are involved, the loop is usually created by two different systems trying to enforce HTTPS (or the opposite) at the same time.

Before you change anything: confirm it’s not just cached

This won’t fix a real configuration problem, but it can remove stale redirects and help you test cleanly.

  1. Test in a private/incognito window (or a different browser/device).
  2. Clear browser cookies/cache for your domain.
  3. Purge caches:
    • Cloudflare cache (Purge Everything or purge affected URLs)
    • Any WordPress cache plugin cache
  4. If you recently enabled HSTS, understand that browsers can “remember” HTTPS behavior aggressively. (If you’re unsure, use incognito + a fresh device first.)

Caching can make a fixed configuration look broken (or vice versa), so do this early.

Step 1: Identify whether Cloudflare is part of the loop

Quick test

Temporarily pause Cloudflare (or set DNS records to “DNS only,” gray cloud) and test again.

  • If the site starts working when Cloudflare is bypassed, your loop is very likely tied to Cloudflare SSL/TLS mode, “Always Use HTTPS,” or Redirect Rules.
  • If it still loops without Cloudflare, the loop is likely on the origin server (.htaccess/Nginx) or inside WordPress URL settings.

Cloudflare documents the “too many redirects” issue as commonly caused by SSL/TLS mode conflicts between Cloudflare and the origin. (Cloudflare Docs)

Step 2: Fix the #1 Cloudflare cause — SSL/TLS encryption mode mismatch

This is the most common reason for WordPress ERR_TOO_MANY_REDIRECTS right after enabling Cloudflare or tweaking SSL.

The classic problem: “Flexible”

Cloudflare’s community support repeatedly points out that redirect loops are “in 99% of cases” tied to using Flexible SSL with origin redirects. (Cloudflare Community)

Why? In Flexible mode, visitors connect to Cloudflare via HTTPS, but Cloudflare connects to your origin via HTTP. If your origin tries to force HTTPS, it redirects Cloudflare back to HTTPS—yet Cloudflare continues requesting HTTP from the origin—loop. (Cloudflare’s own troubleshooting emphasizes encryption-mode misconfigurations. (Cloudflare Docs))

What to set instead

  • Use Full if your origin has a valid certificate (even a basic one).
  • Use Full (Strict) if your origin certificate is valid and properly trusted (recommended when possible).

Cloudflare community threads routinely resolve loops by switching from Flexible → Full/Strict. (Cloudflare Community)

Practical fix checklist (Cloudflare)

In Cloudflare dashboard:

  1. SSL/TLS → Overview
  2. Set Encryption mode = Full (Strict) if possible; otherwise Full.
  3. If you’re using Cloudflare “Always Use HTTPS,” ensure your origin isn’t redirecting HTTPS back to HTTP (Cloudflare warns that this creates loops). (Cloudflare Docs)

If you truly must use Flexible (not recommended), there are workarounds (including a plugin created specifically to prevent infinite loops), but it’s better to install an origin certificate and switch to Full/Strict. (WordPress.org)

Step 3: Make sure you only enforce HTTPS in ONE place

A redirect loop often happens because you’ve enabled multiple HTTPS-forcing mechanisms at once, such as:

  • Cloudflare “Always Use HTTPS”
  • Cloudflare Redirect Rules (or legacy Page Rules)
  • A WordPress plugin that forces SSL
  • .htaccess rules that force HTTPS
  • Nginx rules that force HTTPS
  • A host control panel setting (cPanel, Plesk, etc.)
  • WordPress hard-coded redirects due to WP_HOME / WP_SITEURL

The goal: pick one canonical enforcement layer and remove conflicting ones.

A clean setup many site owners use:

  • Cloudflare handles edge HTTPS redirects (optional).
  • Origin is set up to serve HTTPS correctly.
  • WordPress URLs are set to https and match the canonical host (www or non-www).

Cloudflare explicitly notes redirects can loop when Cloudflare settings conflict with origin behavior. (Cloudflare Docs)

Step 4: Verify WordPress Address (URL) + Site Address (URL)

If you changed these to HTTPS and got locked out, you may have set one value differently than the other (or accidentally introduced www/non-www mismatch).

WordPress itself highlights that there are two URL constants/values: WP_HOME and WP_SITEURL—and both matter. (WordPress.org)

What “correct” looks like

For most sites (WordPress installed in the web root), these should be identical except when WordPress core files live in a subdirectory.

Examples:

  • https://example.com + https://example.com
  • https://www.example.com + https://www.example.com

If one is http:// and the other is https://, or one has www and the other doesn’t, you can create loops.

Step 5: If you can’t access wp-admin, hard-code the URLs in wp-config.php

When WordPress ERR_TOO_MANY_REDIRECTS prevents login, hard-coding your URLs temporarily is often the quickest way to regain control.

WordPress’s developer documentation explains using WP_HOME and WP_SITEURL in wp-config.php, and that these override the database values. (WordPress Developer Resources)

Add (or correct) these in wp-config.php:

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

Important tips

  • Use your real canonical version (www or non-www).
  • Don’t add a trailing slash.
  • Once the site is stable, you can decide whether to keep these hard-coded or switch back to database-managed settings.

If you need background on SSL best practices for WordPress, WP Fix It has a primer on why SSL matters and what it does. (WP Fix It)

Step 6: Fix “WordPress doesn’t know it’s HTTPS” behind Cloudflare (proxy headers)

Even after you set Cloudflare to Full/Strict, some configurations still loop because WordPress thinks it’s receiving HTTP (since the origin sees Cloudflare proxy traffic and not the visitor’s HTTPS state).

A common solution is to tell WordPress it’s HTTPS when Cloudflare indicates HTTPS via headers like X-Forwarded-Proto. (Stack Overflow)

Common wp-config.php snippet (behind a proxy/CDN)

Add this near the top of wp-config.php (before “That’s all…”):

if (
  isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
  $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'
) {
  $_SERVER['HTTPS'] = 'on';
}

Why this helps:

  • WordPress functions like is_ssl() rely on server variables to detect HTTPS.
  • In proxied setups, the origin may not set $_SERVER['HTTPS'] the way WordPress expects. (WordPress Development Stack Exchange)

Cloudflare can also send Cloudflare-specific headers; some setups use HTTP_CF_VISITOR parsing, but X-Forwarded-Proto is a common pattern.

Step 7: Check (and simplify) your .htaccess HTTPS + www redirects

If you’re on Apache, .htaccess rules are a frequent source of loops—especially if you added “force HTTPS” snippets during the SSL switch.

WP Fix It has a detailed guide on WordPress .htaccess usage and common issues. (WP Fix It)

Best practice: keep it minimal

A safe strategy:

  1. Temporarily remove custom redirect blocks (move them somewhere as backup).
  2. Regenerate WordPress rewrite rules:
    • Rename .htaccess to .htaccess.bak
    • In WP Admin (once accessible): Settings → Permalinks → Save
  3. Add back one canonical redirect rule (only if needed), and avoid duplicating what Cloudflare already does.

Example: force HTTPS + non-www (one rule set)

(Use only if Cloudflare is NOT already enforcing the same thing.)

RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Common loop trap: forcing HTTPS in .htaccess while Cloudflare is in Flexible mode (or while origin redirects HTTPS back to HTTP). That’s why Step 2 is so important. (Cloudflare Docs)

Step 8: If you’re on Nginx, check server blocks for conflicting redirects

Nginx loops commonly happen when:

  • You have a server block that redirects https → http (sometimes accidental).
  • You have multiple server blocks for the same host with overlapping rewrite logic.
  • A reverse proxy terminates SSL but backend WordPress server thinks it’s HTTP (similar to Cloudflare header issues).

While this post focuses on WordPress + Cloudflare, the “proxy in the mix + rewrite rules” loop pattern is widely recognized across SSL stacks. (Let’s Encrypt Community Support)

Step 9: Audit Cloudflare “Always Use HTTPS,” Redirect Rules, and Page Rules

Cloudflare calls out that Always Use HTTPS redirects all HTTP requests to HTTPS—and loops occur if your origin redirects HTTPS back to HTTP. (Cloudflare Docs)

Things to check in Cloudflare:

  • SSL/TLS mode (again: Full/Strict preferred)
  • Always Use HTTPS (On/Off)
  • Redirect Rules (or legacy Page Rules) that:
    • force www/non-www
    • force HTTPS
    • rewrite paths (e.g., /wp-admin)
  • Any rule that redirects a URL to a URL that triggers another rule

Rule hygiene tip: If you want Cloudflare to handle redirects, remove origin-level redirects for the same patterns. Or do it the other way around—just don’t do both.

Step 10: Eliminate plugin/theme SSL and redirect conflicts

Some WordPress plugins can add redirects:

  • SSL enforcement plugins
  • security plugins with “force HTTPS”
  • caching plugins with unusual redirect behavior
  • multilingual plugins / URL managers

If you can access files:

  1. Temporarily disable plugins by renaming /wp-content/plugins/ to /wp-content/plugins.off/
  2. If fixed, restore folder name and re-enable plugins one-by-one.

If you want related troubleshooting patterns (like dealing with server errors and rewrite issues), WP Fix It has a broader “fix WordPress issues fast” guide that includes steps like regenerating .htaccess and isolating plugin conflicts. (WP Fix It)

Step 11: Don’t confuse redirect loops with redirect malware

Sometimes people search for “WordPress redirects” and assume it’s always SSL configuration. But malware can also cause redirects (usually to spammy domains, popups, or unrelated pages), and it can coexist with SSL changes—making diagnosis confusing.

If your redirects send users to random sites or shady pages, that’s a different pattern than a clean HTTP↔HTTPS loop. WP Fix It has a guide specifically on WordPress redirect malware symptoms and cleanup. (WP Fix It)

Step 12: Verify the fix with a redirect trace (so you know it’s truly solved)

After each major change, confirm what’s happening with headers.

Use curl (best quick proof)

Run:

curl -I http://example.com
curl -I https://example.com
curl -I https://www.example.com

You want:

  • At most one 301/302 to your canonical URL
  • Then a 200 OK (or a single final redirect to a login/cached page)

If you see the Location header bouncing between http/https or www/non-www, you haven’t fully eliminated the conflict.

A “known-good” configuration for WordPress + Cloudflare (recommended baseline)

If you want the simplest stable setup that avoids WordPress ERR_TOO_MANY_REDIRECTS:

  1. Install a valid SSL cert on the origin
    • Your host’s SSL or a trusted cert is fine.
  2. In Cloudflare:
    • SSL/TLS mode = Full (Strict) (or Full)
    • Use Always Use HTTPS only if your origin is not redirecting HTTPS back to HTTP (Cloudflare Docs)
  3. In WordPress:
  4. On Apache:
    • Keep .htaccess clean; avoid duplicate redirect logic (WP Fix It’s .htaccess guide is a helpful reference). (WP Fix It)
  5. If behind proxy/CDN:
    • Ensure WordPress detects HTTPS via forwarded headers (Stack Overflow)

WP Fix It also offers Cloudflare-integrated hosting guidance and discusses Cloudflare’s role in speed/security if you’re building a more robust setup. (WP Fix It)

Prevention checklist (so this doesn’t happen again)

Once you’ve fixed the loop, lock in habits that prevent it:

  • Choose one redirect authority (Cloudflare or origin) for:
    • HTTP→HTTPS
    • www↔non-www
  • Keep a copy of your working .htaccess before editing (WP Fix It’s .htaccess primer helps explain why small changes can have big effects). (WP Fix It)
  • Add monitoring so SSL expiration or configuration drift doesn’t surprise you (WP Fix It offers monitoring options like SSL watch). (WP Fix It)
  • If you run Cloudflare + caching, make sure cache purges happen properly after configuration changes (WP Fix It’s Cloudflare-friendly cache tooling discusses automated purge/refresh workflows). (WP Fix It)
  • After an HTTPS migration, also watch for mixed content warnings (related but different issue)—WP Fix It has a walkthrough for mixed content cleanup. (WP Fix It)

Quick “if you only do 3 things” fix summary

If you’re in a hurry and this started immediately after SSL/Cloudflare changes:

  1. Cloudflare SSL/TLS mode → Full (Strict) (not Flexible) (Cloudflare Docs)
  2. Ensure WordPress URL settings are consistent (https:// + same host) or hard-code WP_HOME and WP_SITEURL (WordPress Developer Resources)
  3. Remove duplicate/conflicting redirect rules (Cloudflare + origin), and simplify .htaccess (Cloudflare Docs)

That combination resolves the majority of WordPress ERR_TOO_MANY_REDIRECTS cases caused by SSL/Cloudflare changes.