Disassembling the everything rule

Page Rules has long occupied a peculiar place in Cloudflare's product line: a single tool that handles caching, configuration overrides, redirects, and header manipulation based on URL patterns. It was a genuine multitool — and, like most multitools, it handled many jobs adequately but excelled at none. After a decade of service and roughly one million rules deployed every three months, Cloudflare is breaking Page Rules apart into four dedicated products, each engineered around a specific function.

The new suite — Cache Rules, Configuration Rules, Dynamic Redirects, and Origin Rules — is available now through the dashboard, API, and Terraform. Page Rules itself remains operational for existing zones; however, Cloudflare anticipates formally starting its end-of-life process soon.

Why a generalist product no longer fits

Page Rules operates on a simple premise: match a URL pattern, then apply a configuration action. That model contributed to its widespread adoption, but it also produced a familiar list of pain points. Users wanted more than 125 rules per zone. They wanted to trigger on attributes beyond the URL, including regular expressions. They wanted clearer visibility into how rules interact, better debugging, and a broader menu of possible actions.

Cloudflare's response is to dissolve Page Rules into purpose-built products, each able to evolve independently. This separation also clarifies request handling: instead of routing through a single opaque "Page Rules" stage, traffic now moves through distinct phases where each product does one job.

The four products cover the following territory:

  • Cache Rules handles everything related to cache behavior: what gets cached, how long it stays cached, and when cache should be bypassed.
  • Configuration Rules selectively enables, disables, or overrides zone-wide settings for matching traffic.
  • Dynamic Redirects expands on Page Rules' Forwarding URL functionality, allowing redirects based on visitor country, preferred language, device type, and regular expressions (depending on plan).
  • Origin Rules controls where traffic is sent after leaving Cloudflare. It includes host header and resolve overrides (Enterprise only), plus the ability to selectively override the destination port and Server Name Indication (SNI).

Execution order is now visible

One of the chief complaints about Page Rules was that understanding how multiple rules interacted was nearly impossible. It was a black box: traffic went in, some set of operations happened, and traffic emerged.

The new product lineup changes that. The execution sequence among the new products is fixed and explicit. Origin Rules run first, followed by Cache Rules, Configuration Rules, and finally Dynamic Redirects. Host headers are modified before cache parameters are tuned, and configuration settings are adjusted only after caching decisions are made. Cloudflare has also integrated this ordering into the existing Traffic Sequence dashboard element so you can see where each step sits in the broader request lifecycle.

For zones still using Page Rules alongside the new products, the new suite takes precedence: if a Page Rule conflicts with a rule from any of the four new products, the new product's rule wins.

From 125 rules to five times that

The 125-rule ceiling was not an arbitrary limit. Page Rules' backend architecture hit measurable latency increases as the number of rules grew, so Cloudflare could not simply raise the cap. Users worked around this by offloading jobs to Workers or splitting zones into multiple subdomains to obtain additional rule quotas — neither approach ideal.

The replacement products are all built on the Rulesets Engine, the same infrastructure that runs Transform Rules, Custom Rules (WAF), Bulk Redirects, and API Shield. That engine raises the default quota considerably. Enterprise zones go from 125 Page Rules to a minimum of 500 rules distributed across the new products, with negotiable quotas for higher limits. Pro zones move from 20 to 100. Rules are allocated per product, and additional rules cannot be purchased beyond the default allotment.

Building on the Rulesets Engine also brings extensibility. Each product represents a "phase" — a logical bucket containing rules restricted to specific fields and actions relevant to that phase. New capabilities can be shared horizontally across products. Cloudflare's http.request.accepted_languages field, originally created for Transform Rules, was later enabled for Dynamic Redirects nearly for free, since both products shared the underlying engine. That same mechanism will apply to future fields and features: a capability added for one product can be offered to the other 30-plus products on the engine with minimal engineering overhead.

One interface across every rule type

Beyond quota increases, the move to a common engine standardizes the user experience. Every product exposes the same filtering language, the same API structure, the same Terraform configuration model, and essentially the same dashboard interface. The only meaningful difference is the action section of each rule — what happens when a request meets the specified conditions.

The result is that learning one product in the suite means having a head start on all the others. For Cloudflare, the consistency also means extending the Terraform provider for new products is a routine step, not a fresh build. Cache Rules, Configuration Rules, Dynamic Redirects, and Origin Rules are all live now; each has its own dedicated launch blog with deeper detail on use cases and configuration.