Migrate Cloudflare Page Rules to the New Rules System (2026)

Cloudflare’s Page Rules are being deprecated, and you need to migrate them to the new, more powerful Rules system.

Let’s see it in action. Imagine you have a Page Rule that redirects /old-path to /new-path.

Here’s how that looks in the old Page Rules system:

Page Rule:

• URL: *example.com/old-path*
• Setting: Forwarding URL
• Status Code: 301
• URL: https://example.com/new-path

Now, let’s migrate this to the new Rules system. The new system uses a more granular approach, combining "Match" conditions with "Actions."

New Rules System (equivalent):

1. Create a new Rule: Navigate to "Rules" -> "WAF" -> "Custom rules" or "Rules" -> "Page Rules" and click "Create rule" to access the new system.
2. Rule Name: Redirect Old Path
3. Match Condition:
   • Field: URI Path
   • Operator: equals
   • Value: /old-path
4. Action:
   • Type: URL Redirect
   • Status Code: 301 (Permanent Redirect)
   • URL: https://example.com/new-path

This new system offers much finer control. Instead of a single "URL" field, you specify the exact part of the URL you want to match (e.g., URI Path, Hostname, Query String). You can also combine multiple match conditions using AND or OR logic, which wasn’t easily possible with Page Rules.

The core problem Page Rules solved was applying specific configurations (like redirects, caching, or security settings) to different parts of a website based on URL patterns. The new Rules system refines this by providing a more structured and extensible framework. It’s designed to handle complex routing, dynamic content manipulation, and advanced security policies with greater precision.

The new system is built around a powerful expression language that allows you to construct very specific conditions. For example, you could match a URL path only if it contains a specific query parameter, or if the request is coming from a particular country.

Here’s another example: applying a specific cache TTL to images.

Old Page Rule:

• URL: *example.com/images/*
• Setting: Cache Level
• Value: Cache Everything
• Edge Cache TTL: 2 days

New Rules System (equivalent):

1. Rule Name: Cache Images Long
2. Match Condition:
   • Field: URI Path
   • Operator: starts with
   • Value: /images/
   • AND
   • Field: Content Type
   • Operator: equals
   • Value: image/jpeg (or image/png, image/gif, etc.)
3. Action:
   • Type: Cache TTL
   • Value: 172800 (seconds for 2 days)

The "Content Type" match is a significant upgrade, allowing you to target specific file types directly, rather than relying solely on URL patterns.

The new system also introduces the concept of "Phases." Rules are executed in specific phases of the request lifecycle: dns, ssl, http_request_main, http_request_late, origin_fetch_headers, origin_response_headers, http_response_main, and http_response_late. Your Page Rules were implicitly in http_request_main (for most actions) or http_response_main (for some caching). Understanding these phases is crucial for complex rule interactions, as a rule in an earlier phase can alter the request before a later phase’s rules are evaluated. For instance, a http_request_late rule can modify headers that an origin_fetch_headers rule might then use.

The most surprising true thing about the new Rules system is how its expression language, while powerful, can lead to incredibly subtle and difficult-to-debug interactions if you’re not careful about rule order and phase. For instance, a rule that modifies a header in the http_request_main phase might be completely overridden by another rule that also modifies that same header but runs in the http_request_late phase, and the default behavior isn’t always what you’d intuitively expect without deep diving into the execution order.

The next concept you’ll likely encounter is managing the increased complexity of multiple rule sets (WAF Custom Rules, Transform Rules, Cache Rules, Rate Limiting Rules, etc.) and understanding their precedence.