DEV Community: Alex Smirnoff

Page Rules are deprecated. Here is where every setting went.

Alex Smirnoff — Thu, 23 Jul 2026 16:04:43 +0000

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.

The docs say 10,000 bulk redirects. Your account may have 20.

Alex Smirnoff — Thu, 23 Jul 2026 15:57:37 +0000

You uploaded a list of redirects, and somewhere around item 21 Cloudflare stopped taking them:

This account has reached the maximum number of items

The documentation says your free plan holds ten thousand. The import stops at twenty. Both of those are true at the same time, and the reason is a migration that was supposed to finish in 2025.

What the documentation says

Bulk Redirects quotas, read off Cloudflare's availability table on 22 July 2026:

Plan	URL redirects across lists	Lists	Rules
Free	10,000	5	15
Pro	25,000	5	15
Business	50,000	5	15
Enterprise	1,000,000	25	50

Ten thousand on the free plan is a real number and it is current. It is simply not the number every account was actually given.

Where twenty comes from

Until February 2025 the free plan allowance was twenty. The changelog entry that raised it is dated 12 February 2025, and it carries a note that turned out to matter more than the new figures:

Limits are updated gradually. Some customers may still see previous limits until the rollout is fully completed in the first half of 2025.

The rollout was expected to finish by the middle of 2025. Accounts were still reporting the old cap in July 2026.

How to tell which quota your account has

Do not go looking for a number in the dashboard. The quota that governs the import is the one provisioned on the account, and the plan documentation is not a reading of it.

The check that works is the one that fails. Add items to a Bulk Redirect List until it refuses. If item 21 comes back with This account has reached the maximum number of items, your account is still on the old allowance no matter what the plan page says.

Getting it corrected

This is fixed by asking, and the ask is small. Post on the Cloudflare Community with your domain and the exact error text, or open a ticket if your plan has one.

What that gets you varies. On 8 January 2026 someone hit the cap while importing a list and was told:

There is already a ticket on Cloudflare's side, in order to fix the underlying issue. There is no ETA. [...] I'm afraid you will have to wait, until the underlying issue has been fixed.

On 2 July 2026 someone reported the same error, in the same words, and a Cloudflare engineer replied about forty five minutes later:

I have corrected your Bulk Redirect limits.

Same problem, same year, two outcomes. The difference appears to be whether a staff member picks the thread up rather than anything you can control, so include the error text verbatim and name the domain. That is what the thread that got fixed did.

What to use while you wait

Here is the distinction that goes unexplained in every thread, and it solves part of the problem on its own.

Bulk Redirects live on the account. Cloudflare's own wording: they "allow you to define a large number of URL redirects at the account level, which can apply across domains in your account". One list, every zone.

Single Redirects live on the zone. The free plan allowance is ten rules, and it is ten rules per zone, not ten across the account. Six domains with four redirects each fit inside the free plan without touching Bulk Redirects at all.

Two limits worth knowing before you lean on Single Redirects. Wildcards work on every plan, but regular expressions start at Business. And both kinds of rule need the DNS record to be proxied through Cloudflare, which is easy to forget on a domain you park rather than serve.

One more thing to check if these redirects carry advertising click IDs: Bulk Redirects drop the incoming query string unless you say otherwise, and the setting that fixes it has a trap of its own. That is a separate test, and it takes a minute.

Why searching did not help you

The threads that get resolved end like the July one did: a single sentence from an engineer saying the limits have been corrected, and nothing after it. No cause, no scope, no note about who else is affected. Nothing that would rank, and nothing a search engine could show you when you went looking with the error message in hand.

That is why the first page of results for this error is documentation stating a number your account does not have.

When this stops being a support ticket

If you run one domain and a handful of redirects, none of this needs a tool. Ten Single Redirect rules on the free plan cover it, and if you need the bulk list, one forum post gets your quota corrected.

It changes shape when the redirects outlive your attention. Fifty parked domains pointing at one site, several people editing rules, a quota that depends on a support ticket, and no record of which domain was supposed to point where. That is the part 301.st exists for: redirects across many domains, with the history of who changed what. If your answer is still one list in the dashboard, keep the list.

Hi DEV, we're 301. Yes, like the status code

Alex Smirnoff — Thu, 23 Jul 2026 14:48:42 +0000

Every redirect on the internet ends in a status code. Ours is 301 Moved Permanently, so introducing ourselves by moving in here felt about right.

We write about the least glamorous corner of the web: redirects, DNS, and
HTTP on Cloudflare. The stuff nobody thinks about until a domain that
"definitely still redirects" quietly starts returning a 522, and a customer
emails you the screenshot.

Why we exist: we got tired of guides that were correct in 2021. Cloudflare
changes limits and retires products faster than tutorials get rewritten. The
docs promise 10,000 bulk redirects on the free plan; plenty of accounts open
the dashboard and find 20. So we check every number against the live docs and
stamp each article with the date we checked it. If a post doesn't say when it
was verified, assume it's quietly lying to you. Ours say. We are, admittedly,
a little paranoid.

What you'll get from us here:

Why a redirect that looks perfectly configured still returns a 522, a 525, or a registrar parking page — three different lies, one curl.
Which of your 300 domains still redirect, and what to fix first.
How to count a click on a redirect that never runs a line of JavaScript.
The occasional existential post, like the time an "AI readiness" scanner scored our own docs site 21 out of 100 and we had to agree with most of it.

Full disclosure, because DEV is a place that likes it: this account is the
blog behind 301.st, a platform for managing redirects at
scale. That's the thing that made us this strange about DNS. But every article
solves your problem first and only mentions the product where Cloudflare's
native path actually runs out. You get the working answer either way.

Everything is also mirrored at 301.sh with plain markdown
versions for the LLMs, because it's 2026 and even the robots deserve readable
docs.

Say hi, and tell us your worst redirect story. We collect those. 👋

P.S. If this post ever 404s, we know, and we're deeply ashamed.