If a redirect that used to work on your WordPress site — forcing https://, redirecting www to non-www (or the reverse), or sending an old URL somewhere new — has quietly stopped working, and you set it up as a Cloudflare Page Rule some time ago, this is very likely Cloudflare's Page Rules deprecation. Cloudflare has been moving Page Rules functionality into two separate, more capable products — Redirect Rules and Configuration Rules — and existing Page Rules on many accounts are now shown as legacy and can no longer be edited, only viewed or deleted. The fix is finding your old rule's exact settings and rebuilding the same behavior as a new Redirect Rule.

Symptoms

  • A redirect that previously worked (forcing HTTPS, www/non-www redirect, or an old-URL-to-new-URL redirect) no longer happens — visitors land on the un-redirected version of the page instead.
  • In the Cloudflare dashboard, going to Rules → Page Rules shows your existing rule but the edit option is greyed out, missing, or the page indicates the feature is legacy/being phased out.
  • You can still see the old rule's settings, but changes you make to it don't seem to save or take effect.
  • The break coincided with no change on your own WordPress site or hosting — nothing was touched on the server side.

Likely causes, in order of how often they actually happen

  1. Cloudflare deprecated Page Rules as an editable product and split its functionality across Redirect Rules (for URL redirects) and Configuration Rules (for settings like Always Use HTTPS, caching behavior, and security toggles per URL pattern) — old rules remain in a read-only legacy state rather than disappearing outright, which is why you can still see but not fix them.
  2. A Page Rule using "Forwarding URL" for a www/non-www or HTTP-to-HTTPS redirect stopped matching correctly after an account-level change, because Cloudflare's newer products evaluate URL matches with different logic than the old Page Rules engine did.
  3. The rule quietly hit a plan-level limit — Page Rules were capped per plan tier (commonly 3 on Free, more on paid plans), and if you tried to add a new rule instead of migrating an old one, it may have silently failed to apply because the old limit still governs the legacy rules while new rules must go through Redirect Rules instead.
  4. Multiple overlapping rules (an old Page Rule and a newer Redirect Rule or Configuration Rule) are both present and conflict, with Cloudflare's rule precedence now handling that differently than before, so neither behaves as originally intended.

Fix it: lowest-risk steps first

Step 1 — Find and document your existing Page Rule exactly

Go to Rules → Page Rules in the Cloudflare dashboard. For each rule listed, note down:

  • The exact URL match pattern (for example, http://yourdomain.com/* or www.yourdomain.com/*).
  • The setting/action applied (for example, "Forwarding URL (301/302)" with a specific destination pattern, or "Always Use HTTPS").
  • The order/priority of the rule if you have more than one, since Page Rules were evaluated top to bottom and the new products have their own separate ordering.

Do not delete the old rule yet — leave it in place until its replacement is confirmed working, since it may still be partially functioning for some traffic patterns.

Step 2 — Recreate a simple "Always Use HTTPS" redirect using Configuration Rules or the built-in toggle

If your old Page Rule was just forcing HTTPS (matching http://yourdomain.com/* and forwarding to the https:// version), you likely don't need a custom rule at all: go to SSL/TLS → Edge Certificates and confirm the Always Use HTTPS toggle is switched on. This built-in setting covers the exact use case most HTTPS-forcing Page Rules were created for, without needing any custom rule.

Step 3 — Recreate a www ↔ non-www redirect using Redirect Rules

For a domain-level redirect (for example, www.yourdomain.com → yourdomain.com, or the reverse), go to Rules → Redirect Rules and click Create rule.

  1. Under When incoming requests match, choose a custom filter expression, matching Hostname equals www.yourdomain.com (adjust to your actual redirect direction).
  2. Under Then, set Type to Static or Dynamic depending on whether the destination is fixed or needs to preserve the original path — for a full-site www-to-non-www redirect preserving the path, choose Dynamic and set the expression to concat("https://yourdomain.com", http.request.uri.path).
  3. Set the Status code to 301 (permanent) to match typical Page Rule behavior, unless your original rule used 302.
  4. Save and deploy the rule.
  5. Test by visiting the www version of a few different URLs on your site (not just the homepage) and confirming each redirects to the correct non-www equivalent with the path intact.

Step 4 — Recreate a specific old-URL-to-new-URL redirect

If the original Page Rule redirected a specific old path (for example, an old blog URL) to a new one, use Rules → Redirect Rules again:

  1. Match condition: URI Path equals the old path (e.g., /old-post-url/).
  2. Action: Static redirect to the new full destination URL.
  3. Status code: 301.
  4. Deploy, then test the old URL directly to confirm it lands on the new page.

Step 5 — Remove the legacy Page Rule once the replacement is verified

Once you've confirmed the new Redirect Rule (or the Always Use HTTPS toggle) is producing the exact same behavior across a few test URLs, go back to Rules → Page Rules and delete the old legacy rule. Leaving both in place indefinitely risks conflicting behavior if Cloudflare's precedence between the two systems changes again in the future.

Verify the fix

  1. Test each redirect scenario (HTTP→HTTPS, www↔non-www, old URL→new URL) in a private/incognito browser window to avoid cached redirect results.
  2. Confirm the redirect uses the correct status code (301 for permanent) using your browser's developer tools Network tab or an online redirect checker.
  3. Test at least two or three different URL paths, not just the homepage, to confirm path-preserving redirects (like the www Dynamic rule) work sitewide.
  4. Recheck Rules → Page Rules to confirm the old legacy rule has been removed once you're confident the new rule is working correctly.

If you need to roll back

If the new Redirect Rule doesn't behave as expected, go to Rules → Redirect Rules, disable or delete the new rule, and your original (legacy) Page Rule — if you haven't deleted it yet — will resume being the only active rule for that pattern. This is why Step 5 says to wait until you've verified the replacement before removing the old one: it acts as your rollback path during testing.

Related fixes

FAQ

Do I need to migrate every old Page Rule, or only the ones that broke?

Only migrate rules that have stopped working or that you can no longer edit when you need to change them. Page Rules that are still functioning correctly can often be left alone for now, though Cloudflare's long-term direction is to retire the feature entirely, so migrating proactively avoids a future scramble.

Why does the new Redirect Rule need a "Dynamic" expression instead of just a destination URL?

A "Static" redirect sends every matching request to one fixed URL, which breaks path-preserving redirects (like www-to-non-www across an entire site with many pages). "Dynamic" lets you build the destination from parts of the original request, such as http.request.uri.path, so www.yourdomain.com/about correctly redirects to yourdomain.com/about instead of everything landing on the homepage.

Will this affect my Cloudflare plan's rule limits?

Redirect Rules and Configuration Rules have their own separate quotas from the old Page Rules limit, and free-plan quotas for the newer products are generally more generous than the old 3-rule Page Rules cap. Check Rules → Redirect Rules for your plan's current limit before building out multiple rules, since exact quotas can vary by plan tier.