Multi-Language Online Store Setup: A Practical Guide

Denys Apekin 7 min read

Picture a store owner who adds German with a translation plugin one evening and calls it done. Then somebody opens checkout: the payment form is still in English, the address fields expect a US-style zip code, and the return policy page hasn’t been touched at all. Translating product text is maybe a fifth of what multi-language actually means. The rest is currency, payment methods people in that country actually trust, legal pages that match local rules, and search results that show the right language to the right visitor.

Here’s how that works: the platform-specific approaches, how to structure your URLs, why hreflang matters more than people assume, and what gets forgotten most often when a store goes multilingual.

It’s rarely just about the language

Take a shop selling in the US that starts shipping to Germany. Translating product pages into German is the easy part. German shoppers are used to paying via SOFORT or bank transfer, not necessarily a one-click card charge. Prices there are shown with VAT already included – that’s not a style choice, it’s the law. Returns get 14 days under EU consumer rules, and if your site says something different, that’s a legal problem, not a copy problem.

Multi-language setup is really market localization, and the language itself is just the visible layer. Currency, payment options, shipping rules, how prices get displayed – all of it shifts together with the language, even though technically these live in completely separate settings.

Platform-specific approaches

What you use depends heavily on what the store runs on.

WordPress: Polylang or WPML

For WooCommerce, it’s usually one of these two. Polylang is free at its core and simpler to set up, but syncing translated products often needs manual work or an extra add-on. WPML costs money but ships with String Translation and native ACF field support, which matters a lot once a store has a pile of custom product attributes. Both plugins create a separate post for each language version of a page and link them together – that link is what powers the language switcher and the hreflang tags underneath it.

One thing that’s easy to miss: categories, tags, and product attributes need separate translation too. They don’t inherit automatically from translating the product itself.

OpenCart: built-in language packs

OpenCart has multi-language support baked into the core, no third-party plugin required. Install a language pack through Extensions, add the language under Localisation → Languages, and every product, category, and info page gets separate fields for each enabled language right in the edit form. The catch is that currency and language aren’t the same thing in OpenCart – currency gets configured separately under Localisation → Currencies, and without linking them manually, a shopper from Germany can easily see prices in dollars instead of euros.

Laravel or custom builds

Here multi-language support is an engineering decision, not a plugin setting. Locale usually gets resolved from a URL prefix through middleware (a route group with a {locale} parameter), interface strings live in resources/lang files, and product content sits in separate database fields (name_en, name_de, name_fr, or a dedicated translations table). The upside is full control over exactly what gets translated and how, down to per-country pricing and currency logic. The downside is that it has to be planned for upfront – bolting multi-language onto an already-built custom store later costs a lot more than designing it in from the start.

URL structure: subdirectories, subdomains, or separate domains

There are three real options, and the choice affects SEO more than it looks at first glance.

Subdirectories (shop.com/en/, shop.com/de/) – the simplest technically, and all the domain’s accumulated authority works for every language version at once. This is what Polylang and WPML default to.
Subdomains (en.shop.com, de.shop.com) – useful when different teams or even different systems handle each language, but Google treats subdomains as semi-separate sites in places, so ranking weight has to build up for each one on its own.
Separate domains (shop.com, shop.de) – the most trust with a local audience, since buying from a familiar local TLD feels safer to shoppers, but it means separate SEO work, separate backlinks, separate reputation from zero for every single domain.

For most stores adding two or three languages without a budget to promote each as its own site, subdirectories are the sane default. Separate domains earn their cost when a market has a legal requirement for local business registration – that comes up, for instance, when expanding into certain Gulf countries.

hreflang: why Google cares and what breaks without it

Without hreflang, Google sees two pages with near-identical content in different languages and picks one to show a visitor in Warsaw on its own – the guess isn’t always right. Worse, it can read as duplicate content, even though nothing is actually duplicated, it’s just two languages of the same page.

The hreflang tag in the page head tells search engines: this page is in English, here’s its Polish counterpart, show each visitor the right one. It looks like this:

Polylang and WPML generate these automatically, so on WordPress the usual culprit when something’s wrong isn’t the plugin – it’s page caching. A static cache can keep serving an old version of the head, missing tags, for a while after a new language gets added. On custom builds, hreflang has to be written by hand for every page pair, and that’s exactly where a language version gets left out when a new product ships – the listing ends up with no pair, and the hreflang link points at nothing.

What actually needs translating

Product page copy is the obvious part. Less obvious:

Meta title and meta description per language version – leaving English meta tags on a German page just makes it harder for Google to understand what the page is about.
Image alt text – it affects both SEO and accessibility for screen reader users.
Order confirmation, shipping status, and password reset emails – a customer in Germany getting an English email right after checkout doesn’t exactly build trust.
The checkout flow itself: form field labels, validation error messages, payment buttons.
Legal pages – return policy, privacy policy, terms of service. Translating isn’t enough here; someone needs to check the content actually matches local law.

Desk with a laptop showing a store admin panel with a language switcher

Common mistakes

The most common one: running everything through machine translation and calling it done. Fine for internal notes, not fine for a public site that’s supposed to sell – a native speaker notices stiff phrasing immediately, and in legal text a bad machine translation can genuinely distort what a refund clause says.

Second: forgetting the checkout. Product pages get translated beautifully, and then the payment button and form fields are still in the original language. Shoppers get most of the way through the funnel and stall right where the order was supposed to happen.

Third: hreflang tags that point at themselves or at a page that no longer exists. This happens when a translated product gets deleted and the link to it from other language versions never gets cleaned up.

And a less technical one: shipping a new language version without even a quick pass from an actual native speaker. Machine translation plus fifteen minutes of someone who really speaks the language, and most of the awkward bits disappear before launch.