Cloudflare Cache Rules Explained: Recommended Setups by Site Type

Overview

If you want better CDN caching without serving the wrong content, the right starting point is not a preset. It is a content inventory. Cloudflare Cache Rules work best when they reflect how your site actually behaves: which responses are public, which are personalized, which change often, and which can safely live at the edge for longer.

At a high level, your Cloudflare caching setup should answer five questions:

• What should be cached? Usually static assets first, then selected HTML if the pages are public.
• What should never be cached? Logged-in areas, carts, checkout, account pages, previews, and most authenticated API responses.
• How long should each class of content live? TTL settings should match update frequency and purge strategy.
• Who controls freshness? Origin cache headers, Cloudflare edge rules, or both.
• How will stale content be invalidated? By full purge, selective purge, URL versioning, or deployment automation.

That sounds simple, but many sites run into trouble because they apply a broad “cache everything” pattern before they define exclusions. In practice, the safest path is the opposite:

1. Start with obvious static content.
2. Protect personalized and transactional routes.
3. Add HTML caching only where the business logic allows it.
4. Review results using cache status, error patterns, and update frequency.

It also helps to separate edge page caching from the rest of the stack. Cloudflare can cache and deliver responses at the edge, but origin behavior still matters. If the origin sends weak cache headers, varies unexpectedly on cookies, or generates different HTML for the same URL, your edge configuration will be fragile. For a broader look at cache layers, see Page Cache vs Object Cache vs Opcode Cache: What Each Layer Actually Does.

The site-type recommendations below are intended as safe defaults, not universal rules.

Recommended setup: content blog or documentation site

This is the cleanest use case for Cloudflare edge caching. Most pages are public, update on a predictable schedule, and do not vary by user.

• Cache static assets aggressively.
• Cache public HTML if the site has no user-specific output.
• Exclude admin paths, previews, search results if they are highly variable, and any logged-in areas.
• Use moderate edge TTL for HTML and longer TTL for versioned assets.
• Purge selectively on publish or deploy.

For WordPress publishers, combine Cloudflare edge behavior with sensible origin rules and a cache plugin that understands post updates. If you are tuning the application side too, Best WordPress Cache Plugins Compared for 2026 is a useful companion.

Recommended setup: WooCommerce or other ecommerce store

Stores require a stricter separation between public pages and transactional flows. Product, category, and content pages are often good caching candidates. Cart, checkout, account pages, and anything tied to a session are not.

• Cache static assets aggressively.
• Cache public product and category pages only if they are not heavily personalized.
• Bypass cache on cart, checkout, my account, wishlist, and login pages.
• Bypass cache when session or cart cookies are present.
• Keep HTML TTL conservative unless purge automation is reliable.

If your store has dynamic pricing, customer-specific promotions, live inventory by region, or frequent merchandising changes, treat HTML caching carefully. The common mistake is assuming that because a page looks public, it is functionally public. For a deeper store-specific approach, read WooCommerce Caching Guide: What to Cache and What to Exclude.

Recommended setup: SaaS dashboard or logged-in web app

For applications, Cloudflare is usually most valuable for assets, selected unauthenticated marketing pages, downloads, and sometimes specific anonymous API endpoints. Most authenticated HTML should bypass edge page caching.

• Cache static files and media aggressively.
• Cache marketing pages if they are public.
• Do not cache dashboard HTML, user settings, account views, or authenticated API responses.
• Use rules based on path, hostname, cookies, or authorization behavior to protect session-aware traffic.
• Prefer clear origin cache headers for assets and explicit bypasses for app routes.

For app teams, predictability matters more than squeezing every last cache hit out of HTML. It is better to miss a caching opportunity than to cache one authenticated page incorrectly.

Recommended setup: API-first site

APIs can benefit from Cloudflare edge caching, but only when responses are truly cacheable and callers understand freshness. Public endpoints, documentation assets, and some derived read-heavy resources are the main candidates.

• Cache only endpoints that are anonymous, idempotent, and safe to reuse.
• Do not cache authenticated or token-scoped responses unless you have very deliberate variation logic.
• Use short TTLs where freshness matters.
• Document cache behavior so clients know what to expect.

For APIs, correctness depends heavily on Cache-Control, variation, and revalidation strategy. See Cache-Control Header Cheat Sheet for Static Assets, HTML, and APIs for practical header patterns.

Recommended setup: media-heavy publisher or marketing site

Image, font, video, and script delivery often produce the biggest wins here. HTML can also be cached if pages are public.

• Set long TTLs on fingerprinted assets.
• Use edge caching for public landing pages, guides, and evergreen content.
• Keep purge workflows simple so editorial updates do not leave stale headlines or hero modules in cache.
• Monitor variants introduced by query strings, image transformations, localization, or A/B testing.

The key question is whether the site’s variability is content-driven or audience-driven. Content-driven change is manageable with purge and TTL. Audience-driven change requires stricter exclusions.

What to track

A Cloudflare caching setup should be reviewed like an operational system, not a one-time optimization. The most useful tracking points are the ones that tell you whether the rules still match the site.

1. Cacheability by content type

List your major route groups and classify them:

• Static assets
• Public HTML
• Logged-in HTML
• Transactional pages
• API endpoints
• Media and downloads

For each group, document whether it should be cached, bypassed, or conditionally cached. This becomes your baseline. If a route changes role later, your rules should change with it.

2. TTL settings and freshness risk

Track the intended TTL for each route class and compare it to how often that content changes. Long TTL is not inherently good; it is only good when invalidation is dependable. If you need help choosing sensible durations, keep TTL Settings Guide: How to Choose Cache Durations Without Breaking Freshness nearby.

