By default, Cloudflare caches images, CSS, and JavaScript, but it lets every HTML page pass straight through to your origin server. That is why your TTFB barely moves after you turn Cloudflare on. “Cache Everything” changes that: it tells Cloudflare to cache the HTML itself, so repeat visitors get a full page from an edge server a few milliseconds away instead of waiting on your WordPress install. Done right, it can cut Time to First Byte dramatically. Done carelessly, it can serve one visitor’s logged-in dashboard to another. This guide walks through the safe setup.
What “Cache Everything” Actually Does
Cloudflare’s default cache level, “Standard,” only caches static content: files with extensions like .jpg, .css, and .js. HTML pages are treated as dynamic by default, because WordPress pages can change with every login, comment, or cart update.
“Cache Everything” removes that exception. With it enabled, Cloudflare treats an HTML page like any other cacheable file: the first visitor triggers an origin fetch, and every visitor after that gets the stored copy from the nearest edge location until the cache expires or is purged.
The benefit is real. A typical shared-hosting WordPress site might answer in 600ms to over a second. A cached page from Cloudflare’s edge often arrives in under 100ms for nearby visitors. That improvement shows up directly in TTFB, and it usually drags LCP down with it, since the browser starts rendering sooner.
The risk is equally real. If you cache everything without exclusions, Cloudflare cannot tell a public blog post from a logged-in user’s account page, a checkout page, or the WordPress admin. That is the entire game: cache the public pages aggressively, and keep anything personal or dynamic completely out of the cache.
Cache Everything vs Cloudflare APO
If you have read our Cloudflare APO guide, you may wonder why you would build this by hand when Automatic Platform Optimization exists. The honest answer is that APO is this same idea, packaged and maintained by Cloudflare.
APO does full-page edge caching for WordPress, and it handles the hard parts for you: it bypasses the cache for logged-in users, it purges the right pages when you publish or update a post, and it keeps the WordPress toolbar working. If you are on a paid Cloudflare plan and you want the simplest path, APO is usually the better choice — see our setup guide linked below.
Cache Everything is the free, manual alternative. It costs nothing beyond a free Cloudflare account, and it gives you full control over the rules. The price is that you must write the bypass rules yourself and manage purging yourself. For a simple blog or brochure site with no membership, shop, or forum, that trade is usually worth it. For a WooCommerce store or a membership site, think twice before going manual.
Before You Start: Three Things to Get Right
First, your site must already be proxied through Cloudflare (orange cloud on in the DNS settings). If your DNS records are set to “DNS only,” no cache rule in the world will apply.
Second, decide what must never be cached. The standard list for WordPress:
- /wp-admin/ and /wp-login.php
- Preview pages (?preview=true)
- Cart, checkout, and account pages on WooCommerce sites
- Any page behind a login: membership, forum, LMS, or private content
- Search results (?s=) and any URL with a query string that changes content
Third, have a purge plan. Cached pages do not update themselves. When you publish or edit a post, you will need to purge that URL (or the whole cache) in Cloudflare, or your readers will keep seeing the old version. Cloudflare’s free plan allows purging individual URLs, and the dashboard also offers a “Purge Everything” button for emergencies.
Step 1: Set the Cache Level to “Cache Everything”
There are two places to do this: the old Page Rules interface, and the newer Cache Rules interface. Cache Rules are the current, recommended method.
In the Cloudflare dashboard, open your site, then go to Rules > Cache Rules and create a rule:
- Rule name: Cache Everything — Public Pages
- When incoming requests match: use a custom expression. A practical starting expression is: URI Path does not start with /wp-admin, and URI Path does not contain /wp-login.php, and Cookie does not contain wordpress_logged_in.
- Then: set Cache Level to “Cache Everything.”
That cookie condition is the important one. WordPress sets a wordpress_logged_in cookie for signed-in users. By requiring its absence, your rule automatically skips the cache for anyone logged in, which protects the admin bar, account pages, and any personal content.
If your site runs WooCommerce, add exclusions for cart, checkout, and account paths (for example, URI Path contains /cart/, /checkout/, or /my-account/), and consider excluding any URL with a woocommerce_items_in_cart cookie.
On the older Page Rules system, the equivalent setup is a rule for your domain with “Cache Level: Cache Everything,” plus separate higher-priority rules above it that set “Cache Level: Bypass” for /wp-admin/*, /wp-login.php*, and any shop or account paths. Page Rules still work, but Cloudflare is moving toward Cache Rules, so build new setups there.
Step 2: Set a Sensible Edge Cache TTL
Caching everything with no expiry plan is how stale content happens. In the same Cache Rule, set an Edge Cache TTL. For a blog that publishes a few times a week, 4 to 8 hours is a reasonable middle ground: repeat visitors get fast pages, and a new post shows up within hours even if you forget to purge.
If you publish news or time-sensitive content, use a shorter TTL, like 1 to 2 hours. If your content barely changes, a day or more is fine. The right value is a trade-off, not a magic number, and you should pair it with manual purging after every publish — that is what makes a long TTL safe.
Also check your Browser Cache TTL setting (Caching > Configuration). This controls how long visitors’ browsers keep the page. A few hours here is sensible for HTML; your static assets can keep the much longer lifetimes covered in our efficient cache policy guide.
Step 3: Handle Query Strings
WordPress URLs carry query strings for a reason: ?preview=true shows a draft, ?s= runs a search, and plugins add tracking parameters like ?fbclid. By default, Cloudflare’s cache key includes the query string, which means ?fbclid=abc and ?fbclid=xyz create separate cache entries for the same page. That dilutes your hit rate.
For a standard site, the cleanest approach is to bypass the cache entirely for URLs with query strings that change content (search, preview, sorting, filtering), while letting harmless tracking parameters ride along. Cache Rules let you write that distinction: bypass when the query string contains s=, preview=, or your shop’s filter parameters, and ignore the rest. If you are unsure, start conservative — bypass on any query string — and loosen it later once you confirm nothing breaks. A slightly lower cache hit rate beats serving the wrong page.
Step 4: Verify It Is Actually Caching
Do not trust the dashboard alone. Open your site in a private browser window, then check the response headers with your browser’s developer tools or an online header checker. Look for the cf-cache-status header:
- HIT means Cloudflare served the cached page. That is the win.
- MISS means the request went to the origin and the response was stored for next time. Refresh once and you should see a HIT.
- DYNAMIC or BYPASS means your rule excluded the page. Check your rule conditions if a public post shows this.
- EXPIRED means the cached copy aged out and Cloudflare fetched a fresh one.
Test twice: once logged out (you should see HIT on a blog post) and once logged in (you should see BYPASS or DYNAMIC on the same post, and the admin bar should appear normally). If a logged-in view shows HIT, stop and fix your cookie exclusion before going further — that is a privacy problem, not a performance win.
Then measure. Run PageSpeed Insights or your usual speed tool before and after, on the same page, and compare TTFB specifically. If TTFB barely moved, your page probably is not being cached — go back to the headers. If it dropped sharply, the setup is working.
Step 5: Build a Purging Habit
The number one complaint about full-page edge caching is stale content: “I updated the post but the site still shows the old version.” That is not a bug; it is the cache doing its job. The fix is a habit:
- After publishing or updating a post, purge that post’s URL in Cloudflare (Caching > Configuration > Custom Purge, enter the URL).
- After changing your theme, menus, widgets, or homepage, purge everything.
- After plugin or WordPress core updates that change front-end output, purge everything and check a few key pages.
If purging manually gets old, there are free plugins that purge Cloudflare’s cache automatically when you publish or update content. That automation is one of the things APO gives you out of the box, and it is the main convenience you give up with the manual route.
Common Mistakes to Avoid
Caching the admin area. The classic blunder is a Cache Everything rule with no exclusions, which can cache /wp-admin pages or the login screen. Always put bypass rules for admin and login first, and test them logged in.
Forgetting logged-in users. Even outside wp-admin, a cached page built for an anonymous visitor can hide the admin bar or show the wrong state to a signed-in user. The wordpress_logged_in cookie condition prevents this.
Caching cart and checkout. On WooCommerce sites, a cached cart page can show one customer’s items to another. Exclude shop pages entirely, and consider excluding the whole site from full-page caching if the store is a large part of your traffic.
Purging nothing, ever. A cache that is never purged will eventually embarrass you with outdated prices, old headlines, or a broken layout from a theme change you made days ago.
Expecting it to fix a slow origin. Edge caching hides a slow server from repeat visitors, but the first visitor after every purge still waits on your origin, and uncached pages still do. If your origin TTFB is several seconds, fix the server side too — our TTFB guide covers the fixes in order of impact.
Should You Use Cache Everything?
Use it if you run a content site — a blog, a brochure site, a portfolio, a documentation site — where most pages are the same for every visitor, and you are willing to manage rules and purging. The speed gain is real and the cost is zero.
Skip it (or use APO instead) if your site is heavily personalized: a store, a membership community, a forum, or anything where most pages differ per visitor. In those cases, the bypass list gets so long that little is left to cache, and the risk of a wrong cached page outweighs the gain.
Either way, the principle is the same one behind every caching layer on WordPress: cache aggressively what is public and identical, and keep anything personal or dynamic far away from the cache. Get that boundary right, and full-page edge caching is one of the biggest free speed wins available.
Further Reading
- Cloudflare APO for WordPress: Setup Guide That Actually Lowers TTFB
- Bunny CDN vs Cloudflare for WordPress (2026)
- How to Configure a CDN for WordPress via DNS (Nameserver Method)
- How to Fix “Serve Static Assets With an Efficient Cache Policy” in WordPress
- WordPress TTFB Too High? 8 Fixes in Order of Impact
