A Multilingual Website That Actually Works

This site exists in Dutch, English and Spanish, so this article is partly a description of our own decisions and the ones we got wrong first.

Translating the words is the part everyone plans for. The part that breaks projects is everything around it.

Decide what you are actually doing

Three different things get called "multilingual", and they need different answers.

Same content, different languages. One business, one offer, three audiences. This is most companies and it is the simplest case.

Different content per market. Different services, different prices, different legal requirements. Now you have three sites that share a design.

Same language, different countries. Spanish for Spain and Spanish for Mexico, or Dutch for the Netherlands and Belgium. Different currency, different terms, sometimes different vocabulary.

Get this decision wrong and you will fight your own architecture for years. Most small businesses need the first, and adopt the machinery of the third because a plugin offered it.

URL structure

Three options, and the choice is close to permanent.

Subdirectories — example.com/nl/, /en/, /es/. All the authority accumulates on one domain, one certificate, one setup. This is what we use and what we recommend for almost everyone.

Subdomains — nl.example.com. Cleaner separation, but you are dividing your authority across hosts for very little benefit.

Country domains — example.nl, example.es. The strongest local signal and by far the most work: separate domains, separate hosting, separate authority to build from zero. Worth it if you are running genuinely separate country operations, and a trap otherwise.

Whichever you pick, the language must be in the URL. A site that shows different languages at the same address cannot be indexed properly, cannot be shared, and cannot be bookmarked in the language someone wanted.

hreflang, and the three ways it goes wrong

hreflang tells search engines that these pages are the same content in different languages, so the right one gets shown to the right person and they do not compete with each other.

The rules are short and unforgiving:

Every version must list every version, including itself. If your Dutch page declares the English one but the English page declares nothing, the relationship is broken and gets ignored.

Include x-default. This says which version to serve someone the others do not fit.

Use the right codes. Language, or language-region: "es", or "es-ES" and "es-MX". Not "es-latam", which is not a thing.

The three failures we see most often, in order: return links missing on one version; hreflang pointing at a URL that redirects rather than the final one; and hreflang on pages that are not actually translations of each other, which happens when someone reorganises one language and not the others.

Search Console reports hreflang problems, and it is worth looking after any structural change.

Language detection: do it gently

The pattern that annoys everyone is automatic redirection based on IP. A Dutch speaker travelling in Spain gets a Spanish page. Someone deliberately opening the English version gets bounced back. A crawler based in the United States only ever sees one version.

Something like this works better: check for a saved preference first, then the browser's Accept-Language header, then country as a weak hint, and default to your main language if none of that helps. Then let the visitor override it, remember what they chose, and never redirect them again.

The visible part matters too. The language switcher should show each language in that language — Nederlands, English, Español, not flags. Flags are countries, not languages, and they get this wrong constantly: which flag do you use for English, and how does a Belgian feel about the Dutch one?

Keeping three versions in step

This is where multilingual projects actually die. Not in translation — in drift. Someone updates the prices in Dutch. Three months later the Spanish page still shows last year's.

Two things prevent it.

Structure the content so a missing translation is impossible to ignore. In our case every piece of text is typed as a record with all three languages required, so adding a language makes the compiler list every string that is missing rather than quietly serving English. If your CMS can enforce something similar, turn it on.

Have one moment where translation happens. Not "we will translate it later", which means never. Either it ships in three languages or it does not ship.

The details that get forgotten

• The lang attribute on the html element, correct per page. Screen readers use it to choose pronunciation.
• Dates, numbers and currency formatted per locale. 1.495 in Dutch and Spanish, 1,495 in English. Getting this wrong makes a price look ten times bigger or smaller.
• Forms and error messages, which are usually the last thing anyone translates and the first thing a customer sees when something goes wrong.
• Emails. The confirmation after the contact form should be in the language they used.
• Legal pages. Privacy statements and terms need to be in a language the customer understands, and in some contexts that is a requirement rather than a courtesy.
• The 404 page, which is exactly when someone is already frustrated.

On machine translation

Use it for the first draft, then have someone who speaks the language read every line. That combination is dramatically faster than translating from scratch and produces text that reads as though a person wrote it.

Published raw, machine translation produces prose that is grammatically fine and subtly wrong in tone — and in a market where you are already an outsider, that is exactly the impression you cannot afford. It is also the one shortcut whose cost lands entirely on the market you were trying to enter.