iFastHostingHow to stop caching breaking your cart
Cache the wrong page and one customer starts seeing another customer's basket — here is exactly what to exclude and why.
Page caching is one of the most effective speed improvements available on shared hosting, and it is also the single most common way a badly-configured store shows one customer's basket to somebody else. The mechanism behind that failure is simple once you see it, and avoiding it is entirely a matter of configuration rather than avoiding caching altogether.
Why caching and shopping carts are naturally in conflict
A full-page cache works by generating a page once and serving that same saved copy to every subsequent visitor, skipping the work of rebuilding it from scratch each time. That is exactly right for a homepage, a blog post, or a product listing — content that looks the same to everyone.
A cart, a checkout page, and a logged-in account page are the opposite: they are different for every single visitor, and they change every time that visitor does something. Cache one of those pages and you are not caching "the checkout" in the abstract — you are freezing one specific visitor's basket, address and totals, and then handing that frozen snapshot to the next person who happens to load the page.
Customers report seeing products in their basket that they never added. A total that never changes no matter what is added or removed. Being shown someone else's order confirmation, or someone else's account details. Every one of these has the same root cause: a session-specific page got served out of a shared cache.
How WooCommerce tries to prevent this
WooCommerce sets a cookie in the visitor's browser as soon as they have something in their cart, specifically to signal "this visitor now has session-specific content — do not serve them a cached page." A caching plugin or a CDN that correctly checks for this cookie will skip its cache for that visitor and generate the page fresh.
The catch is that "correctly checks for this cookie" is not automatic. Many caching plugins and most CDN-level page caching only respect that cookie when it has been explicitly told to — added to a cookie exclusion list, or configured as a "bypass cache" rule. Installing a caching plugin with its defaults and assuming WooCommerce compatibility is handled is the single most common way this goes wrong.
The pages that must never be served from a full-page cache
| Page | Why it must be excluded |
|---|---|
| Cart | Shows the contents of one specific visitor's basket. |
| Checkout | Shows basket contents, totals, and payment fields tied to one visitor's session. |
| My Account | Shows order history, saved addresses and account details for whoever is logged in. |
| Any page with a session-dependent element | A "recently viewed" widget, a logged-in-only notice, or a personalised recommendation block all break the same way if the page around them is cached. |
Everything else on a typical store — the shop page, individual product pages, category pages, the blog — is safe to cache normally and benefits considerably from it. The exclusion list above is short and specific; it is not an argument against caching the rest of the store.
How to configure the exclusion correctly
-
Open your caching plugin's exclusion settings
Most caching plugins have a section for URLs, pages or cookies to exclude from the cache. The exact wording varies by plugin, but look for "excluded pages", "cache exceptions" or "do not cache".
-
Add the cart, checkout and my-account pages by URL
WooCommerce creates these as ordinary pages during setup, so their URLs are visible in your Pages list. Add each one explicitly rather than assuming a plugin's WooCommerce-aware default already covers it.
-
Confirm the plugin respects the WooCommerce cart cookie
Many caching plugins have a specific toggle for WooCommerce compatibility, separate from the general exclusion list. Turn it on if it exists rather than relying on manual exclusions alone.
-
Test as two different visitors at once
Add different products to the cart in a normal browser window and a private/incognito window at the same time. If the two baskets ever show the same contents, caching is still interfering and the exclusion has not fully taken effect.
A CDN caches at a layer in front of WordPress entirely, which means a plugin-level exclusion inside WordPress will not help if the CDN itself is caching the page before the request even reaches your server. Check the CDN's own page rules for the same cart, checkout and account URLs.
Object caching is a different thing and is safe
Everything above is about full-page caching — saving an entire rendered HTML page. Object caching, which speeds up repeated database queries without freezing a whole page for every visitor, does not carry the same risk and is generally safe to leave on for a store. If you are unsure which type of caching a setting controls, check with your caching plugin's documentation before assuming.
Getting this right is one part of keeping a growing catalogue fast without breaking checkout — see how to keep an online store fast as it grows for the rest of it, and this is also the first thing to double-check before a high-traffic event — preparing a store for a sales rush covers that.
Related reading
A store that was fast on launch day slows down for specific, fixable reasons as the catalogue and the order history grow.
How to fix a WooCommerce checkout that failsA broken checkout loses money every hour it stays broken, so work through the common causes in order rather than guessing.
How to secure an online storeA store is a bigger target than a brochure site because there is more to steal and more ways in — here is where to focus first.
How to prepare a store for a sales rushThe traffic your store handles fine on a normal Tuesday is not the traffic it needs to survive on the one day everyone shows up at once.