Cloudflare has introduced Cache Response Rules, a new rule type designed to fix a long-standing gap in CDN caching: problems that only become visible after the origin server responds, not before.
Cache decisions have traditionally been split into two moments. Cloudflare first has to decide whether to check the cache at all, a call made using request-time information such as the URL, file extension, headers, and geography. But many of the biggest cache killers, like a stray Set-Cookie header, an overly cautious Cache-Control: no-cache directive, or an aggressive ETag that forces constant revalidation, only show up in the origin’s response. By the time Cloudflare sees them, the request phase is already over and there’s no way to undo the wasted origin round trip.
According to Cloudflare, these response-level issues are a common source of leaking cache hit ratio. A single mistaken header on an asset like a static JavaScript file can make it uncacheable across every visitor and every Cloudflare data center, quietly pushing more traffic back to the origin and driving up infrastructure costs. The problem is often made worse organizationally, since the team managing origin responses and the team managing the CDN configuration are frequently different, turning a simple header fix into a lengthy cross-team negotiation.
Previously, site owners had three imperfect options for this class of problem: change the origin code directly, write a Cloudflare Worker to re-fetch and rewrite the response, or simply accept a worse cache hit ratio. Each option costs engineering time, adds latency, or costs money in unnecessary origin traffic.
What Cache Response Rules Do
Cache Response Rules run after the origin replies but before Cloudflare writes the content to cache. This timing lets administrators:
- Rewrite Cache-Control directives coming from the origin
- Manage cache-tags
- Strip headers such as Set-Cookie, ETag, and Last-Modified before they reach Cloudflare’s cache
All of this happens entirely on Cloudflare’s side, with no changes required to the origin server itself.
Cloudflare frames this as the natural complement to its existing Cache Rules, which operate in the request phase and answer a different question: whether to look something up in cache and under what key. Cache Response Rules answer a separate question, namely whether the response Cloudflare just received should actually be written to cache, and in what form.
Why It Matters for Site Owners
For WordPress sites and other CMS-driven properties running behind Cloudflare, this closes a gap that has historically forced site owners into workarounds involving custom Workers or origin-level header surgery. Teams that have struggled with cache hit ratio problems caused by CMS plugins or application frameworks injecting cookies or conservative cache headers now have a direct, request-free way to correct that behavior at the edge.