WooCommerce Multilingual Headless: Drop WPML, Keep Your SEO

Selling internationally with WooCommerce means dealing with multilingual content, currency switching, localised SEO, and translated checkout flows. The standard solution — WPML or Polylang with WooCommerce Multilingual — works, but it's expensive, complex, and significantly slows down your store. A headless WooCommerce architecture handles internationalisation (i18n) more cleanly: your Next.js frontend manages all language routing and translation, WooCommerce handles localised pricing and order management, and you never need WPML again.

TL;DR

Headless WooCommerce multilingual means your Next.js frontend handles all language routing, UI translations, and hreflang tags via its built-in i18n support (or next-intl/next-i18next). WooCommerce provides translated product data via WPML or directly via separate language-specific content. You get clean URLs, correct hreflang tags, and multilingual SEO without WPML dragging down every page load.

Why WPML slows WooCommerce stores down

WPML is the most widely used WordPress multilingual plugin, but it has a significant performance cost. On every page load, WPML determines the current language context, rewrites URLs, loads translation tables, and filters content through its hooks. On a WooCommerce store with 1,000+ products in two or more languages, WPML can add 30–60 database queries per page — on top of the queries WooCommerce already generates.

$99/yr

WPML ecommerce licence cost (one site)

30–60

Additional DB queries per page from WPML hooks

2×

Storage overhead for translated content vs single-language store

The performance impact compounds with database size. A store with 10,000 products in three languages has 30,000 product records. Every product query must join to the WPML translation tables to return the correct language version — slowing down product archives, search, and related product blocks significantly.

WPML and WooCommerce compatibility issues

WPML WooCommerce Multilingual requires its own plugin on top of the base WPML install, bringing the plugin count to at least three (WPML core, WPML String Translation, WooCommerce Multilingual). Plugin conflicts with other WooCommerce extensions — particularly pricing, checkout, and shipping plugins — are common and often undocumented.

Headless multilingual architecture

A headless WooCommerce multilingual setup separates language concerns clearly:

Frontend language routing (Next.js)

Next.js has built-in internationalised routing. You define your supported locales in next.config.js and Next.js automatically generates locale-prefixed routes:

yourstore.com/en/products/blue-shirt
yourstore.com/fr/products/chemise-bleue
yourstore.com/de/products/blaues-hemd

Each route gets the correct hreflang tags automatically. Google can discover all language versions from the canonical page, and link equity flows correctly across language variants.

UI string translations

Checkout labels, error messages, navigation text, and other UI strings are managed in your Next.js app using a translation library — next-intl is the most popular choice for Next.js App Router. Translation files (JSON or YAML) live in your frontend repository. Updating a label in French means editing the French translation file and deploying — no WordPress admin access required.

Product content translations

Translated product titles, descriptions, and attributes come from WooCommerce. You have two main options:

WPML on the backend only: WPML runs on WooCommerce (no WPML frontend theme rendering), and your Next.js frontend requests translated content via the WPML REST API extensions. WPML adds language parameters to the WooCommerce REST API (?lang=fr), and product content is returned in the requested language. You keep WPML for content management but remove it from the frontend rendering path entirely.
Separate WooCommerce installs per language: Run a separate WooCommerce install for each language (or language region). Your Next.js app routes /fr/* requests to the French WooCommerce API and /de/* requests to the German API. No WPML needed — but you manage multiple WooCommerce databases.
Polylang with REST API: Polylang exposes translated content via the REST API similarly to WPML. The Polylang for WooCommerce extension is required. This is a lower-cost alternative to WPML for stores that don't need WPML's full translation management features.

“Dropped WPML from the frontend entirely. Next.js handles routing and UI strings, WPML just serves translated product data via REST. Site went from 4s to under 1s on product pages.”

RedditNext.js ecommerce developer· 2025· r/woocommerce discussionView source →

Multilingual SEO with headless WooCommerce

International SEO is one of the clearest wins of going headless for multilingual stores. Traditional WooCommerce/WPML setups often produce SEO problems that are hard to diagnose and fix: incorrect hreflang tags, duplicate content across language versions, and slow page loads hurting Core Web Vitals in non-English markets.

hreflang tags

In a Next.js app with built-in i18n, hreflang tags are generated automatically for every page. You define your locale-to-language mappings once. Every product page, category page, and content page gets the correct hreflang annotation without any plugin or manual work.

Language-specific sitemaps

Your Next.js sitemap generator (using next-sitemap or the built-in Next.js sitemap API) generates language-specific sitemaps with correct hreflang annotations. Google can discover and index all language versions efficiently.

Currency and pricing for international markets

WooCommerce's multi-currency support (via WooCommerce Payments, Aelia Currency Switcher, or WPML's currency features) is separate from language translation. In a headless setup, your frontend detects the user's locale, requests prices in the appropriate currency from WooCommerce, and displays them. The currency conversion logic stays on the WooCommerce backend — your frontend just renders the prices it receives.

Headless vs WPML: the honest comparison for multilingual stores

Pros

WPML removed from frontend rendering — no more 30–60 extra DB queries per page
hreflang tags generated automatically by Next.js i18n routing
UI strings managed in version control — no WordPress admin for translation updates
Language-specific sitemaps generated correctly from the frontend
Consistent multilingual performance — no WPML slowdown in any language
Polylang is a viable (cheaper) backend alternative without frontend performance cost

Cons

Product content translation still requires WPML, Polylang, or multiple WP installs
next-intl setup and translation file management adds frontend complexity
Currency switching requires WooCommerce multi-currency extension
Right-to-left (RTL) language support requires specific CSS handling in your theme

Implementation checklist for headless multilingual WooCommerce

Configure Next.js i18n in next.config.js with all supported locales
Install and configure next-intl for UI string translations
Create translation JSON files for each supported language
Configure WPML or Polylang REST API language parameter support
Update API calls to pass ?lang=[locale] for translated product content
Generate language-specific sitemaps with hreflang annotations
Test hreflang implementation in Google Search Console
Configure currency display for each locale
Test checkout flow in each supported language
Implement language detection (browser preference or URL-based)

Start with one additional language

Don't try to launch in five languages simultaneously. Add your highest-priority second language first, prove the architecture works end-to-end (product display, checkout, order emails), then expand. Translation management gets complex at scale — start simple.

For the broader SEO picture with headless WooCommerce, see our guide on headless WooCommerce SEO. For the technical setup, see our WooCommerce REST API with Next.js guide.