WooCommerce GDPR Compliance & Multilingual Store Setup: A Combined Guide
A store owner in the UK sells candles. Business is good. The plan is to sell into Germany, France, and Spain next quarter.
Two things usually break that plan. Nobody has answered a data erasure request yet. And nobody has tested what happens to a variable product’s price once WPML clones it into three languages. Both problems sound boring. Both can stall a launch for weeks.
This guide covers WooCommerce GDPR compliance and multilingual setup together. In practice they land on the same to-do list. Getting WooCommerce GDPR compliance right before launch avoids the worst of these problems. A store expanding into new markets needs both at once, not one after the other.
Why GDPR and Localization Show Up Together
GDPR applies the moment a store processes personal data from someone in the EU or UK. It doesn’t matter where the server sits. So the day a WooCommerce store starts shipping to Germany, GDPR rules are already live.
The same is true the day it starts running ads that target German shoppers. Multilingual setup usually happens around the same time. A checkout in English only converts so well for a shopper in Munich.
Treat these as one project, not two separate tickets. That saves rework. Consent banners, checkout translations, and privacy policy updates all touch the same checkout template. Change it once. Test it once.
WooCommerce GDPR Compliance: Where Most Stores Get It Wrong
WooCommerce doesn’t come GDPR-compliant out of the box. No single plugin makes it fully compliant either. Compliance is three separate jobs: consent mechanics, data-handling workflows, and documentation. Plugins only automate part of each one.
Consent Before You Collect
Every point where WooCommerce collects personal data needs clear consent. The checkbox must be unticked by default. This applies to the checkout form, any newsletter opt-in near it, account registration, and product review submissions.
- A checkout consent checkbox for marketing, kept separate from the order itself. An order can’t depend on marketing consent.
- Account creation consent, if the store keeps anything beyond what’s needed to fulfill the order.
- Plain-language wording. “By checking this box you agree to receive occasional emails about new products” beats a link buried in six paragraphs of legal text.
A plugin like WP GDPR Compliance or Complianz handles the checkbox and the consent log. What it won’t do is decide which custom checkout fields need consent, and which are just needed to ship the order. That’s a store-specific judgment call.
It’s easy to get wrong on stores with custom fields added by a page builder or a booking plugin. If you’re still choosing tools, our roundup of WordPress plugins built for GDPR compliance compares the leading options.
Handling Data Export and Erasure Requests
WordPress ships with built-in tools for this. Find them under Tools → Export Personal Data and Tools → Erase Personal Data.
For a WooCommerce store, those tools need to reach further than core comments and user meta. They also need to pull order history, saved payment tokens (or confirm none are stored locally), and any custom fields a CRM sync has added.
Here’s where it gets tricky. An erasure request runs into a legal retention rule almost immediately. Tax law in most EU countries requires invoices to be kept for six to ten years. WooCommerce’s default erasure tool anonymizes order data instead of deleting it outright. That’s the right instinct.
But “anonymizes” needs checking on a per-store basis, especially once a CRM integration, a loyalty points plugin, or an email marketing sync is in the mix. Third-party syncs almost never get cleaned up by WordPress’s native erasure tool. They need a custom hook into `woocommerce_privacy_erase_personal_data`.
Scenario: a mid-sized homeware store expands into the EU. It gets its first data erasure request three weeks after launch. WordPress core anonymizes the WooCommerce order fine. But the store also syncs every order to Klaviyo and an external fulfillment partner’s API. Neither system gets touched by the erasure request, because nothing was ever built to tell them to. The store is technically non-compliant until someone writes the extra hook.
This is a common gap. The fix isn’t a settings toggle. It’s a short custom function hooked into WooCommerce’s privacy exporters and erasers, one that also calls the CRM and fulfillment APIs when a request comes through. Plugin defaults stop at the WordPress database boundary. Anything synced outside it needs its own erasure path.
Cookie Consent for Tracking Scripts
Google Analytics, Meta Pixel, TikTok Pixel, and abandoned-cart recovery scripts all set cookies before a user clicks anything. That happens unless something actively blocks them. Under GDPR, non-essential cookies need consent before they fire. A banner that just says “cookies exist” isn’t enough.
A proper setup looks like this:
| Script type | Consent required | Load timing |
|---|---|---|
| Session, cart, checkout nonce cookies | No, essential | Always |
| Google Analytics / GA4 | Yes | Only after consent |
| Meta Pixel / TikTok Pixel | Yes | Only after consent |
| Abandoned cart recovery scripts | Yes, usually | Only after consent |
Most consent plugins (CookieYes, Complianz, Cookiebot) can block Google Tag Manager until consent is given. That handles most tracking scripts in one move.
The gaps show up in scripts loaded directly by a theme or a marketing plugin, outside GTM. Those need manual consent-gating.
It’s the kind of thing that only shows up when someone audits the site’s network requests before a consent click. We covered one all-in-one option in our cookie consent and legal compliance platform review, if you’d rather not stitch several plugins together.
Multilingual and Multi-Currency WooCommerce Setup
The second half of a market expansion is making the store usable in the new market’s language and currency. WooCommerce doesn’t localize itself. That work happens through WPML with the WooCommerce Multilingual add-on, or through Polylang with Polylang for WooCommerce.
WPML vs. Polylang for WooCommerce
WPML is the heavier, more complete option. It suits stores with real product catalogs: variable products, bundles, subscriptions. Its WooCommerce Multilingual add-on syncs prices, stock, and attributes across translated product copies. It also has dedicated handling for checkout fields and order emails.
Polylang, with its WooCommerce add-on, is lighter. It works well for smaller catalogs. But variable product sync is less mature, and some store owners end up managing stock manually across translations.
Neither plugin is “set and forget” on a catalog with more than a couple hundred SKUs. Budget real testing time before launch. Focus that testing on variable products. That’s where the two most common bugs live. For a wider comparison beyond these two, see our guide to multilingual plugin options for WooCommerce.
Translating Checkout Fields and Order Emails
Checkout labels, validation messages, shipping method names, payment gateway labels, and order confirmation emails all need translation. They’re easy to miss, because they don’t live in the visual page builder most translators work in.
WPML’s String Translation module catches most of these, if it’s pointed at the right text domains: `woocommerce`, plus any checkout plugin’s own domain.
Order emails need a manual check. WooCommerce sends transactional emails in the language the order was placed in, but only if the language switch happened before checkout, not after.
Currency Switching Without Breaking Tax and Shipping
Multi-currency and multilingual are separate problems that get bundled into one project. WooCommerce Multilingual includes a currency switcher. By default it’s a display-layer conversion. Prices shown in EUR are calculated from the base currency at a fixed or periodically-updated rate. They aren’t stored as separate EUR prices. That’s fine for many stores.
It becomes a problem once tax rules differ by country, or shipping rates are currency-specific rather than converted on the fly. Underneath the display conversion, tax and shipping calculations still run against the base currency logic.
Some stores need real per-market pricing, not just converted display prices. Actual different price points per currency, for psychological pricing or margin reasons.
That needs WooCommerce’s multi-currency pricing tables, or a dedicated pricing plugin layered on top, configured to match whichever translation plugin is running. Getting the layering order wrong between currency switcher, tax plugin, and translation plugin is the single most common cause of “price shows wrong at checkout” bugs.
Scenario: a specialty tea store goes multilingual to launch in France and the Netherlands. Everything looks right in the product catalog. French names, French descriptions, correct EUR pricing. Then support tickets start coming in about one loose-leaf tea sold in three tin sizes. The French version shows the 250g tin’s price under the 100g tin’s label. WPML had synced the parent product, but not the variation order, because the variations were added after the initial translation sync ran. The fix was a manual re-sync of variation attributes, plus a small script to catch future variation additions automatically. The plugin’s default sync schedule never did that on its own.
That kind of bug rarely shows up in a quick manual test of two or three products. It surfaces once a catalog has real depth. Dozens of variable products, added over time, some edited after the initial translation.
Where GDPR and Localization Actually Overlap
A few things sit at the intersection. They get missed when the two projects are handled by different people, or on different timelines.
- Privacy policy and cookie consent banners need translated versions in every checkout language. A French shopper seeing an English-only consent banner is both a compliance gap and a conversion killer.
- Data export and erasure request forms need to work no matter which language the customer’s account was created in.
- Consent records need to store which language version of the policy the customer agreed to, in case the wording differs between translations.
None of this is exotic. It’s just easy to skip when GDPR setup happens in January and the French launch happens in March, run by two people who never compared notes.
A Pre-Expansion Checklist
Before a store opens checkout to a new market, walk through this end to end:
- Consent checkboxes present and unticked by default on checkout, account creation, and newsletter opt-ins.
- Data export tool returns full order history, not just user meta and comments.
- Data erasure tool reaches every third-party sync: CRM, email platform, fulfillment partner. Not just the WordPress database.
- Tracking scripts blocked until consent, including any loaded outside Google Tag Manager.
- Product catalog fully translated. Variable product attributes and stock sync verified after the most recent product edit.
- Checkout labels, shipping method names, and order confirmation emails translated and tested end to end in each language.
- Currency display tested against tax and shipping calculation, not just the product page price.
- Privacy policy and consent banner available in every checkout language.
Most of these take an afternoon to check. Two don’t: third-party erasure sync, and variable product translation sync. Budget real time for those. They only fail under real catalog depth and real customer volume, not in a five-minute test.
When Plugin Defaults Stop Being Enough
Consent plugins and translation plugins get a store most of the way there. Where we get called in is usually one of two situations.
A data erasure request that needs to reach a CRM or fulfillment API the default WordPress tools don’t know exists. Or a WPML/WooCommerce sync bug on variable products that’s already live, already affecting orders.
Both are fixable without replacing the plugins already in place. It’s a matter of writing the missing hook, or fixing the sync logic so it matches how the store’s catalog actually works.
Frequently Asked Questions
Does GDPR apply if my WooCommerce store isn’t based in the EU?
Yes, if you sell to customers in the EU or UK. GDPR is based on where the customer is, not where the store or server is hosted. A US-based store shipping to Germany is still processing EU residents’ personal data. It falls under the regulation.
Is WooCommerce GDPR compliant by default?
No. WooCommerce includes the export and erasure tools GDPR requires. But they only cover core order and user data stored in WordPress. Consent collection, cookie blocking, and erasure across third-party integrations still need to be configured or built.
Can I use WPML and Polylang together?
No. They solve the same problem, and running both causes conflicts. Pick one before setup starts. WPML usually fits larger, variable-product-heavy catalogs better. Polylang suits smaller, simpler stores.
Will a currency switcher plugin handle multi-currency pricing automatically?
It handles display conversion, which is enough for many stores. It won’t create separate fixed price points per currency on its own. And it doesn’t rewrite tax or shipping logic underneath the converted price, those still run against the base currency unless configured otherwise.
Do I need a data processing agreement with my hosting or CRM provider?
Yes, in most cases. Under GDPR, any third party that processes personal data on your behalf needs a signed data processing agreement, or DPA.
That includes your hosting provider, your email marketing platform, and any CRM or fulfillment partner your store syncs orders to. Most established providers publish a standard DPA you can accept online. Smaller or custom tools may need one drafted.
Getting Both Right Before You Launch
GDPR compliance and multilingual setup rarely fail because a store owner didn’t try. They fail because both projects get tested lightly: a couple of products, a couple of test orders, right before launch.
The real edge cases, deep catalogs, third-party syncs, variation-level pricing, only show up once real customers place real orders. Test both properly, with a catalog that resembles what will actually go live. That catches most of this before it becomes a support ticket.
If your store is heading into a new market, and either the compliance side or the localization side feels unfinished, get a proper audit before launch.
That’s cheaper than fixing it after the first erasure request, or the first mispriced variation ships to a customer. WooCommerce GDPR compliance and multilingual readiness are both cheaper to fix before launch than after.
