Should I cache WooCommerce cart and checkout pages?

A shopping cart is different from a public article

A public article can usually show the same content to many visitors. A cart cannot: the items, quantities, shipping choices and customer details belong to one shopper. A shared full-page cache must not reuse that response for someone else.

Exclude the store's actual cart, checkout and account pages. If you have changed their slugs, check the pages assigned in WooCommerce rather than relying only on a plugin's default URL list.

Check every caching layer

Your WordPress plugin may bypass checkout correctly while a host-level cache or CDN still caches it. Review each layer that can store an HTML response. Use its WooCommerce integration or documented exclusions, including the required cart and session cookie rules.

Also check what happens after a shopper adds an item on a product page. Public pages can contain session-dependent elements, so excluding three URLs alone is not a complete caching configuration.

Static assets are a separate matter. Images, stylesheets and scripts can still benefit from appropriate caching. Object caching is also different from saving a finished HTML page, although the application and cache integration still need to handle data correctly.

Test two independent shopping sessions

Use separate browser profiles or isolated sessions. Put different items in each cart, change quantities and move between product, cart and checkout pages. Confirm that neither session sees the other's items or account information.

Check logged-out and logged-in behaviour, and repeat the checks after clearing and warming the caches. Use your payment gateway's test environment for any checkout test that reaches payment; there is no need to charge a real customer to check page caching.

If cart information becomes stale or appears in the wrong session, disable the affected HTML caching rule while investigating. Faster responses are only useful when the store shows the right information.