A customer emails to say her cart showed three items she never added. Another says the header said “2 items” but the cart page was empty. Someone in another country saw prices in the wrong currency. Or nobody complains, but orders have dipped since you switched on caching last month, and you have a nagging feeling the two are connected.
Caching WooCommerce cart and checkout pages is the one area of speed work where a mistake costs money directly. A store needs caching to be fast, and it needs a few precise holes in that cache to work at all. Getting those holes right is not difficult once you know where they go, and a ten-minute test with two browsers tells you whether they work.
Symptoms that point to wrong caching
If you are seeing any of these, suspect caching first:
- Cart contents or the item count belonging to a different shopper.
- A cart that empties itself, or items that come back after being removed.
- The header mini cart and the cart page disagreeing.
- Prices, tax or currency that are right for one country and shown to visitors in another.
- “Your session has expired” or a security check error at checkout, or coupons that fail for no clear reason.
- Stock shown as available after it sold out, or sale prices still showing after the sale ended.
- A customer’s name or “My account” links showing to logged-out visitors.
Some of these have other causes too. Carts that empty on their own are covered in our post on WooCommerce carts emptying after adding products, which deals with session and cookie problems beyond caching. But when several symptoms appear together and started after a caching change, the cache is the place to look.
Why a store is harder to cache than a blog
A page cache, as described in our guide to the different website caches, stores one copy of a page and hands it to everyone. That works for a blog post, which is the same for every reader. Large parts of a shop are not the same for everyone.
WooCommerce tracks each shopper with a session, identified by cookies. As soon as someone adds something to the cart, those cookies tell WooCommerce whose cart to show. A page cache that ignores those cookies stores the first shopper’s version and serves it to the next. A cache that respects them steps aside and lets WooCommerce build the page fresh.
Product and category pages can usually be cached, as long as the personal parts, such as the mini cart in the header, are loaded separately. The cart, checkout and account pages cannot be cached at all.
WooCommerce cache exclusions: pages
These pages must never come from a page cache or a CDN’s HTML cache:
- Cart.
- Checkout, including the order received or thank-you page and the order payment page, which sit under the checkout address.
- My account, including all its sections: orders, addresses, account details, downloads.
Use the addresses actually assigned to those pages in your WooCommerce settings. If someone renamed “checkout” to “complete-order”, the exclusion has to match. Exclude the address as a prefix, so /checkout/ also covers everything beneath it.
Also exclude pages from plugins that behave like these: wishlists, quote request lists, compare lists, subscription management, booking pages showing availability, and any custom “track your order” page.
WooCommerce itself marks its cart, checkout and account pages as not to be cached, and most WordPress caching plugins respect that. Server-level caches and CDNs that cache HTML do not always look for it. That is why the exclusion needs to be set in every caching layer, not just the plugin.
WooCommerce cache exclusions: cookies
Page exclusions protect the cart and checkout. Cookie exclusions protect everything else, so a shopper with items in the cart is not served a cached product page with someone else’s mini cart. The cookies to bypass the cache for are:
- woocommerce_items_in_cart, set when the cart has items.
- woocommerce_cart_hash, which changes when cart contents change.
- wp_woocommerce_session_ followed by a unique code, the session cookie. Match it by its beginning.
- wordpress_logged_in_ followed by a code, for logged-in customers, unless you have deliberately set up separate logged-in caching.
Well-known caching plugins include these by default. Server caches and CDN rules usually need them added by hand. Check what your plugin’s documentation says it excludes rather than assuming.
Requests that must pass straight through
- Add-to-cart links. Addresses containing ?add-to-cart= followed by a product number must never be served from cache, or the click does nothing.
- WooCommerce AJAX requests. Addresses containing wc-ajax= handle cart updates, coupon checks and the mini cart refresh.
- Store API requests. Stores using the newer block versions of the cart and checkout send their requests through REST addresses starting with /wp-json/wc/store/. These are personal and must not be cached at the CDN.
- Payment gateway callbacks and webhooks. Gateways tell your store about successful payments by calling special addresses. A CDN or firewall rule that caches or blocks them leaves orders stuck as pending.
The mini cart refresh in particular, the “cart fragments” request, has its own speed questions. We cover what it does and whether to limit it in our post on WooCommerce cart fragments.
Prices, currency and location
This is where well-configured stores still go wrong. If the price shown depends on who is looking, a cached page shows whatever the first visitor saw:
- Geolocated tax. If WooCommerce works out the customer’s location to display tax-inclusive prices, ordinary page caching breaks that. WooCommerce has a geolocation option intended to work with page caching, which adds a parameter to addresses. Use that, or show the same price to everyone.
- Currency switchers. Check the plugin’s documentation for its caching instructions. Some add a cookie that must be used as part of the cache key, others load prices separately after the page appears.
- Role-based or wholesale pricing. Logged-in trade customers must never get cached retail pages, or the reverse.
- Stock and sale timers. Low-stock counts and countdowns go stale in a cached page. Shorter cache lifetimes for product pages, or purging when stock changes, help.
Caching WooCommerce cart and checkout across every layer
Stores often have three caches in a row: a caching plugin, the host’s server cache and a CDN. Each must exclude the same pages, cookies and requests. The common failure is a perfectly set up plugin behind a CDN rule that caches every page, which silently overrides everything below it. If you use Cloudflare, our post on Cloudflare caching rules for WordPress explains what it caches by default and how to keep HTML caching away from a store’s personal pages.
Look at the response headers on the cart page, logged out, with an item in the cart. Whichever caching headers appear should show a miss, bypass or “dynamic” result, never a hit.
Test with a real order before you trust it
Do this after any caching change, and after adding a payment, currency, pricing or shipping plugin.
- Open the shop in two different browsers, or one normal and one private window. Do not log in.
- In browser A, add two different products. Open the cart in browser B. It must be empty.
- In browser B, add a different product. Go back to browser A and reload. A’s cart must still show only its own two products.
- Check the header cart count matches the cart page in both browsers.
- Change a quantity and remove an item in browser A. Reload. The changes must stick.
- Apply a coupon in browser A. It should work, and browser B should not show it.
- Complete a test order in browser A, using a test payment mode or a manual payment method. Check the thank-you page shows A’s details and the cart is empty afterwards.
- Log in as a customer and check the account page shows that customer’s orders. Log out, reload, and check nothing personal remains.
- If prices vary by location or currency, repeat from a second location or with a VPN switched on.
Write down the date and what you tested. If a shopper reports a problem later, you will know whether it worked on that day.
What not to do
- Do not switch caching off for the whole store because the cart misbehaved once. Product and category pages are where visitors arrive, and they benefit from caching. Fix the exclusion.
- Do not cache logged-in customers unless you understand exactly how your setup separates them.
- Do not add CDN “cache everything” rules without bypass rules for WooCommerce cookies and pages.
- Do not rely on a single test in your own logged-in browser. You are almost certainly bypassing the cache.
A cached store is only part of a fast store, and our website loading speed guide shows what else matters for product and checkout pages that cannot be cached.
Frequently asked questions
Can I cache WooCommerce product pages?
Yes, in most stores. Product and category pages are the same for most visitors and benefit from caching. The cache must be bypassed for shoppers who already have items in the cart or are logged in, and pages that show location-based prices, wholesale prices or live stock counts need extra care or shorter cache lifetimes.
Why does the cart count in my header show the wrong number?
The header is often part of a cached page, so it can show the count from whoever visited first. WooCommerce normally refreshes the mini cart separately after the page loads. If that refresh is blocked, delayed by an optimisation setting, or cached itself, the header and the cart page disagree.
Can a recently viewed products widget work on a cached store?
Not in its usual form. A recently viewed widget built in PHP reads a cookie when the page is built, so on a cached page every visitor sees the list that was stored. Load that block separately after the page appears, use a version designed for caching, or remove it. Excluding whole category pages just for this costs more speed than it saves.
Is it safe to run a sale with page caching on?
It is generally safer than running without it, because cached product and category pages reduce the load on the server when traffic rises. Check the exclusions and run a full test order before the sale starts, purge the cache after changing prices, and avoid making caching changes during the sale itself.
Before a busy sale is a sensible time to have the cache rules checked across plugin, host and CDN. Stores with slow product or checkout pages are one of the cases our speed optimisation work for stores is meant for, and the checks are done with test orders rather than guesswork.
Next in this series: Cache Preloading Explained: Warm Up Your Website Cache
