You added Cloudflare to your site, turned on the orange cloud, and now you want to control what gets cached. Cache Rules are the modern replacement for the old Page Rules caching features, and they give you fine-grained control over how Cloudflare stores and serves your content.
But one wrong rule can break your login pages, serve stale content to customers, or bypass the cache entirely. I've seen support tickets where a site owner cached their admin panel by accident or set a seven-day TTL on product pages that update hourly.
This checklist walks through the twelve steps you need before pushing cache rules live, with clear definitions and examples for each.
What cache rules actually do
Cloudflare sits between your visitors and your origin server. When someone requests a page, Cloudflare checks if it already has a fresh copy. If yes, it serves that copy instantly. If no, it fetches from your origin, caches it, and then serves it.
Cache Rules let you define which requests get cached, how long they stay cached, and what gets stored. They replaced the caching portion of Page Rules and offer more flexibility with better performance.
You create rules using match expressions (like "if the URL path starts with /images/") and actions (like "cache everything for 2 hours").
The difference between edge cache and browser cache
Two caches exist in this flow.
Edge cache lives on Cloudflare's servers. When a file is edge-cached, Cloudflare serves it to everyone without touching your origin. This reduces server load and speeds up delivery globally.
Browser cache lives on the visitor's device. The Cache-Control header tells the browser how long to keep a copy before asking Cloudflare (or your origin) again.
Cache Rules control the edge cache TTL. Your origin's headers still control the browser cache unless you override them.
Step 1: Identify what should and should not cache
Start with a list.
Should cache: - Static assets: images, CSS, JavaScript, fonts, PDFs - Public pages that change infrequently: landing pages, blog posts, documentation - API responses that are identical for all users
Should NOT cache: - Login pages, dashboards, admin panels - Checkout and cart pages - Personalized content (user-specific data) - API endpoints that return different data per user - Pages with CSRF tokens or session cookies
In past support cases I handled, the most common mistake was caching /wp-admin/ or /account/ paths. Visitors saw other people's data.
Step 2: Check your origin's cache headers
Before creating rules, see what your server already sends.
Run this in your terminal:
curl -I https://yourdomain.com/sample-page.html
Look for the Cache-Control header. You might see:
Cache-Control: public, max-age=3600
Or:
Cache-Control: no-cache, no-store, must-revalidate
Cloudflare respects these by default for most file types. If your origin says "do not cache," Cloudflare usually won't unless you override it.
Document what you find. You'll need this later.
Step 3: Understand cache eligibility vs cache rules
Not everything can be cached, even if you write a rule for it.
Cloudflare only caches responses that meet these conditions: - HTTP status is 200, 301, 302, 404, or 410 (by default) - The request method is GET or HEAD - The file extension is in the eligible list (for standard caching) or you use "Cache Everything"
If you want to cache HTML pages, you must use the "Eligible for cache" action or "Cache Everything" in your rule. Otherwise Cloudflare skips HTML even if the rule matches.
Step 4: Map out your URL structure
Write down the patterns you need to match.
Examples:
- /static/* – all static assets
- *.jpg, *.png, *.css – specific extensions
- /blog/* – blog posts
- /api/public/* – public API endpoints
- /wp-admin/* – WordPress admin (to explicitly bypass)
Cache Rules use Cloudflare's expression builder. You can match by: - URI path - File extension - Hostname - Query string - Cookie presence - Request headers
The more specific your patterns, the less risk of unintended matches.
Step 5: Decide on TTLs for each pattern
TTL is "time to live"—how long Cloudflare keeps a cached copy before fetching a fresh one.
Pick conservative values first: - Static assets (images, CSS, JS): 1 hour to 1 day - Blog posts and articles: 2 hours to 1 day - Homepages and frequently updated pages: 5 minutes to 30 minutes - API responses: 1 minute to 15 minutes
You can raise these after you confirm everything works.
Don't set multi-day TTLs on content that changes daily. I've seen product catalogs cached for a week with outdated prices.
Step 6: Create a bypass rule for sensitive paths
Your first rule should explicitly bypass caching for sensitive areas.
Go to your Cloudflare dashboard → Caching → Cache Rules → Create rule.
Name: Bypass Admin and Account Pages
When incoming requests match:
(http.request.uri.path starts_with "/wp-admin/") or
(http.request.uri.path starts_with "/account/") or
(http.request.uri.path starts_with "/checkout/")
Then: - Eligibility: Bypass cache
Save it and move it to the top of your rule list. Rules process in order, and you want bypasses evaluated first.
Step 7: Create rules for static assets
Next, cache your static files.
Name: Cache Static Assets
When incoming requests match:
(http.request.uri.path ends_with ".jpg") or
(http.request.uri.path ends_with ".png") or
(http.request.uri.path ends_with ".css") or
(http.request.uri.path ends_with ".js") or
(http.request.uri.path ends_with ".woff2")
Or if all your static files live under /static/:
http.request.uri.path starts_with "/static/"
Then: - Eligibility: Eligible for cache - Edge TTL: 4 hours - Browser TTL: 1 hour
This tells Cloudflare to cache these files for four hours and tell browsers to cache them for one hour.
Step 8: Add rules for dynamic pages if needed
HTML pages don't cache by default. If you want to cache blog posts or landing pages, you need a specific rule.
Name: Cache Blog Posts
When incoming requests match:
http.request.uri.path starts_with "/blog/"
Then: - Eligibility: Eligible for cache - Edge TTL: 2 hours - Browser TTL: 30 minutes
Be careful here. If your blog has comments or user-specific elements, caching can show the wrong content. Test thoroughly.
Step 9: Handle query strings correctly
By default, Cloudflare treats page.html and page.html?ref=twitter as separate cached objects.
If your query strings don't change the content (analytics tracking, referral codes), you're wasting cache space.
Add a Cache Key setting to your rule:
Cache key settings: - Query string: Ignore query string
Or if only specific parameters matter:
- Query string: Include specific parameters → list only the ones that change content (like
?page=2or?id=123)
This consolidates cache entries and improves hit rates.
Step 10: Test with cache disabled first
Before enabling rules, test your site with caching off.
Go to Caching → Configuration → Caching Level → set to No Query String or Standard (default).
Browse your site. Check: - Login and logout work - User-specific pages show correct data - Forms submit properly - Admin panels load
If something breaks here, it's not the cache rules—it's a site or Cloudflare config issue. Fix that first.
Step 11: Enable rules one at a time and purge between tests
Now activate your rules.
Start with the bypass rule. Save it, then purge the entire cache (Caching → Configuration → Purge Everything).
Test the bypassed paths. Try logging in. Check an admin page. Confirm nothing is cached that shouldn't be.
Next, enable the static asset rule. Purge again. Visit an image URL twice and check the response headers:
curl -I https://yourdomain.com/image.jpg
Look for:
cf-cache-status: HIT
The first request might say MISS (Cloudflare fetched it). The second should say HIT (served from cache).
Repeat for each rule. Purge, test, verify headers.
Step 12: Monitor cache analytics and adjust
After rules are live, check Caching → Analytics.
Watch: - Cache hit ratio: percentage of requests served from cache. Higher is better. Aim for 70% or more for content sites. - Saved bandwidth: how much traffic Cloudflare handled without hitting your origin. - Top uncached requests: which URLs aren't caching that maybe should be.
If your hit ratio is low, investigate:
- Are rules matching correctly?
- Are query strings fragmenting the cache?
- Is your origin sending no-cache headers?
Adjust TTLs and rules based on real data. Start short, then extend.
What happens when you need to clear cache
Sometimes you push a site update and need to force fresh content immediately.
You have options:
Purge everything: wipes the entire cache. Fast but nukes good cached content too. Use sparingly.
Purge by URL: clears specific pages or files. Better for surgical updates.
Purge by tag or host: if you set cache tags in your origin's headers, you can purge groups of related content at once.
For most small updates, purge by URL is the right choice.
Common mistakes to watch for
A few issues I've seen repeatedly in support:
Caching personalized content: if a page changes based on who's logged in, don't cache it. Use bypass rules or check for session cookies in your match expression.
Forgetting to purge after changes: you updated a CSS file but the old version is cached for another three hours. Purge the specific file after deployment.
Setting TTLs too long on volatile data: a product page cached for 24 hours when inventory updates every hour leads to overselling.
Ignoring origin headers entirely: if your app already sends good Cache-Control headers, you might not need many custom rules. Respect what your backend says unless you have a specific reason to override.
Not testing logged-in vs logged-out states: always test your site both ways. Some frameworks serve different HTML depending on authentication.
What to check first when something breaks
If your site misbehaves after enabling cache rules, start here:
- Check which rule matched the problematic request in your logs or by inspecting response headers (
cf-cache-status,cf-ray). - Temporarily disable that rule and purge the cache. Does the issue vanish?
- Review the match expression—are you catching more URLs than intended?
- Confirm sensitive paths have explicit bypass rules at the top of your rule list.
- Clear your browser cache and test in private/incognito mode to rule out local caching.
Cache Rules give you powerful control over performance, but they require careful setup. Follow this checklist, test each step, and start with conservative TTLs. You can always make caching more aggressive once you've confirmed nothing breaks.