When Caching Breaks the Cart and Checkout
A wrong cart count, stale prices or a login loop usually means a page that should be dynamic was cached. Here is how to test it in two minutes and fix it, with what we saw on a real Kinsta WooCommerce site.
Written by Tom George · How we research hosts
The Problem: Speed Tools That Cache the Wrong Page
Caching makes a site fast by saving a finished page and handing the same copy to everyone. That works for a blog post. It is a problem for a cart, because the copy has to be different for every customer.
WooCommerce's developer documentation says the Cart, My Account and Checkout pages need to stay dynamic, because they display information specific to the current customer and their cart. When one of them gets cached, the failure is easy to recognize but hard to trace.
The usual symptoms are a cart that shows the wrong number of items, a checkout that shows out-of-date prices or stock, and logged-in users who are sent back to the login page. Those are what a cached copy of a personal page looks like. Below is how to prove the cause and fix it, in the order we would check.
Test the headers before you change settings. One request to the cart and checkout URLs tells you whether a cache is serving them, and saves guessing between your plugin, your host and your CDN.
Never accept "HIT" on cart, checkout or My Account. Those pages should bypass the cache for every visitor.
Running a busy store? See our high-volume WooCommerce hosting comparison.
What the Official Documentation Says
WooCommerce's documentation on configuring caching plugins gives three rules, and everything else follows from them.
- Exclude three pages: Cart, My Account and Checkout, because they are specific to the current customer.
- Key on one cookie:
woocommerce_items_in_cart, a session cookie that helps WooCommerce determine when cart contents change. - Handle add-to-cart URLs: its Varnish example passes requests for
cart,my-account,checkoutandaddonspaths, and any URL containing?add-to-cart=, straight through to the server instead of serving them from cache.
The same page notes that some plugins already do this for you. WP Super Cache, for example, receives information from WooCommerce so that it does not cache the Cart, Checkout or My Account pages by default. With WP Rocket, the documentation asks you to make sure those pages are excluded in its settings.
Step 1: Test the Headers on Every Layer
Request the cart page, then the checkout, then My Account, and read the cache header on each. You can use your browser's network tab or curl:
curl -sI https://yourstore.com/cart/ | grep -i -E 'cache|age|set-cookie'
Header names depend on your host and CDN. On Kinsta, x-kinsta-cache returns HIT, MISS or BYPASS. Behind Cloudflare, cf-cache-status reports the CDN's view. A plugin may add its own header. Check every layer you have, because a page can be fresh at the host and stale at the CDN.
The cart, checkout and My Account pages should show BYPASS, DYNAMIC or no cache hit at all. If any shows HIT, you have found the problem.
What we saw on a real Kinsta store
When we ran our WooCommerce test site on Kinsta in September 2026, we checked x-kinsta-cache directly. The Shop archive returned BYPASS on every request, with and without cookies, while ordinary non-WooCommerce pages on the same site returned HIT. Across a 2,220-request load test, every response was BYPASS.
Kinsta's own documentation explains part of that behavior: it states that cart, my-account and checkout pages are automatically excluded from caching, with a server-level rule that bypasses the cache when the woocommerce_items_in_cart cookie is present. Why our Shop archive also bypassed with no cookies is not covered by that documentation, so it remains our inference, as we say in the full test write-up.
Step 2: Find Which Layer Is Caching It
Turn layers off one at a time, and retest after each change.
- Caching plugin. Open its exclusion settings and confirm the Cart, Checkout and My Account pages are excluded, and that the
woocommerce_items_in_cartcookie is on its "do not cache when present" list. - Host-level cache. Some hosts exclude these pages automatically, as Kinsta states it does. Others expect you to set it up, so ask your host how it treats the cart cookie.
- CDN rules. Any CDN rule that caches HTML pages needs the same exclusions. In our judgment, a broad "cache everything" rule is the most common way a store ends up caching a checkout by accident.
- Add-to-cart links. URLs with
?add-to-cart=should pass through uncached, as in WooCommerce's example.
Step 3: Fix It and Retest
Exclude the three pages, key your cache bypass on the cart cookie, and purge every cache afterwards. Purging matters: a bad copy that was cached earlier stays in place until it expires or you clear it.
Then test the way a customer would. Add an item in a private window, check the cart count, change the quantity, go to checkout, and confirm the totals and shipping options are right. Do it again as a logged-in user. Retest the headers on each URL.
Why Uncached Pages Are Slower and What Helps
Fixing the cache means your most important pages now run PHP and the database on every request. That is correct, but it makes your host matter more. A fast cached homepage tells you nothing about checkout speed.
- Measure the uncached pages specifically. Our TTFB guide shows how to test cached and uncached pages separately.
- Be careful with add-ons. Object caching such as Redis can help dynamic pages in theory. In our alternating on/off load test on a Kinsta WooCommerce site we saw no consistent effect, so measure your own store before you pay for it.
- Put the server near your customers. Pages that cannot be cached go to your origin, so distance matters. See our guide for visitors in India for the method.
Choosing a Host That Handles This Well
The difference between hosts here is whether the exclusions are built in and documented, or left to you. Kinsta documents automatic exclusion of cart, my-account and checkout. For every host, confirm the behavior with the header test, because documentation and your store's real setup can differ.
If you are comparing stores' needs more broadly, our high-volume WooCommerce hosting guide and WooCommerce hosting guide cover plans and limits. Read the Kinsta review and the Rocket.net review, which relies on edge caching and is worth testing carefully for cart behavior, and see our Kinsta vs Cloudways comparison.
Planning a move? Our zero-downtime switch checklist includes a freeze-and-sync step for stores.
Kinsta for WooCommerce → See Cloudways Plans →
Frequently Asked Questions
Which WooCommerce pages should never be cached?
WooCommerce's developer documentation says the Cart, My Account and Checkout pages need to stay dynamic, because they show information specific to the current customer and their cart.
Caching plugins often exclude them already, but you should confirm it.
What is the woocommerce_items_in_cart cookie?
It is a session cookie that helps WooCommerce determine when cart contents or data change.
WooCommerce's documentation lists it as the cookie to exclude from caching, which is why many caches skip the page cache for visitors who have it.
Does Kinsta cache the WooCommerce checkout?
No. Kinsta states that pages such as cart, my-account and checkout are automatically excluded from caching.
It also describes a server-level rule that bypasses the cache when the woocommerce_items_in_cart cookie is detected.
How can I tell if a page is being cached?
Check the response headers. On Kinsta, x-kinsta-cache shows HIT, MISS or BYPASS, and behind Cloudflare, cf-cache-status shows the same kind of status.
A cart or checkout page should never show HIT.
Can object caching like Redis fix a slow checkout?
It can help dynamic pages that skip the page cache, but the effect is not guaranteed.
In our own alternating on/off Redis test on a Kinsta WooCommerce site, we saw no consistent effect, so measure your own store before paying for it.
The Bottom Line
Cart, checkout and My Account must stay dynamic. Prove it with a header check on every layer, exclude the pages and the cart cookie, purge, and retest as a customer.
Then measure the uncached pages, because that is where your store's real speed shows up.
Sources: WooCommerce developer documentation, "How to configure caching plugins for WooCommerce" (developer.woocommerce.com), and WooCommerce Cookies documentation (woocommerce.com), both read October 2026. Kinsta, "WordPress Cookies and PHP Sessions" (kinsta.com/blog/wordpress-cookies-php-sessions/), read October 2026. Header checks and load test: our own Kinsta WooCommerce test site, September 24, 2026. The reason our Shop archive bypassed the cache without cookies is our inference.