Best Cloudflare Settings for WordPress (2026 Setup Guide)

Cloudflare is the easiest performance and security win available for a WordPress site — a free CDN, DDoS protection, and SSL with a 5-minute DNS change. But several Cloudflare settings actively break WordPress if configured incorrectly, and the documentation doesn't make this obvious.

This guide covers the correct setup for WordPress (and WooCommerce) — what to enable, what to disable, and why.

Step 1: Add your site to Cloudflare

1. Create a free account at cloudflare.com
2. Add your domain under "Add a Site"
3. Cloudflare scans your existing DNS records — verify they're imported correctly
4. Update your domain's nameservers at your registrar to Cloudflare's nameservers (shown in setup)
5. DNS propagation takes 5–30 minutes

After nameserver change, all traffic routes through Cloudflare before reaching your origin server.

Step 2: Set SSL/TLS mode — this is critical

Go to SSL/TLS > Overview and set the encryption mode.

Use: Full (Strict)

Never use: Flexible

Here is why this matters:

Flexible SSL encrypts traffic between the visitor and Cloudflare, but sends unencrypted HTTP to your origin server. WordPress, which is on your origin server, sees HTTP requests. If WordPress or your server is configured to redirect HTTP to HTTPS (which it should be), it redirects the Cloudflare connection. Cloudflare then sends the request again. You get an infinite redirect loop (ERR_TOO_MANY_REDIRECTS).

Full SSL encrypts all the way to your server but doesn't validate your origin certificate. Works but less secure.

Full (Strict) encrypts end-to-end and validates your origin SSL certificate. This is the correct setting. Your hosting provider already gives you a free Let's Encrypt certificate — use it.

If your SSL certificate isn't set up on the origin server yet, use Cloudflare's Origin Certificate (under SSL/TLS > Origin Server) — a free certificate specifically for the Cloudflare-to-origin connection.

Step 3: Configure caching

Cloudflare caches static assets (CSS, JS, images) by default. For WordPress, you need to be more deliberate about what gets cached and what doesn't.

What Cloudflare should cache

Static assets: images, fonts, CSS, JavaScript. Cloudflare handles these automatically based on file extension.

What Cloudflare should NOT cache for WordPress

Dynamic WordPress pages (containing Set-Cookie headers or logged-in session data) should bypass Cloudflare's cache and be served directly from your origin server's own caching layer (WP Rocket, LiteSpeed Cache, etc.).

Cache Rules for WordPress

Go to Caching > Cache Rules and create rules in this order:

Rule 1 — Bypass cache for wp-admin and logged-in users

Expression:

(http.request.uri.path contains "/wp-admin/") or
(http.request.uri.path contains "/wp-login.php") or
(http.cookie contains "wordpress_logged_in") or
(http.cookie contains "wordpress_sec")

Action: Bypass cache

Rule 2 — Bypass cache for WooCommerce (if applicable)

Expression:

(http.request.uri.path contains "/cart/") or
(http.request.uri.path contains "/checkout/") or
(http.request.uri.path contains "/my-account/") or
(http.cookie contains "woocommerce_items_in_cart") or
(http.cookie contains "woocommerce_cart_hash")

Action: Bypass cache

Without the WooCommerce rule, Cloudflare can cache a user's cart page and serve it to a different user — this is a serious data issue, not just a UX problem.

Step 4: Disable Rocket Loader

Go to Speed > Optimization > Content Optimization.

Disable Rocket Loader.

Rocket Loader rewrites how JavaScript loads on your page. It conflicts with a significant number of WordPress plugins — page builders, form plugins, sliders, and anything with complex JS initialisation. The errors are often intermittent and difficult to diagnose.

Your WordPress caching plugin (WP Rocket, LiteSpeed Cache) handles JavaScript deferral and optimisation more reliably. Let it handle JS — disable Cloudflare's version.

Step 5: Configure Speed settings

In Speed > Optimization:

Auto Minify: retired — you will probably not see this setting

Cloudflare removed Auto Minify in 2024, so on a current account the toggle is simply absent. If you are on an older account that still shows it, disable all three. Minification belongs to your caching plugin, and minifying twice — once by Cloudflare, once by WP Rocket — breaks assets.

Polish: Enable — Pro plan and above only

Polish converts images to WebP and AVIF automatically for browsers that support them. Use "Lossy" for photos and "Lossless" for graphics containing text. Note that this is not available on the free plan: if you are on free, image conversion is your caching or image plugin's job, not Cloudflare's.

Mirage: Only if needed — Pro plan and above only

Mirage optimises image loading on slow mobile connections. Worth enabling on image-heavy sites, but it has minimal impact on a WordPress site that already lazy-loads and serves properly sized images.

Step 6: Firewall rules

Go to Security > WAF (on free plan: Security > Tools).

Block xmlrpc.php

