Cloudflare Cache Rules: How to Speed Up Your Business Website Safely
Cloudflare does not cache HTML by default. Learn how Cache Rules can cache public pages while bypassing logins and carts, how TTLs and purging work, and how to confirm it with cf-cache-status.
Putting your website behind Cloudflare does not automatically make every page fast. By default, Cloudflare caches static files such as images, CSS, JavaScript and PDFs, but it does not cache HTML, so every page view still waits for your server to build the page. Cache Rules let you change that safely: cache public pages at the edge, bypass the cache for logged-in users, admin areas and shopping carts, and control how long copies live. This guide explains the defaults, the rules worth adding, the settings that matter on each plan and how to confirm it is working. For the broader picture of page speed, see our Core Web Vitals guide.
What Cloudflare caches by default
Cloudflare decides what to cache by file extension, not by content type. According to its documentation, the default list includes:
- Images: JPG/JPEG, PNG, GIF, WEBP, AVIF, SVG, ICO and others
- Styles and scripts: CSS, JS
- Documents: PDF, DOC/DOCX, XLS/XLSX, PPT/PPTX, CSV
- Fonts: WOFF, WOFF2, TTF, OTF, EOT
- Media and archives: MP4, MP3, WEBM, ZIP, GZ and others
Cloudflare states that it "does not cache HTML or JSON by default." Even eligible files are not cached when the origin response includes Cache-Control: private, no-store, no-cache or max-age=0, when it sets a cookie (Set-Cookie), or when the request is not a GET. On the Free, Pro and Business plans, the largest cacheable file is 512 MB.
All of this only applies to hostnames that are proxied (the orange cloud in DNS). DNS-only records bypass Cloudflare's cache entirely.
Cache Rules: the modern way to control caching
Cache Rules replaced the caching settings that used to live in Page Rules, which Cloudflare now treats as legacy and documents a migration path for. Rules are built in the dashboard (the Rules overview page includes ready-made templates). Cloudflare's documentation lists these limits:
| Plan | Cache Rules |
|---|---|
| Free | 10 |
| Pro | 25 |
| Business | 50 |
| Enterprise | 300 |
One behaviour catches many people out: cache rules stack. Every matching rule applies, and when two rules set the same option, Cloudflare's docs say "the value in the last matching rule wins." Order matters.
A safe pattern for caching HTML
For a typical business site, two rules do most of the work:
- Rule 1: Cache public pages. Match your hostname and set the cache eligibility to Eligible for cache. This tells Cloudflare to cache HTML as well as static files.
- Rule 2 (placed after Rule 1): Bypass for anything personal. Match requests where any of the following is true, and set it to Bypass cache:
- the path starts with
/wp-adminor is/wp-login.php(WordPress), or any admin, account or portal path on a custom site - the path starts with
/cart,/checkoutor/my-account(WooCommerce and similar stores) - the request carries a login or cart cookie, such as WordPress's
wordpress_logged_in_or WooCommerce'swoocommerce_items_in_cartandwp_woocommerce_session_ - the request method is POST, or the path is a search, preview or API endpoint
- the path starts with
Because Rule 2 comes last, its bypass wins whenever both match. Before you enable Rule 1, list every page that shows something specific to one visitor: a greeting with their name, a cart count, a member price, a form with a session token. If such a page gets cached, the next visitor sees the previous visitor's version. When in doubt, bypass it.
Two built-in protections help:
- Cache Deception Armor (a toggle in the cache key section of a rule) refuses to cache a response when the URL's extension does not match the content type, which blocks a known trick where an attacker gets a private page cached under a fake
.jpgURL. - Cloudflare's default behaviour of not caching responses that set cookies is a safety net, but do not rely on it alone: Edge TTL overrides and some cache settings can change what gets stored.
Edge TTL vs Browser TTL
These two settings are often confused:
- Edge TTL is how long Cloudflare keeps a copy on its network. You can respect your server's
Cache-Controlheader, fall back to Cloudflare's defaults, or ignore the header and set your own TTL. You can also set different TTLs by status code, for example a short TTL for 404 pages. - Browser TTL is how long a visitor's browser keeps its copy. Cloudflare's default Browser Cache TTL is 4 hours on every plan.
Plan limits matter here. Cloudflare documents a minimum Edge Cache TTL of 2 hours on Free, 1 hour on Pro and 1 second on Business and Enterprise. Most importantly, purging Cloudflare's cache does not clear copies already stored in visitors' browsers. For HTML, keep the browser TTL short (or respect the origin's no-cache header) and rely on the edge TTL plus purging. For CSS and JavaScript, use versioned file names (for example site.css?v=12) so you can give them long browser lifetimes.

Purging the cache
When you publish a change, cached copies need to be cleared. Cloudflare lists these purge methods as available on all plans:
- Single file (URL): the method Cloudflare recommends; purge exactly the pages you changed.
- Hostname, prefix and cache tags: clear a whole subdomain, a folder such as
/blog/, or tagged groups of content. - Purge everything: effective but heavy, because every visitor's next request goes back to your server.
Purge requests are rate-limited, and on the Free plan the bulk methods are limited to a few requests per minute. A successful API response only means the request was received; Cloudflare suggests checking that the CF-Cache-Status header no longer shows HIT.
Tiered Cache, compression and images
Tiered Cache
Without Tiered Cache, each Cloudflare data center that misses goes to your server separately. Tiered Cache makes lower-tier data centers ask an upper tier first, which reduces load on your origin. Cloudflare's documentation says Smart Tiered Cache is available on every plan, including Free, and is enabled under Caching > Tiered Cache. Regional Tiered Cache is Enterprise-only.
Compression
Cloudflare compresses responses with Gzip, Brotli or Zstandard depending on what the visitor's browser supports, the plan and any Compression Rules. According to its documentation, the default is Zstandard on Free, Brotli on Pro and Business and Gzip on Enterprise; Compression Rules can change the default. There is little to configure here, but if your server already compresses responses, check that nothing is compressing twice.
Images
- Polish strips metadata and compresses images automatically, without changing your markup. It is available on Pro, Business and Enterprise, not Free.
- Image transformations (resizing and format conversion through special URLs) are available on the Free plan up to 5,000 unique transformations per month, according to Cloudflare's Images documentation. Beyond that, new transformations return an error until you move to a paid plan, though already-cached ones keep working.
Checking that it works
Open a terminal and request a page twice:
curl -sI https://www.example.com/ | grep -i cf-cache-status
| Value | What it means |
|---|---|
| HIT | Served from Cloudflare's cache |
| MISS | Eligible, not cached yet; fetched from your server |
| EXPIRED | Cached copy was stale; refreshed from your server |
| BYPASS | Eligible, but the origin response was not cacheable |
| DYNAMIC | Not eligible for cache; went straight to your server |
| UPDATING / STALE | An older copy was served while refreshing, or because the origin was unreachable |
Then test the bypass rule: send a request with a fake login cookie (curl -sI -H "Cookie: wordpress_logged_in_test=1" …) and confirm it is not a HIT. Log in to the admin area in a private window and check the header in the browser's developer tools as well.
WordPress specifics
- Use one caching plan. A WordPress page-cache plugin plus Cloudflare HTML caching works, but the plugin must purge Cloudflare when content changes, or visitors see old pages until the edge TTL expires.
- Automatic Platform Optimization (APO) is Cloudflare's WordPress-specific option for caching dynamic pages at the edge. It requires the official Cloudflare WordPress plugin; check your plan for availability before choosing between APO and your own Cache Rules.
- Avoid caching nonces. Some forms and plugins embed short-lived security tokens in the page. If cached pages cause "link expired" errors on forms, bypass those pages or shorten their edge TTL.
- Keep security layers in place. Caching speeds things up but does not protect the login page; see our guide to protecting your website with the Cloudflare WAF.
Let us tune it for you
Core Florida IT is an independent IT provider, not a Cloudflare partner. We configure Cloudflare caching, purging and WordPress integration as part of our performance optimization and web hosting management services. If your website feels slow or you are not sure what Cloudflare is actually caching, request a free IT assessment for your Miami-Dade or South Florida business.
Sources
- Default cache behavior (Cloudflare Docs)
- Cache Rules (Cloudflare Docs)
- Cache Rules settings (Cloudflare Docs)
- Order and priority of Cache Rules (Cloudflare Docs)
- Edge and Browser Cache TTL (Cloudflare Docs)
- Purge cache (Cloudflare Docs)
- Tiered Cache (Cloudflare Docs)
- Content compression (Cloudflare Docs)
- Polish (Cloudflare Docs)
- Cloudflare Images pricing and Free plan limits (Cloudflare Docs)
- Cloudflare cache responses (Cloudflare Docs)
- Cache Deception Armor (Cloudflare Docs)
- Page Rules migration guide (Cloudflare Docs)


