Building a Multilingual Website: What Actually Matters

The most common misconception about multilingual websites: take the existing site, have the text translated, done. Technically this often even works. The English version goes live, looks fine, and nobody finds it.

The reason is that a language version is a separate page as far as search engines are concerned, and it needs its own signals. Without them one of two things happens: Google treats the versions as duplicate content, or Google serves users the wrong language. Both cost you visibility.

This article covers what a multilingual site actually consists of, which mistakes recur most often, and how to recognise a considered proposal.

When multilingual makes sense

Not every business needs a second language. It is justified in reasonably well-defined situations.

International customers or investors. Research-adjacent and export-oriented companies need an English version because their counterparts sit abroad.

Audiences within one country who speak another language. A substantial share of small business in Germany is run by people whose first language is not German. Reaching that group means addressing them in their own language. This is not about prestige. People make decisions more comfortably in their first language.

Border regions and multilingual markets. Selling into Austria, Switzerland or neighbouring countries brings its own linguistic requirements.

A poor reason is the assumption that more languages automatically mean more reach. A neglected second version with outdated content does more harm than good.

Three decisions before any code

URL structure

Three common approaches.

Subdirectories such as example.com/de/ are the right choice for most projects. All language versions share one domain's authority, administration is simple, hosting stays singular.

Subdomains such as de.example.com separate versions more strongly. This can make sense when country organisations operate independently, but it adds overhead.

Country-code domains such as example.fr send the strongest geographic signal but are expensive to acquire and maintain and share no authority between them.

For a mid-sized company with two to four languages, subdirectories are almost always correct.

Language or region

Are you targeting a language or a country? These are not the same. English for the UK and English for the US are different audiences with different spellings and pricing. If you need one general English version, mark it up as such rather than tying it to a single country.

Full translation or partial

Must every page exist in every language? Frequently not. A blog article about local regulation needs no translation. What matters is that the implementation handles this and does not point to pages that do not exist.

hreflang: where it usually breaks

hreflang markup tells search engines which language versions of a page exist and who they are intended for. It is the most important technical component and simultaneously the most error-prone.

Four mistakes recur constantly.

Missing reciprocity. If the German page points to the English one but the English page does not point back, Google ignores the entire annotation. All language versions must reference each other, and every page must also reference itself.

Relative instead of absolute URLs. hreflang references require full URLs including protocol and domain.

References to redirected or non-existent pages. If a language version does not exist, it must not be annotated. Automatically generated references to theoretically possible but practically absent pages are a widespread fault.

Missing x-default. This entry tells Google which version to serve users for whom no matching language exists. Without it, Google decides on its own.

These errors are invisible. The site looks entirely normal to visitors. It only becomes apparent when Search Console shows the wrong language version appearing in results, or when language versions are not indexed at all.

Why translation plugins are problematic

Common content management systems have extensions that make a site multilingual at the click of a button. The appeal is obvious: fast, cheap, no restructuring.

The problems surface later.

Machine-generated translations without editorial review read poorly and offer little value to search engines. Technical terminology, product names and legal wording suffer first.

Then the technical side. Some solutions generate language versions via URL parameters rather than clean paths, implement hreflang incompletely, or reference pages that do not exist. I have taken over projects where exactly this had happened and Google served the wrong language version for months. Correcting it took more effort than doing it properly would have in the first place.

A further point concerns maintenance. When text changes in the primary language, translations drift apart unless a process exists. A year later the English version quotes a price that no longer applies.

What gets forgotten

Beyond the text itself, several details separate a translated site from a genuinely multilingual one.

• Per-language metadata. Title and description in search results must be translated, otherwise a German snippet appears in English search.
• Language declaration in the markup. Screen readers use this to select pronunciation.
• Formats. Dates, numbers, currencies and addresses differ.
• Forms and error messages. Often overlooked because they live in code rather than the CMS.
• Legal pages. Imprint and privacy policy should be available in every language offered.
• Images containing text. Graphics with baked-in text need per-language versions or should be designed text-free.
• The language switcher. It should open the current page in the other language, not the homepage. And languages belong in their own spelling: Deutsch, English, Українська.

That last point seems minor but is constantly got wrong. If a user switches language on a subpage and lands on the homepage, they are usually gone.

A practical example

For an artist I built a presence in four languages: Ukrainian, English, Polish and German. Four languages means four complete versions of every page, four sets of metadata, and for individual works their own descriptions.

The lesson from it: translation volume is calculable in advance. The real work sits in the structure that prevents versions from drifting apart. When a new work is added, it must be clear what is maintained in which language and what happens when a language is missing.

On a project for a translator with four language pairs, a second lesson emerged: German legal requirements such as the Impressum and privacy policy belong in the plan from the beginning, not at the end. Retrofitted across four language versions, it is unnecessarily tedious.

What multilingual sites cost

An additional language does not double the price. Design, concept and technical foundation happen once. What is added:

• Building the language structure and hreflang annotation, one-off
• Translating the content, depending on text volume
• Translated metadata for every page
• Additional review effort per language version

As a guideline: on a well-planned project a second language adds roughly 20–40 percent, each further language less. This assumes multilingual capability was planned from the outset.

Retrofitting costs more because URL structure, data handling and navigation have to be rebuilt. If you even suspect a second language is coming, say so in the first conversation. Preparing the structure costs almost nothing. Retrofitting it costs noticeably.

My pricing for multilingual sites starts at €3,900. Translation is not included unless explicitly agreed.

How to recognise a considered proposal

• You are asked which languages and which target regions, not just how many
• The URL structure is named and justified
• hreflang and x-default come up
• It is clarified whether every page really needs to exist in every language
• Translated metadata is part of the scope, not just body text
• There is an answer to how you will maintain content going forward

If a proposal lists multilingual capability as a line item with a flat price and asks none of these questions, a plugin is probably what is meant.

Frequently asked questions

Is machine translation good enough? For comprehension, yes. For a public company site, no. Unedited machine output is linguistically unreliable and damages the impression. Machine pre-translation with human editing is the sensible middle ground.

Does duplicate content across languages hurt? No, provided the language versions are correctly annotated. Translated content does not count as duplicate content. Problems only arise when hreflang is missing or incorrect.

Should language switch automatically based on browser settings? With caution. Automatic redirection can impede crawling and frustrates users who deliberately chose another language. A visible suggestion with a choice is better, while the requested URL remains accessible.

How do I verify my hreflang implementation? Google Search Console provides international targeting reports. For a technical pass, a crawler such as Screaming Frog, free up to 500 URLs, reliably finds missing reciprocity.

Do I have to translate everything? No. Translate what is relevant to the respective audience. What matters is that the implementation correctly reflects which pages exist in which language.

Summary

Multilingual capability is a structural decision, not a translation task. Text is the visible part, but the work sits in URL structure, correct annotation, and a maintenance process that keeps versions from drifting apart.

Plan it from the start and you pay a manageable surcharge. Retrofit it and you pay for the rebuild.

If you are weighing whether and in which languages your site makes sense, tell me who you want to reach. Sometimes the honest answer is that one well-executed language does more than three half-finished ones.