If you have ever opened your browser’s developer tools and checked the response headers on a Cloudflare-proxied WooCommerce page, you have almost certainly seen this: cf-cache-status: DYNAMIC. That single header tells the whole story. Cloudflare received the request, routed it to your origin server, and passed the response straight back to the browser — no edge cache involved, no performance benefit beyond basic DDoS protection and TCP optimization.
For a WooCommerce store serving customers in Southeast Asia from a US-based origin, that means every uncached page load crosses the Pacific. Latency compounds. Conversion rates drop. And your origin server bears every hit regardless of how repetitive the traffic is.
The good news: Cloudflare can cache your HTML at the edge and serve it from the nearest Point of Presence — Singapore, Frankfurt, Chicago, wherever the visitor is. First-byte time drops from well over a second to tens of milliseconds at the edge. The fear holding most store owners back is breaking checkout, cart, or the logged-in session. This guide shows you precisely how to solve that, safely.
Why Cloudflare Does Not Cache HTML by Default
Cloudflare’s default behavior is conservative by design. For most content types — images, CSS, JavaScript, fonts — it caches aggressively. For HTML, it does not, because HTML pages are frequently personalized: they may contain cart counts, account names, CSRF tokens, or pricing variations. Caching the wrong response and serving it to the wrong visitor creates serious correctness problems.
The cf-cache-status: DYNAMIC header signals that the response bypassed the cache entirely. MISS means Cloudflare checked the cache, found nothing, fetched from origin, and stored the result. HIT means the response was served from the edge without touching your origin. Your goal is to reach HIT on guest-facing pages while keeping cart, checkout, and account pages always DYNAMIC or BYPASS.
Two Paths to Edge HTML Caching: APO vs Cache Rules
Cloudflare offers two distinct approaches for caching WordPress and WooCommerce HTML at the edge. Understanding the trade-offs helps you choose the right tool for your infrastructure.
| Feature | No Edge Cache | Cache Rules (Free+) | APO for WordPress |
|---|---|---|---|
| Cost | Included | Included on Free plan | $5/month per zone |
| HTML cached at edge | No | Yes (with rules) | Yes (automatic) |
| WooCommerce awareness | N/A | Manual cookie/path rules | Built-in bypass logic |
| Cache invalidation on publish | N/A | Manual or API | Automatic via WordPress plugin |
| Edge TTL control | N/A | Full control | Managed by Cloudflare |
| Requires WordPress plugin | No | No | Yes |
| Best for | — | Dev control, cost-sensitive | Simpler setup, larger stores |
APO (Automatic Platform Optimization) is Cloudflare’s managed solution. After installing the official WordPress plugin, APO automatically caches HTML globally, purges on post updates, and has built-in awareness of WooCommerce cookies. It is the lower-effort path, and at $5/month it is cost-effective for most stores.
Cache Rules give you full control at no additional cost. They work on any Cloudflare plan, do not require a WordPress plugin, and let you tune every detail: which paths cache, at what TTL, and exactly which cookies trigger a bypass. For teams managing multiple zones or requiring precise infrastructure control, Cache Rules are the right choice.
This guide focuses on the Cache Rules approach because it is more instructive — understanding it also helps you reason about what APO is doing under the hood.
The Safe Cache Rules Pattern for WooCommerce
The core insight is simple: WooCommerce communicates session and cart state entirely through cookies. A guest visitor browsing your homepage, category pages, or product pages carries none of those cookies. An authenticated shopper — or anyone who has added something to their cart — carries them. You cache only for the guests.
You will create two Cache Rules in your Cloudflare dashboard under Caching > Cache Rules. Rule ordering matters: Cloudflare evaluates rules in order and the last matching rule wins. Place Rule A (cache) first and Rule B (bypass) second, so the bypass always overrides when the conditions are met.
Rule A — Enable Edge Caching for Guest HTML
This rule activates edge caching for standard GET and HEAD requests that do not carry any session-related cookies. Configure it as follows:
- When: Request method is GET or HEAD
- And: Cookie does not contain
wordpress_logged_in_,wp_woocommerce_session_,woocommerce_cart_hash,woocommerce_items_in_cart, orcomment_author - Then — Cache eligibility: Eligible for cache
- Then — Edge TTL: Override origin, set to 4 hours (14400 seconds)
- Then — Browser TTL: Respect origin Cache-Control headers
Four hours is a pragmatic starting TTL for most stores. Product pages and categories do not change every few minutes. You can increase it for purely editorial content like blog posts. Adjust downward if your store has time-sensitive promotions.
Rule B — Bypass Cache for Dynamic WooCommerce Paths and Sessions
Rule B must match any request that could return personalized or session-dependent content. Because it is evaluated after Rule A, it overrides the cache instruction for all matching requests.
- When any of the following are true:
- Cookie contains
wordpress_logged_in_orwp_woocommerce_session_orwoocommerce_cart_hashorwoocommerce_items_in_cartorcomment_author - URI path starts with
/cart,/checkout,/my-account,/wp-admin,/wp-login.php, or/wp-json - Query string contains
add-to-cart - Then — Cache eligibility: Bypass cache
The /wp-json bypass is important if you use the REST API for any front-end functionality — WooCommerce Blocks relies on it heavily. The add-to-cart query string bypass ensures that redirect URLs from simple products never get cached mid-flow.
Vilee LLC combines deep technical expertise in WordPress/WooCommerce development with AI-powered automation to operate 520+ profitable online businesses at scale.
Additional Cloudflare Settings Worth Enabling
Cache Rules alone are not the complete picture. Three additional Cloudflare settings compound the performance gain significantly:
- Tiered Cache: Enable this under Caching > Tiered Cache. Instead of every edge node going to origin on a cache miss, a smaller set of upper-tier nodes acts as an intermediate cache. This dramatically improves cache hit ratios on lower-traffic zones and reduces origin load on cache purge events.
- Brotli compression: Enable under Speed > Optimization. Brotli achieves meaningfully better compression ratios than gzip on HTML and text assets, reducing transfer size without any additional server load — Cloudflare applies it at the edge.
- HSTS max-age: Under SSL/TLS > Edge Certificates, set HSTS max-age to at least one year (31536000 seconds). The Cloudflare default is a conservative low value. A long max-age eliminates the redirect from HTTP to HTTPS on repeat visits, saving one full round trip on every returning visitor’s session establishment.
Why This Is Safe for WooCommerce
The safety guarantee comes from how WooCommerce manages session state. Every action that makes a page personalized — logging in, adding a product to the cart, leaving a comment — results in a cookie being set on the browser. Those cookies are present on every subsequent request from that visitor.
Rule B checks for those exact cookies before any response is served from the edge cache. If any matching cookie exists, Cloudflare routes the request to your origin, guaranteed. The edge cache never sees a logged-in or active-cart session.
What does get cached are the pages a first-time or anonymous visitor sees: your homepage, product category listings, individual product pages (before any add-to-cart action), and blog posts. These pages are identical for every such visitor. Caching them at the edge is not just safe — it is the correct behavior.
For a store with international traffic, the practical effect is substantial. A visitor in Singapore requesting a category page no longer waits for a round trip to a US-based origin server. They receive the response from Cloudflare’s Singapore PoP, with first-byte time in the tens of milliseconds rather than over a second. That difference in perceived responsiveness directly affects bounce rate and conversion.
How to Verify Your Configuration
After deploying the rules, verification is straightforward using your browser’s developer tools or a command-line tool like curl. You are looking for the cf-cache-status response header on every request type.
- Guest homepage or category page (no cookies): First request should return
cf-cache-status: MISS— Cloudflare fetched from origin and stored the response. Subsequent requests from other edge nodes will returnHIT. You can force a clean check with a private browsing window or by usingcurl -I https://yourstore.com/shop/. - /cart page: Should always return
cf-cache-status: BYPASSorDYNAMIC, confirming Rule B is matching the path correctly. - /my-account page: Same as above — always
BYPASSorDYNAMIC. - Any page visited while logged in: Add a product to your cart, then browse your homepage. The
wordpress_logged_in_orwoocommerce_items_in_cartcookie is now present. The homepage request should returnBYPASS, notHIT. - After a cache purge: Cloudflare > Caching > Configuration > Purge Everything, then re-request a guest page. You should see
MISSon the first request andHITon subsequent requests from the same region.
If you are seeing DYNAMIC on pages that should be HIT, the most common cause is an unexpected cookie being set by a plugin — analytics scripts, chat widgets, or A/B testing tools sometimes write first-party cookies on page load. Audit your cookie footprint using the Network panel in Chrome DevTools and add any unexpected cookies to Rule B’s bypass condition.
Putting It Into Production
The Cache Rules approach described here requires no changes to your WordPress installation, no additional plugins, and no modifications to your origin server configuration. Everything is configured at the Cloudflare zone level. That makes it easy to test, easy to roll back, and simple to replicate across multiple WooCommerce zones.
For stores already using a server-side page cache — such as WP Rocket, LiteSpeed Cache, or W3 Total Cache — Cloudflare edge caching is additive, not redundant. Server-side caching reduces origin PHP execution time. Cloudflare edge caching reduces the geographic distance between the cached response and the visitor. Both layers contribute independently to overall performance.
If your store operates across the US, EU, and Southeast Asia markets — the three regions Vilee serves — the edge caching layer is particularly valuable. Cloudflare’s network spans all three regions densely, meaning cached HTML reaches international visitors with minimal latency regardless of where your origin server sits.
Want an expert review of your Cloudflare configuration, WooCommerce performance stack, or overall infrastructure? Explore our services, see how the platform supports multi-market WooCommerce operations, or contact us to talk through your specific setup.
Frequently Asked Questions
Will Cloudflare edge caching break my WooCommerce checkout?
No — when configured correctly using Cache Rules with cookie-based bypass conditions, Cloudflare will never serve a cached response to a visitor with an active cart or logged-in session. The bypass rule checks for WooCommerce session cookies (wp_woocommerce_session_, woocommerce_cart_hash, woocommerce_items_in_cart) and WordPress authentication cookies (wordpress_logged_in_) on every request. If any of those cookies are present, the request goes directly to your origin. Only truly anonymous, session-free requests are served from the edge cache.
Should I use Cloudflare APO or Cache Rules for my WooCommerce store?
APO (Automatic Platform Optimization) is the easier path — it handles cache invalidation automatically when you publish or update content, and it has built-in WooCommerce awareness. It costs $5/month per zone. Cache Rules are free, give you more granular control, and do not require a WordPress plugin, but you are responsible for cache invalidation (manually or via the Cloudflare API). For most stores, APO is worth the cost for the operational simplicity. For teams managing many zones or needing precise custom logic, Cache Rules are the better fit.
How do I check if Cloudflare is actually caching my WooCommerce HTML?
Open your browser’s developer tools (F12), go to the Network tab, and click on any HTML page request. Look for the cf-cache-status response header. A value of HIT means the response was served from Cloudflare’s edge cache — your origin was not contacted. A value of MISS means Cloudflare fetched from origin but stored the response for future requests. BYPASS or DYNAMIC means the cache was intentionally skipped, which is the correct result for /cart, /checkout, and /my-account pages. You can also use curl -I https://yourstore.com/ from the command line to inspect headers without browser interference.
