WooCommerce Caching Done Properly: The Exclusions That Let You Cache Everything Else

WooCommerce caching goes wrong more often from caching too little than from caching too much. The cautious setup is the expensive one.

Almost every guide on the subject is written as a warning. Here is the list of things caching will break; here is what to switch off. Good luck.

Store owners read it, get nervous, exclude half the store, and end up paying for a caching layer that barely does anything.

Meanwhile, the Deloitte and Google study Milliseconds Make Millions found that a 0.1 second improvement in mobile site speed was associated with an 8.4% lift in retail conversion rate and a 9.2% lift in average order value across 37 brands.

Undercaching does not show up in any report. It just quietly costs you the lift.

The working posture is the opposite one. Cache hard wherever the page looks identical to every visitor, and bypass precisely, at every layer, where it does not.

The bypass list is shorter than most store owners expect, and once it is in place, the rest of the store can be cached without flinching.

In this guide, we cover the four cache layers in a WooCommerce store and what each one breaks.

We walk through the full exclusion list for pages, cookies, and AJAX endpoints, then configure page caching across plugins, Cloudflare, and server-level tools.

We also cover object caching with Redis, the caching WooCommerce now handles natively, and how to prove the whole thing works instead of hoping it does.

Why WooCommerce Caching Needs Its Own Configuration

A blog serves the same HTML to everyone, so caching it is a free win. A store does not.

Carts, checkouts, account pages, and personalized pricing change for every visitor, which means a WooCommerce cache has to make a decision on every request rather than apply one blanket rule.

Skip that decision and the failure is quiet. Nothing errors. The store just starts telling customers things that are no longer true.

• Every cart is unique: A cached cart page hands one visitor’s items to everybody who lands on it, which is a conversion problem and a privacy problem at the same time.
• Checkout carries live state: Payment nonces, shipping quotes, and session tokens expire. A cached checkout looks fine and then fails at the exact moment money changes hands.
• Prices are not static: Sale pricing, dynamic pricing rules, currency switchers, and region-based tax all change what a given visitor should see on a given product page.
• Stock counts move faster than TTLs: A cached product page keeps selling something that sold out twenty minutes ago, and you pay for that in refunds and support time.
• Page caching does nothing for logged-in traffic: Returning customers, the admin area, and every excluded page still run full PHP, so a store that only caches HTML has optimized the easy half.

Only 48% of websites deliver a good Core Web Vitals experience on mobile, so a store that simply passes already outperforms roughly half the web.

The Four Caching Layers in a WooCommerce Store

Most caching bugs are not caused by one cache being wrong.

They are caused by two caches disagreeing, which is why it is worth knowing which layer you are actually configuring before you touch a setting.

Page caching and edge caching are the two that break stores, because they store whole pages.

Object caching and browser caching are comparatively safe.

That is why nearly all WooCommerce cache configuration comes down to telling those two layers which requests to leave alone.

What to Exclude From Your WooCommerce Cache

This is the list the rest of the setup depends on.

Every page cache, CDN, and server-level cache needs the same four categories, so it is worth pasting somewhere you can reuse it.

Pages to exclude

• /cart/
• /checkout/ and every child path, including /checkout/order-received/
• /my-account/ and all of its endpoints
• /wp-login.php and /wp-admin/
• Any custom checkout, order form, or upsell page you have built

Cookies that should bypass the cache

WooCommerce uses cookies to track cart contents and sessions. If any of these are present on a request, serve the page fresh:

• woocommerce_cart_hash
• woocommerce_items_in_cart
• wp_woocommerce_session_
• woocommerce_recently_viewed
• wordpress_logged_in_

The WooCommerce cookie reference documents what each one does.

Query strings and AJAX endpoints to exclude

These are the exclusions most guides leave out, and they account for a large share of every “the cart is not updating” support ticket ever filed:

• ?add-to-cart=
• ?remove_item= and ?undo_item=
• wc-ajax, which handles add to cart, cart fragments, and checkout updates
• ?wc-api=, used by payment gateway callbacks
• /wp-json/wc/store/, the Store API behind the cart and checkout blocks

