Cloudflare Cache Rules Guide: Common Setups That Actually Work

Overview

The main job of Cloudflare cache rules is straightforward: decide what can be cached at the edge, what must bypass cache, and how long responses should stay there before Cloudflare revalidates or refetches them. In practice, the hard part is not creating a rule. It is creating a rule set that still works six months later after a theme update, a new plugin, a pricing change, a checkout flow adjustment, or an API path that did not exist when you first configured the site.

A durable Cloudflare caching setup usually starts with a simple principle: cache aggressively only where the response is clearly safe to share between users, and bypass aggressively where user-specific state exists. That means your public assets and anonymous content should be treated differently from cart pages, account areas, admin paths, and anything influenced by cookies, authorization, or per-user headers.

If you have worked with the old concept of Cloudflare page cache rules, think in terms of the newer rule-driven model but keep the same goal: make intent explicit. The best Cloudflare cache rules are not clever. They are readable, limited in scope, and aligned with the application’s actual behavior.

For most sites, a reliable starting pattern looks like this:

• Cache static assets aggressively such as images, fonts, CSS, JavaScript, and other versioned files.
• Cache public HTML carefully only when you are confident the page is the same for all anonymous visitors.
• Bypass dynamic and personalized paths including login, account, checkout, cart, preview, search results, and authenticated API traffic.
• Use origin cache-control headers intentionally rather than fighting them accidentally.
• Keep purge strategy in mind before you increase TTLs, especially for CMS-driven sites.

This is also where many teams overuse the classic “cache everything Cloudflare” idea. Caching everything is not wrong by itself, but it is only safe when paired with clear bypass conditions and a purge process you trust. If you want a broader framework for how a CDN and reverse proxy fit together, see Reverse Proxy Cache vs CDN: What’s the Difference and When Do You Need Both?.

To keep this article useful over time, treat your configuration as a monitored system rather than a finished task. Product interfaces change, application routes evolve, and your edge cache should be reviewed on a recurring schedule.

What to track

If you want Cloudflare caching setup choices that actually work, track the variables that reveal whether your rules match reality. The most useful review points are not abstract performance scores. They are the signals that show whether Cloudflare edge cache is serving the right content to the right users.

1. Cache hit ratio by content type

Do not look only at a single site-wide cache hit ratio. Break it down mentally, or in your observability workflow, by:

• Static assets
• Public HTML pages
• API responses
• Admin and authenticated traffic

A low hit ratio on static assets often suggests short TTLs, poor versioning, query string fragmentation, or unnecessary bypass rules. A low hit ratio on HTML may be perfectly normal if your site is highly personalized. A low hit ratio on public blog pages may indicate missed caching opportunities.

If improving the ratio is a priority, this companion guide is useful: How to Improve Cache Hit Ratio on a CDN.

2. TTFB and origin load

Cloudflare caching should reduce work at origin. If Time to First Byte improves only slightly but origin CPU, PHP workers, or bandwidth costs remain high, your rules may not be targeting the expensive responses. On the other hand, if TTFB improves dramatically for anonymous pages and your origin quiets down, your public page cache is probably doing useful work.

Track changes after each major rule update. The question is not just “Is it faster?” but “Did this rule reduce avoidable origin work without breaking correctness?”

3. Bypass conditions: cookies, query strings, headers

Many broken cache setups come from not tracking request variation. If the response changes based on a cookie, query parameter, or request header, you need to know that before you enable broad HTML caching.

Common examples include:

• Session or cart cookies
• Preview and logged-in cookies in WordPress
• Tracking or campaign query parameters that create duplicate cache keys
• Authorization headers for APIs
• Language or geography-based responses

This is worth auditing regularly because application behavior drifts over time. A marketing tool, A/B test, personalization widget, or plugin update may introduce new variation without anyone revisiting edge rules. For a deeper look at this topic, see CDN Cache Bypass Rules Explained: Cookies, Query Strings, and Headers.

4. TTL strategy for assets and HTML

Your cache-control headers and edge TTL decisions should match the kind of content you serve.

• Versioned static assets can usually support long-lived caching because the filename changes when the file changes.
• Public HTML often needs shorter TTLs unless you have reliable purge events.
• Personalized pages should usually bypass caching entirely.

If your team keeps shortening TTLs because purges feel risky, the real problem may be your purge workflow rather than the cache duration itself. See How to Purge CDN Cache Without Breaking Your Site and ETag vs Last-Modified: Which Revalidation Strategy Should You Use?.

5. Path-based correctness

Review your route map and ask which paths belong in each bucket:

• Always cache: /assets/, image directories, build output, public theme files
• Cache with care: home page, category pages, blog posts, documentation pages
• Always bypass: /admin, /login, /cart, /checkout, account pages, preview endpoints, authenticated APIs

This sounds basic, but many Cloudflare cache rules fail because the path rules were written once and never revisited as the application added new routes.

6. WordPress- and ecommerce-specific exceptions

WordPress caching is where many otherwise sensible rules become unsafe. Logged-in users, comment forms, preview states, WooCommerce fragments, and account pages all require careful treatment. If you run WooCommerce, the bypass list matters more than the cache list. Public product and category pages may be cacheable; cart and checkout definitely require stricter handling.

