Fix Redirect Loops: WP_HOME/SITEURL, Cloudflare SSL Modes, Cache Purge Order

Fix Redirect Loops: WP_HOME/SITEURL, Cloudflare SSL Modes, Cache Purge Order

If you’re trying to fix WordPress redirect loop issues (the dreaded “Too many redirects” error), you’re usually dealing with one of three root causes:

  1. WordPress URL settings are inconsistent (WP_HOME / WP_SITEURL, or “WordPress Address” vs “Site Address”)
  2. Cloudflare SSL mode is mismatched with how your origin server handles HTTPS
  3. Caches are serving stale redirects (301/302 responses get cached aggressively) and you’re purging in the wrong order

The good news: redirect loops are very fixable if you follow a clean, layered process. This guide is written to stop the loop without guesswork—and without creating a new loop while you “fix” the old one.


What a redirect loop actually is (and why it happens)

A redirect loop happens when your site keeps bouncing a visitor between two (or more) URLs or protocols—commonly:

  • http://example.com → https://example.com → http://example.com (protocol loop)
  • example.com → www.example.com → example.com (host loop)
  • /wp-admin → /wp-login.php → /wp-admin (auth/cookie loop)
  • Cloudflare “Flexible” + origin force-HTTPS is the classic: visitor hits HTTPS, Cloudflare goes to origin via HTTP, origin forces HTTPS, Cloudflare repeats… forever

Redirect loops often show up after:

  • enabling SSL,
  • switching to Cloudflare,
  • migrating hosts,
  • changing WordPress Address / Site Address,
  • adding a redirect plugin,
  • enabling “Force HTTPS” in multiple places,
  • restoring a backup,
  • or clearing some caches but not the one still serving an old redirect.

Before you change anything: identify the redirect pattern

To fix WordPress redirect loop problems quickly, you want to see the chain.

Quick checks

  • Open an incognito window and try loading:
    • http://yourdomain.com
    • https://yourdomain.com
    • http://www.yourdomain.com
    • https://www.yourdomain.com
  • Note which version “wins” (or whether all versions loop)

Technical check (best)

Use your browser DevTools → Network tab and reload. Look for repeating 301/302 responses and where they point.
This is also a common reason WordPress features break (like REST API / block editor) when requests get redirected unexpectedly—WP Fix It even calls out redirect loops as a cause of “HTML instead of JSON” problems. (WP Fix It)


Step 1: Make sure you have ONE canonical URL

Decide the single URL format you want:

  • https://example.com (recommended for most sites)
  • or https://www.example.com

Pick one and force everything else to it. Don’t mix-and-match between WordPress, your server, Cloudflare, and plugins.


Step 2: Fix WP_HOME / WP_SITEURL (and WordPress Address vs Site Address)

What these settings mean (in plain English)

WordPress has two URL values:

  • WordPress Address (URL): where WordPress core files live
  • Site Address (URL): what visitors type to reach your site

WordPress documents this distinction in its migration/admin guidance. (WordPress Developer Resources)

In most installs, they should be the same.

Where to check in wp-admin

Go to: Settings → General

  • WordPress Address (URL)
  • Site Address (URL)

Make sure:

  • Both are HTTPS if your site runs on HTTPS
  • Both match your chosen host version (www or non-www)
  • No trailing slash at the end

When wp-admin is inaccessible (common during loops)

Hard-code the values in wp-config.php using constants.

WordPress officially documents WP_SITEURL (and how it overrides the database option). (WordPress Developer Resources)

Add this near the top of wp-config.php (above “That’s all, stop editing”):

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

Rules:

  • Use your single canonical URL
  • Include https://
  • No trailing slash

If your WordPress core files are in a subdirectory (example: /wordpress), then WP_SITEURL may differ from WP_HOME—but that’s a special case. Most sites should keep them identical.

Bonus: check the database if needed

If you can access your database, check wp_options:

  • home
  • siteurl

If they don’t match your intended canonical URL, fix them—or rely on the wp-config constants to override them.


Step 3: Cloudflare SSL Modes (Flexible vs Full vs Full Strict)

