Cloudflare cache rules for dynamic content

Cache rules versus page rules

Cloudflare has two families for controlling cache behaviour:

| Control | Scope | Status |

| Cache Rules | Match by host/path/query, set cacheability, TTL, key | Modern, recommended |

| Page Rules (classic) | Free plan limit (3 rules), match by URL pattern | Legacy, fewer limits |

Cache rules are the forward-looking modern interface. Page rules still exist for URL patterns and some special-case settings, but for cache control, prefer Cache Rules (or Edge TTL) and only reach for a Page Rule for a one-off override.

How cacheability is decided

A response is cached by default only when Cloudflare decides that:

• The origin sent no Cache-Control: no-store / no-cache signal, or the origin response was explicitly cacheable.
• The request did not carry a dynamic marker (a POST, a session cookie, or an Authorization header) that the origin treats as dynamic.
• The file type is one Cloudflare considers cacheable, usually a static extension.

For most sites the practical goal is the opposite of the defaults: make your static assets cacheable with long TTLs, and protect the fully dynamic pages from being cached.

Standard WordPress pattern

WordPress is dynamic: PHP renders the page, and the login area plus carts change per user. A common sensible pattern:

| Path | Cache behaviour |

| /wp-content/, /wp-includes/ | Cache by default (hashed URLs serve stale-safe) |

| /wp-admin/, /wp-login.php | Never cache |

| Front pages with cookies (wordpress_*) | Bypass cache to avoid leaking personalized state |

Set a Cache Rule:

• Match http.host equals your host AND path starts with /wp-content.
• Set cache level to Standard with a browser TTL and edge TTL, for example 30 days.
• For the /wp-admin rule set "Bypass cache".

Do not switch every page to "Cache Everything" bluntly. A cache-everything rule on a site with logged-in users serves a sanitized stub to the wrong visitor and hides the cart. If you want full-page caching, use a WordPress cache plugin that renders complete pages and set "Cache Everything" only on routes that genuinely can be HTML-cached.

Cookie and dynamic detail

The precise behaviour depends on three settings:

• Standard behaviour: Cloudflare respects Cache-Control and the default cache list.
• Cache Everything: the edge caches regardless of query parameters (unless ignored) and does not cache requests carrying certain cookies by default.
• Ignore Query String: tells the edge to treat different query strings as one cached entity.

For best results, set explicit rules: bypass cache when a cookie or header marks the response as user-specific, and cache otherwise. Do not bypass the cache for all static WordPress assets: wp-content files are safe to cache hard because the URL hashes change on theme update. What needs the bypass is the server-rendered, per-login page, not the asset.

Building the rule (dashboard)

1. Open Rules > Cache Rules > Create rule.
2. Set the expression, for example:

(hostname eq "www.example.com" and starts_with(path, "/wp-admin"))

1. Choose action "Bypass cache" for the dynamic paths, and "Eligible for cache" (or "Cache with a custom TTL") for the static paths.
2. Order rules so the most specific override comes last. Cloudflare evaluates Cache Rules in list order and, when two matching rules set the same setting, the last matching rule wins. So a broad "Cache everything" rule must come before a narrower "Bypass cache on /wp-admin" rule, so the bypass can win on the paths that actually reach it.

Prevention

• Review the rule list after a WordPress plugin change, since plugins that tweak caching can clash with your rules.
• Measure before and after: capture the cache hit rate and Core Web Vitals so you know what the rules proved, not just what they declared.