WPFIX STACK — home
Cloudflare & SSL

Cloudflare Killed Page Rules — Here's Why Your WordPress Redirects Broke (and the Fix)

Cloudflare deprecated Page Rules and your WordPress HTTPS or www redirect stopped working. Here's how to find the old rule and rebuild it as a Redirect Rule.

By Published Updated 6 min read

A brass padlock securing a rusty wire on a concrete post, symbolizing security and protection.
Photo by Markus Winkler on Pexels

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 stopped working, and you set it up as a Cloudflare Page Rule some time ago, check how it interacts with Cloudflare's newer Rules products. Page Rules are deprecated (opens in a new tab) and Cloudflare plans to migrate them automatically; in the meantime, a newer rule on the same URLs takes precedence over the Page Rule. The durable fix is finding your old rule's exact settings and rebuilding the same behavior as a Redirect Rule (Single Redirect).

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, Rules → Page Rules still lists your rule, marked as deprecated, but the redirect no longer fires.
  • Changes to the Page Rule don't seem to take effect, because another rule matches the same URLs first.
  • 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. A newer Rules product matches the same URLs. Modern Rules features take precedence over Page Rules (opens in a new tab), so a Redirect Rule, Configuration Rule or Cache Rule that you, a teammate or an automatic migration added for the same pattern wins over the old Page Rule.
  2. A Worker now runs on the route. Cloudflare notes that requests handled by Workers suppress Page Rules actions (opens in a new tab), but not the newer Rules — so a Worker added later can silently disable a Page Rule redirect.
  3. You ran out of Page Rules. The Free plan allows 3 Page Rules (opens in a new tab), so a redirect you meant to add as a fourth rule never existed. New redirects belong in Redirect Rules (10 on the Free plan) instead.
  4. Several Page Rules overlap. Only the highest-priority matching Page Rule takes effect (opens in a new tab), so a broader rule above your redirect can stop it from ever running.

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 an HTTPS redirect with the built-in toggle or a template

If your old Page Rule was just forcing HTTPS (matching http://yourdomain.com/ (opens in a new tab)* and forwarding to the https:// version), you don't need a custom rule at all: turn on Always Use HTTPS under SSL/TLS → Edge Certificates, or create a Redirect Rule from the Redirect from HTTP to HTTPS template, which is Cloudflare's recommended replacement (opens in a new tab).

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. Start from Cloudflare's www-to-root example (opens in a new tab), or under When incoming requests match, choose a custom filter expression matching Hostname equals www.yourdomain.com (opens in a new tab) (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) produces the exact same behavior across a few test URLs, go back to Rules → Page Rules and delete the old rule. Leaving both in place makes future troubleshooting confusing, and the Page Rule will be migrated or retired eventually anyway.

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.

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 need to change. Working Page Rules can be left alone for now: Cloudflare says it will migrate them automatically, with advance notice (opens in a new tab), though migrating proactively avoids surprises.

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 have their own quota, separate from Page Rules: 10 on the Free plan, 25 on Pro and 50 on Business (opens in a new tab), compared with 3, 20 and 50 Page Rules. Check your plan's current limit before building out many rules.

Stefan Nistor

Founder, WP Fix Stack

Stefan runs WP Fix Stack. Every guide checks its commands, menu paths and limits against the official documentation of WordPress, PHP, the hosting panel, Cloudflare or the plugin involved, and links those sources so you can verify them. Fixes are ordered from the least risky step, each guide ends with a way to confirm the fix and roll it back, and guides are corrected, with a new Updated date, when the documentation or the software changes.

Every guide explains the symptom, likely causes, the safest order of checks and how to confirm the fix. How we check our guides.

On this page