Database exclusions

If your host or plugin lets you filter what gets cached at the database level, exclude the _wc_session_ transients.

Those hold cart contents and shipping data, and caching them is how visitors end up inheriting each other’s sessions.

Custom checkout pages need the same treatment as the default ones.

Stores running FunnelKit Funnel Builder can copy their checkout and upsell permalink slugs from the plugin’s global settings and drop them into the exclusion field of whatever cache tool they use.

FunnelKit keeps a reference list of exclusion steps for every major cache plugin, host, and CDN.

This is worth bookmarking even if you never use the plugin, because it saves you from working out the same rules one tool at a time.

How to Set Up WooCommerce Caching Without Breaking the Cart

Most WooCommerce-aware cache plugins apply the standard page exclusions the moment you activate them.

None of them apply the query string, AJAX, or custom page exclusions, and none of them tell you when something is quietly wrong.

Step 1: Find out what your host already caches

Before installing anything, check whether your host runs its own page cache.

WP Engine, Kinsta, Pressable, SiteGround, and Cloudways all cache at the server level, and several of them block third-party cache plugins outright.

Running two page caches at once is the single most common cause of purge failures, where you update a product and the change appears on one layer but not the other.

If your host already caches pages, configure exclusions there first and use a plugin only for what your host does not handle.

Step 2: Install a WooCommerce-aware cache plugin

Pick a plugin that already knows what WooCommerce is rather than a generic one you teach from scratch.

WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Fastest Cache, FlyingPress, and Breeze all detect WooCommerce and exclude the cart, checkout, and account pages on activation.

On a LiteSpeed or OpenLiteSpeed host, we reach for LiteSpeed Cache, because it caches at the server level and supports ESI, which lets you inject a live mini cart into an otherwise cached page.

On Nginx or Apache behind a CDN, we find WP Rocket and FlyingPress the most predictable.

W3 Total Cache gives you the most control and, for the same reason, is the most likely to be misconfigured.

Step 3: Add your exclusions

Open your plugin’s exclusion settings, usually labeled “Never cache URLs”, “Rejected URL strings”, “Excludes”, or “Advanced Rules,” and enter everything from the list above.

Use wildcards so child paths are covered. Write /checkout(.*) rather than /checkout/ alone, so order received and payment return pages are excluded too.

Cookie exclusions go in the “Never cache cookies” field and query strings in the “Never cache query strings” field.

Two exclusions are worth adding by hand, because in our experience most plugins skip them.

First, exclude wc-ajax. If a store’s mini cart counter refuses to update, this is almost always the reason.

Second, if you run a currency switcher, a geolocation tax plugin, or wholesale pricing, exclude the cookie that tool sets.

Make a note of this rule: Any plugin that changes what a page displays based on who is looking at it needs a bypass, and its documentation will name the cookie.

The trick with sliding and side carts is that they only survive a page cache if they fetch their contents over AJAX rather than reloading the page.

FunnelKit Sliding Cart works this way, so the cached page stays cached and the cart stays live, but the endpoint serving it still belongs in your exclusion list.

Step 4: Set cache lifetimes and purge rules

A cache lifetime, or TTL, decides how long a stored page stays valid.

We set ten hours for blog posts and static pages.

Product and category pages do better between ten minutes and an hour, and if your pricing moves during the day, drop that to a few minutes and let purges handle edits.

Turn on automatic purge on product update, then add category and shop archives to the purge list.

Editing one product should clear its page, its archives, and any page listing new arrivals.

Avoid making full-site purges a habit. They work, and during a promotion they also send every visitor to an uncached page at the same instant, which is a creative way to take your store down on your busiest day.

Step 5: Test and prove it works

Open a private window and load your homepage twice, checking the response headers each time.

The first load should report a cache MISS and the second a HIT.

In Chrome DevTools, open the Network tab, click the document request, and look for X-Cache, X-Cache-Status, or cf-cache-status.

From a terminal, curl -I https://yourstore.com does the same job.