If Cloudflare is in front of your site, SSL mode mismatches are one of the most common reasons people can’t fix WordPress redirect loop problems.

Cloudflare explains SSL/TLS encryption modes as controlling two connections:

  1. Visitor ↔ Cloudflare
  2. Cloudflare ↔ Your origin server (Cloudflare Docs)

The modes (what they really do)

Flexible (usually causes loops)

Cloudflare says Flexible encrypts traffic from the visitor to Cloudflare, but Cloudflare connects to your origin over HTTP. (Cloudflare Docs)

If your origin is forcing HTTPS (via .htaccess, nginx, a plugin, or your host panel), you can create an endless loop:

  • visitor requests https://
  • Cloudflare requests origin via http://
  • origin says “nope, go https”
  • Cloudflare tries again via http://
  • repeat

If you’re trying to fix a redirect loop and Cloudflare is set to Flexible, change that first.

Full

Cloudflare’s Full mode allows HTTPS to Cloudflare and then connects to your origin using the scheme requested by the visitor. (Cloudflare Docs)
This typically works if your origin has an SSL certificate installed (even self-signed), but it’s not the “tightest” configuration.

Full (strict) (recommended)

Cloudflare explains Full (strict) as Full mode plus stricter validation requirements for the origin certificate. (Cloudflare Docs)
Cloudflare also strongly recommends using Full or Full (strict) where possible. (Cloudflare Docs)

Practical recommendation (most WordPress sites)

  • Install a valid SSL cert on your origin (Let’s Encrypt is fine)
  • Set Cloudflare SSL mode to Full (strict)

That single change eliminates a huge chunk of redirect-loop scenarios.


Step 4: Make sure HTTPS is enforced in ONE place (not three)

To fix WordPress redirect loop issues permanently, you want one source of truth.

Common places that might be forcing redirects:

  • Cloudflare “Always Use HTTPS” and/or redirect rules
  • Your host control panel “Force HTTPS”
  • .htaccess redirects
  • nginx redirects
  • WordPress plugins (Really Simple SSL, security plugins, caching plugins)
  • WordPress itself (when URLs are set to HTTPS)

The “multiple enforcers” problem

If Cloudflare forces HTTPS, and your origin forces HTTPS, and your plugin forces HTTPS—with slightly different assumptions (www vs non-www, headers, proxy detection)—you can create loops or chains.

A related but slightly different SSL symptom is mixed content, and WP Fix It notes common SSL setups involve redirecting all incoming requests to HTTPS and updating site URLs. (WP Fix It)

Pick one layer to force the canonical redirect, and keep other layers consistent or disabled.


Step 5: Confirm WordPress knows it’s behind a proxy (Cloudflare headers)

When Cloudflare is involved, WordPress might not “see” HTTPS correctly unless the right headers are present.

Signs this is your issue

  • wp-admin redirects oddly
  • login redirects back to login
  • site works sometimes but loops for logged-in users
  • REST API calls redirect

Fix ideas (safe-first)

  • Make sure Cloudflare is not stripping headers
  • On many hosts, enabling “restore visitor IP” (or Cloudflare module) helps
  • Some SSL plugins handle reverse proxy detection—but avoid stacking multiple redirect solutions

Step 6: Check your .htaccess or server redirects for conflicts

If you’re on Apache, your .htaccess may contain redirect rules that clash with WordPress or Cloudflare.

WP Fix It has a practical guide to .htaccess usage and redirect concepts. (WP Fix It)

Example: force HTTPS + non-www (Apache)

Use either Cloudflare redirect rules or .htaccess, not both—unless you really know what you’re doing.

RewriteEngine On

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

If your site is behind Cloudflare, %{HTTPS} can be tricky depending on server config. Sometimes you must rely on X-Forwarded-Proto—but that’s host-specific.

If you don’t understand a rule, remove it temporarily

A surprising number of redirect loops are caused by old copy/paste redirect snippets from:

  • migration tutorials,
  • SSL plugin instructions,
  • or “force www” snippets that contradict DNS/CDN behavior.

Step 7: Cache Purge Order (this is where most people waste hours)

