If you only fix one setting after reading this: check your SSL/TLS mode. It's set to Full (strict), not Flexible, and that single setting is behind more Cloudflare + WordPress support tickets than everything else in this guide combined. Beyond that: bypass cache for /wp-admin/* and /wp-login.php, rebuild any old Page Rules as Redirect Rules or Cache Rules (Page Rules are deprecated and silently stop working), and scope Cloudflare's bot-protection features so they don't lock out your own login. The rest of this guide covers the full setup, plus the four specific ways we've seen this combination break after it's already running.
DNS and nameservers — the one-time setup
Point your domain's nameservers to the two Cloudflare gave you when you added the site, then confirm every DNS record you actually want protected has the proxy status set to Proxied (the orange cloud icon), not DNS only (grey cloud). This matters more than it sounds: a grey-clouded record bypasses Cloudflare entirely for that subdomain — no caching, no WAF, no SSL termination at the edge — which is sometimes intentional (a mail server record, for instance) but is a common accidental gap if it happens on your main www or @ record.
SSL/TLS mode — the setting that causes the most breakage
Set SSL/TLS mode to Full (strict). This encrypts traffic both from visitor to Cloudflare and from Cloudflare to your origin server, and validates that your origin's certificate is real — which it will be on any modern host, including a free Let's Encrypt certificate from aaPanel.
Flexible mode is where almost every Cloudflare + WordPress redirect loop comes from. In Flexible, Cloudflare terminates SSL at its own edge and talks to your origin over plain HTTP — but WordPress (or a security plugin, or a .htaccess rule) is very often configured to force every request to HTTPS. The result: your origin sees an HTTP request, redirects it to HTTPS, Cloudflare receives that redirect and re-requests over HTTP again since that's what Flexible mode does — and the browser gives up with ERR_TOO_MANY_REDIRECTS. Switching to Full (strict) resolves this immediately, provided your origin's SSL certificate is actually valid — check that first if the switch itself causes an outage instead of fixing one.
Caching — what to cache, and what to never cache
Cache static assets and publicly-viewable pages aggressively; that's most of the performance benefit Cloudflare offers a WordPress site. But explicitly bypass cache for /wp-admin/*, /wp-login.php, and anything tied to a logged-in session — caching the admin area produces stale nonces, broken CSRF tokens, and editors seeing each other's half-finished changes.
If your setup predates Cloudflare's deprecation of Page Rules, check whether any old rule handling this (or a redirect, or a cache exception) is quietly no longer working — Page Rules didn't get removed overnight, but they stopped being editable and are being phased out in favor of Cache Rules and Redirect Rules. A rule that worked fine for years can silently stop applying after an unrelated Cloudflare-side change, which is exactly the failure mode covered in the linked fix below.
Cloudflare APO (Automatic Platform Optimization, a paid add-on) caches full rendered HTML pages at the edge and integrates with WordPress's own cache-purge hooks — worth it for a high-traffic, content-heavy site, but not something a small-to-medium WordPress site needs to start with. The free tier's standard caching covers most sites completely.
Security features that conflict with WordPress logins
Cloudflare's bot-protection features — Managed Challenge, Turnstile, Bot Fight Mode — are the most common cause of a legitimate admin getting locked out of their own site. If any of these apply an aggressive challenge to /wp-login.php or /wp-admin/* without an explicit exception, a real admin logging in can get stuck behind a "Checking your browser" screen repeatedly, or bounced back to the login form after passing the challenge.
This gets worse, not better, when combined with a WordPress-side security plugin doing its own two-factor authentication — Wordfence's 2FA step and a Cloudflare Turnstile challenge can end up fighting each other, producing a genuine infinite loop rather than just one extra verification step. If you run both, test the full login flow (including 2FA) immediately after any Cloudflare security setting change, not just a plain login.
The WordPress-side plugin — what it actually does
The official Cloudflare plugin for WordPress isn't required for Cloudflare to work — DNS proxying, caching, and SSL termination all happen regardless of whether it's installed. What it actually does is purge Cloudflare's cache automatically whenever you publish or update a post, so readers see the new version immediately instead of a cached copy from before your edit. Without it, you (or your editors) need to manually purge cache after every content change, which is easy to forget. Install it for that convenience; don't treat it as a setup requirement.
Common Cloudflare + WordPress problems (and where to fix them)
- Cloudflare Challenge Loop on Your WordPress Login — the exact settings to fix a Managed Challenge loop on wp-login.php without disabling security entirely.
- Cloudflare Killed Page Rules — Here's Why Your WordPress Redirects Broke — how to find an old Page Rule and rebuild it as a Redirect Rule.
- 'Updating Failed: Response Is Not a Valid JSON Response' — Cloudflare Fix — how to find the specific Cloudflare rule blocking the block editor's autosave request.
- WordPress Login Loop After a Cloudflare Turnstile Update — the Wordfence 2FA conflict behind this exact loop, and how to fix or unlock it.
FAQ
What SSL/TLS mode should I use for WordPress on Cloudflare?
Full (strict). Confirm your origin server has a valid SSL certificate first — most hosts, including aaPanel via Let's Encrypt, issue one free — since Full (strict) will fail to connect if the origin certificate isn't valid.
Why does my WordPress site show a redirect loop right after adding Cloudflare?
Almost always Flexible SSL mode fighting against WordPress's own force-HTTPS behavior. Cloudflare terminates SSL at the edge and talks to your origin over plain HTTP in Flexible mode; if your origin then redirects that HTTP request to HTTPS, the two sides bounce the request back and forth until the browser gives up. Switch to Full (strict).
Do I need to install the Cloudflare WordPress plugin?
No. Cloudflare protects, caches, and terminates SSL for your site at the DNS/proxy level regardless of whether the plugin is installed. The plugin's only real job is auto-purging Cloudflare's cache when you publish or update content — a convenience, not a requirement.
