Multilingual WooCommerce on a Next.js storefront

The first decision is how languages live in the URL. A per-locale path prefix — the same structure this storefront uses — gives every language a distinct, crawlable address and keeps routing predictable. What matters is consistency: each piece of content has one canonical URL per language, the default language is handled deliberately, and switching language keeps the shopper on the equivalent page rather than dumping them on the homepage. A Next.js storefront makes this routing explicit instead of leaving it to a translation plugin's rewrite rules.

hreflang is how you tell search engines that two URLs are the same content in different languages, so the right version is shown and the pages do not compete as duplicates. The annotations have to be complete and reciprocal — every language version references all the others and itself — and they must point to the canonical URL of each translation. Getting this wrong is a common cause of the wrong-language page ranking; getting it right is mostly a matter of generating the tags from a single source of truth on every page.

• Reciprocal hreflang linking every language version, including itself
• Point hreflang at the canonical URL of each translation
• Use a clear default/x-default where appropriate
• Generate the annotations from one source so they never drift

Real localisation goes deeper than the visible text. Slugs, titles, meta descriptions, Open Graph data, breadcrumb labels and structured data should all be in the target language, because a translated page with an English URL and English metadata reads as half-localised to both shoppers and search. The storefront pulls translated fields from WooCommerce and WordPress and renders a fully localised page, so nothing gives away that the content was translated after the fact.

Most multilingual WooCommerce stores already manage translations in WPML or Polylang, and that work should not be thrown away. The storefront reads those translated products, categories and content through the API and presents them, so your team keeps translating in the familiar WordPress workflow while the Next.js frontend renders each language fast. The translation source of truth stays in WordPress; the storefront just displays it correctly per locale.

Multilingual bugs are easy to ship and hard to notice, because you rarely browse your own store in every language, so validation has to be deliberate. Before launch, crawl each locale separately to confirm every translated page resolves at its own URL and returns the translated content, not a fallback to the default language. Check the hreflang annotations with a dedicated tool so they are complete and reciprocal and point to canonical URLs. Verify that language switching lands on the equivalent page, that currencies and formats render correctly per market, and that the sitemap includes every locale. Search Console's international targeting reports then confirm, after launch, that Google is treating the versions as intended rather than as duplicates.

• Crawl each locale to confirm pages resolve and are translated
• Validate hreflang with a dedicated tool for completeness and reciprocity
• Check language switching, currency and format per market
• Confirm international targeting in Search Console after launch

Language is only part of localisation. Prices should display in the expected currency and format for the market, dates and numbers should follow local conventions, and right-to-left languages need layout that genuinely mirrors rather than a language toggle bolted onto a left-to-right design. Handling these on the storefront — while WooCommerce remains the source of prices and product data — is what makes a multilingual store feel native in each market instead of translated.