CF GarageWhat changes with WordPress behind the proxy
WordPress mixes three kinds of traffic that need opposite treatments: anonymous page views (cacheable), authenticated sessions (never cached), and high-volume automation such as xmlrpc.php and wp-login.php (rate limited). A Cloudflare setup that treats them identically produces the classic symptoms: admin pages that log you out, carts that empty, or a hit ratio stuck near zero.
Setting it up step by step
Step 1: set SSL/TLS to Full (strict). In SSL/TLS > Overview, choose Full (strict). Flexible mode makes the edge fetch your origin over plain HTTP and is the number-one cause of redirect loops on WordPress (ERR_TOO_MANY_REDIRECTS) and of mixed-content warnings. Install a free origin certificate or a valid Let's Encrypt certificate on the server.
Step 2: bypass cache for authenticated traffic. Add a Cache Rule: when the request matches wp-admin paths or carries a WordPress login cookie (Cookie contains "wordpress_logged_in"), set cache eligibility to Bypass. Anonymous pages stay cacheable, logged-in editors get a live site.
Step 3: cache the rest aggressively. Extend edge and browser TTL for /wp-content/ static assets. WordPress versions static files by filename when you use optimization plugins, so long TTLs are safe. This single rule typically lifts the hit ratio from near zero to the 80-95% range, as detailed in our guide on cache diagnostics and hit ratios.
Step 4: protect the login and xmlrpc endpoints. wp-login.php and xmlrpc.php absorb constant brute-force noise. A Rate Limiting rule on those exact paths (a few requests per minute per IP, Managed Challenge action) removes the noise without touching real editors. For deeper form protection, the patterns in our guide on credential stuffing and abusive signups apply directly.
Step 5: real IPs and purge strategy. Make sure your WordPress sees visitor IPs (Cloudflare restores the CF-Connecting-IP header; plugins or server config translate it) so security plugins do not ban Cloudflare's IPs. And before any theme update, plan the purge: WordPress does not signal content changes to the edge by itself unless your caching plugin talks to the Cloudflare API.
Common mistakes on WordPress sites
- Flexible SSL "to make it work". It hides the real problem (no certificate at origin) and creates loops with typical WordPress redirect configs. Full (strict) is the correct setting.
- Changing A records to DNS only to "fix" the cache. That removes every protection and acceleration. Fix the cache rules instead.
- Blocking without exempting verified bots. Aggressive bot blocking that ignores
cf.client.botrisks search crawler access; our guide on accidental Googlebot blocking covers the recovery. - Leaving
xmlrpc.phpwide open. Unless a plugin requires it, rate limit or block it; it is the favorite amplifier of password spraying. - Forgetting the A record's proxy status after a staging switch. DNS-only records expose the server IP and skip all rules.
Frequently asked questions
Does Cloudflare caching break WordPress logins or carts?
Not when the bypass rule covers logged-in cookies and admin paths. The breakages happen when HTML is cached indiscriminately, which serves one user's session to another. Separate anonymous from authenticated traffic and both problems disappear.
Do I still need a caching plugin with Cloudflare?
They do different jobs: the plugin handles page caching at the server and purges it on content updates, while Cloudflare caches at the edge closer to visitors. Many sites use both; if you use only one, decide deliberately which layer owns page caching.
Why do I get a redirect loop after enabling Cloudflare?
Almost always Flexible SSL combined with a WordPress or server configuration that forces HTTPS. The edge serves HTTP to the origin, the origin redirects to HTTPS, and the cycle repeats. Set Full (strict) and fix the loop instantly.
Should I proxy the wp-admin subdomain?
Proxy it: the protections apply to admin traffic too, and the bypass cache rule keeps it functional. Add your office IPs to an allowlist rule if you want stricter access, and keep webhooks and integrations exempt from the strictest rules.