By default, Cloudflare’s free plan does not cache your WordPress HTML. It happily caches your images, CSS, and JavaScript, but every actual page request still travels all the way back to your origin server, boots WordPress, runs PHP, queries the database, and renders the page from scratch. That’s the slow part — and it’s exactly the part most people assume Cloudflare is already handling for them.
The good news: you can absolutely set up full-page Cloudflare page cache for WordPress on the free plan, without paying for Automatic Platform Optimization (APO) and without burning your limited Page Rules. The trick is Cloudflare’s modern Cache Rules, which give you granular, free control over what gets cached at the edge. This guide walks through exactly how to do it — and how to avoid the two mistakes that cause people to serve logged-out pages to logged-in users or cache someone else’s shopping cart.
There are two different layers of caching worth keeping straight, because they solve different problems:
Edge caching is powerful because it moves your HTML physically closer to your visitors and offloads traffic from your origin entirely. A visitor in Sydney hitting a page cached in Cloudflare’s Sydney edge gets a response in a handful of milliseconds — your server in, say, Frankfurt is never involved. If you want the deeper conceptual breakdown of how these layers relate, see our guide on page cache vs object cache vs CDN.
The catch with edge caching is that Cloudflare’s edge is dumb about WordPress. It doesn’t know that a logged-in admin should see a different page than an anonymous visitor. It doesn’t know that a WooCommerce cart page must never be cached. If you cache HTML carelessly at the edge, you will eventually serve the wrong page to the wrong person. Everything below is designed to prevent that.
For years, the standard advice was “you need APO or a Business plan to cache HTML on Cloudflare.” That’s outdated. Here’s the current lay of the land:
| Method | Cost | Caches HTML? | Notes |
|---|---|---|---|
| Page Rules | Free (only 3 rules) | Yes, with “Cache Everything” | Works, but you burn your tiny free quota fast |
| Cache Rules | Free | Yes | Modern, granular, generous free limits — the recommended path |
| APO (Automatic Platform Optimization) | Paid add-on / Pro | Yes, automatically | Handles cookie logic for you, but it’s a recurring cost |
Cache Rules are the answer. They’re a newer, more flexible system than the legacy three Page Rules, they’re available on the free plan, and they let you match specific requests and tell Cloudflare exactly how to cache them. You can build a proper HTML edge cache with them without spending anything and without touching APO or Page Rules at all.
The single most important principle: only cache pages for anonymous (logged-out) visitors, and never cache dynamic pages. WordPress and WooCommerce set cookies that signal “this is a logged-in user” or “this person has items in their cart.” Your edge cache must respect those cookies and bypass the cache whenever one is present.
Here is the logic your setup needs to enforce:
wordpress_logged_in_*).woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*, edd_items_in_cart)./wp-admin/, /wp-login.php, /cart/, /checkout/, /my-account/, and anything under /wp-json/.Add your site to Cloudflare, update your nameservers, and confirm the orange cloud (proxy) is on for your main records. Nothing gets cached at the edge until traffic is actually proxied through Cloudflare.
In the Cloudflare dashboard go to Caching → Cache Rules → Create rule. Build an expression that matches requests where the URI path starts with any of the dynamic paths above, or where the Cookie header contains wordpress_logged_in or a WooCommerce cart cookie. Set the action to Bypass cache. Order this rule first so it always wins.
Add a second Cache Rule matching your hostname, with the action Eligible for cache (Cache Everything). Set an Edge TTL — a few hours is a sane default for a content site; shorter if you publish frequently. Leave Browser TTL modest so visitors re-check reasonably often. This is what actually stores your HTML at the edge.
Now the real problem: when you publish a post or edit a page, Cloudflare’s edge is still holding the old HTML until the TTL expires. Manually purging the cache every time you hit “Update” is not a workflow anyone sustains. You need something that automatically purges the relevant Cloudflare URLs the moment content changes — and this is precisely where a plugin earns its keep.
You can wire all of the above by hand. Plenty of people do. But there are sharp edges that bite even careful setups:
This is the honest case for using a caching plugin that integrates with Cloudflare rather than treating the edge as a standalone black box. The best setups stack all three layers — edge, origin disk cache, and object cache — so that every possible request is fast, whether or not it’s cached at the edge.
Speed of Light (by Digitaldive) was built specifically to make this stack work without a spreadsheet of manual rules. In a single license it ships three caching layers:
advanced-cache.php), so cache misses at the edge still hit a fast origin.Crucially, it also handles the invalidation problem: when you publish or edit content, it purges the relevant Cloudflare URLs automatically so visitors never see stale pages. And because it’s an all-in-one engine, the same license also includes image optimization (WebP by default plus AVIF, converted on your own server), Critical CSS and unused-CSS removal, ad-safe JavaScript defer/delay (it never delays AdSense, GTM, GA4, or Meta Pixel), self-hosted Google Fonts, and Core Web Vitals tuning for LCP and CLS.
That bundling is the real differentiator. Most competitors make you assemble this from parts.
Cloudflare edge caching is one layer, not a whole strategy. Here’s how the popular plugins line up on the pieces that matter for a complete setup — feature presence only:
| Tool | Origin page cache | Built-in object cache | Cloudflare edge (free-plan HTML) | Image optimization |
|---|---|---|---|---|
| Speed of Light | Yes | Yes (Redis) | Yes (Cache Rules, no APO) | Yes (own server) |
| WP Rocket | Yes | No | Needs Cloudflare APO | Add-on (Imagify) |
| FlyingPress | Yes | No | Via FlyingCDN (CF Enterprise) | Yes |
| LiteSpeed Cache | Yes (LiteSpeed server) | Yes | Server-dependent | Via QUIC.cloud (metered) |
| W3 Total Cache | Yes | Yes (Redis/Memcached) | Manual | Limited |
The standout pattern: a built-in Redis object cache is rare — only LiteSpeed Cache, W3 Total Cache, and Speed of Light include one; WP Rocket and FlyingPress don’t. And Speed of Light is the option that bundles origin cache, object cache, free-plan Cloudflare edge, and image optimization together with no add-ons or metered cloud services. For a fuller breakdown, see our roundup of the best WordPress caching plugins in 2026 and the head-to-head WP Rocket vs LiteSpeed vs FlyingPress comparison.
No. APO automates the cookie-handling logic for you and is convenient, but it’s a paid add-on. You can achieve full-page Cloudflare page cache for WordPress on the free plan using modern Cache Rules — one rule to bypass logged-in and dynamic requests, and one to cache everything else. The main thing APO buys you is not having to manage those rules and purges yourself, which a plugin like Speed of Light also handles automatically.
Only if you configure it carelessly. Cart, checkout, and my-account pages must always bypass the cache, and any request carrying a WooCommerce session or cart cookie must be served fresh. If your rules respect those cookies and paths, WooCommerce works perfectly. For a broader look at safe WooCommerce speed work, read how to speed up WooCommerce without breaking checkout.
Yes. The edge cache only helps for cacheable, frequently-requested pages — cache misses, logged-in users, admin actions, and dynamic endpoints all still hit your origin. A fast origin page cache (and, on database-heavy sites, an object cache) keeps those requests quick too. Edge and origin caching are complementary layers, not either/or.
Two mechanisms: the Edge TTL you set (after which Cloudflare re-fetches from origin), and cache purging. Relying on TTL alone means edits are visible only after it expires. Automatic, targeted purging on publish or edit is what keeps the edge current in real time — which is why a plugin that purges Cloudflare for you is worth having.
It directly improves Time to First Byte and, by extension, Largest Contentful Paint for cached pages, because the HTML arrives from a nearby edge instead of a distant origin. It won’t fix render-blocking CSS or heavy JavaScript on its own, though — for those you also want unused-CSS removal and script optimization. See our Core Web Vitals guide for the full picture.
Full-page caching on Cloudflare’s free plan is very achievable in 2026: use Cache Rules, cache anonymous HTML only, bypass logged-in and dynamic requests, and automate your purges. Do that and you’ll shave real latency off every cacheable page while taking load off your origin — for free.
If you’d rather not hand-build and babysit those rules, Speed of Light configures free-plan Cloudflare edge caching (zero Page Rules), stacks it on a pre-boot disk cache and a native Redis object cache, handles purging automatically, and throws in image optimization and Core Web Vitals tuning — all in one license, from $49/year with a 7-day free trial — card required, cancel anytime.
An honest ranking of the best WordPress caching plugins in 2026, comparing page caching, object caching, edge caching, image optimization and Core Web Vitals features side by side.
A practical 2026 comparison of WP Rocket, LiteSpeed Cache and FlyingPress — how their caching, CSS, image and object-cache features really differ, and how to pick the right…
Install, enter your key, pick a mode — and let every visitor land on a page that's already waiting.