Related reading: Best WordPress Caching Plugins Compared, How to Set Up Nginx FastCGI Cache for WordPress, and WooCommerce Caching Rules: What to Cache and What to Bypass.

7. Rule sprawl

Cloudflare cache rules often become hard to reason about after months of small edits. Track how many rules you have, what each one is for, and whether any are overlapping or contradictory. A shorter rule set with explicit naming is easier to troubleshoot than a layered stack of emergency fixes.

Cadence and checkpoints

A stable edge caching setup benefits from a schedule. You do not need daily audits for most sites, but you do need repeatable checkpoints so cache behavior stays aligned with the site.

Monthly checks

Once a month, review the basics:

• Any change in cache hit ratio for static assets or public HTML
• Any rise in origin load or bandwidth
• Any new paths introduced by releases, plugins, or product updates
• Any reports of stale content, broken logins, or inconsistent cart behavior
• Any change in cache-control headers at origin

This is a good time to test a few representative URLs manually: a static asset, a public blog post, a category page, a login page, a cart page, and an authenticated account path. Keep the sample set small but consistent so month-to-month comparisons are meaningful.

Quarterly checks

Every quarter, step back and review architecture rather than symptoms:

• Does your current Cloudflare caching setup still match how the app works?
• Are there rule exceptions that should become permanent logic?
• Are long-tail query strings reducing cache efficiency?
• Are you purging too broadly when targeted invalidation would be safer?
• Are origin-side headers and edge-side rules fighting each other?

Quarterly review is also the right time to look at whether certain traffic should move to a reverse proxy cache or app-level cache rather than being solved only at the CDN layer.

Release-based checkpoints

In addition to monthly or quarterly review, revisit cache rules whenever any of these happen:

• CMS theme or plugin changes
• Checkout, account, or search redesigns
• Migration to a new origin or hosting stack
• Introduction of personalization, geolocation, or A/B testing
• New API endpoints or mobile app traffic patterns
• Changes to URL structure or query parameter handling

If your team treats caching as part of release validation, you will catch more issues before users do.

How to interpret changes

Numbers are only useful if you know what they imply. A few common patterns can help you read what changed after a Cloudflare edge cache adjustment.

Higher cache hit ratio, but more support issues

This often means you cached something that should have remained dynamic. Look for user-specific pages accidentally entering cache, especially where cookies or login state matter. The fix is usually not to abandon caching entirely, but to tighten bypass conditions.

Better TTFB, but stale content complaints

Your TTL may be longer than your content workflow can support, or your purge strategy may be too broad and inconsistent. For blogs and marketing sites, the answer may be shorter HTML TTLs with long-lived asset caching. For highly updated sites, targeted purge discipline matters more than extreme TTLs.

No meaningful speed improvement after enabling cache rules

Check whether the expensive responses are actually cacheable. If most traffic is authenticated or dynamic, the gains from page caching may be limited. In that case, optimizing asset caching, origin performance, database queries, and reverse proxy behavior may matter more.

Static assets still miss too often

This usually points to asset URLs changing unpredictably, query strings fragmenting the cache key, or origin headers preventing efficient reuse. If assets are versioned, they should generally be your easiest caching win. For implementation details, see How to Cache Static Assets for Faster Core Web Vitals.

HTML cache works on the blog but fails on ecommerce

That is normal. Ecommerce introduces user state quickly. Product listing and product detail pages may still benefit from controlled edge caching, but cart, account, and checkout require much more caution. Do not copy a content-site rule set directly into a store.

Frequent purges are masking a design problem

If your team is purging the whole cache constantly, your setup may be over-caching HTML or under-planning invalidation. Broad purge habits reduce the value of edge caching and make performance inconsistent. A tighter path model and clearer ownership of purge events usually works better.

When to revisit

The practical rule is simple: revisit Cloudflare cache rules whenever the shape of your content, routes, or personalization changes. If you wait for visible breakage, the audit will always feel reactive. A better approach is to treat rule review as part of operations.

Use this action list as a standing checklist:

1. Map your current routes into cache, cache-with-care, and bypass groups.
2. Document which cookies, query strings, and headers change the response.
3. Confirm TTL intent for static assets, public HTML, and APIs.
4. Test representative URLs monthly and after major releases.
5. Review purge patterns to see whether they are targeted or wasteful.
6. Remove stale rules that no longer match the application.
7. Re-check ecommerce and WordPress exceptions whenever plugins, themes, or checkout logic change.

If you want one durable baseline, start here: cache static assets aggressively, cache anonymous HTML only where you understand the variation, bypass all authenticated and transactional flows, and keep the rule set short enough that another engineer can understand it in a few minutes.

That approach will not produce the most aggressive edge caching possible. It will, however, produce a Cloudflare caching setup that is easier to maintain, easier to debug, and more likely to keep working as the site evolves. And that is usually the difference between a benchmark-friendly rule set and one that actually survives production.

For follow-up reading, these guides complement this workflow well: How to Improve Cache Hit Ratio on a CDN, CDN Cache Bypass Rules Explained: Cookies, Query Strings, and Headers, and How to Purge CDN Cache Without Breaking Your Site.