How to Cache a Multi-Currency WooCommerce Store

You’ve set up your WooCommerce store to sell in USD, EUR, and GBP. Prices convert automatically. A visitor from Berlin sees euros, a visitor from London sees pounds.

Then you turn on page caching, and something strange happens.

A customer in the UK lands on your store and sees prices in euros. Someone in Germany sees dollars. Nobody changed anything, but the cache decided for them.

This is one reason store owners are cautious about caching multi-currency setups. And it’s a shame, because skipping the cache means a slower store, worse Core Web Vitals, and a lot of wasted server resources.

The good news is that this is a solvable problem. Here’s why it happens and how to fix it.

Why caching and multi-currency clash

A page cache works by saving a ready-made HTML copy of a page and serving it to everyone who asks for it. That’s what makes it fast: no PHP, no database queries, no waiting.

The catch is that the cache assumes the page looks the same for every visitor. On a multi-currency store, it doesn’t.

Here’s the typical failure:

1. A visitor browsing in EUR requests your product page.
2. The cache has no copy, so WooCommerce builds the page with euro prices.
3. The cache saves that page.
4. The next visitor, who wants GBP, gets the saved euro version.

The cache did exactly what it was designed to do. It just wasn’t told that the same URL can have different content.

This isn’t only a cosmetic problem. Wrong prices on product pages mean confused customers, abandoned carts, and support tickets asking why the price changed at checkout.

How currency switchers decide what to show

To fix this, you need to know how your currency plugin chooses a currency in the first place. Most use one (or a mix) of these methods:

Cookies. When a visitor picks a currency, the plugin stores the choice in a cookie and reads it on every request. The URL stays the same, and only the cookie differs.

URL parameters or paths. The currency lives in the address itself, like ?currency=EUR or /eur/product/.

Geolocation. The plugin detects the visitor’s country and picks a currency to match. Depending on the plugin, the detected currency may then be stored in a cookie or handled in another way.

Cookie-based switching is the trickiest one for a cache, because the URL gives it no hint that the page is different.

What your cache actually needs to do

Whatever method your store uses, the principle is the same: the cache must keep a separate copy of each page for each currency.

With URL-based currencies, the currency itself may already be part of the URL, which can make cache separation simpler. Still, test each currency URL to make sure your caching setup treats them correctly.

With cookie-based currencies, the cache has to look at the currency cookie and store one version per value.

If your caching plugin can’t do this, you’re stuck choosing between two bad options: no caching, or wrong prices.

This is where FastPixel makes things easier. Its Vary Cache feature can store different cached versions of the same page depending on the value of cookies you choose. Location-based currency is one of the use cases it was built for. A multi-currency store can stay cached without serving the wrong prices to visitors.

One thing to know upfront: Vary Cache only works once you tell it which cookie to watch. That’s the one step you’ll need to do yourself, and we’ll walk through it below.

Pages you should never cache

Even on a single-currency store, some WooCommerce pages are personal by nature. On a multi-currency store, they matter even more:

• Cart
• Checkout
• My Account

These pages hold session-specific data: items in the cart, shipping choices, totals in the selected currency. They need to be generated fresh every time.

FastPixel keeps cart, checkout, and account pages out of the page cache, so shoppers get live pages while regular visitors get the cached version whenever possible. If you’ve built custom cart or checkout pages (for example, with a page builder), double-check that they’re excluded as well.

Step by step: caching a multi-currency store with FastPixel

Step 1: Find out which cookie holds the currency

Open your store in an incognito window and switch currency using your store’s switcher. Then open Chrome DevTools (F12), go to Application > Cookies, and look for a new or changed cookie.

Its name depends on your currency plugin. Note the exact cookie that changes when you switch currencies, because you’ll need it in a moment.

If you see no cookie change at all, your plugin may use the URL or another method to set the currency. In that case, jump to the testing section and confirm that each currency really gets its own cached page.

Step 2: Install and activate FastPixel as usual

Install FastPixel from the WordPress repository, activate it, and go through the usual onboarding. There’s no need to disable caching across your store.

Step 3: Add the currency cookie to Vary Cache

