Cloudflare’s documentation now titles the Page Rules section “Page Rules (deprecated)”. The page itself carries no banner, no date and no explanation. The replacement products exist, they are documented, and the mapping between old and new is published. What is missing is anyone telling you which of your rules will quietly stop doing anything.
Thirty three settings, five destinations, and five settings that go nowhere.
The five that go nowhere
Start here, because this is the part that costs you something. Cloudflare’s migration reference lists these as settings that will not be migrated, each with its own reason:
| Setting | Cloudflare’s reason |
|---|---|
| Disable Performance | this setting is deprecated |
| Disable Railgun | deprecated, since Railgun is no longer available |
| Disable Security | this setting is deprecated |
| Response Buffering | this setting is deprecated |
| Web Application Firewall | deprecated, since the previous version of WAF managed rules is deprecated |
If one of your Page Rules turns off security or the old WAF for a path, that behaviour has no successor. The automatic migration will not warn you and will not recreate it. Whatever that rule was protecting you from, or letting through, changes without a deploy on your side.
Go and look at your rules for these five before the migration reaches your zone.
The full map
Everything else has somewhere to go. Read off the migration reference on 22 July 2026:
| Page Rules setting | Replacement |
|---|---|
| Always Use HTTPS | Redirect Rules (Single Redirects) |
| Forwarding URL | Redirect Rules (Single Redirects) |
| Browser Cache TTL | Cache Rules |
| Bypass Cache on Cookie | Cache Rules |
| Cache By Device Type | Cache Rules |
| Cache Deception Armor | Cache Rules |
| Cache Level | Cache Rules |
| Cache on Cookie | Cache Rules |
| Cache TTL by status code | Cache Rules |
| Custom Cache Key | Cache Rules |
| Edge Cache TTL | Cache Rules |
| Origin Cache Control | Cache Rules |
| Origin Error Page Pass-thru | Cache Rules |
| Query String Sort | Cache Rules |
| Respect Strong ETags | Cache Rules |
| Browser Integrity Check | Configuration Rules |
| Disable Apps | Configuration Rules |
| Disable Zaraz | Configuration Rules |
| Email Obfuscation | Configuration Rules |
| Opportunistic Encryption | Configuration Rules |
| Polish | Configuration Rules |
| Rocket Loader | Configuration Rules |
| Security Level | Configuration Rules |
| SSL | Configuration Rules |
| Host Header Override | Origin Rules |
| Resolve Override | Origin Rules |
| IP Geolocation Header | Transform Rules (Managed Transforms) |
| True Client IP Header | Transform Rules (Managed Transforms) |
Two things fall out of reading it as a whole.
Most of Page Rules was caching. Thirteen of the thirty three settings became Cache Rules, and another nine became Configuration Rules. Redirects, the thing Page Rules is remembered for, account for two.
And the replacements are separate products. A single Page Rule that set a cache level, forced HTTPS and overrode the host header becomes three rules in three different places. There is no combined view of what a path does any more.
They also carry their own quotas, which are not the ones Page Rules had, and on the free plan one of them may not even be the number the documentation states. Worth reading before you plan a migration around a limit: the docs say 10,000 bulk redirects, your account may have 20.
What Cloudflare does not say
The migration reference is clear about the destination and vague about the schedule. Its words:
This process is planned for late 2025 or beyond, with no action required on your part.
Written in the middle of 2026, “late 2025 or beyond” is doing a lot of work.
There is also no published date for when creating new Page Rules stopped being possible.
Third party write ups name one, Cloudflare’s own documentation does not, and I am not going
to repeat a date I cannot source. What the documentation does show is the feature being
hollowed out on a schedule: the
deprecations page records that on
3 November 2025 the Mirage parameter was removed from Page Rules settings and from the
POST, PATCH and PUT operations on /zones/{zone_id}/pagerules.
So the honest summary is that Page Rules still exist, still work, are losing parameters one at a time, and will be migrated for you at an unspecified point.
Migrating by hand, and checking you got it right
Waiting for the automatic migration is a reasonable choice for most zones. Doing it yourself is worth it when you want the five dropped settings handled deliberately, or when you want the new rules named and ordered the way you would have written them.
The order is the part people get wrong. Page Rules ran by priority within one list. The replacements are separate products, each evaluated at its own point in the request, so “which rule wins” is no longer a number you control in one place. After migrating, verify against the real request rather than against your expectation: Cloudflare Trace replays a URL and reports which rules matched, which is the only check that answers the question directly.
If any of the migrated rules sit on a path that receives advertising traffic, check the query string separately. Trace tells you which rule matched, not what survived the hop, and a redirect that quietly drops the click ID looks perfectly healthy in every other respect.
When this stops being a settings screen
For one zone this is an afternoon. Read the list, note the five with no successor, recreate the rest in three products, trace a few URLs.
The arithmetic changes with the number of zones. The same afternoon, repeated, with no way to see across domains whether you finished, and nothing recording which zone you already did. That is the shape of the work 301.st is built for. For a single domain, the settings screen is still the right tool.