Multilingual Website: How to Build One, What to Translate and How to Set Up SEO

A multilingual website is a site where every page has versions in several languages, each with its own address, and visitors can switch between them. Google shows a properly built multilingual site to the right audience: the German version to people in Germany, the English one in the US, the Ukrainian one in Ukraine.

Below: whether you need several languages at all, how translation differs from localization, how to choose a URL structure and set up hreflang, which tools to use on WordPress, and what to check before launch. Our own site is bilingual, so we’re writing from practice.

Do you need several languages?

Each language version isn’t a one-off job but an ongoing cost: prices, news and case studies all have to be updated in several languages. So first decide how many languages you really need.

• Export and international B2B. One well-made English version is often enough. We’ve built such sites for metal trading companies from Austria, the Czech Republic and China: JetHummel, Stellata and Zionmet. Their customers are procurement teams from different countries, and English is the working language for all of them. Here one good English version is more useful than five weak translations.
• Selling to consumers abroad. Here you need the language of each market: a German shopper searches in German and buys where everything is clear in German.
• Markets with language laws. Some countries regulate the language of commercial websites. In Ukraine, for example, under Article 27 of the state language law, in force for websites since 16 July 2022, websites of companies registered in Ukraine that sell goods and services there must have a Ukrainian version with no less information than the other versions, loaded by default for users in Ukraine. If you enter a new market, check whether it has similar rules.

A good rule: add a language when there’s a market for it, a person who will answer customers in that language, and a budget to maintain the version. A language added “just in case” usually stays half-translated.

Translation or localization

Translation carries the text into another language. Localization adapts the site to the market: language, formats, prices, legal requirements, examples, search queries.

For a small company website, a good translation with localization of the key places is often enough: headings, the first-screen offer, prices, contacts and legal pages. Full localization is needed when the market is a main one.

What to localize besides the copy

• Search queries. People in different countries search for the same thing with different words. Research keywords for each market separately instead of translating your existing ones: “website development” and “web design agency” are different queries with different results.
• Formats. In the US: month/day/year dates, inches, pounds and 12-hour time; in most EU countries: day.month.year, the metric system and 24-hour time.
• Privacy. For visitors from the EU, the GDPR applies: you need consent to non-essential cookies before they’re set, and a clear privacy policy. In the US the rules depend on the state; California, for example, has the CCPA.
• Contacts. A phone number in international format, the time zone you respond in, the messengers popular in that market.
• Forms. Address fields, company name, a VAT number for B2B in the EU; don’t make fields required that the market doesn’t use.
• Images with text. Banners, infographics and screenshots with text in the original language are a separate item that’s often forgotten.
• System messages. Form messages, confirmation emails, the 404 page, cart buttons: everything the user sees.

URL structure: domains, subdomains or folders

Google tells language versions apart by their addresses, so each version must live at its own URL. Google describes several options:

For most company websites, folders are the most practical option: the main language at the root and the others in /en/, /de/ and so on. That’s how our site is built too.

And separately: don’t switch the language automatically based on IP address or browser settings. Googlebot crawls mostly from the US and may never see the other versions, and someone in Germany who wants English won’t be able to open it. It’s better to show a hint like “This page is available in your language” and a language switcher.

Hreflang: telling Google which version to show to whom

The hreflang attribute tells Google that pages are language versions of each other. Then a German searcher sees the German page and an American sees the English one, and the versions aren’t treated as duplicates. The rules from Google’s documentation:

• each version links to all the others and to itself;
• the links are reciprocal: if the English page points to the German one, the German page must point back to the English one, or Google may ignore the markup;
• codes follow ISO: en, de, uk, with a region if needed: en-GB, de-AT;
• x-default is the page for everyone whose language doesn’t match any version, such as a language selection page or the main English version;
• the canonical of each version points to itself, not to the original-language page.

Multilingual plugins for WordPress add hreflang automatically, but after launch it’s worth checking a few pages by hand: missing translations and addresses with and without a trailing slash are common causes of errors.

How to build a multilingual website on WordPress and site builders

• WPML is a paid plugin and the most common choice for complex sites: it translates pages, menus, fields and custom post types and integrates with WooCommerce. Our site runs on it.
• Polylang has a free version, is lighter than WPML and works well for company sites without a complex store.
• TranslatePress lets you translate right on the page in a visual mode; convenient for small sites.
• Site builders. Wix, Squarespace and Shopify have built-in language versions; what you can do depends on the plan, and there are usually fewer SEO settings per language.

If the site is being built from scratch, put multilingual support into the specification straight away: adding a language to a finished site where text is hard-coded into templates is much more expensive. What else to include in the specification is covered in our article on the website development specification, and how to choose a CMS in what a CMS is and how to choose one.

Machine translation and AI: fine, but with an editor

DeepL, Google Translate and ChatGPT produce a decent draft and make translation much cheaper. But publishing their output unchecked is a risk:

• native speakers notice unnatural phrasing immediately, and it lowers trust, especially in B2B;
• machines often mistranslate technical terms, service names and legal wording;
• Google’s spam policies explicitly list pages generated at scale, including through automated translation, that provide little value to users as a violation.

A workable process: machine translation as a draft, then editing by a native speaker or a translator who knows your industry, and for key pages, adaptation to the market’s search queries as well.

Common mistakes on multilingual websites

• One address for all languages. The language switches through a script or a cookie while the page address stays the same. Google sees only one version and misses the rest.
• Only the home page and menu are translated. A visitor switches language, opens a service page and sees the original text. Fewer pages translated in full is better.
• The switcher leads to the home page. Someone was reading an article, switched language and ended up on the other language’s home page. The switcher should open the same page.
• All versions’ canonicals point to the original language. Then Google treats the translations as duplicates and doesn’t show them in search.
• The same title and description in every language, or none translated at all, so a foreign searcher sees a snippet in the wrong language.
• The version was launched and forgotten. Prices, contacts and news are updated only in the main language, and six months later the other version shows outdated information.

What a language version costs

An exact figure is impossible without knowing the size of the site, but the costs always consist of the same parts:

1. The technical part: setting up the language versions, switcher and hreflang, translating templates, forms and emails. If multilingual support is planned from the start, it’s a small part of development; if it’s added to a finished site, templates may need to be reworked.
2. Translation and editing: depends on the number of words on the site and the industry. Technical, medical and legal texts cost more.
3. Localization: adapting headings and the offer to the market, keyword research, local case studies and reviews.
4. Maintenance: every change to the site also needs translating. Budget for it in your monthly website work.

Checklist before launching a language version

• Every page of the version has its own address and translated title and description.
• Hreflang is reciprocal, with x-default; each version’s canonical points to itself.
• The language switcher on every page leads to the same page in the other language, not to the home page.
• Language names in the switcher are in the language itself (“English”, “Deutsch”), not flags: a flag means a country, not a language.
• There’s no automatic redirect based on IP.
• Forms, messages, confirmation emails and the 404 page are translated.
• Prices, currency, date and phone formats fit the market.
• The privacy policy and cookie banner meet the market’s requirements.
• The sitemap includes all language versions, and the site is added to Google Search Console.
• There’s a person who answers enquiries in that language, and a plan for keeping the version updated.

Going multilingual is first a decision about markets, and only then about plugins. Start with one additional language for a market where there’s already demand, do it well, and only then add more. And for what goes into the budget of such a site, see our article on how much a website costs.