Cloudflare is probably the most common addition to WordPress sites I work on. It’s free to start, it takes minutes to set up and it brings a CDN, DNS, SSL, a firewall and DDoS protection in one place. For most sites, it’s an easy win. Getting your Cloudflare WordPress settings right from the start is what keeps it that way.
But I’ve also spent many hours fixing problems that Cloudflare caused, or more accurately, that a particular Cloudflare setting caused in combination with a particular WordPress setup. Redirect loops, cached shopping carts, broken admin screens, contact forms that silently fail and mixed content warnings are all common.
This guide goes through the settings that matter, what they do and how to configure them for WordPress. It assumes you’ve already added your site to Cloudflare and pointed your domain’s nameservers to it.
SSL/TLS mode: get this right first
This is the setting that causes the most trouble. Cloudflare sits between visitors and your server, so there are two connections: visitor to Cloudflare, and Cloudflare to your server. The SSL mode controls the second one.
- Off. No HTTPS at all. Never use this.
- Flexible. Visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your server over plain HTTP. This is the cause of most redirect loops: WordPress sees an HTTP request, redirects to HTTPS, Cloudflare requests HTTP again, and round it goes.
- Full. Cloudflare connects to your server over HTTPS but doesn’t validate the certificate.
- Full (strict). Cloudflare connects over HTTPS and requires a valid certificate on your server.
Use Full (strict). If your server doesn’t have a valid certificate, get one. Let’s Encrypt is free, or you can install a Cloudflare Origin Certificate, which is trusted by Cloudflare and valid for up to fifteen years.
Flexible mode also means traffic between Cloudflare and your server is unencrypted, which defeats much of the point of HTTPS. It exists for servers that can’t support HTTPS, and in 2026 there’s no good reason for a WordPress server to be in that position.
Also turn on “Always Use HTTPS” so HTTP requests are redirected at Cloudflare, before reaching your server.
Caching: what Cloudflare caches by default
By default, Cloudflare caches static files like images, CSS and JavaScript based on file extension. It does not cache HTML pages. So out of the box, Cloudflare speeds up asset delivery but every page request still goes to your server.
That’s safe. It also leaves a lot of performance on the table, because the HTML is where the server does its work.
Caching HTML safely
There are two common approaches to caching WordPress HTML at Cloudflare.
Automatic Platform Optimization (APO)
APO is a paid add-on on the free plan and included in higher plans. It caches WordPress HTML at Cloudflare’s edge, works with the official Cloudflare WordPress plugin to purge cache when content changes and automatically bypasses cache for logged-in users and WooCommerce cart and checkout pages based on cookies.
For most content-focused WordPress sites, APO is the easiest way to get full-page caching at the edge with sensible defaults. It’s less suitable for highly dynamic sites where pages vary by user.
Cache Rules
If you don’t use APO, you can create Cache Rules to cache HTML yourself. This gives more control but requires care. A basic rule caches everything except:
- Paths starting with /wp-admin and /wp-login.php
- Requests with cookies starting with wordpress_logged_in_, wp-postpass_, comment_author_ or woocommerce_
- WooCommerce paths like /cart, /checkout and /my-account
- Requests with query strings used for previews or search
If you get the bypass rules wrong, you’ll serve one user’s cart or logged-in admin bar to everyone else. That’s the classic Cloudflare horror story, and it’s entirely avoidable with careful rules and testing.
You’ll also need a way to purge the cache when content changes. The Cloudflare plugin or a caching plugin with Cloudflare integration can purge specific URLs when posts are updated.
Browser cache TTL
This tells visitors’ browsers how long to keep files. Setting it very high is fine for versioned assets like style.css?ver=1.2, because WordPress changes the version when files change. It’s a problem if you upload a new image with the same file name, because returning visitors keep the old one.
“Respect Existing Headers” is a safe choice if your server sets sensible cache headers. Otherwise, a few hours to a day for HTML-adjacent content and longer for static assets is a reasonable starting point.
Settings to avoid or use carefully
Rocket Loader
Rocket Loader changes how JavaScript loads to speed up rendering. On some sites it helps. On many WordPress sites, it breaks things: sliders that don’t start, forms that don’t submit, analytics that don’t fire, page builder features that misbehave. If you enable it, test thoroughly. If anything is odd, turn it off first.
Auto Minify
Cloudflare used to offer HTML, CSS and JavaScript minification. It has been deprecated, and most WordPress caching plugins do this better anyway. If you still see it in an older account, leave it off and handle minification in WordPress or your build process.
Email Obfuscation
This rewrites email addresses in your HTML to hide them from scrapers. It occasionally breaks JavaScript or JSON that contains email-like strings. Usually harmless, but worth remembering when debugging odd issues.
Development Mode and Under Attack Mode
Development Mode bypasses the cache temporarily, which is useful while making changes. Under Attack Mode shows a challenge page to every visitor. Use it during a real attack, not as a permanent setting, because it adds friction for everyone and can break integrations that call your site, like payment webhooks.
Firewall and security rules
Cloudflare’s WAF is one of its strongest features. The free plan includes managed rules for common attacks, and you can create custom rules.
Useful custom rules for WordPress:
- Block xmlrpc.php if you don’t use it.
- Challenge or rate limit wp-login.php to slow brute-force attempts. A managed challenge for login requests from outside your country is a reasonable option for many small businesses.
- Block access to sensitive files such as wp-config.php backups, .env files and readme.html.
- Allow your own IP for admin areas if you want to restrict them further.
Be careful with rules that affect /wp-admin/admin-ajax.php and /wp-json/. The front end of many sites uses these, so challenging them can break forms, filters, carts and search.
Bot Fight Mode
Bot Fight Mode challenges traffic Cloudflare thinks is automated. It reduces junk traffic, but it can also block legitimate services that call your site: payment gateways sending webhooks, uptime monitors, backup services, Jetpack, and some search tools. On the free plan you can’t add exceptions to Bot Fight Mode.
If you rely on webhooks, especially for WooCommerce payments, test carefully or leave it off and use targeted WAF rules instead.
Getting the real visitor IP
Behind Cloudflare, your server sees Cloudflare’s IP address for every request, not the visitor’s. This breaks security plugins, login limiting, analytics and comment spam filtering, because everyone appears to come from the same handful of addresses.
Fix it at the server level by trusting the CF-Connecting-IP header from Cloudflare’s IP ranges. On Nginx, that’s the real_ip module:
Use the current list from Cloudflare’s website and update it occasionally. Many managed hosts handle this automatically, so check first.
Also consider locking your origin server so it only accepts web traffic from Cloudflare’s IP ranges. Otherwise attackers who discover your server’s real IP can bypass Cloudflare entirely.
Testing after setup
After configuring Cloudflare, test:
- Load the site logged out, then logged in. The admin bar should only appear when logged in.
- Add a product to the cart in a private window and confirm another private window shows an empty cart.
- Submit every form.
- Complete a test checkout, including the payment gateway’s return to your site and its webhook.
- Check response headers for cf-cache-status to see what’s being cached: HIT, MISS, BYPASS or DYNAMIC.
| <code>curl -sI https://example.com/ | grep -i cf-cache-status</code> |
|---|
If the homepage shows HIT after a second request and your cart page shows BYPASS or DYNAMIC, your rules are doing what you intended.
A sensible starting configuration
For a typical business site:
- SSL/TLS set to Full (strict), Always Use HTTPS on.
- Default static file caching, plus APO or careful Cache Rules for HTML.
- Rocket Loader off.
- Managed WAF rules on, plus custom rules for xmlrpc.php and login rate limiting.
- Real visitor IP configured on the server.
- Bot Fight Mode only after testing webhooks.
Start simple and add features one at a time, testing as you go. When something breaks after a Cloudflare change, you’ll know exactly which setting caused it. Revisit your Cloudflare WordPress settings after major site changes, because a rule that was safe last year may not suit a new checkout or plugin.
Frequently asked questions
Do I still need a caching plugin with Cloudflare?
Usually yes. A server-side page cache handles requests that reach your server, including cache misses and logged-in users. Cloudflare’s edge cache sits in front of that.
Why does my site show a redirect loop after adding Cloudflare?
Almost always the SSL mode is set to Flexible while WordPress is configured for HTTPS. Switch to Full (strict) with a valid certificate on the server.
Is the free plan good enough?
For most small business sites, yes. Paid plans add more WAF rules, image optimisation and better support, which matter more as traffic and risk grow.
Will Cloudflare improve my Core Web Vitals?
It can, mainly by reducing server response time and delivering assets from nearby locations. It won’t fix heavy JavaScript, large images or layout shifts on its own.