Then walk the buying path logged out.

• Add a product with the add to cart button, then add a second one by loading a ?add-to-cart= URL directly.
• Apply a coupon and confirm the total moves.
• Go to checkout, confirm shipping recalculates, and place a test order.

None of the cart, checkout, or account pages should return a cache HIT.

Two final checks catch the failures that hide.

Open the store in a second browser or on your phone, add a different product, and confirm the two carts stay separate.

Then change a product price in the admin and reload that page logged out to confirm the purge fired.

Test mobile as well as desktop, because some plugins keep a separate mobile cache with its own rules.

Cloudflare and WooCommerce: Use Cache Rules, Not Page Rules

Cloudflare has deprecated Page Rules and is migrating everything to a newer system split across Cache Rules, Configuration Rules, and Redirect Rules.

Any guide still telling you to create a Page Rule with Cache Level set to Bypass is out of date, and the dashboard will say so when you try.

Out of the box, Cloudflare only caches static assets, so a default setup will not break anything.

In our experience, it also will not do much for TTFB.

The gain lives in Cache Everything, which caches your HTML at the edge, and that is where the exclusions start to matter.

Create a 'Cache Rule' under Caching > Cache Rules with a bypass expression covering your dynamic paths and cookies:

(http.request.uri.path contains "/cart") or
(http.request.uri.path contains "/checkout") or
(http.request.uri.path contains "/my-account") or
(http.request.uri.path contains "/wp-admin") or
(http.request.uri.path contains "/wp-json/wc/store") or
(http.request.uri.query contains "add-to-cart") or
(http.request.uri.query contains "wc-ajax") or
(http.cookie contains "woocommerce_items_in_cart") or
(http.cookie contains "wp_woocommerce_session_") or
(http.cookie contains "wordpress_logged_in_")

Set that rule to Bypass cache, then add a second rule marking everything else Eligible for cache. Order matters, so keep the bypass rule above the caching rule.

One behavior changed in the migration and catches people out.

The old Page Rules version of Cache Everything stripped cookies from requests, and Cache Rules does not behave identically.

Walk the full buying path after switching rather than assuming the migration was equivalent.

If you run Automatic Platform Optimization, confirm it excludes the same paths, because APO caches HTML on its own terms.

Server-Level Caching With Nginx, Varnish, and LiteSpeed

Server-level caching sits below your plugins and beats all of them, because a cached response never reaches PHP at all.

On your own VPS or a managed cloud server, this is where the largest TTFB gains are.

The logic is the same across all three tools.

Skip the cache on POST requests, on cart and checkout paths, when an add-to-cart query string is present, and when a WooCommerce or logged-in cookie is set.

Here is a working Nginx FastCGI configuration:

map $http_cookie $woo_no_cache {
    default 0;
    ~*(wordpress_logged_in_|woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_) 1;
}

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WOOCACHE:100m inactive=60m use_temp_path=off;

