Cloudflare Page Rules Retiring: How to Migrate Safely

Logged into Cloudflare and seen a banner telling you Page Rules are being retired, or noticed one of your redirects just stopped working overnight? You're not imagining it. Cloudflare is winding down its original Page Rules product in favor of five separate, more capable "Rules" products, and if your zone still leans on old Page Rules, you need a migration plan before Cloudflare makes the decision for you.

Symptom

This shows up a few different ways depending on your plan and when your zone was created:

• A dashboard notice under Rules > Page Rules saying the feature is deprecated and pointing you to the new Rules suite.
• A "Forwarding URL" Page Rule (say, redirecting example.com to www.example.com) that suddenly 404s or serves the wrong page.
• New domains added to your Cloudflare account that simply don't have a Page Rules tab at all — only Configuration Rules, Cache Rules, Redirect Rules, Origin Rules, and Transform Rules.
• Free-plan zones capped at 3 Page Rules instead of the older allowance, breaking a setup that depended on 4 or 5.
• A rule that still exists but stopped firing after you edited an unrelated setting, because rule evaluation order changed.

Why This Happens

Page Rules used to be Cloudflare's one-stop shop: a single rule could set cache level, force HTTPS, disable security, and redirect a URL all at once, evaluated top to bottom by drag-and-drop priority. That flexibility turned out to be a maintenance headache — both for Cloudflare's infra and for admins who forgot what a rule from three years ago actually did.

Cloudflare's replacement splits that single product into purpose-built rule types, each with its own execution phase and its own dashboard tab:

Because each product now lives in its own list with its own ordering, two rules that used to sit next to each other in one Page Rule can end up executing in a different relative order — which is the usual reason a working redirect or cache setting quietly breaks after a "routine" dashboard change.

Fix

1. Inventory what your Page Rules actually do

Before touching anything, open Rules > Page Rules and write down, for every rule: the URL match pattern, and every setting it changes. Don't skip this — a rule named "old redirect" from 2022 might also be quietly setting Cache Level to "Bypass," and if you only migrate the redirect part you'll lose the caching behavior.

2. Recreate redirects first — they're the most visible breakage

Go to Rules > Redirect Rules > Create rule. For a simple domain forward:

When incoming requests match:
  Hostname equals example.com

Then:
  Type: Dynamic (or Static)
  Expression: concat("https://www.example.com", http.request.uri.path)
  Status code: 301
  Preserve query string: Yes

For bulk redirects (dozens or hundreds of old URLs), use Bulk Redirects instead of creating individual Redirect Rules one at a time — it's built for CSV-style lists and won't eat into your Redirect Rules quota.

3. Move caching behavior to Cache Rules

Go to Rules > Cache Rules > Create rule. Match the same URL pattern your Page Rule used, then set Eligible for Cache, Edge TTL, and Browser TTL explicitly instead of relying on the old "Cache Level: Cache Everything" shorthand. This is also a good time to add a "Bypass cache on cookie" rule for logged-in WordPress/WooCommerce sessions if you were relying on that in the old rule.

4. Move security and header overrides to Configuration Rules or Origin Rules

Anything that changed Security Level, disabled a Cloudflare feature for a specific path, or overrode the origin's host header belongs in Configuration Rules or Origin Rules respectively. These are newer tabs, so if you don't see them, check that your zone plan supports them — they're available on Free plans too, just introduced later than Page Rules.

5. Test before you delete the old rule

Keep the original Page Rule in place (just note it) until the new rule is verified working:

curl -I https://example.com/old-path
# Look for: HTTP/2 301, and a location header pointing where you expect

If both an old Page Rule and a new Redirect Rule match the same URL, Cloudflare's documented precedence generally runs Redirect Rules before Page Rules — so test with the old rule still active rather than assuming it's the only thing firing.

6. Delete the old Page Rule only after confirming the new one works

Once curl -I shows the behavior you expect from the new rule, delete the legacy Page Rule. Don't do this in bulk — go one at a time, especially for zones with mixed WordPress caching and WooCommerce checkout paths, where an over-eager Cache Rule can accidentally cache a cart page.

Prevention

• Audit your Page Rules list quarterly and migrate opportunistically instead of waiting for a deprecation deadline to force a rushed change.
• Name every new rule with what it does and why (e.g. "redirect-old-blog-path-2026"), not a generic label — future-you will thank present-you.
• If you manage many zones, script the migration with the Cloudflare API or Terraform's cloudflare_ruleset resource instead of clicking through the dashboard per domain.
• Subscribe to Cloudflare's changelog for your account so plan-level quota changes (like the Free-plan Page Rules cap) don't surprise you mid-migration.
• After migrating, screenshot or export the final Rules configuration for each product so you have a record outside the dashboard.