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.
What “full-page caching on Cloudflare” actually means
There are two different layers of caching worth keeping straight, because they solve different problems:
- Origin page cache — a copy of the rendered HTML stored on your server (usually as static files), so WordPress and PHP don’t have to run on every request. This is what most caching plugins do.
- Edge page cache — a copy of that same HTML stored in Cloudflare’s data centers around the world, so many requests never even reach your server. This is what we’re setting up here.
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.
Why the free plan can do this now (Cache Rules vs Page Rules vs APO)
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 safe recipe: only cache anonymous HTML
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:
- Bypass cache when a WordPress logged-in cookie is present (
wordpress_logged_in_*). - Bypass cache when WooCommerce/EDD session or cart cookies are present (
woocommerce_items_in_cart,woocommerce_cart_hash,wp_woocommerce_session_*,edd_items_in_cart). - Bypass cache for dynamic paths entirely:
/wp-admin/,/wp-login.php,/cart/,/checkout/,/my-account/, and anything under/wp-json/. - Cache everything else — the anonymous, static-for-everyone pages like your home page, blog posts, and product listing pages.
Step 1 — Point WordPress at Cloudflare
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.
Step 2 — Create a bypass Cache Rule
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.
Step 3 — Create a “Cache Everything” rule for the rest
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.
Step 4 — Solve cache invalidation (the hard part)
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.
Doing this the hard way vs. the easy way
You can wire all of the above by hand. Plenty of people do. But there are sharp edges that bite even careful setups:
- Invalidation: manual purges don’t scale. Comments, new posts, menu changes, price updates — each should surgically purge the right edge URLs, not nuke the whole cache.
- Cookie drift: plugins and themes introduce new cookies over time. A hand-built rule you wrote a year ago may quietly start caching pages it shouldn’t.
- The origin still matters: the edge cache only helps for pages that are actually cacheable and requested often enough to stay warm. Cache misses, logged-in users, and dynamic pages still hit your origin — so you still want a fast origin page cache and, on a busy or database-heavy site, a Redis object cache underneath it.
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.
How Speed of Light handles Cloudflare edge caching
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:
- Full-page Cloudflare edge caching that works on the free plan — it configures modern Cache Rules for you and uses zero Page Rules, so your free quota stays untouched. It caches anonymous HTML only, bypasses logged-in users, and keeps WooCommerce carts and checkout uncached automatically.
- A disk full-page cache served before WordPress even boots (via
advanced-cache.php), so cache misses at the edge still hit a fast origin. - A native Redis object cache drop-in with a GUI and value compression, for the dynamic and logged-in requests the edge can’t help with.
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.
How this compares to other WordPress caching options
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.
Frequently asked questions
Do I need Cloudflare APO to cache HTML on the free plan?
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.
Will edge caching break my WooCommerce cart or checkout?
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.
Do I still need a page cache plugin if Cloudflare is caching my HTML?
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.
How does content stay fresh once it’s cached at the edge?
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.
Does caching HTML at the edge help Core Web Vitals?
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.
The bottom line
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 14-day money-back guarantee.