WordPress's XML-RPC endpoint (/xmlrpc.php) is a common attack vector for brute-force and DDoS amplification. Block it unless you have a specific integration that requires it (Jetpack uses it, for example).

(http.request.uri.path eq "/xmlrpc.php")

Action: Block

Block wp-login.php brute force

Rate-limit login attempts to 5 per minute per IP:

(http.request.uri.path eq "/wp-login.php")

Action: Rate limit (5 requests per 1 minute per IP)

Block user enumeration

WordPress author archive URLs (/?author=1) can reveal usernames. Block them:

(http.request.uri.query contains "author=" and not http.request.uri.path contains "/wp-admin/")

Action: Block

Step 7: Always Use HTTPS

Go to SSL/TLS > Edge Certificates and enable:

• Always Use HTTPS: Redirects all HTTP requests to HTTPS at Cloudflare edge level
• Automatic HTTPS Rewrites: Fixes mixed content by rewriting HTTP asset URLs to HTTPS

With these enabled, you can remove the HTTP-to-HTTPS redirect from your .htaccess (or keep both — they're redundant but harmless).

Step 8: Verify setup

After configuring everything:

Check response headers using browser DevTools (Network tab). Look for:

• cf-cache-status: HIT on static assets (images, CSS, JS)
• cf-cache-status: BYPASS on wp-admin and WooCommerce cart pages
• x-content-type-options header present (Cloudflare adds this)

Test redirect behaviour:

• http://yourdomain.com should 301 to https://yourdomain.com
• No redirect loops

Test WooCommerce cart (if applicable):

• Add an item to cart, load the cart page, verify it shows the correct item
• Load the cart URL in a different browser (no session) — it should be empty

Which settings your plan actually gives you

Before changing anything, check what you can change. A good deal of Cloudflare advice online quietly assumes a paid plan.

The practical consequence: on the free plan, image conversion is your caching plugin's job, not Cloudflare's. Polish and Mirage are Pro-only, so a free-plan site needs an image optimisation plugin to serve WebP at all.

Tiered Cache — the free setting most WordPress sites never turn on

Turn this on. It is free on every plan, takes one click, and is the single highest-value Cloudflare setting most WordPress sites are not using.

By default, every Cloudflare data centre that receives a request for an uncached file fetches it from your origin independently. With hundreds of locations, your server can be asked for the same file many times over. Tiered Cache arranges those data centres into a hierarchy — a lower tier asks an upper tier before it asks you.

The result is fewer origin requests, a higher cache hit ratio, and less load on your server for exactly the same content. Enable it under Caching → Tiered Cache and choose Smart Tiered Cache Topology, which lets Cloudflare pick the upper tier for you.

Argo Smart Routing is a different thing and is not free. It routes requests over less congested network paths and is billed by usage. It helps sites with a genuinely global audience and uncacheable, dynamic responses. For a regional WordPress site that caches well, Tiered Cache delivers most of the benefit at no cost.

Cache Rules have replaced Page Rules

If your setup uses Page Rules, migrate it. Page Rules are Cloudflare's legacy system and are being phased out in favour of Cache Rules, which the Step 3 configuration above already uses.

Cache Rules are better in ways that matter for WordPress: you get far more of them, and expressions can match on cookies rather than only URL patterns. That distinction is not cosmetic — the correct WordPress bypass depends on the wordpress_logged_in and woocommerce_items_in_cart cookies, and a URL-only Page Rule cannot see them. A logged-in user browsing a normal page URL is invisible to a Page Rule and obvious to a Cache Rule.

If you inherited a site with rules under Rules → Page Rules, rewrite them as Cache Rules before adding anything new, and do not run both systems against the same paths. Overlapping rules across two systems produce behaviour that is genuinely difficult to reason about.

Automatic Platform Optimization (APO)

APO caches your HTML at Cloudflare's edge rather than only your static assets. That is the single biggest architectural upgrade available here, because it is what separates a normal CDN setup from edge HTML caching.

Without APO, a visitor's request for a page still travels to your origin, where your caching plugin serves it. With APO, the HTML itself is served from the data centre nearest the visitor. On a host with mediocre response times, the difference is substantial.

When APO is worth it: sites on shared or budget hosting, sites with a geographically spread audience, and sites where your host's TTFB is the bottleneck. It costs $5/month on the free plan and is included on Pro and above, and it requires the official Cloudflare plugin so that publishing a post purges the edge cache.

When to skip it: if you already run a host with edge caching built in, you would be paying twice for the same architecture. If your audience is concentrated in one region and your origin is fast, the gain is small.

The caveat that matters: APO caches HTML, so your bypass rules become critical rather than merely advisable. Verify that logged-in users and WooCommerce cart pages bypass correctly before enabling it — the failure mode is serving one visitor's page to another.

The settings that break WordPress

Four settings cause most Cloudflare-related WordPress problems. Three should be off.

Bot Fight Mode — leave it off. It challenges requests that do not look like browsers, and a great deal of legitimate WordPress traffic does not look like a browser: REST API calls, webhooks from payment gateways, uptime monitors, and external cron services. On the free plan it is a blunt on/off toggle with no way to exempt a path, which is precisely why it breaks things. Pro's Super Bot Fight Mode is configurable and safer.

Rocket Loader — leave it off. Covered in Step 4 above; it rewrites JavaScript loading and conflicts with page builders, sliders and form plugins.

Email Address Obfuscation — usually off. It rewrites email addresses in your HTML with JavaScript. This defeats basic scrapers, and it also mangles addresses output inside form fields, structured data and some plugin templates. If your contact form or schema markup is behaving strangely, this is a good first suspect.

Auto Minify — no longer exists. Cloudflare retired it in 2024, so if you are following older guides expecting to find the toggle, that is why it is missing. Minification belongs to your caching plugin now. On an account old enough to still show the setting, disable it — double-minifying assets breaks things.

Running Cloudflare in front of a managed host

If your host already includes Cloudflare, do not add a second Cloudflare proxy in front of it.

Kinsta includes Cloudflare Enterprise on every plan, Rocket.net is built on Cloudflare Enterprise, and several other managed hosts bundle some form of it. Proxying your own Cloudflare account in front of theirs means requests pass through Cloudflare twice, which adds latency, makes cache purging unreliable, and turns any debugging session into an exercise in working out which layer did what.

What to do instead:

• Host includes Cloudflare Enterprise (Kinsta, Rocket.net): use theirs. If you keep your domain's DNS at Cloudflare for convenience, set the records to DNS-only — the grey cloud, not the orange one — so Cloudflare resolves the name without proxying the traffic.
• Host includes a plain CDN, not edge HTML caching (most managed hosts): your own Cloudflare is a genuine addition, and APO is worth considering.
• Self-managed VPS or budget hosting: Cloudflare in front is a clear win, and the configuration in this guide is written for exactly that case.

The general rule: one proxy layer, and know which one it is.

Verify from the command line, not the dashboard

A setting shown as enabled in the dashboard is not proof it is working on your site. Check the response headers directly.

Confirm a cached asset is being served by Cloudflare:

curl -sI https://yourdomain.com/wp-content/uploads/example.jpg | grep -i "cf-cache-status\|server"

You want cf-cache-status: HIT. A MISS on the first request is normal — repeat it. A persistent MISS, or no cf-cache-status header at all, means the request is not being proxied.

Confirm your bypass rules actually bypass:

curl -sI https://yourdomain.com/cart/ | grep -i cf-cache-status

This must return BYPASS or DYNAMIC. If a WooCommerce cart page returns HIT, stop and fix the rule before doing anything else — Cloudflare is caching one shopper's cart and can serve it to another.

Confirm your SSL mode is not producing a redirect loop:

curl -sI http://yourdomain.com | grep -i "location\|HTTP/"

You want a single 301 to the HTTPS URL. Several hops, or a redirect back to HTTP, is the Flexible SSL problem described in Step 2.

Common problems and fixes

ERR_TOO_MANY_REDIRECTS

Cause: Flexible SSL mode + WordPress configured to force HTTPS Fix: Change SSL/TLS to Full (Strict)

wp-admin loads slowly or breaks after login

Cause: Cache rule not bypassing wp-admin, or a cookie isn't matching the bypass rule Fix: Verify your bypass cache rule includes the wordpress_logged_in cookie

Images not converting to WebP

Cause: Polish is disabled or set to "Off" Fix: Enable Polish > Lossy in Speed settings. Check browser DevTools to confirm content-type: image/webp on image responses

WordPress login creates redirect loop

Cause: Missing cookie in bypass rule — the wordpress_sec cookie is set before wordpress_logged_in during login Fix: Add both wordpress_sec and wordpress_logged_in to your bypass rule

Page builder preview breaks

Cause: Rocket Loader interfering with builder JavaScript Fix: Disable Rocket Loader

The minimal correct setup summary

Five things that cover 90% of what matters:

1. SSL/TLS: Full (Strict) — never Flexible
2. Cache bypass rules for wp-admin, wp-login, and the logged-in cookies
3. WooCommerce cache bypass for cart, checkout and account cookies
4. Rocket Loader: Off — let your caching plugin handle JavaScript
5. Bot Fight Mode: Off — it challenges the REST API, webhooks and uptime monitors
6. Tiered Cache: On — free on every plan, and most sites never enable it

Then verify with curl rather than trusting the dashboard. On Pro and above, add Polish: Lossy for automatic WebP; on the free plan that job belongs to your image plugin.

Everything else is refinement.

Related reading

• How to Get a 100 PageSpeed Score in WordPress
• Best WordPress Caching Plugins 2026
• WordPress Security Hardening Checklist
• WordPress SEO Checklist 2026