Page Rules are rules that change Cloudflare's behavior for specific URL patterns. The Free plan gives you 3 Page Rules, Pro — 20.

Creating a Page Rule

Rules → Page Rules → Create Page Rule.

URL patterns support an asterisk (*) as a wildcard:

example.com/blog/* — all blog pages
*example.com/* — the entire site, including subdomains
example.com/api/* — all API endpoints

Examples of useful Page Rules

Redirect www → non-www

URL: www.example.com/*
Setting: Forwarding URL
Type: 301 Permanent Redirect
Destination: https://example.com/$1

Disable cache for /wp-admin

URL: example.com/wp-admin/*
Setting: Cache Level → Bypass

Force HTTPS

URL: http://example.com/*
Setting: Always Use HTTPS

Disable minification for /api

URL: example.com/api/*
Setting: Disable Performance

💡 Use Redirect Rules (Rules → Redirect Rules) instead of Page Rules for redirects — they don't take up Page Rules slots and are more flexible.

Page Rules vs Redirect Rules

Feature	Page Rules	Redirect Rules
Redirects	✅	✅ (preferred)
Limit (Free)	3	10
Regex URL	❌	✅
Cache/security settings	✅	❌

⚠️ Page Rules apply on first match — rule order matters. Put more specific rules higher in the list.

Settings you can combine in a single Page Rule

One rule can turn on several settings at once — Cloudflare applies all of them if the URL matches the pattern:

Setting	What it does
Forwarding URL	301/302 redirect to another address
Always Use HTTPS	Forces a switch to https://
Cache Level	Bypass, Standard, or Cache Everything for this path
Disable Performance	Turns off Auto Minify and Rocket Loader for the URL
Security Level	A custom check level for a specific part of the site
Browser Integrity Check	Blocks requests with suspicious headers

Forwarding URL cannot be combined with most other settings in one rule — Cloudflare stops processing at the first matching redirect. For choosing between Flexible and Full (Strict) SSL, see the article on Cloudflare SSL/TLS modes.

Common mistakes explained

The rule is created but nothing happens

The most frequent cause: the rule exists, but sits below another rule that matches the same URL earlier and contains a command that stops further processing (for example, its own Forwarding URL). Page Rules run top to bottom, and once a rule with a redirect fires, the rest are ignored for that request.

The second frequent cause: the rule targets example.com/*, while the actual request goes to www.example.com/*. These are different patterns — list them separately or use *example.com/*.

The rule fired, but the wrong setting applied

If two rules match the same URL with different actions, the one listed higher wins, not the more specific one. Check the order in Rules → Page Rules and move the narrower rule (for example, for /wp-admin/*) above the more general one (/*).

Verifying the result

After saving a rule, wait about 30 seconds for it to propagate across the Cloudflare network, then check the response headers:

curl -I https://example.com/old-page

HTTP/2 301
location: https://example.com/new-page
cf-ray: 7d1a2b3c4d5e6f7g-WAW

The cf-ray value is a unique request identifier inside the Cloudflare network — keep it when contacting support. For rules that change caching, check the cf-cache-status header: values like HIT, MISS, BYPASS, and DYNAMIC show exactly how the request was handled.

When Page Rules do not fit

You need regex matching — Page Rules only support the asterisk wildcard; for regex you need Redirect Rules with Advanced mode enabled.
The condition depends on a header, a cookie, or the visitor's country — that is a job for Configuration Rules and Cache Rules, not Page Rules.
The plan's rule limit is used up — move part of the logic (redirects, caching, security) into the separate Rules products, since their limits are counted independently from Page Rules.

Cloudflare is gradually moving Page Rules functionality into separate products — Configuration Rules, Cache Rules, Redirect Rules, Origin Rules. For new projects it makes sense to use those directly, keeping Page Rules only for rules already configured.

Verify that a new rule actually applies using curl or a private browser window: a regular tab can show a cached older version of the page, making it look like the rule did not fire when the real cause is just the browser's local cache. The current count of used and available rules is always shown right above the list in Rules → Page Rules — more reliable than counting them from memory.