Here’s the dirty secret: you can “fix” everything and still see the redirect loop because a cache is still serving the old redirect response.

Cloudflare supports multiple purge options and recommends purging by URL (single-file) rather than nuking everything. (Cloudflare Docs)

Why purge order matters

Redirect responses (301/302) can be cached at:

  • browser level
  • Cloudflare edge
  • server-level cache (LiteSpeed, nginx fastcgi cache, Varnish)
  • WordPress caching plugin (page cache)
  • object cache (Redis/Memcached) in some cases

If you purge only one layer, another can “re-seed” it with the wrong behavior.

The correct cache purge order (use this exact sequence)

1) Fix configuration first (don’t purge yet)

  • Confirm WP_HOME/WP_SITEURL
  • Confirm Cloudflare SSL mode
  • Remove conflicting redirects
  • Confirm canonical URL plan (https + www/non-www)

2) Purge server/host cache

Examples:

  • LiteSpeed Cache: “Purge All”
  • Host panel cache: clear cache
  • Varnish: purge domain

Do this first so your origin is serving the correct responses.

3) Purge WordPress caching plugin cache

Examples:

  • WP Rocket: “Clear cache”
  • W3TC: “Purge All Caches”
  • SG Optimizer: “Flush Cache”

If you have multiple caching plugins (you shouldn’t), disable extras.

4) Purge Cloudflare cache

Use Cloudflare dashboard → Cache → Purge Cache

  • Prefer purge by URL for your homepage and key pages
    Cloudflare documents purge methods and recommends granular purging. (Cloudflare Docs)
    If you must, do “Purge Everything” once—but understand it’s heavy-handed.

Recommended URLs to purge:

  • https://example.com/
  • https://example.com/wp-login.php
  • https://example.com/wp-admin/
  • a few key pages that were looping

5) Purge browser cache / HSTS edge cases

  • Hard refresh (Ctrl+Shift+R / Cmd+Shift+R)
  • Try incognito
  • Try a different device/network
  • If you recently enabled HSTS, understand browsers can “remember” HTTPS-only behavior for a while

6) Re-test redirect chain

Use DevTools Network again. Your goal:

  • one redirect max from non-canonical → canonical
  • then 200 OK on the canonical URL

Step 8: Common redirect loop scenarios and the exact fix

Scenario A: WordPress URLs set to HTTP but site is HTTPS

Symptoms: front-end loops, wp-admin loops, REST issues
Fix:

  • Set WP_HOME/WP_SITEURL to https://...
  • Remove “force HTTPS” from plugin if WordPress itself is now correct
  • Purge caches in the order above

Scenario B: Cloudflare SSL mode = Flexible + origin forces HTTPS

Symptoms: endless loop only when Cloudflare proxy is on
Fix:

  • Change SSL mode to Full or Full (strict) (Cloudflare Docs)
  • Confirm origin has a cert installed
  • Purge Cloudflare cache

Scenario C: www vs non-www fight

Symptoms: www redirects to non-www, but another layer redirects back
Fix:

  • Pick one canonical host
  • Ensure WordPress + Cloudflare + .htaccess all match
  • Remove duplicate redirect rules

Scenario D: Cached 301 won’t die

Symptoms: you fixed settings but you still get redirected
Fix:

  • Purge host cache → WP cache → Cloudflare cache → browser cache (in that order)
  • Purge by URL at Cloudflare for the exact URLs involved (Cloudflare Docs)

Scenario E: It’s not a loop—it’s malware redirects

If your site is redirecting users to spam, popups, or random domains (especially only on mobile or only for first visit), that may be malicious rather than misconfiguration.

WP Fix It covers this specific situation here:
WordPress redirect malware (WP Fix It)

And if you need emergency cleanup help:
WordPress malware removal (WP Fix It)


Step 9: A clean “gold standard” setup (WordPress + Cloudflare)

If your goal is to fix WordPress redirect loop issues and make sure they don’t come back:

