Cloudflare sits in front of millions of WordPress sites — acting as a CDN, DDoS protection layer, DNS manager, and performance optimiser simultaneously. When configured correctly, it dramatically reduces page load times, absorbs attack traffic before it reaches the server, and provides SSL without any hosting changes. But WordPress Cloudflare integration has specific configuration requirements that, when missed, cause 521 errors, redirect loops, broken admin access, and caching conflicts. This guide covers the complete correct setup and every common problem. This fits into the wider topic we cover in our Complete Guide to WordPress How.
WordPress Cloudflare — Initial Setup
Setting up WordPress Cloudflare integration starts at the DNS level, not at the plugin level. Cloudflare works by proxying all traffic through its network — DNS records for the domain must point to Cloudflare’s nameservers, and individual DNS records must have the orange cloud (proxy) enabled rather than the grey cloud (DNS-only).
Add the site to Cloudflare: sign in at cloudflare.com → Add a site → enter the domain → select the free plan (covers all essential WordPress features) → Cloudflare scans existing DNS records → review and confirm the scanned records are complete → update the domain’s nameservers at the registrar to the two Cloudflare nameservers provided. Nameserver propagation takes up to 48 hours but is typically complete within 2–4 hours. After propagation, Cloudflare’s dashboard shows the site as Active. Verify each DNS record has the correct proxy status: the A record and CNAME record for the domain and www subdomain should have the orange cloud (proxied); MX records for email should always be grey cloud (DNS-only, never proxied through Cloudflare). Proxying email through Cloudflare breaks mail delivery — email records must always be grey cloud regardless of the WordPress Cloudflare configuration.
Install the Cloudflare plugin for WordPress: WordPress admin → Plugins → search “Cloudflare” → install the official Cloudflare plugin → configure with Cloudflare API credentials (API token or Global API Key from the Cloudflare dashboard → Profile → API Tokens). The WordPress Cloudflare plugin provides automatic cache purging when WordPress content is updated — without it, Cloudflare serves cached pages after content changes until the cache expires. It also enables Automatic Platform Optimisation (APO) for WordPress, which caches WordPress pages at Cloudflare’s edge for even faster delivery. Configure APO: Cloudflare plugin → Home → Enable Automatic Platform Optimisation. APO is free for WordPress sites on any Cloudflare plan. According to Cloudflare’s developer documentation, APO reduces TTFB (Time to First Byte) by serving cached HTML from Cloudflare’s edge rather than waiting for the origin server to generate it, typically reducing TTFB from 300–800ms to under 30ms for cached pages.
Fixing WordPress Cloudflare SSL and HTTPS Issues
The most common WordPress Cloudflare problem after initial setup is an SSL/HTTPS loop or error. Cloudflare sits between the browser and the WordPress server — there are two SSL connections to configure correctly: browser-to-Cloudflare and Cloudflare-to-origin.
Set the SSL/TLS encryption mode correctly: Cloudflare dashboard → SSL/TLS → Overview → select “Full (strict)” if the origin server has a valid SSL certificate (from Let’s Encrypt or a paid certificate). “Full” (not strict) works if the origin has a self-signed certificate. Never use “Flexible” — this mode means Cloudflare connects to the origin over HTTP, and if WordPress is configured to use HTTPS, a redirect loop occurs (WordPress redirects to HTTPS, Cloudflare fetches HTTP, WordPress redirects again, indefinitely). The “Flexible” mode is the single most common cause of HTTPS redirect loops in WordPress Cloudflare configurations.
Enable the Always Use HTTPS setting in Cloudflare: SSL/TLS → Edge Certificates → Always Use HTTPS → enable. This forces Cloudflare to redirect all HTTP requests to HTTPS at the edge, before they reach the origin server. Pair this with the WordPress HTTPS settings: ensure WordPress Address and Site Address in Settings → General both use https://, and add define('FORCE_SSL_ADMIN', true); to wp-config.php. With Cloudflare handling the HTTPS enforcement at the edge and WordPress configured for HTTPS internally, all requests use HTTPS consistently without the redirect loops that occur when only one layer enforces it. Our guide on adding SSL to WordPress covers the origin server SSL configuration that is the prerequisite for setting Cloudflare to Full (strict) mode.
Cloudflare Cache and WordPress Content
WordPress Cloudflare caches static assets (images, CSS, JavaScript, fonts) by default when the orange proxy is enabled. With APO enabled, it also caches HTML pages. Both types of caching require correct configuration to avoid serving stale content to WordPress visitors after updates.
Configure the WordPress Cloudflare cache behaviour: Cloudflare dashboard → Caching → Cache Rules → create a rule to bypass cache for WordPress admin and logged-in users. A cache bypass rule: URL path contains “/wp-admin/” OR cookie contains “wordpress_logged_in” → Cache status: Bypass. Without this rule, Cloudflare may cache admin pages or serve the same cached page to a logged-in user as an anonymous visitor — causing data privacy issues and broken admin experiences. The official Cloudflare plugin for WordPress creates these bypass rules automatically when APO is enabled, but manually verifying the rules exist confirms no misconfiguration.
After publishing in WordPress, the WordPress Cloudflare automatic cache purge from the Cloudflare plugin clears the affected URLs from Cloudflare’s cache. Verify this is working: publish a test post → immediately visit the post URL → check the response headers for CF-Cache-Status: MISS (fresh from origin) or CF-Cache-Status: HIT (from Cloudflare cache). A HIT immediately after publishing indicates the cache purge did not work — check the Cloudflare plugin settings and confirm the API credentials are valid. Manual purge as a fallback: Cloudflare dashboard → Caching → Purge Cache → Purge Everything. This purges all cached content from all Cloudflare edge nodes globally, ensuring the next request for every URL fetches fresh content from the WordPress origin. Use “Purge Everything” sparingly — it temporarily increases origin server load as Cloudflare rebuilds its cache. Our guide on the complete WordPress caching guide covers how Cloudflare CDN cache fits into the full WordPress caching stack alongside page caching plugins and browser caching headers.
Cloudflare Firewall Rules for WordPress Security
WordPress Cloudflare firewall rules are the security layer that blocks malicious traffic before it reaches the origin — providing a security layer that server-level plugins like Wordfence cannot, because Cloudflare drops the traffic at its network edge rather than at the PHP level. This reduces server load from attacks and blocks threats that would otherwise consume WordPress PHP execution time.
Create essential WordPress Cloudflare firewall rules: Security → WAF → Custom Rules. Essential rules for WordPress:
- Block xmlrpc.php access — unless specifically needed for Jetpack or mobile apps: URI Path equals “/xmlrpc.php” → Action: Block. This eliminates XML-RPC brute force attacks that target this endpoint specifically.
- Challenge suspicious wp-admin access — requests to /wp-admin/ from countries or ASNs known for attack traffic: URI Path contains “/wp-admin/” AND Country not in [your country list] → Action: Managed Challenge. This adds a CAPTCHA for non-domestic admin access without blocking legitimate remote admins.
- Rate limit wp-login.php — more than 5 requests per minute to the login page from a single IP: URI Path equals “/wp-login.php” → Rate limiting → Action: Block for 1 hour after 5 requests. This blocks brute force login attempts at the Cloudflare network level before they consume server resources.
Bot Fight Mode (Security → Bots → Bot Fight Mode → enable) adds Cloudflare’s machine learning bot detection to block known malicious bots from reaching the WordPress site. Combined with the custom WAF rules, the WordPress Cloudflare security configuration blocks the vast majority of automated attack traffic before it reaches PHP. Reviews from independent web security publications confirm that Cloudflare’s free plan WAF, combined with Bot Fight Mode and rate limiting on login and xmlrpc endpoints, eliminates the most common automated attacks on WordPress sites without requiring any plugin-level security overhead.
WordPress Cloudflare Performance Optimisation
Beyond CDN and security, WordPress Cloudflare provides performance optimisations that reduce page load time for the resources Cloudflare serves directly. Correctly configuring these options produces measurable Core Web Vital improvements without any server-side changes.
Enable the key performance features in Cloudflare: Speed → Optimisation → enable “Auto Minify” for JavaScript, CSS, and HTML (reduces file sizes by removing unnecessary whitespace); enable “Rocket Loader” with caution — it defers JavaScript loading to improve perceived performance, but can break plugins that require synchronous JavaScript execution (test thoroughly before enabling in production). Speed → Optimisation → Image Optimisation → enable “Polish” (compresses images) and “WebP” (converts images to WebP format for browsers that support it) — both improve image load times without any WordPress-side image processing. Speed → Optimisation → Brotli → enable (more efficient compression algorithm than Gzip for text files, reducing CSS and JavaScript transfer sizes by an additional 15–20% compared to Gzip).
Cloudflare Page Rules (or the newer Rules system) allow URL-specific behaviour overrides that handle edge cases in WordPress Cloudflare performance configuration. Create a page rule for WooCommerce checkout: URL = yoursite.com/checkout/* → Cache Level: Bypass. This ensures checkout and cart pages are never served from cache — critical for WooCommerce where cached cart data could show one customer another customer’s order details. Create a page rule for the WordPress admin: URL = yoursite.com/wp-admin/* → Cache Level: Bypass, Security Level: High. The elevated security level adds CAPTCHA challenges for admin access from suspicious IP addresses while bypassing cache to ensure admin pages are always fresh. These rules complete the WordPress Cloudflare configuration, ensuring performance optimisation for public pages while preserving correct dynamic behaviour for authenticated and transactional pages. Our guide on fixing WordPress admin bar missing covers the SSL and cookie configuration that intersects with Cloudflare’s proxy when the admin bar disappears on HTTPS-proxied WordPress sites.
Cloudflare’s analytics dashboard provides real-time data on the traffic hitting the WordPress Cloudflare proxy — including requests served from cache versus from the origin, bandwidth saved by the CDN, and security threats blocked. Analytics → Traffic → check the “Cached” versus “Uncached” breakdown. A healthy Cloudflare-WordPress configuration shows 60–80%+ of traffic served from cache (Cached), with only uncacheable dynamic requests (admin, checkout, logged-in pages) going to the origin. A low cache hit rate indicates cache bypass rules that are too broad, or that APO is not enabled. Security → Threats shows blocked requests by attack type — monitoring this confirms the firewall rules are active and quantifies the attack traffic being blocked before it reaches the WordPress server.
Troubleshooting 521 and 522 errors in WordPress Cloudflare setups requires understanding what these codes mean: a 521 error (Web server is down) means Cloudflare can connect to the origin server’s IP but the origin web server is refusing the connection. A 522 error (Connection timed out) means the origin server accepted Cloudflare’s TCP connection but did not respond in time. Both indicate the origin server has a problem — not a Cloudflare problem. For 521 errors: verify the web server (Apache, Nginx, LiteSpeed) is running on the origin via SSH or hosting control panel. For 522 errors: the origin server is overloaded or a firewall on the origin is blocking Cloudflare’s IP ranges. Whitelist Cloudflare’s IP ranges (listed at cloudflare.com/ips/) in the origin server’s firewall to ensure Cloudflare’s proxy requests are always accepted. Our guide on diagnosing WordPress site down events covers the full origin server diagnostic procedure that resolves 521 and 522 errors at the server level when the Cloudflare proxy correctly identifies origin server issues.
Cloudflare Workers provide the most advanced WordPress Cloudflare customisation — serverless JavaScript that runs at Cloudflare’s edge and can modify requests and responses before they reach the WordPress origin. For most WordPress sites, Workers are unnecessary, but specific use cases benefit significantly: A/B testing different page versions without WordPress plugins, adding custom headers to all responses, implementing edge-side personalisation that shows different content per country without origin server changes, and transforming image URLs to use a different CDN. Cloudflare Workers are available on the free plan with 100,000 requests per day — sufficient for most WordPress sites’ A/B testing or header modification needs. The Workers KV (key-value storage) can cache WordPress-specific data at the edge, enabling even faster responses for data that changes infrequently but is expensive to compute on the WordPress origin.
DNS-only mode (grey cloud) in Cloudflare provides DNS management without any proxy, CDN, or security features — useful for specific subdomains (mail, ftp, legacy API endpoints) that must connect directly to the origin without Cloudflare interception. For WordPress Cloudflare setups on multisite networks, the main domain and www subdomain should be orange cloud (proxied) while dedicated subdomains for specific subsites may need individual proxy decisions based on whether those subsites benefit from Cloudflare caching or need direct origin access. Verifying the orange cloud status of each DNS record in the Cloudflare DNS panel after any DNS change confirms the proxy configuration remains correct and that no records were accidentally switched to grey cloud during DNS management updates.
