Page Rules Cloudflare: A Practical Configuration Guide for DevOps Teams
Cloudflare’s page rules give you fine-grained control over how individual URLs on your site are cached, redirected, and secured, without touching your origin server. If you’ve ever needed to force HTTPS on a single subdomain, bypass caching for an admin path, or set up a fast redirect without deploying code, page rules cloudflare configuration is usually the fastest way to get there. This guide walks through how page rules work, how to set them up correctly, common patterns, and where newer Cloudflare features are starting to take over some of their responsibilities.
What Are Cloudflare Page Rules?
Page rules are URL-pattern-based instructions that tell Cloudflare’s edge network how to handle requests matching a specific pattern before they ever reach your origin server. Each rule consists of a URL match (using wildcards) and one or more settings that apply when a request matches that pattern.
Unlike DNS-level settings, which apply globally to a zone, page rules cloudflare configuration lets you scope behavior down to a single path, subdomain, or even a query string pattern. This is the mechanism most teams reach for when they need exceptions to their site-wide caching or security posture.
Typical use cases include:
How Rule Matching Works
Each page rule uses a URL pattern with asterisk (*) wildcards. Cloudflare evaluates rules in the order they’re listed in the dashboard (or via the API, by the priority field), and the first matching rule wins — it does not merge settings from multiple matching rules. This trips up a lot of people migrating from other CDN configuration systems, where multiple rules can stack. With page rules cloudflare setups, ordering is not cosmetic; it’s functionally part of the logic.
A pattern like example.com/blog/* matches everything under /blog/, including nested paths. A pattern like example.com/blog/*.pdf matches only PDF files inside that directory. Query strings can be included in the match as well, which is useful for handling tracking parameters differently from clean URLs.
Setting Up Your First Page Rule
Before creating rules, it helps to have a clear picture of what you’re trying to achieve, since the free plan on Cloudflare limits you to a small number of rules (historically three, though this varies by plan tier and Cloudflare periodically adjusts pricing/limits, so check your dashboard for your current allotment rather than relying on a fixed number). Because slots are limited, plan the fewest rules that cover the most cases.
Creating a Rule via the Dashboard
1. Log into the Cloudflare dashboard and select your zone.
2. Navigate to Rules → Page Rules.
3. Click Create Page Rule.
4. Enter the URL pattern (e.g., www.example.com/api/*).
5. Add one or more settings — for example, “Cache Level: Bypass”.
6. Save and confirm the rule appears with the correct priority.
A basic redirect rule looks like this in practice:
url_pattern: "old.example.com/*"
settings:
- forwarding_url:
url: "https://new.example.com/$1"
status_code: 301
While the dashboard UI is the most common entry point, most DevOps teams eventually manage page rules cloudflare configuration through the API or Terraform, especially once rules become part of a reproducible infrastructure setup.
Managing Rules via the API
Cloudflare exposes a REST API for page rules, which lets you version-control your CDN configuration alongside your infrastructure code. A minimal example using curl:
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/pagerules" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{
"targets": [
{
"target": "url",
"constraint": {
"operator": "matches",
"value": "www.example.com/images/*"
}
}
],
"actions": [
{ "id": "cache_level", "value": "cache_everything" },
{ "id": "edge_cache_ttl", "value": 7200 }
],
"priority": 1,
"status": "active"
}'
Keeping this configuration in a script or Terraform module (Cloudflare maintains an official provider) means your page rules cloudflare setup is reviewable in pull requests instead of living only in a dashboard that anyone with access can silently edit.
Common Page Rules Patterns for DevOps
Most production Cloudflare zones converge on a handful of recurring rule patterns. Below are the ones worth knowing well.
Forcing HTTPS Everywhere
Even with “Always Use HTTPS” available as a zone-level toggle, some teams still use a page rule for finer control over specific subdomains during a migration:
http://*example.com/*This is often the very first rule created on a new zone, since it closes off plaintext traffic before anything else is configured.
Bypassing Cache for Dynamic Paths
APIs, admin dashboards, and authenticated areas should almost never be cached at the edge. A typical rule:
example.com/api/* or example.com/wp-admin/*Skipping this step is a common cause of “my API returns stale data intermittently” bugs, where Cloudflare’s default caching heuristics accidentally cache a response that should have been dynamic.
Aggressive Caching for Static Assets
For image directories, CSS/JS bundles, or anything with a content-hashed filename, you can push the cache level much harder than Cloudflare’s defaults:
example.com/assets/*This offloads a large share of origin traffic to Cloudflare’s edge, which matters if your origin is a modest VPS rather than an autoscaling cluster. If you’re running your origin on a lean box, pairing an aggressive caching rule with a solid unmanaged VPS hosting setup keeps bandwidth costs predictable.
Page Rules vs Newer Cloudflare Products
Cloudflare has been gradually pushing more granular control into newer products — Cache Rules, Configuration Rules, and Transform Rules — which are part of the newer Rules engine. It’s worth understanding how these relate to legacy page rules cloudflare configuration, since Cloudflare’s own documentation now recommends the newer tools for new zones.
Cache Rules and Configuration Rules
Cache Rules replace the caching-related actions of page rules with a more expressive rule builder that supports boolean logic (AND/OR) rather than a single wildcard match. Configuration Rules take over settings like Rocket Loader, Mirage, and minification toggles that used to live under page rules. Both are generally available on all plan tiers, including free, unlike page rules’ historically stingy free-tier limits.
If you’re building a new zone today, it’s worth checking the official Cloudflare documentation to see which rule type is now recommended for your use case, since Cloudflare periodically shifts feature parity between the systems.
Should You Migrate Existing Rules?
If your existing page rules cloudflare setup is working and you’re not hitting the rule-count limit, there’s no urgent need to migrate. Page rules aren’t deprecated — they still function and are documented — but new features are increasingly landing in the newer rule types first. A pragmatic approach:
Troubleshooting Page Rules
When a page rule doesn’t behave as expected, the most common causes are ordering conflicts, browser cache interference, or pattern mismatches.
Rule Order and Priority Conflicts
Because only the first matching rule applies, a broad rule placed above a narrow one will silently swallow the narrow rule’s intended behavior. For example, if example.com/* (bypass cache) sits above example.com/assets/* (cache everything), the assets rule never fires. Always order from most specific to least specific.
Cache Not Clearing After a Rule Change
Page rule changes affect Cloudflare’s edge cache going forward, but they don’t retroactively purge existing cached objects. After changing a caching rule, you typically need to manually purge cache (either the whole zone or specific URLs) for the new behavior to take effect immediately, rather than waiting for the old TTL to expire naturally.
Verifying What’s Actually Happening
Use curl -I against the affected URL and check the cf-cache-status response header (values like HIT, MISS, BYPASS, or DYNAMIC tell you exactly what Cloudflare did with that request):
curl -sI https://example.com/assets/logo.png | grep -i cf-cache-status
If the header doesn’t show the status you configured, double-check rule ordering and pattern syntax before assuming the feature is broken — a mistyped wildcard is a far more common culprit than an actual platform issue.
FAQ
Does the free Cloudflare plan support page rules?
Yes, but the free plan includes a limited number of page rule slots. Paid plans include more, and you can purchase additional rules on some tiers. Check your dashboard’s Rules section for your zone’s current limit, since Cloudflare adjusts these allotments over time.
Can I use page rules to redirect an entire domain?
Yes. A common pattern is matching olddomain.com/* with a Forwarding URL action pointing to https://newdomain.com/$1, using a 301 status code for permanent redirects that search engines will follow and re-index.
Why isn’t my page rule cloudflare cache bypass working for a specific path?
The most frequent cause is a higher-priority rule matching the same URL first. Since only one rule applies per request, verify no broader rule above it in your dashboard is intercepting the traffic before it reaches your intended rule.
Are page rules being deprecated in favor of Cache Rules?
Not officially deprecated, but Cloudflare has clearly shifted new feature development toward Cache Rules, Configuration Rules, and Transform Rules. Existing page rules continue to work; new zones may benefit from starting with the newer rule types instead.
Conclusion
Page rules remain one of the simplest ways to control caching, redirects, and security behavior at Cloudflare’s edge without touching your origin infrastructure. Getting page rules cloudflare configuration right comes down to a few fundamentals: understand that only the first matching rule applies, order your rules from specific to general, and keep your limited rule slots reserved for things that genuinely need edge-level handling. For anything more complex than a simple match-and-act pattern, look at Cloudflare’s newer Cache Rules and Transform Rules, which offer more expressive logic without the legacy constraints. Whichever system you use, treat your CDN configuration the same way you treat any other infrastructure — version it, review it, and periodically audit it — and pair it with a related deep dive like this site’s Cloudflare Page Rules setup guide or its Cloudflare Pages hosting guide if you’re also managing static or full-stack deployments behind the same zone. For the underlying platform mechanics and the most current list of available match types and actions, Cloudflare’s own Rules documentation is the authoritative reference.
Leave a Reply