Write Cloudflare Cache Rules to Control What Gets Cached (2026)

Cloudflare’s cache is a powerful tool, but its default behavior often caches too much or too little, requiring explicit control.

Let’s say you have a dynamic website where certain pages should never be cached, like a shopping cart or a user’s personalized dashboard. You also have static assets like images and CSS that you want aggressively cached. Cloudflare Cache Rules are the precise mechanism to achieve this granular control.

Here’s a look at a typical setup in action. Imagine you’re serving a .jpg file and a /cart page.

Scenario 1: Caching Static Assets

You want all .jpg files to be cached at the edge for 30 days.

• Cache Rule Name: Cache Images Aggressively
• When incoming requests match:
  • Field: URI Path
  • Operator: ends with
  • Value: .jpg
• Then the cache TTL is:
  • Value: 30 days
• Cache eligibility: Eligible

When a user requests https://example.com/images/logo.jpg, Cloudflare will first check its cache. If it’s there and not expired, the edge server serves it directly. If not, Cloudflare fetches it from your origin, caches it for 30 days, and then serves it to the user. Subsequent requests for logo.jpg from users near that edge location will be served from cache.

Scenario 2: Bypass Cache for Dynamic Content

You absolutely must not cache the /cart page because it’s user-specific and changes constantly.

• Cache Rule Name: Bypass Cart Page
• When incoming requests match:
  • Field: URI Path
  • Operator: equals
  • Value: /cart
• Then the cache TTL is:
  • Value: Bypass cache
• Cache eligibility: Not eligible

When a user requests https://example.com/cart, Cloudflare will see this rule, immediately bypass its cache, and always fetch the content directly from your origin server. This ensures the user always sees the freshest, most accurate cart contents.

The Mental Model: How Cache Rules Work

Cloudflare evaluates Cache Rules in the order they appear in your dashboard. The first rule that matches an incoming request determines the caching behavior for that request. If no Cache Rule matches, Cloudflare falls back to its default caching behavior, which is often influenced by Cache-Control headers from your origin.

The core components you control are:

1. Matching Criteria: This is how you tell Cloudflare which requests this rule applies to. You can match based on:

   • URI Path: The part of the URL after the domain (e.g., /images/logo.jpg, /products/123).
   • Hostname: The domain name (e.g., www.example.com, api.example.com).
   • Query String: The parameters after the ? in a URL (e.g., ?sort=price&page=2).
   • HTTP Method: GET, POST, PUT, etc.
   • Cookie: Presence or value of specific cookies.
   • Header: Presence or value of specific HTTP headers.
   • Origin IP: The IP address Cloudflare sees the request coming from (less common for typical caching).
   • Country: The user’s geographical location.

2. Cache Action: This defines what to do with the cache for matching requests.

   • Cache TTL: Sets how long an asset is considered fresh in the cache (e.g., 1 hour, 7 days, 30 minutes).
   • Bypass cache: Explicitly tells Cloudflare not to cache this request, always going to the origin.
   • Respect Existing Cache Headers: Falls back to your origin’s Cache-Control and Expires headers.

3. Cache Eligibility: This is a more granular control that can override the TTL.

   • Eligible: The request can be cached according to the TTL set.
   • Not eligible: The request cannot be cached, even if a TTL is set. This is functionally similar to "Bypass cache" for the TTL action but offers a clearer separation of intent.

This rule-based system allows you to override Cloudflare’s default behaviors or your origin’s headers. For instance, you might have your origin send Cache-Control: no-cache for all assets, but you want your .css files cached for a week. A Cache Rule targeting .css files with a 7-day TTL and Eligible status would achieve this.

The most powerful aspect is the ability to match on virtually any part of the request. You can cache *.js files everywhere except when a specific cookie _debug=true is present, effectively creating a debug mode that bypasses the cache for a single user. You can also set cache rules based on the query string, allowing you to cache ?v=123 but not ?v=latest if you’re using versioned assets.

When you set a Cache TTL of 0 seconds, it’s functionally equivalent to Bypass cache or Not eligible. It means the item is immediately considered stale and will always be fetched from the origin.

You’ll often find yourself creating a "default" rule at the bottom of your list that catches everything else and sets a sensible cache TTL, then creating more specific rules above it for exceptions. For example, a rule at the very bottom might match All incoming requests and set a 1 day TTL, while a rule above it might specifically bypass /admin/* paths.

The next logical step after mastering Cache Rules is to explore Page Rules, which offer a broader set of actions beyond just caching, such as setting origin headers, redirecting URLs, or disabling security features on a per-URL basis.