Open FastPixel’s settings, either from the FastPixel icon in the admin bar or from the FastPixel menu in your dashboard, and find the Vary Cache option. Add the currency cookie you found in Step 1. From now on, FastPixel stores a separate cached version of each page for each value of that cookie.

Pick carefully. The rule from FastPixel’s docs applies here: only vary by cookies that have a small number of possible values and actually change what’s rendered. A currency cookie is a good fit because it usually has only a small number of possible values. A session ID is not, because it would create a separate cache for every single visitor and defeat the purpose.

Step 4: Check your exclusions

Make sure cart, checkout, and account pages are not cached. For a standard WooCommerce setup, this is handled automatically. If you use custom page templates for these, verify them manually.

Step 5: Purge the cache

Before testing, purge the cache so you’re not looking at an older version of the page. If you have another caching layer in front of WordPress, such as host-level caching or a separate CDN, make sure that one has been refreshed too.

Step 6: Test every currency

Don’t assume it works. Test it. The next section covers exactly how.

How to test that every currency is served correctly

This takes five minutes and saves you from the nightmare scenario of customers seeing the wrong prices.

1. Open an incognito window. This gives you a clean session with no cookies.
2. Visit a product page and note the default currency.
3. Switch to another currency using your store’s switcher.
4. Reload the page, then visit a few other pages. The currency should stay consistent.
5. Open a second incognito window (or a different browser) and load the same product page. It should show the default currency, not the one you just picked.
6. Repeat for each currency you offer.

For geolocation, use a VPN or your plugin’s test mode to simulate visitors from different countries.

You can also use Chrome DevTools: open the Network tab, reload the page, and check that the prices in the returned HTML match the expected currency.

If a currency ever “sticks” for the wrong visitor, you’ve found a caching problem. Re-check the cookie name in Vary Cache, purge the cache, and test again.

Common mistakes

Varying by the wrong cookie. If the cookie in Vary Cache isn’t the one your plugin actually uses, the cache can’t tell currencies apart. Always confirm the exact name in DevTools.

Caching everything, including cart and checkout. Personal pages should always stay dynamic.

Forgetting other caching layers. If a CDN or host-level cache sits in front of WordPress and ignores cookies, it can undo everything your page cache does right.

Stacking multiple caching plugins. Running several WordPress performance plugins at once makes it very hard to know which layer is serving which page. Pick one page cache and keep the stack simple.

Testing only as a logged-in admin. Logged-in users usually get live pages. Always test as a logged-out visitor.

The bottom line

Multi-currency and page caching don’t have to be enemies. The conflict comes from a cache that doesn’t know one URL can have several correct versions.

Tell the cache which cookie decides the currency, keep cart, checkout, and account pages dynamic, and test every currency as a logged-out visitor. With FastPixel, you don’t have to choose between caching your store and showing the right currency.

Your international customers get a fast store that speaks their currency. And your server does less unnecessary work rebuilding the same product pages over and over.

FAQs

Can I cache a WooCommerce store that sells in multiple currencies?

Yes. You need a cache that can keep separate versions of each page per currency. Without that, visitors may see prices in the wrong currency.

Does FastPixel work with multi-currency WooCommerce stores?

Yes. With Vary Cache, FastPixel can maintain different cached versions of a page based on the cookies you choose, such as a currency cookie. Dynamic WooCommerce areas like cart, checkout, and account pages stay outside the page cache.

Do I need to configure anything?

Yes, one thing: tell Vary Cache which cookie your currency switcher uses. Vary Cache doesn’t work until at least one cookie is set.

Does supporting multiple currencies increase the number of cached variants?

Potentially, yes. When different currencies need different HTML, the cache stores separate variants instead of serving one identical copy to everyone. That can slightly lower your cache hit ratio, which is why you should only vary by cookies with a small number of values, like a currency code.

Which cookie should I vary by?

The one that stores the visitor’s selected currency. Never use cookies with a unique value per visitor, like session IDs, since that creates a separate cache for every user.

Will caching make my cart and checkout show the wrong currency?

No, as long as those pages aren’t cached. FastPixel keeps cart, checkout, and account pages out of the page cache.

Why do my prices show the wrong currency after enabling a cache?

Usually the cache is serving a page generated for one currency to everyone. Check that the correct currency cookie is set in Vary Cache, purge the cache, and test again as a logged-out visitor.