How to write Cloudflare cache rules without serving private pages to strangers

Caching is safest when it is boring. Static stylesheets, images and scripts usually benefit from reuse; login screens, carts, account pages and previews often cannot be treated the same way. A single broad “cache everything” rule can make a fast page while handing a visitor a response intended for someone else. Before optimizing speed, draw the boundary between public and personalized content.

Cloudflare's default-cache documentation says the service generally caches selected file extensions and does not cache HTML or JSON by default. It also explains how origin cache headers and HTTP response characteristics affect eligibility. A custom rule can change these assumptions. That is why copying an aggressive rule from a tutorial is risky.

Classify routes by audience and state

Divide URLs into public static assets, public anonymous HTML, pages that vary by cookie or login state, administration, APIs and unpredictable endpoints. Mark preview links, checkout steps, comment actions and password-protected content explicitly. If a page depends on visitor identity, the safest initial decision is to bypass shared caching until the application has been designed for it.

Review how the origin sends Cache-Control, Set-Cookie and Vary headers. An anonymous page can still set a harmless cookie, while a personalized page may fail to set a protective header. Testing the real response is more reliable than assuming behavior from a URL path alone.

Build narrow rules before broad ones

In the Cloudflare dashboard, Cache Rules let you choose a matching expression and then either bypass caching or make matching requests eligible for caching. The rule creation guide walks through rule order and deployment. Begin with a restrictive test targeting public content rather than every request on the hostname.

Account for rule order and overlaps. A bypass covering login paths must not be unintentionally superseded by a later broad match. Test parameter variants, language paths, device-specific content and cookie states. If you alter cache keys, verify that content variants really produce distinct keys.

Be cautious about edge TTL overrides

An Edge Cache TTL can change how long Cloudflare holds a response and may override instructions from the origin, depending on settings. The available-settings documentation explains options and warns that behavior interacts with headers and other configuration. Do not set a long shared TTL for HTML you cannot safely invalidate.

Choose a purge procedure before deployment. Editorial publishers need updates and corrections to appear quickly. A mistaken article headline held at the edge can remain visible after the CMS has been fixed unless cache invalidation reaches the relevant variants.

Run an anonymous-versus-authenticated test

Visit a public article without cookies, then with a normal authenticated session. Inspect the network response and any cache status headers. Repeat with distinct test accounts on a safe environment. Confirm that private names, tokens, carts and user-specific navigation never cross between accounts. Test redirects and error pages too. A HIT is not proof of a correct cache rule; correctness comes first.

Keep a brief rule inventory with the reason for each exception, the person who approved it and a known-safe test URL. An unexplained rule inherited from an earlier deployment should not remain indefinitely merely because nobody knows what it does. Review cache changes alongside authentication and checkout releases.

After deployment, monitor origin load, cache hit rates, stale content and error rates. Keep the pre-change rules ready for rollback. Where correctness is uncertain, bypass caching and fix the application contract before attempting another optimization.

A route can look public while varying invisibly with request headers, country, device or an A/B test. If you cache a single representation for everyone, the wrong language or variant may reach the wrong person. Before designing a custom cache key, identify precisely which input changes the HTML response. Cloudflare documents options for query strings, headers and cookies, but adding every header to a key can destroy cache efficiency and create unpredictable combinations.

Test three different states for each important route: first visit with no cookies, repeat anonymous visit and authenticated visit. Record response status, Cache-Control, Set-Cookie, CF-Cache-Status when available, and a short fingerprint of the visible content. Repeat after an editorial correction and a targeted purge. This is a hypothetical QA method, not a claim about the configuration of a specific site.

Be particularly cautious with error pages and redirects. Caching a temporary maintenance response, an authentication redirect or a localized destination too broadly can appear as a site outage even when the origin is healthy. Roll out rules first to a small path pattern and test on a safe hostname where possible. If the symptoms are ambiguous, return to the default behavior and investigate before enabling wider eligibility.

Preserve speed without losing trust

Static asset caching often produces useful gains without touching personalized HTML. Make changes one route class at a time, write down the exceptions and verify again after CMS or authentication updates. Our Cloudflare security update story covers a separate protection concern; the WordPress staging guide addresses testing changes before production. Fast pages are valuable only if they show the right content.