Cloudflare sits between your visitors and your web server, acting as DNS provider, content delivery network, SSL terminator and firewall in one. For a WordPress site that can mean faster page loads, less load on your host and a layer of protection against bots and attacks, often on the free plan. It can also cause redirect loops, cached admin bars and broken logins if it is set up carelessly. This guide covers how the service works, a clean setup sequence, the settings that matter for WordPress, and the pitfalls to avoid.
How Cloudflare works with WordPress
When you add a domain, you point its nameservers to the service. From then on it answers DNS queries for your domain. Each DNS record can be either proxied (the orange cloud) or DNS only (the grey cloud). Proxied records resolve to the network’s edge servers rather than your host’s IP address, so every request passes through its data centers first, where it can be cached, filtered or served over HTTPS before reaching your origin server.
Two consequences follow. First, static files such as images, CSS and JavaScript can be served from an edge location near the visitor instead of your server. Second, your origin’s real IP address is hidden from casual lookups, which makes direct attacks harder. WordPress itself does not need to know much about any of this, but a few settings on both sides must agree, especially around HTTPS.
Setting it up step by step
- Take a backup of your site and a screenshot or export of your current DNS records at your registrar or host.
- Create an account and add your domain. The dashboard scans existing DNS records and imports what it finds.
- Review every imported record. Scans miss things. Compare against your export, and confirm MX, TXT (SPF, DKIM, DMARC) and any subdomains are present.
- Choose proxy status. Proxy the records serving your website (the root domain and
www). Leave mail-related records and anything that is not HTTP traffic, such as a mail server hostname or FTP, as DNS only. - Install a valid certificate on your origin before switching (see the SSL section below).
- Change your nameservers at your domain registrar to the two assigned to your account. Propagation is often quick but can take up to a day or two.
- Set the SSL mode to Full (strict) and enable “Always Use HTTPS”.
- Test the front end, wp-admin login, forms, checkout and email delivery, logged in and logged out.
Some hosts offer an integration that connects your domain without changing nameservers (a partial or CNAME setup). That is fine too; the settings below still apply.
SSL modes: why Full (strict) matters
The SSL/TLS mode controls how the edge connects to your origin server. There are four main options, documented in the official SSL modes reference:
| Mode | Visitor to edge | Edge to origin | Verdict for WordPress |
|---|---|---|---|
| Off | HTTP | HTTP | Never use |
| Flexible | HTTPS | HTTP | Avoid: causes redirect loops and leaves the second hop unencrypted |
| Full | HTTPS | HTTPS, certificate not validated | Acceptable as a temporary step |
| Full (strict) | HTTPS | HTTPS, valid certificate required | Recommended |
Full (strict) needs a valid certificate on your server. A free Let’s Encrypt certificate from your host works, or you can generate a free Origin CA certificate in the dashboard and install it on your server; that certificate is trusted by the edge but not by browsers, so only use it on proxied records.
On the WordPress side, make sure both WordPress Address and Site Address under Settings → General start with https://, and update any hard-coded http:// links in content with a search-and-replace tool or WP-CLI.
Caching: static files, HTML and APO
By default the CDN caches static file types (images, CSS, JavaScript, fonts) but not HTML. Your pages are still generated by WordPress on every uncached request, so the biggest speed gain comes from caching HTML too, which must be done carefully because logged-in users, carts and previews must never be cached for everyone.
Automatic Platform Optimization (APO)
APO is a product built specifically for WordPress. It caches HTML at the edge, bypasses the cache for logged-in users and common e-commerce cookies, and purges pages automatically when you publish or update content, via the official Cloudflare WordPress plugin. It is a paid add-on on the free plan and included with higher plans; check the current pricing page. See the APO documentation for supported setups.
Cache Rules
Without APO you can cache HTML with Cache Rules (the newer replacement for Page Rules), found under Caching → Cache Rules. A typical pattern is “cache everything” for your hostname, with bypass conditions for:
- URI paths starting with
/wp-adminand the file/wp-login.php - Requests carrying cookies such as
wordpress_logged_in_,wp-postpass_andcomment_author_ - WooCommerce cart, checkout and account pages, plus the
woocommerce_items_in_cartcookie /wp-json/REST API routes and preview URLs withpreview=true
Pair HTML caching with a purge mechanism, either the official plugin or your caching plugin’s integration, so readers see updated posts. If your host already runs a server-side page cache, edge caching is an extra layer on top; keep the two consistent rather than fighting each other. For the rest of the performance picture, see our speed optimization guide.
Security: WAF, bots and Turnstile
The proxy gives you DDoS mitigation on every plan. On top of that, a few tools are especially useful for WordPress:
- Web Application Firewall. Managed rulesets block known exploit patterns. The free plan includes a basic managed ruleset; fuller rulesets, including WordPress-specific rules, come with paid plans.
- Custom rules. You can challenge or block requests to
/wp-login.phpand/xmlrpc.phpfrom outside your country, or blockxmlrpc.phpentirely if you do not use the mobile apps or Jetpack features that rely on it. - Rate limiting. Throttle repeated login attempts before they reach PHP.
- Bot Fight Mode. Challenges automated traffic, but test it: it can interfere with legitimate webhooks, uptime monitors and payment gateway callbacks.
- Turnstile. A free, privacy-friendly CAPTCHA alternative you can add to login, registration, comment and contact forms with a plugin or your form builder’s built-in integration. It works even if your site is not proxied.
Edge protection complements, rather than replaces, the basics inside WordPress: updates, strong passwords, two-factor authentication and least-privilege accounts. Our security hardening guide covers those.
Common pitfalls and how to fix them
ERR_TOO_MANY_REDIRECTS
Almost always Flexible SSL combined with WordPress or the server forcing HTTPS. The edge requests HTTP, the origin redirects to HTTPS, and the loop repeats. Install a certificate on the origin and switch to Full (strict).
Logged-in content shown to visitors
A “cache everything” rule without cookie and path bypasses can serve a page with the admin bar, or someone’s cart, to everyone. Purge the cache immediately and add the bypass conditions listed above.
Wrong visitor IP addresses
Behind the proxy, your server sees edge IPs instead of real visitors, which confuses security plugins, comment spam filters and analytics. The real address arrives in the CF-Connecting-IP header. Many hosts restore it automatically; otherwise configure your web server (for example Apache’s mod_remoteip) or use your security plugin’s setting for trusted proxies.
Broken scripts and email
Optional features that rewrite JavaScript, such as Rocket Loader, can break sliders, the block editor or checkout scripts; if something misbehaves, turn them off first. If email stops arriving after the switch, check that MX records exist and that mail hostnames are DNS only.
Frequently asked questions
Is the free plan enough for a WordPress site?
For many small and medium sites, yes: DNS, static caching, free SSL at the edge, basic DDoS protection and Turnstile cover a lot. APO and fuller WAF rulesets are the usual reasons to pay.
Do I still need a caching plugin?
Often yes, or a host-level cache. Edge caching misses still hit your server, and logged-in users always bypass the edge, so origin caching keeps those requests fast.
Will it work with my managed host?
Usually, but some managed WordPress hosts run their own CDN or an Enterprise integration and recommend a specific configuration. Check your host’s documentation before adding a second proxy layer.
Key takeaways
- Cloudflare works by proxying your DNS records, so check every imported record and keep mail records DNS only.
- Always use Full (strict) SSL with a valid origin certificate; Flexible causes redirect loops.
- HTML is not cached by default: use APO or Cache Rules with bypasses for admin, logged-in, cart and REST requests.
- Combine WAF rules, rate limiting and Turnstile with good security practice inside WordPress.
- Restore real visitor IPs and test logins, forms, checkout and email after every change.
