Page caching is one of the fastest wins you can apply to a WordPress site. But WooCommerce is not a standard WordPress site β€” and if you enable full-page caching without the right exclusions, you will break your store. Broken carts. Empty checkouts. Login sessions that vanish. Wrong prices on product pages.

This guide tells you exactly which pages to exclude from caching in WooCommerce, why each exclusion matters at a technical level, and how to configure the most popular caching plugins correctly. If you have already read the 90+ PageSpeed Score guide, consider this the WooCommerce-specific layer on top of everything covered there.

Why WooCommerce and Page Caching Conflict

Page caching saves a static HTML snapshot of a page and serves that snapshot to every visitor β€” bypassing PHP execution and database queries entirely. That is what makes it fast.

The problem is that WooCommerce pages are inherently dynamic and user-specific. The cart page must show your items. The checkout page must verify your session. The My Account page must pull your order history. Serve a cached snapshot to the wrong visitor and the data is either stale, incorrect, or β€” in edge cases β€” someone else’s.

This is also why generic WordPress speed advice does not map cleanly to WooCommerce stores. Techniques like aggressive full-page caching that work perfectly on a blog will silently break a store. If you want the full picture on what separates safe from unsafe optimisations, the WordPress speed optimisation code snippets post covers the no-plugin layer β€” this post covers the caching configuration layer.

The Core WooCommerce Exclusion List

WooCommerce designates specific pages during installation under WooCommerce β†’ Settings β†’ Advanced β†’ Page setup. These pages carry session data, security tokens, or user-specific content and must never be served from a static cache.

1. Cart Page β€” /cart/

The cart page reads live session data to render items, quantities, applied coupons, and subtotals. It also displays persistent WooCommerce notices (“Coupon applied”, “Item removed”) that are generated dynamically by PHP on each request.

What breaks without exclusion: Cart contents appear empty or frozen. Add-to-cart actions do not reflect. Mini-cart widgets in the header stop updating. Coupons appear to apply but the discount never shows.

# Nginx β€” exclude cart from cache
location ~* ^/cart/ {
    set $skip_cache 1;
    set $skip_reason "WooCommerce cart";
}

2. Checkout Page β€” /checkout/

The checkout page generates a nonce β€” a one-time cryptographic token used to validate the order form submission and prevent CSRF attacks. If a cached version of the checkout page is served, the nonce is stale. WooCommerce rejects the order with an error such as “Your session has expired” or “Invalid security token”.

What breaks without exclusion: Customers cannot complete orders. Payment gateway fields may not load. Address fields prefilled from user accounts fail to populate. Order submission returns a security error.

# Nginx β€” exclude checkout from cache
location ~* ^/checkout/ {
    set $skip_cache 1;
    set $skip_reason "WooCommerce checkout nonce";
}

3. My Account Page β€” /my-account/

The My Account page and all its sub-pages (/my-account/orders/, /my-account/downloads/, /my-account/edit-account/) display user-specific data pulled from the database at request time. They also contain login and registration forms with nonces.

What breaks without exclusion: Logged-in users see each other’s order history in misconfigured setups. Logout links stop working. Password reset forms return token errors. In worst-case scenarios, a guest is served a cached authenticated account page β€” a security incident, not just a bug.

# Nginx β€” exclude My Account and all sub-pages
location ~* ^/my-account/ {
    set $skip_cache 1;
    set $skip_reason "WooCommerce my account";
}

4. Order Received / Thank You Page β€” /checkout/order-received/

The order confirmation page is generated after a successful purchase. It displays the unique order number, purchased items, and payment status. If this page is cached after the first order and served to a subsequent visitor, they see someone else’s order confirmation β€” which also means exposing their name, address, and purchase details.

What breaks without exclusion: Wrong order details shown post-purchase. Email confirmation links land on a cached page showing a different order. Analytics and conversion tracking fire incorrectly for repeat visitors.

# Nginx β€” exclude order received page
location ~* ^/checkout/order-received/ {
    set $skip_cache 1;
    set $skip_reason "WooCommerce order confirmation";
}

5. Add-to-Cart Query Strings β€” /?add-to-cart=

When a product is added to the cart via a URL query string (common with external affiliate links and WooCommerce shortcode buttons), the URL carries the product ID as a parameter. If this URL is cached, every subsequent visitor hitting that URL adds the same product to their cart β€” or worse, lands on a stale cached state.

What breaks without exclusion: Cart manipulation bugs on linked product pages. “Added to cart” notices disappear. Quantity increments misfire.

# Nginx β€” exclude add-to-cart query strings
if ($query_string ~* "add-to-cart=") {
    set $skip_cache 1;
}

Cookies That Signal “Do Not Cache”

Beyond specific URLs, WooCommerce sets browser cookies that indicate an active session. Any request carrying these cookies should bypass the cache entirely β€” you are dealing with a logged-in user or an active cart, not an anonymous guest.

Cookie What It Signals Cache Action
woocommerce_cart_hash Cart has items Bypass cache
woocommerce_items_in_cart At least one item in cart Bypass cache
wp_woocommerce_session_* Active WooCommerce session Bypass cache
wordpress_logged_in_* User is logged in Bypass cache
wordpress_sec_* Secure logged-in session Bypass cache

Most caching plugins handle WordPress login cookies automatically. The woocommerce_cart_hash and session cookies are WooCommerce-specific and need to be added manually in some plugins β€” double-check your configuration.

Plugin-by-Plugin Configuration

WP Rocket

WP Rocket automatically excludes WooCommerce Cart, Checkout, and My Account pages when WooCommerce is detected. It also auto-adds woocommerce_cart_hash and woocommerce_items_in_cart to its cookie exclusion list.

