Weekly ecommerce tips, deals & news.
A cache conflict happens when a saved copy of a page is shown where a live, personal page was needed. On an online store, the shopper sees an old cart, a stale price, or a coupon that won’t apply. The page looks normal, but the information on it belongs to an earlier moment or another visitor.
A cache conflict works by answering a shopper with a page saved earlier, instead of building a fresh one. For most pages that saving is a good thing, because it makes the store faster. The trouble starts when the saved page was meant for one person, at one moment.
A cache is like a photocopy of a menu kept at the front door. For example, handing out copies is faster than asking the kitchen each time. However, a photocopy can’t show today’s special if the special changed an hour ago.
A WooCommerce store usually has several of these photocopy points stacked on top of each other:
Each layer follows its own rules. As a result, a fix in one layer can leave the stale copy sitting in another.
Carts, checkouts, and coupons break first because they are different for every shopper. A product page looks the same to everyone. By contrast, a cart page holds one person’s items, totals, and discounts.
The web’s caching standard already has a word for this. RFC 9111 says a response marked “private” is meant for a single user. So a shared cache must not store it. A cache that ignores or overrides that signal hands one shopper’s page to the next.
WooCommerce’s own documentation tells caching tools to leave the Cart, My Account, and Checkout pages dynamic. It also names the cookies that mark an active shopper: woocommerce_cart_hash, woocommerce_items_in_cart, and wp_woocommerce_session_. However, when a cache skips those rules, the store loses track of who is shopping.
Coupons feel it sharply. Advanced Coupons’ guide to a WooCommerce coupon not working warns about cached cart and checkout pages. In that case, coupons can “fail or behave inconsistently.” Plus, security tokens called nonces add another risk. A cached form can carry an expired token that the server then rejects.
A cache conflict tends to show itself through problems that come and go, depending on who is looking. That’s the clue that separates it from a plain bug. The most common signs are:
Even so, admins often miss these signs completely. That’s because many caching tools skip logged-in users, so the owner always sees the live page.
Stopping a cache conflict starts with a list of every cache layer your store uses. Most owners know about their caching plugin. However, fewer know their host or CDN runs a second cache on top.
Next, add the same exclusions to each layer. Exclude the cart, checkout, and my-account URLs, and skip caching when the WooCommerce cookies are present. Then purge every layer, starting closest to the server and ending at the CDN.
Finally, test like a customer. Open a private browser window, stay logged out, add a product, and apply a code. In practice, this one habit catches most conflicts before shoppers do.
No public study counts cache conflicts on their own. So the evidence comes from what they damage: errors and speed. Baymard Institute’s checkout research found 17% of shoppers abandoned an order because the website had errors or crashed. A cart that forgets its items is exactly that kind of error.
On the other side, caching exists for good reason. Deloitte studied mobile sites across retail and other verticals. It found that a 0.1-second speed gain lifted retail conversions by 8.4%.
Meanwhile, shared caches keep spreading. The HTTP Archive’s Web Almanac found the top 1,000 websites have the highest CDN usage at 70%. Every one of those CDNs is another layer that needs the right exclusions.
What these numbers don’t settle is how often caching is the cause. They only show that errors cost sales, and that switching caching off costs speed.
A cache conflict in practice looks like a sale where the discount works for the owner but fails for customers. Here’s a hypothetical example.
Imagine a candle shop called Harbor & Pine that runs a weekend sale. The owner emails a 20% off code and a URL coupon link that applies it automatically.
First, some background: a month earlier, the shop moved to a faster host. The new host switched on its own page cache by default. Meanwhile, the shop’s caching plugin still held its original exclusions, so the owner assumed everything was covered.
Then the owner tests the link while logged in. The discount applies, the cart looks right, and the email goes out to 4,000 subscribers.
By Saturday morning, support emails start arriving. Some customers see an empty cart after adding candles. Meanwhile, others see the coupon rejected with a session error.
The host’s cache had saved a copy of the cart page for the first logged-out visitor. After that, every other shopper was served that same stale page. Worse still, the cached checkout form carried a security token that had since expired.
Harbor & Pine normally takes about 60 orders on a sale weekend. This weekend it takes 38. At an average order of $45, those 22 missing orders cost roughly $990. On top of that, the owner spends Sunday answering 14 support emails.
The owner runs the private-window test and finally sees the problem. First, they add cart, checkout, and my-account exclusions to the host cache, matching the plugin. Next, they tell the host cache to skip visitors carrying the WooCommerce cart and session cookies.
Then they purge the plugin cache, the host cache, and the CDN, in that order. This time, a logged-out test shows the right cart and the discount. As a result, Harbor & Pine extends the sale by a day, and orders return to normal.
A cache conflict serves an old copy of a page. By contrast, a plugin conflict is two pieces of code clashing live.
| What you’re comparing | Cache Conflict | Plugin Conflict |
|---|---|---|
| Root cause | A saved page shown to the wrong shopper | Two plugins’ code interfering with each other |
| Who sees it | Mostly logged-out shoppers, on and off | Everyone, every time the clash triggers |
| Quickest test | Purge all caches, then retest logged out | Deactivate plugins one at a time |
| Usual fix | Cache exclusions on every layer | Update, replace, or reconfigure a plugin |
The cache-clear test tells them apart. If purging every cache fixes the problem, even briefly, caching is the cause. If the problem survives a full purge, work through Advanced Coupons’ basic debug routine and disable plugins one by one.
That said, the two can also overlap. For example, a caching plugin can be one side of a plugin conflict. Still, starting with the purge saves time, because it takes minutes rather than an afternoon.
A coupon that works for you but not for customers usually points to a cache conflict. Many caching tools skip logged-in users, so admins always see a fresh page. Customers, however, may get a cached cart or checkout. Test the code in a private window while logged out to see what shoppers see.
The cart, checkout, and my-account pages should never be cached, because they show one customer’s details. WooCommerce also recommends skipping the cache when its cart and session cookies are present. Apply these exclusions on every layer, including your host and CDN, not just your caching plugin.
Turning off caching completely will usually slow your store down, so it’s rarely the right fix. In fact, product and category pages benefit most from caching. The better approach is to keep caching on and exclude only the personal pages. That way shoppers get speed where it helps and live data where it matters.
Cache conflicts matter because they break the exact pages where money changes hands, while hiding from the owner. A store can look perfect from the admin account and still fail at checkout for real shoppers. Getting the exclusions right keeps both the speed and the sale.
Copyright © StoreOwnerTips.com. All Rights Reserved.