Recommended baseline

  • WordPress URLs:
    • WP_HOME = https://example.com
    • WP_SITEURL = https://example.com
  • Cloudflare:
    • SSL mode: Full (strict) (Cloudflare Docs)
    • Use one redirect method: either a Cloudflare redirect rule or origin redirect
  • Origin:
    • One canonical redirect rule only (if not handled at Cloudflare)
  • Caching:
    • One page cache plugin
    • Purge order documented and followed

Troubleshooting checklist (print-this mental model)

When you’re still stuck trying to fix WordPress redirect loop problems, run this checklist:

  1. What is the canonical URL? (https + www or non-www)
  2. Do WP_HOME/WP_SITEURL match that exactly? (WordPress Developer Resources)
  3. Is Cloudflare set to Full/Full(strict), not Flexible? (Cloudflare Docs)
  4. Are you forcing HTTPS in multiple layers? (reduce to one)
  5. Is .htaccess or nginx redirecting contrary to Cloudflare rules?
  6. Did you purge caches in the right order?
  7. Are you testing in a clean browser session?
  8. Is it actually malware redirects? (WP Fix It)

Helpful internal resources on WP Fix It (related to redirect loops)

If you want deeper supporting reads (or you suspect adjacent issues), these WP Fix It guides pair well with redirect-loop troubleshooting:


External references (authoritative + informational)

These are the core docs that support the key fixes in this post:


When to stop DIY and get it fixed fast

Redirect loops can get expensive fast: downtime, lost leads, broken checkout, SEO crawl errors, and users who bounce instantly.

If you’ve done:

  • URL constants corrected,
  • Cloudflare set to Full (strict),
  • conflicting redirects removed,
  • cache purge order followed,

…and it still loops, the fastest path is often having an expert trace the redirect chain at the server + CDN + WordPress level.

WP Fix It specializes in getting broken WordPress sites back online quickly:
fix WordPress issues (WP Fix It)


Quick recap: the shortest path to fix it

To fix WordPress redirect loop issues with the least pain:

  1. Choose your canonical URL: https:// + (www or non-www)
  2. Set WP_HOME + WP_SITEURL to match exactly (WordPress Developer Resources)
  3. If using Cloudflare, switch off Flexible → use Full or Full (strict) (Cloudflare Docs)
  4. Ensure only one redirect layer enforces the canonical rule
  5. Purge caches in the correct order: host → plugin → Cloudflare → browser (Cloudflare Docs)

When HTTP Does Not Redirect or Canonicalize to the HTTPS Homepage

If http://example.com loads without redirecting to https://example.com/, or the page has no canonical URL pointing to the HTTPS homepage, first determine whether the problem is a redirect issue or an SEO signal issue. A canonical tag does not force visitors or search engines to use HTTPS; it only states which URL WordPress considers preferred. The HTTP homepage should normally return a redirect, while the HTTPS homepage should return a successful response and identify itself as canonical.

  1. Test every homepage variant separately: check http://example.com/, http://www.example.com/, https://example.com/, and https://www.example.com/. Confirm that each non-canonical version reaches the same HTTPS host.
  2. Inspect the response chain: use the browser Network tab or a header request such as curl -I http://example.com/. The HTTP response should contain a redirect location using your chosen HTTPS hostname. If it returns 200, the HTTP-to-HTTPS rule is missing or is being bypassed.
  3. Check the canonical page source: on the HTTPS homepage, look for a canonical link whose URL exactly matches the preferred HTTPS homepage, including the www or non-www choice. A missing or conflicting canonical usually comes from WordPress URL settings, a SEO plugin, theme output, or cached HTML.
  4. Verify the origin separately: temporarily test the origin or disable the proxy only if your hosting setup permits it. If the origin redirects correctly but the proxied hostname does not, review Cloudflare redirect rules, SSL mode, and cached responses.

Set WP_HOME and WP_SITEURL to the same canonical HTTPS URL unless WordPress core is intentionally installed in a subdirectory. Then keep one HTTPS redirect rule at either Cloudflare or the origin, not multiple competing rules. Purge the origin, WordPress, and Cloudflare caches after changing the configuration, then retest in a private browser window. The target result is one redirect from each HTTP or alternate-host homepage to the canonical HTTPS homepage, followed by a successful response with a matching canonical URL.