WooCommerce Cache Rules Generator
Cache-bypass rules for Cloudflare, Nginx, LiteSpeed and Apache, covering cart, checkout, account and the Store API so shoppers never see someone else's page.
Your details
Cache bypass rules
(http.request.uri.path contains "/cart") or (http.request.uri.path contains "/checkout") or (http.request.uri.path contains "/my-account") or (http.request.uri.path contains "/wp-json/wc/store") or (http.request.uri.path contains "/wp-admin") or (http.request.uri.path contains "/wp-login.php") or (http.cookie contains "woocommerce_items_in_cart")
Cloudflare dashboard: Caching → Cache Rules → Create rule. Paste this into "Edit expression", then set the action to Bypass cache.
Fields, operators and actions checked against developers.cloudflare.com/cache/how-to/cache-rules/.
Why caching breaks WooCommerce (until you exclude the right pages)
A full-page cache is one of the biggest speed wins for a WordPress store, but cart, checkout, my-account and the block-based Store API endpoint (/wp-json/wc/store, used by the cart and checkout blocks) are personal to each shopper. Cache those and one customer can see another customer's cart, or a stale checkout total. This tool builds the bypass rules for the cache layer you actually run.
Cloudflare's syntax is checked against its own Cache Rules documentation: an expression like (http.request.uri.path contains "/cart") combined with the action Bypass cache.
Adding the rules
- Cloudflare: dashboard → Caching → Cache Rules → Create rule, paste the expression, set the action to Bypass cache.
- Nginx: add the
if/set $skip_cacheblock above your existingfastcgi_cache_bypassorproxy_cache_bypassline, thennginx -tand reload. - LiteSpeed Cache: LiteSpeed Cache → Cache → Excludes → "Do Not Cache URIs". LSCache already has built-in ESI support for the cart fragment, so this is mostly a backstop.
- Apache: adds a
Cache-Control: no-storeheader on the matched paths using mod_headers, which most page-cache plugins and CDNs both respect.
Pitfalls
- If you run a page-cache plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache), check its own "never cache these pages" setting too: some caching happens inside PHP, before Cloudflare or Nginx ever see the request.
- The Nginx snippet is a widely used community pattern for pairing WordPress with fastcgi_cache or proxy_cache, not a single official Nginx page, so check it against your existing cache zone directives before reloading.
- Test by adding an item to cart in one browser and an incognito window at the same time; if the cart count or contents ever leak between them, a cache layer somewhere isn't excluding these paths.
Questions people ask
Do I need this if I already use a caching plugin?
Most WordPress page-cache plugins (WP Rocket, LiteSpeed Cache) already exclude WooCommerce's dynamic pages automatically. This tool matters most for a separate edge layer like Cloudflare, or a hand-rolled Nginx cache, which doesn't know anything about WooCommerce on its own.
What's the Store API, and why does it need excluding too?
It's the REST endpoint (/wp-json/wc/store) the newer block-based cart and checkout use to fetch cart totals and update quantities. Cache it and shoppers can see a stale or someone else's cart total.
301 or 302 for the redirect... wait, this isn't a redirect tool?
Right, this generates cache bypass rules, not redirects. For redirects after a URL change, see the Nginx redirect generator.
Will this slow my site down by excluding too much?
No: only the specific paths you toggle on are excluded from caching. Everything else (product pages, the shop, blog posts) still caches normally.
Related tools
Last reviewed 30 September 2026.
Sources: Cloudflare Docs: Cache Rules