What to verify manually:

  • Go to WP Rocket β†’ Advanced Rules β†’ Never Cache These Pages and confirm /cart/, /checkout/, /my-account/ are present.
  • Go to WP Rocket β†’ Advanced Rules β†’ Never Cache Cookies and confirm woocommerce_cart_hash and wp_woocommerce_session_* are listed.
  • Add /checkout/order-received/ manually β€” WP Rocket does not always auto-detect this sub-page.

LiteSpeed Cache

LiteSpeed Cache includes a WooCommerce compatibility module. Enable it under LiteSpeed Cache β†’ WooCommerce.

What to verify manually:

  • Enable Instant Click only after confirming cart pages are excluded β€” Instant Click prefetches pages on hover and will prefetch cart/checkout if not properly excluded.
  • Under LiteSpeed Cache β†’ Cache β†’ Excludes, add /checkout/order-received/ and /?add-to-cart= URI strings.
  • Cookie exclusions: confirm woocommerce_* and wp_woocommerce_session_* are in the do-not-cache cookie list.

W3 Total Cache

W3 Total Cache does not auto-detect WooCommerce pages. Every exclusion must be configured manually.

Go to Performance β†’ Page Cache β†’ Advanced β†’ Never Cache The Following Pages and add:

cart
checkout
my-account
checkout/order-received

Under Performance β†’ Page Cache β†’ Advanced β†’ Reject Cookies, add:

woocommerce_cart_hash
woocommerce_items_in_cart
wp_woocommerce_session_

FlyingPress

FlyingPress detects WooCommerce automatically and excludes Cart, Checkout, and My Account pages on activation. It also supports Cache Invalidation on Stock Change β€” a useful WooCommerce-specific feature that clears product page cache when stock levels drop to zero.

What to verify manually: Confirm the order-received page and add-to-cart query strings are excluded under FlyingPress β†’ Cache β†’ Exclude URLs.

What You CAN Safely Cache in WooCommerce

Excluding the pages above does not mean you give up performance gains on the rest of the store. The following pages are safe to cache aggressively for anonymous (non-logged-in, empty-cart) visitors:

  • Shop / Archive pages β€” /shop/, /product-category/ β€” safe for anonymous visitors. Invalidate when prices or stock change.
  • Individual product pages β€” cache for anonymous visitors. Use short TTLs (15–30 minutes) on stores with frequent stock updates.
  • Blog posts and static pages β€” full aggressive caching is safe here with long TTLs.
  • Tag and category archive pages β€” safe to cache; low churn.

The practical architecture is: cache everything, then punch holes for the pages and cookies listed above. Most caching plugins implement this as an exclusion-first model β€” cache all, skip when rules match.

For a deeper look at how this connects to your PageSpeed score, see the full 90+ PageSpeed developer guide β€” caching is one layer; server configuration, asset delivery, and Core Web Vitals are the rest.

Object Caching vs Page Caching β€” Know the Difference

Page caching (what this entire post covers) stores complete HTML outputs. Object caching stores the result of individual database queries in memory (via Redis or Memcached) so they do not need to be re-executed.

Object caching is safe on all WooCommerce pages β€” including Cart, Checkout, and My Account β€” because it caches the database query result, not the rendered HTML. The page itself is still generated fresh per visitor; the expensive database calls are just answered from memory instead of running again.

For WooCommerce stores with high traffic or complex product catalogues, combining page caching with cookie-based bypass + Redis object caching is the highest-performance architecture available without moving to a headless setup.

Core Web Vitals Impact of Getting This Right

A correctly cached WooCommerce store sees measurable improvements across all three Core Web Vitals. Cached pages eliminate server processing time and dramatically reduce TTFB β€” which directly feeds into your LCP (Largest Contentful Paint) score. Google’s current LCP threshold for a “good” rating is under 2.5 seconds.

Getting caching wrong, however, has the opposite effect: broken pages, failed navigations, and JavaScript errors all contribute to poor INP (Interaction to Next Paint) scores and increased CLS. If you are actively working on INP, the dedicated guide to INP optimisation for WordPress covers exactly how to diagnose and fix interaction delays. And if CLS is your current issue, the Visual Stability Index guide walks through layout shift debugging in depth.

Quick Reference: WooCommerce Cache Exclusion Checklist

  • /cart/ β€” excluded from page cache
  • /checkout/ β€” excluded from page cache
  • /my-account/ and all sub-pages β€” excluded from page cache
  • /checkout/order-received/ β€” excluded from page cache
  • /?add-to-cart=* query strings β€” excluded from page cache
  • woocommerce_cart_hash cookie β€” triggers cache bypass
  • woocommerce_items_in_cart cookie β€” triggers cache bypass
  • wp_woocommerce_session_* cookie β€” triggers cache bypass
  • wordpress_logged_in_* cookie β€” triggers cache bypass
  • WooCommerce compatibility mode enabled in your caching plugin

Final Notes

Caching exclusions are not a set-and-forget configuration. Every time you add a new plugin that introduces session-dependent pages (membership areas, subscription portals, wishlists), revisit your exclusion list. The pattern is always the same: if the page content changes per visitor or per session, it does not belong in the cache.

If your store is still slow after getting caching right, the performance ceiling is usually at the server level β€” PHP workers, database query time, or TTFB from the host itself. The no-plugin speed optimisation snippets are the next logical place to look, particularly the database query reduction and PHP bloat removal sections.

And if you have been hacked and suspect the cache is serving injected content, the WordPress redirect hack fix guide and the hacked site diagnosis guide are essential reading before you spend time optimising performance.