3. Purge method

Note how each content type is invalidated:

• Full cache purge
• Prefix or tag-based purge
• Single-URL purge
• Asset versioning
• Natural expiration

This is one of the most important tracking points because many cache issues are not caused by bad rules. They are caused by a mismatch between TTL and invalidation. A long-lived edge cache without a reliable purge path is operational debt. For a broader framework, see Cache Invalidation Strategies Compared: Purge, Revalidate, Versioning, and SWR.

4. Cookie and personalization boundaries

Document which cookies indicate a session, a cart, a login, an experiment, or a region-specific experience. Then confirm that the relevant rules bypass or vary correctly. Many edge caching mistakes happen because teams introduce a new cookie for personalization and forget that the page was previously safe to cache.

5. Query string behavior

Track whether query strings represent true content variation or just tracking parameters. If the site treats both the same, cache fragmentation usually follows. Marketing parameters should not create a distinct cache key unless the response actually changes.

6. Origin headers

Cloudflare rules and origin headers should not work against each other. Keep a simple record of the cache headers your origin sends for key route types. That makes it easier to spot drift after application changes, plugin updates, or hosting migrations.

7. Outcomes that matter

Do not track configuration alone. Track outcomes:

• Cache hit behavior on key public pages
• Time to first byte trends on cacheable routes
• Unexpected stale content reports
• Incidents involving login, cart, checkout, or account pages
• Origin load during traffic spikes

Those signals tell you whether your Cloudflare cache rules are still doing useful work rather than simply looking tidy.

Cadence and checkpoints

The easiest way to keep Cloudflare caching healthy is to review it on a schedule and after known change events. A tracker article is useful only if it supports an operating rhythm, so here is a practical cadence.

Monthly checkpoint

• Review any new paths, subdomains, or application features.
• Check whether public pages intended for edge caching are still returning the expected headers.
• Look for new cookies or personalization logic.
• Spot check a few representative URLs from each route class.

This monthly pass does not need to be long. Its purpose is drift detection.

Quarterly checkpoint

• Audit the full route inventory.
• Review TTL choices against publishing frequency and release cadence.
• Test purge workflows end to end.
• Confirm that staging, preview, and production rules remain separated cleanly.
• Revisit whether more HTML can be cached safely, or whether certain routes now need bypass rules.

Quarterly review is where most teams catch outdated assumptions. A store that added customer-specific recommendations, for example, may need stricter exclusions than it did three months earlier.

Event-driven checkpoints

Revisit Cloudflare cache rules immediately after:

• A redesign or major template change
• A CMS or plugin change that affects output or headers
• A checkout, login, or account-system update
• A move to new hosting or origin caching layers
• A/B testing rollout or personalization launch
• Internationalization or geo-targeted content changes
• New API versions or authentication changes

If your origin stack changes too, review the division of responsibility between origin and edge. For example, adding server caching can alter what should be controlled at Cloudflare versus what should be handled upstream.

How to interpret changes

Not every cache metric shift means your setup is broken. The goal is to connect observed changes to likely causes.

If cache hit behavior improves but content complaints increase

This usually points to overcaching, weak exclusions, or a purge process that cannot keep up. High hit rate is not success if users see stale prices, outdated headlines, or another user’s stateful content.

If hit behavior falls after a feature launch

Check whether the feature introduced cookies, query string variants, or response differences for the same URL. Many launches accidentally convert previously public pages into semi-personalized pages.

If origin load rises despite unchanged traffic

Investigate whether new rules reduced cacheability, whether headers changed at origin, or whether more routes now bypass cache. This is also where query-string fragmentation often appears.

If pages are fast for repeat visits but inconsistent after updates

Your TTL may be reasonable, but invalidation may be weak. Rebalance the system by shortening edge TTL, improving purge automation, or using versioned asset URLs where possible.

If one site section behaves differently from another

That is often a routing or template clue rather than a general Cloudflare problem. Compare headers, cookies, and rule matches between the working and non-working sections. The delta is usually more informative than the isolated failure.

When you make changes, adjust one variable at a time where possible. A rule update, plugin update, and hosting change in the same release window make interpretation harder than it needs to be.

When to revisit

The simplest rule is this: revisit your Cloudflare caching setup whenever your site becomes more dynamic, more personalized, or more operationally complex. That includes product changes as much as infrastructure changes.

Use this short action list as a recurring review template:

1. Reconfirm route classes. Which URLs are public, private, transactional, or conditionally cacheable?
2. Reconfirm exclusions. Are login, cart, checkout, account, preview, and admin paths still fully protected?
3. Review cookie impact. Did a new feature add cookies that change content output?
4. Review TTLs. Do current durations still match update frequency and purge reliability?
5. Test invalidation. Can editors and deploy pipelines clear or refresh what they need without broad emergency purges?
6. Check edge versus origin ownership. Are your cache headers and Cloudflare rules aligned or fighting each other?
7. Document exceptions. Keep a short changelog of why each non-obvious rule exists.

If you only do one thing after reading this guide, do that last step. Teams forget the intent behind cache rules faster than they forget the rules themselves. A short explanation like “bypass on this path because content varies by session cookie” prevents future regressions.

Cloudflare cache rules are most effective when treated as a maintained policy layer. They are not a set-and-forget performance tweak. Revisit them monthly for drift, quarterly for structure, and immediately after changes to templates, personalization, commerce flows, or origin caching behavior.

For ongoing refinement, keep these related guides close at hand: TTL Settings Guide, Cache-Control Header Cheat Sheet, and Cache Invalidation Strategies Compared. Together, they make it much easier to keep edge caching fast, predictable, and safe.