Building a Multilingual Website: Architecture, SEO and a Translation Workflow That Survives

A multilingual website fails in one of two ways: it is built as a translation layer bolted onto a finished site, or it is built without deciding who maintains the second language six months later. This is the architecture we use, the SEO rules that make the extra languages actually visible, and the workflow that keeps them from going stale.

Decide what the second language is for

Before any technical decision, answer one commercial question: which market is this language for, and what do you want from it? The honest answers usually fall into three very different cases, and each implies a different build.

The third case is the one people underestimate. Translating a page is not the same as entering a market — the objections, the regulations and the payment expectations differ, and a literal translation of copy written for one country frequently reads as slightly wrong in another. Budget for adaptation, not just translation.

URL structure: pick one and never change it

There are three legitimate structures. All of them work; mixing them does not.

For almost every small and medium business, the subdirectory is the right answer. It is what we use by default, and the only situation where we recommend country domains is when a client genuinely operates as a separate local company with its own address, phone number and legal entity.

hreflang, done correctly

hreflang tells search engines that two pages are the same content in different languages, so the right one is shown to the right person. It is simple in principle and gets broken in practice more often than any other piece of international SEO.

On every page, list every version — including itself:

<link rel="alternate" hreflang="en" href="https://example.com/services/">
<link rel="alternate" hreflang="es" href="https://example.com/es/servicios/">
<link rel="alternate" hreflang="x-default" href="https://example.com/services/">

The rules that catch people out:

• Annotations must be reciprocal. If English points to Spanish, Spanish must point back to English. One-way references are ignored entirely.
• Use absolute URLs, with the protocol. Relative paths do not work here.
• Self-reference. Every page includes an annotation pointing at itself. Missing this invalidates the whole set.
• Point at canonical URLs only. Never at a redirecting or parameterised address.
• Language code first, region optional. Use es unless you genuinely serve es-MX differently from es-ES.
• Add x-default for visitors whose language you do not cover.

And the rule that saves the most trouble: each language version must be canonical to itself. Pointing the Spanish page's canonical tag at the English one — a surprisingly common plugin default — tells search engines to ignore the Spanish page completely.

A language switcher people can actually use

The switcher is a small component that carries a lot of weight, and there are four rules worth following.

• Write language names in their own language. "Deutsch", not "German". Someone looking for German may not read English.
• Do not rely on flags. Flags mean countries, not languages: Spanish is spoken in twenty countries, and Belgium alone has three official languages. Use text; add a flag only as decoration.
• Stay on the same page. Switching language from the menu page should land on the translated menu page, not the homepage. Every visitor who is dumped on the homepage has to navigate twice, and many simply leave.
• If a page has no translation, say so and offer the closest equivalent rather than silently redirecting.

Remember the choice in local storage so the visitor is not asked twice — but never let a stored preference override an explicit URL the person just clicked.

What actually has to be translated

People translate the visible text and forget the rest. The full list is longer than it looks, and the omissions are exactly what make a site feel half-finished:

• Page titles and meta descriptions — not just body copy
• Image alt text
• Form labels, placeholders, validation messages and the confirmation screen
• Button text, menu labels, breadcrumbs, the 404 page
• Automatic e-mails sent after a form is submitted
• Structured data fields that contain human-readable text
• PDFs, menus and price lists linked from the site
• Date, number and currency formats — 09/08/2026 means two different days in two different countries
• The privacy policy and any legal text

Machine translation: where it belongs

Modern machine translation is good enough for a first draft and not good enough for a homepage. Our rule is simple: machine-translate, then have a native speaker edit anything a customer reads before deciding to buy. For a restaurant that means the menu and the front page get human attention; a 2019 blog post can stay machine-translated with a note.

The workflow that keeps languages in sync

Every multilingual site drifts. Prices change in one language and not the other, a new service appears only in the original, and eighteen months later the second language is quietly wrong. The fix is process, not software.

• One source language. Everything is written in it first, always. Two "primary" languages guarantees divergence.
• A translation status per page. Up to date, needs review, or missing — visible to whoever edits.
• Changes go out as a set. A price update is not finished until every language has it. Treat it as one task, not one per language.
• Shared data, not duplicated data. Prices, opening hours and contact details live in one place and are pulled into every language. Numbers should never be re-typed per language.
• A quarterly review. Fifteen minutes with the page list open catches nearly everything before a customer does.

Six mistakes that quietly cost half the traffic

• Same URL for all languages, switching content by cookie. Search engines index one version and the others may as well not exist.
• Canonical tags pointing at the source language, which asks search engines to drop every translated page.
• Automatic IP redirects that trap crawlers and travellers in the wrong language.
• Translated body text, untranslated titles and descriptions, so the pages never rank for anything in the second language.
• Flags instead of language names, which is ambiguous at best and offensive at worst.
• No plan for maintenance, so the second language freezes on launch day and slowly becomes misinformation.

None of these are exotic. We find at least two of them on nearly every multilingual site we are asked to rescue.

Questions people ask about this