Cloudflare Page Rules: A Practical Guide for Developers and Sysadmins

If you manage a domain behind Cloudflare, sooner or later you’ll need finer-grained control than the global dashboard settings allow. That’s where Cloudflare Page Rules come in. They let you override Cloudflare’s default behavior — caching, SSL, redirects, security level — for specific URL patterns, without touching your origin server’s configuration.

This guide walks through what Page Rules actually do, how the priority system works (a common source of confusion), and practical configurations you can copy directly into your Cloudflare dashboard.

What Are Cloudflare Page Rules?

A Page Rule is a URL-pattern match paired with one or more settings that apply only when a request matches that pattern. Free plans get 3 rules, Pro gets 20, Business gets 50, and Enterprise can have hundreds. Each rule can bundle up to a handful of settings — cache level, browser cache TTL, forwarding URL, security level, SSL mode, and more.

Think of them as if this URL matches, then do this statements layered on top of Cloudflare’s edge network. They’re evaluated before the request reaches your origin, which makes them powerful for performance tuning and access control alike.

Common Use Cases

Force HTTPS on specific subdomains or paths

Bypass cache for admin panels or API endpoints (/wp-admin/*, /api/*)

Set aggressive caching on static assets (/assets/*, /images/*)

Create 301 redirects for old URLs after a migration

Disable security features (like Rocket Loader) on pages where they break JavaScript

Enable Always Online for specific high-traffic pages

If you’re running a Dockerized app behind Cloudflare, Page Rules pair well with the reverse proxy setup covered in our Docker Compose reverse proxy guide — Cloudflare handles edge caching while Nginx or Traefik handles routing internally.

Setting Up Your First Page Rule

Log into the Cloudflare dashboard, select your domain, and navigate to Rules > Page Rules. Click Create Page Rule.

A rule has three parts:

1. URL pattern — supports wildcards (*)
2. Settings — one or more actions to apply
3. Order/priority — determined by the rule’s position in the list

Here’s a basic example that caches everything under /static/ aggressively:

URL: example.com/static/*
Settings:
  Cache Level: Cache Everything
  Edge Cache TTL: a month
  Browser Cache TTL: a month

And one that bypasses cache entirely for an API path:

URL: example.com/api/*
Settings:
  Cache Level: Bypass
  Disable Performance (Rocket Loader, Auto Minify)

Using the API Instead of the Dashboard

For infrastructure-as-code workflows, you’ll want to manage Page Rules via the Cloudflare API rather than clicking through the UI every time. Here’s a curl example creating a cache rule:

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": "example.com/static/*"
        }
      }
    ],
    "actions": [
      { "id": "cache_level", "value": "cache_everything" },
      { "id": "edge_cache_ttl", "value": 2592000 }
    ],
    "priority": 1,
    "status": "active"
  }'

You can find your ZONE_ID on the domain overview page, and generate a scoped API token under My Profile > API Tokens with Zone.Page Rules edit permissions. Full parameter reference is available in the Cloudflare API documentation.

If you’d rather manage rules declaratively, Terraform’s Cloudflare provider supports the cloudflare_page_rule resource, which is worth adopting once you have more than a handful of rules across multiple zones.

Priority Order: The Part Everyone Gets Wrong

Page Rules don’t evaluate in the order you’d expect from most rule-based systems. Cloudflare processes rules top to bottom in the order they appear in your dashboard list, and the first matching rule wins — subsequent matching rules are ignored, even if they contain different settings.

This trips people up constantly. If you have a broad rule like example.com/* sitting above a specific rule like example.com/blog/*, the broad rule will always win and the specific one never fires.

Correct Ordering Example

1. example.com/blog/feed/*        -> Cache Level: Bypass
2. example.com/blog/*             -> Cache Level: Cache Everything
3. example.com/*                  -> Security Level: Medium

Most specific rules go first, broadest rules go last. You can drag rules to reorder them in the dashboard, or set the priority field explicitly via the API.

Debugging Priority Conflicts

List all rules and their order before troubleshooting

Use the Cache Status header (cf-cache-status) in response headers to verify which behavior is actually being applied

Test with curl -I against the live URL, not a browser (browser cache can mask the real edge behavior)

curl -I https://example.com/blog/some-post/

Look for cf-cache-status: HIT, MISS, BYPASS, or DYNAMIC to confirm the rule that actually applied.

Page Rules vs. Cloudflare Rulesets (Transform/Cache Rules)

Cloudflare has been migrating functionality out of the legacy Page Rules system into newer, more granular products: Cache Rules, Transform Rules, and Redirect Rules, all part of the Rulesets engine. These are available on all plans (including Free, with limits) and are generally the better choice going forward because:

They support more complex logic (AND/OR conditions, not just URL wildcards)

They separate concerns (cache behavior vs. redirects vs. header rewrites) instead of bundling everything into one rule type

They don’t count against your legacy Page Rule limit

If you’re starting fresh in 2026, lean toward Cache Rules and Redirect Rules for new configurations, and reserve legacy Page Rules for settings that haven’t been migrated yet (like Forwarding URL redirects on older plans, or Always Online). Our DNS records explained article covers how these interact with your zone’s DNS setup if you’re still getting your domain fully onboarded.

Redirect Example (Legacy Page Rule)

URL: example.com/old-page
Setting: Forwarding URL (301 - Permanent Redirect)
Destination: https://example.com/new-page

For bulk redirects (hundreds of URLs after a migration), use Bulk Redirects instead — Page Rules cap out fast and aren’t meant for large redirect maps.

Security-Focused Page Rule Configurations

Beyond caching, Page Rules are useful for tightening security on sensitive paths:

Set Security Level: High on login and admin URLs to trigger more aggressive challenge behavior

Enable Browser Integrity Check on form submission endpoints

Force Always Use HTTPS across the entire zone if you haven’t already enabled it globally

Disable Email Obfuscation on paths where it conflicts with your app’s JS (rare, but it happens)

If you’re running self-hosted services and want an alternative to exposing an origin IP entirely, look at Cloudflare Tunnel — we cover the tradeoffs in Cloudflare Tunnel vs. VPN for homelab and small production setups.

Combining Page Rules With Origin Server Config

Page Rules operate at the edge, but they work best when your origin server headers agree with them. For example, if you set Cache Level: Cache Everything at the edge but your origin sends Cache-Control: no-store, Cloudflare will generally respect the more restrictive origin header unless you also set an explicit Edge Cache TTL in the rule to override it. Always test both layers together rather than assuming the edge rule is the final word.

Monitoring the Impact of Your Rules

After deploying Page Rules, verify they’re actually improving performance rather than just trusting the dashboard. Check:

Analytics > Traffic in Cloudflare for cache hit ratio changes

Origin server request logs to confirm reduced load (fewer requests reaching your backend is the real signal a caching rule worked)

Uptime and latency from an external monitor — a tool like BetterStack gives you synthetic checks from multiple regions so you can see whether edge caching actually improved response times for real users, not just from your own location

If your infrastructure lives on a VPS, pairing Cloudflare’s edge layer with a solid host matters just as much as the rules themselves — see our comparison in best VPS providers for self-hosting if you’re still choosing where to run the origin.

FAQ

Q: How many free Page Rules does Cloudflare give me?
A: The Free plan includes 3 Page Rules per zone. Pro gets 20, Business gets 50, and Enterprise plans can negotiate higher limits or use the Rulesets engine instead, which has separate, more generous limits.

Q: Why isn’t my Page Rule working even though the URL matches?
A: The most common cause is rule ordering — a broader rule listed above your specific rule will match first and suppress it. Reorder so the most specific URL patterns are at the top of the list.

Q: Do Page Rules affect DNS-only (grey-clouded) records?
A: No. Page Rules only apply to traffic proxied through Cloudflare (orange-clouded). If a DNS record is set to “DNS only,” none of your Page Rules, Cache Rules, or security settings will apply to it.

Q: Should I use Page Rules or Cache Rules for new caching configurations?
A: Use Cache Rules going forward. They’re more flexible, available on all plans, and don’t consume your limited legacy Page Rule count. Reserve legacy Page Rules for settings not yet available in the newer Rulesets products.

Q: Can Page Rules replace a CDN cache-busting strategy for a Docker-deployed app?
A: Partially. Page Rules control edge caching behavior, but you’ll still want cache-busting via versioned filenames or query strings in your build pipeline. Combine both for the most reliable results.

Q: Will changing a Page Rule take effect immediately?
A: Changes propagate across Cloudflare’s edge network within seconds to a few minutes globally. If you don’t see the change reflected, check for browser cache or an overriding rule higher in priority.

Wrapping Up

Cloudflare Page Rules are a small but sharp tool: three or four well-ordered rules can meaningfully cut origin load, tighten security on sensitive paths, and clean up legacy URLs after a migration. The biggest pitfall is priority ordering — get specific rules above broad ones, verify behavior with curl -I and the cf-cache-status header, and migrate new configurations to Cache Rules and Redirect Rules where possible since that’s where Cloudflare’s development effort is focused going forward.

If you manage Cloudflare across multiple domains or want deeper analytics and rule automation, a Cloudflare Pro or Business plan is worth evaluating — the added Page Rule slots and Cache Rule flexibility pay for themselves quickly once you’re managing more than a couple of sites.