Multilingual Ecommerce Website Development: 7 Decisions to Make Before You Build

Multilingual or multi-regional? Define the scope first

Multilingual ecommerce website development means building an online store that serves product pages, search, checkout and order emails in more than one language, and usually in more than one country. Those are two different problems, and confusing them at the start is the most expensive mistake in the project.

Google draws the same line. A multilingual site offers content in more than one language. A multi-regional site explicitly targets users in different countries. A store can be both, for example French and English content for Canada plus a separate US version.

Spanish shows why the distinction matters. Spain, Mexico and the US all read Spanish, but they differ in vocabulary, currency and delivery. Write down a language-by-market matrix before you pick any tool: which languages, sold into which countries, in which currencies. Every cell you fill is something to translate, price, test and keep current.

My default advice is to launch with the languages where you already have demand and add the rest later. Each extra language multiplies your maintenance work, not just your launch work.

Decision 1: Choose a platform by how it stores and serves translations

Translation is a data-model question before it is a design question. Where does the French product title live, which URL serves it, and what happens when the English original changes? Platforms answer these differently.

The Shopify details above come from its localization and translation documentation as of October 2026. Plan limits change, so check the page before you commit to a language count.

The platform logo matters less than the translation workflow. Two or three languages with a stable catalog fit native tools comfortably. Many languages, per-market content differences or frequent catalog changes need a workflow with owners, statuses and review. If you are starting a store from scratch and want the language architecture designed in rather than patched on later, that is the kind of project covered by Netalith's custom eCommerce website service.

Decision 2: Pick a URL structure for each language

Google recommends a separate URL for each language version rather than switching content with cookies or browser settings. It also warns that Googlebot usually crawls from the USA and sends requests without an Accept-Language header, so content that changes by visitor language may never be crawled.

For most stores adding a second or third language, subdirectories on one domain are the practical choice: one host, one checkout domain, one analytics setup. Move to country domains when a market needs its own legal entity, payment setup or brand. That is a business reason, not an SEO one.

Localized words in URLs are fine. Google accepts them and internationalized domain names, as long as the URLs are UTF-8 encoded and properly escaped when linked.

Decision 3: Implement hreflang on product and category pages

Hreflang tells Google which pages are localized versions of each other. Google lists three equivalent ways to do it: HTML link elements, HTTP headers, or an XML sitemap. Pick one. Running all three adds maintenance and no benefit in Search.

The rules that break most stores, per Google's localized versions documentation:

• Every version lists itself and all the others. If page A points to B and B doesn't point back, the annotations may be ignored.
• URLs must be fully qualified, including https, not relative paths.
• Codes follow ISO standards. Language is ISO 639-1 (fr), region is ISO 3166-1 Alpha 2 (GB). A region alone is invalid, and UK or EU have no effect. Use en-GB for the United Kingdom. For Chinese use zh-Hans or zh-Hant to name the script.
• Add a catch-all for same-language variants. If you have en-IE, en-CA and en-AU, also publish a plain en page for everyone else.
• Add an x-default fallback for visitors whose language you don't serve.

A product page in three variants looks like this:

<link rel='alternate' hreflang='en-US' href='https://example.com/en-us/products/walnut-chair' />
<link rel='alternate' hreflang='en-GB' href='https://example.com/en-gb/products/walnut-chair' />
<link rel='alternate' hreflang='fr' href='https://example.com/fr/produits/chaise-noyer' />
<link rel='alternate' hreflang='x-default' href='https://example.com/en-us/products/walnut-chair' />

The same four lines go in the <head> of every variant. Google says x-default was designed for language-selector pages and works best there. Pointing product-page x-default at your default-language URL is a common convention, not a Google requirement.

Two points worth knowing. First, Google doesn't use hreflang or the HTML lang attribute to detect a page's language. It reads the visible content, so the main content must really be translated, not only the template. Localized pages count as duplicates only when the main content stays untranslated. Second, you don't need a translation of every product in every language. Missing languages on some pages are acceptable, but link new language versions back to your main language version. Give each language URL a canonical pointing to itself, because pointing the French canonical at English tells Google the pages are duplicates.

On Shopify, hreflang is added automatically for published languages and all published languages appear in the sitemap. Still check the rendered source of a product page, especially on custom themes.

Decision 4: Let people switch language without breaking crawlability

Do not redirect visitors automatically to another language version based on what you guess their language is. Google warns that such redirects can stop users and search engines from seeing all versions. It also advises against adapting content by IP location, because IP analysis is unreliable and most Google crawls originate in the US.

• Show a visible language and country selector on every page, in the header or footer.
• If you want to suggest a better version, use a dismissible banner instead of a forced redirect.
• Keep one language per page. Avoid side-by-side translations, and avoid translating only the navigation and footer while the main content stays in one language.
• Use a language-selector page as your x-default for the home page if you serve several markets.

Shopify requires a theme with a language selector before you can sell in multiple languages. It also warns that unpublishing a language turns its URLs into 404 errors, so set up redirects first. That is easy to forget when you retire a language that underperformed.

Decision 5: Decide what gets machine, human or hybrid translation

"Translate the store" hides a dozen content types with different risk. A practical split:

On SEO risk, Google's spam policies (last updated 28 August 2026) define scaled content abuse as many pages created mainly to manipulate rankings. Its examples include generating pages through automated transformations such as translating where little value reaches users. The test is value to the reader, not how the text was produced. Machine-translating your own catalog is not automatically spam, but publishing thousands of unreviewed pages is the pattern to avoid. Review the highest-traffic and highest-margin pages first.

Shopify's Translate & Adapt app lists free automatic translation for up to two languages, with manual translations beyond that. Confirm the current limit in the app listing before planning around it. Also note that Shopify's default SEO title and description fields reuse the translated product title and description automatically. Fields you customized need their own translation.

Decision 6: Localize currency, tax, shipping and checkout per market

A translated page with a wrong price or an untranslated payment step still loses the sale. Google also treats local language, currency, addresses and phone numbers as signals about the audience a page is meant for, so these details help search as well as customers.

If you use a third-party payment gateway or shipping app, check whether it supports your languages. Shopify notes that some apps don't support multiple languages by default, so ask the developer before you install.

Decision 7: Plan how translations stay in sync after launch

Launching a language is a one-off job. Keeping it current is a process. Every time the default-language title, price note or policy changes, each translation becomes stale. Shopify tracks this with Translated, Outdated and Untranslated statuses, and lets you export only outdated content for your translators. Whatever platform you use, you need the equivalent: a list of what changed and who updates it.

Netalith's own site is published in English, Vietnamese and French, so we work with the same constraint ourselves.

Before launch, run through this checklist for every language:

• Crawl each language folder and look for pages that still contain default-language text.
• Validate that hreflang return links exist on every variant.
• Place a test order in every language and currency, and read the confirmation email.
• Confirm all languages appear in the XML sitemap and that no unpublished language leaves 404s behind.
• Localize product feeds for Google Merchant Center and any marketplaces, since feeds are per country and language.
• Assign a named owner for each language's updates.

Shopify's warning about the default language is worth repeating for any platform. Changing the default language deletes existing translations for the language you switch to. Choose the default language deliberately before loading content, and export translations before any change.

What drives the cost of a multilingual ecommerce build

Multilingual ecommerce website development is priced to scope, and the same few factors move the number on every project:

If you want these factors turned into a scoped estimate for your languages, markets and platform, the lowest-commitment next step is Netalith's free quote form.