Multilingual websites: how to structure languages properly
How to build a website in more than one language so visitors and search engines find the right version, and the team can keep every language current.
The short answer
A website in more than one language is built as parallel versions of the same structure. Each language has its own addresses, usually a folder per language on one domain, the language is declared on every page, and each page links to its alternatives in the other languages so that search engines know they are versions of one page and serve the right one to each searcher. Content is structured so that every page exists once per language with the same identity, which keeps the language switcher exact, makes missing translations visible and lets one build produce every version. Visitors get a visible switcher that keeps them on the same page in the new language, no forced redirects based on their location, and dates, numbers and currency formatted for the language. The build is the easy part. Keeping every language current over years is the hard part, and it needs an owner per language and a workflow that flags what has changed in one language and not the others.
Structuring it properly
| Element | What we do | Why |
|---|---|---|
| Addresses | A folder per language on one domain | Shared authority; one site; clear to search engines |
| Language declaration | Declared on every page in the document and the alternate links | Search engines and assistive technology know the language |
| Alternate links | Each page lists every language version, including itself, plus a default | Search engines serve the right version; no duplicate content confusion |
| Content model | One entry per page per language, sharing an identifier | Exact switching; missing translations visible; one build |
| Switcher | Visible, on every page, keeps the visitor on the equivalent page | Visitors change language without losing their place |
| Detection | Optional dismissible suggestion; never a forced redirect | Respects choice; does not break crawling |
| Formatting | Dates, numbers, currency, addresses per language | Trust and correctness |
| Translatable interface | Navigation, buttons, form labels, error messages, alt text | Nothing left in the wrong language |
| Sitemap | Every version listed with its alternates | Complete indexing |
Building and running it
- Decide the languages and the default, and whether every page or only some will exist in each.
- Model content so each page has one entry per language sharing an identifier.
- Build the folders, declarations, alternates and switcher into the site’s templates once.
- Translate the interface, not only the content: navigation, forms, errors, alt text, metadata.
- Set the missing-translation policy and make it visible in the editing workflow.
- Assign an owner per language who approves translations and keeps them current.
- Flag changes: when the source language changes, the other languages are marked as needing review.
- Check alternate links, sitemaps and the switcher after every structural change.
Language versus market
Language and market are different axes. A Dutch business serving Belgium in Dutch and French, and international clients in English, has three languages and perhaps several markets. A small business should structure by language and handle market differences, such as currency or legal text, within the language versions. Separate market sites are a large-organisation pattern with large-organisation costs.
What this means for you
Build multilingual sites as parallel versions in language folders on one domain, with languages declared, alternates linked, content modelled once per language, a switcher that keeps visitors in place and no forced redirects. Then put the real effort where it belongs: an owner per language and a workflow that shows what is out of date, so every language stays as good as the first.
Frequently asked questions
Folders, subdomains or separate domains for each language?
Folders on one domain for almost every small business: they share the domain's ranking strength, they are one site to build and maintain, and search engines handle them well when the language is declared. Separate country domains suit large operations with distinct market presence and budgets to build each domain's authority. Subdomains sit awkwardly between and are rarely the right choice for languages.
Should we redirect visitors to their language automatically?
No. Detecting location or browser language and forcing a redirect gets it wrong often enough to be annoying: a Dutch speaker in Germany, an expat, a traveller, and search engine crawlers that arrive from one country and are redirected away from the version they came to index. Serve the address requested, show a clear switcher, and at most offer a polite suggestion banner that can be dismissed and remembered.
What happens when a page is not translated yet?
Decide the policy in advance. Either the page does not exist in that language, and the switcher says so or omits it, or a fallback shows the original language with a clear note. What should not happen is an empty page, a machine translation nobody reviewed presented as the real thing, or a silent redirect to the home page. The structure makes missing translations visible so the policy can be applied deliberately.
Sources
- Google Search Central: Localized versions of your pages (accessed 2026-09-12)