server {
    set $skip_cache 0;
    if ($request_method = POST) { set $skip_cache 1; }
    if ($request_uri ~* "/cart|/checkout|/my-account|/wp-admin|wc-ajax|add-to-cart=") { set $skip_cache 1; }
    if ($woo_no_cache = 1) { set $skip_cache 1; }

    location ~ \.php$ {
        fastcgi_cache WOOCACHE;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
        fastcgi_cache_valid 200 301 302 10m;
        fastcgi_cache_use_stale updating error timeout http_500;
        fastcgi_cache_background_update on;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

We keep that add_header X-Cache-Status line permanently.

It puts a HIT or MISS value in every response header, which turns cache debugging from guesswork into a one-second check.

The Nginx FastCGI module reference documents the rest of the directives.

Varnish expresses the same rules in VCL, using return (pass) for each condition you want to skip.

Its advantage is flexibility, since you can strip analytics cookies that would otherwise block caching and issue targeted BAN purges when a product changes.

Its cost is that a mistake in VCL is far harder to spot than a mistake in a settings screen.

LiteSpeed handles the job through the LiteSpeed Cache plugin, which has a dedicated WooCommerce tab.

Set cart and checkout to Do Not Cache, turn on ESI if your theme supports it so the mini cart stays live on cached pages, and enable purge on product update.

The LiteSpeed Cache documentation maps each setting to what it actually does.

For high-traffic stores, microcaching is worth knowing about.

A TTL of thirty seconds to two minutes on product and category pages, paired with background updates, removes an enormous amount of repeated PHP work during a sale with almost no risk of anything going stale.

Object Caching With Redis, and When Caching Is Not the Problem

Page caching only helps the visitors who receive a cached page.

Logged-in customers, the admin area, and every excluded page still run the full stack, which is half of your traffic object caching is for.

WordPress caches database results in memory for the duration of one request and then throws them away.

A persistent object cache using Redis or Memcached keeps those results between requests, so repeated queries for options, product meta, and taxonomy terms stop reaching the database.

On a large catalog, that is usually the difference between an admin that drags and one that responds.

Setting it up is short. Confirm your host offers Redis, install the Redis Object Cache plugin, and enable the drop-in from its settings screen.

Verify it under WooCommerce > Status, where the persistent object cache row should report Redis rather than none.

It also cleans up transients.

WooCommerce stores temporary data such as variation prices and product filter results as transients, and on a busy store the options table fills with expired entries that nothing ever removes.

A persistent object cache keeps that data out of the database in the first place.

Now the part we rarely see covered.

A store with a few hundred thousand orders can still return a two-second TTFB with LiteSpeed Enterprise, a persistent object cache, and a high-core-count server, which store owners report in community threads regularly and which no amount of additional caching will fix.

WooCommerce order queries are effectively single-threaded, so more cores do not help.

When TTFB stays bad after page and object caching are both working correctly, the problem has moved to the database.

Enable High Performance Order Storage, archive old orders, index your custom meta queries, and audit the plugins running unindexed queries on every page load.

The Caching WooCommerce Now Does for You

WooCommerce ships caching features of its own now, and most stores have not switched them on.

Product object caching arrived as experimental in WooCommerce 10.5 and became the default for new installations in 11.0.

It intercepts wc_get_product() calls and serves product objects from an in-memory cache for the duration of a single request, which removes the cost of rebuilding the same object again and again on one page.

WooCommerce measured variable products loading roughly 9 to 12% faster on product pages, and bundle products processing 6 to 12% faster during checkout.

The cache is non-persistent, so it clears at the end of every request rather than holding data for minutes.

That makes it low risk, because it cannot carry a stale price from one visitor to the next. Existing stores are not switched over automatically.

Enable it under WooCommerce > Settings > Advanced > Features, under Cache Product Objects.

A related change improved cached variation prices.

On a product with 800 variations, WooCommerce measured get_variation_prices() dropping from roughly 500ms to between 40 and 50ms on cached requests, which is the kind of number that matters if you sell apparel or anything configurable.

Experimental REST API caching landed in 10.5 as well.

It caches responses for product endpoints and needs a persistent object cache to function, so it is worth testing if you run a headless storefront or a mobile app against the WooCommerce REST API.

One check we run before enabling product object caching on an established store.

Look for extensions that write price meta with raw SQL rather than through WooCommerce hooks, because those writes bypass the invalidation that keeps the cache honest.

It is rare, and it is the one pattern that can produce a wrong price.

How to Clear WooCommerce Cache

When a change refuses to appear on the front end, something is holding an older copy. There are four places to clear, and the order saves time.

• Clear WooCommerce’s own caches first

Go to WooCommerce > Status and open the Tools tab.

Clear transients removes expired temporary data, including cached variation prices and product filter results.

Clear customer sessions empties active cart sessions, which fixes carts that have gotten stuck.

Clear template cache rebuilds theme template references, which fixes layouts that broke after a theme or plugin update.

• Clear your caching plugin next

Every plugin has a purge control in the admin bar or its settings screen.

Purge the single page rather than everything where you can.

• Clear the CDN or host cache third

Plugin purges do not reach Cloudflare, BunnyCDN, or a host’s server-level cache.

In Cloudflare, use Caching > Configuration > Purge Cache, and purge by URL unless you have a reason not to.

• Clear the browser cache last

If a page still looks wrong after the three steps above, load it in a private window before deciding the problem is server-side.

You can also clear product caches in code, which is useful inside an import script or a scheduled task:

// Clear all cached data for a single product
wc_delete_product_transients( $product_id );

// Clear cached product data across the store
wc_delete_product_transients();

WooCommerce Caching Problems and How to Fix Them

Almost every WooCommerce cache issue we see produces one of a small number of symptoms. Start here rather than changing settings and hoping.

That last row deserves its own warning.

Most cache plugins never serve cached pages to logged-in administrators, so a store can look perfect to you and broken to everyone else.

This can be a poor way to discover your cache is working exactly as configured. So, testing in logged-out mode is critical.

6 Best Practices That Keep a Fast Store Accurate

• Run one page cache

Layering a plugin on top of a host cache is the leading cause of purges that look like they worked and did not.

• Leave a cache status header switched on

A permanent X-Cache-Status header turns every future cache question into a one-second check instead of an afternoon.

• Re-test checkout after every plugin update

Payment gateways, currency switchers, and tax plugins introduce cookies and endpoints your exclusion list has never heard of.

• Prefer targeted purges over full-site purges

The full purge is the tempting option during an incident and the one most likely to turn a slow store into an offline one.

• Warm the cache before a sale

Crawling your top URLs ahead of a launch means the first wave of shoppers lands on cached pages rather than generating them.

• Do not minify checkout scripts

Minification and JavaScript combination break payment fields often enough that checkout and upsell pages should be excluded from both, even where caching is already off.

Speed work compounds with checkout work, and the compounding is where the money is.

Google research found that 53% of mobile visitors abandon a page taking longer than three seconds to load, and the pages where that abandonment is most expensive are the ones furthest down the funnel.

For the broader playbook on that half of the problem, see our guide to WooCommerce checkout optimization.

Frequently Asked Questions

Ready to Set Up Caching in Your WooCommerce Store?

The exclusion list in this guide is short on purpose.

Once the cart, the checkout, the account pages, the WooCommerce cookies, and the AJAX endpoints are bypassing the cache at every layer, everything else in your store can be cached hard, which is the whole point and the part most setups never get to.

None of this is a single dramatic change.

Page caching takes the largest bite out of TTFB, object caching picks up the traffic page caching cannot touch, WooCommerce 11.0 quietly adds a few percent on top, and a sane purge strategy keeps all of it accurate.

Individually, they are small. Stacked, they are the difference between a store that feels instant and one that feels like work.

We would start with page caching and the exclusion list, verify with a logged-out test order, and only then move on to Redis and the server layer.

If your checkout or upsell pages come from FunnelKit Funnel Builder, add those slugs to the same exclusion rules and the compatibility documentation will cover whichever cache tool you land on.

Related Resources:

• WooCommerce Checkout Optimization: The Complete Guide
• How to Customize the WooCommerce Checkout Page
• WooCommerce Direct Checkout: How to Skip the Cart Page
• WooCommerce Sliding Cart

Related Blogs

Editorial Team

July 7, 2026

WooCommerce Direct Checkout: 4 Easy Ways to Set It Up (2026)

Are shoppers adding products to their cart and leaving before they buy? According to Baymard Institute research on checkout usability, 18% of shoppers who abandon their cart do so because...

Editorial Team

May 28, 2026

How to Create And Sell Digital Products with WooCommerce

WooCommerce makes it pretty simple to create and sell digital products like eBooks, software, and online courses etc from a single WordPress store. You don’t need anything complex to get...

Editorial Team

March 23, 2026

How to Set Up WooCommerce Stripe Integration in 5 Simple Steps

Does your WooCommerce store offer enough payment options? If not, you could be losing up to 13% of sales. [According to Baymard]. WooCommerce’s default payment options don’t always meet customer...