Multilingual Website Development: Structure, URLs and Workflow
Adding languages to a website is rarely just translation. It changes URL structure, adds a set of reciprocal tags that break silently, and introduces a content workflow where one page becomes twelve pages that can drift apart.
This guide covers the structural decisions, the technical requirements, and the workflow that keeps translations from going stale.
Decide the URL pattern first#
This is the decision that is expensive to reverse, because it touches every URL, every redirect and every hreflang tag on the site.
| Pattern | Example | When it fits |
|---|---|---|
| Subdirectory | site.com/de/guides | Most sites — simplest, one domain accumulates authority |
| Subdomain | de.site.com/guides | Separate infrastructure or separate teams |
| Country domain | site.de/guides | Strong local commitment, and a separate site to run |
| Parameter | site.com/guides?lang=de | Avoid — weak signals, duplicate risk |
Decide separately whether the slug is translated. Translated slugs help local relevance; identical slugs are simpler to maintain. Either is defensible — changing your mind later is not.
The technical requirements#
Each of these fails silently, which is why multilingual sites so often have no working hreflang despite having the tags.
- Reciprocal hreflang. Every page in a language set lists every other, including itself. One missing reverse reference discards the cluster.
- Consistent codes. The same code in the HTML and in the sitemap. Two codes for one page breaks the set.
- x-default pointing at the language selector or the default version.
- Correct lang and dir attributes on the html element for every version.
- Self-referencing canonical per language — never canonicalise translations to the original.
- No automatic redirection by IP or browser language. It breaks crawling and overrides a deliberate choice; offer a suggestion instead.
- Translated metadata. Titles and descriptions in the target language, not the source.
A translation workflow that survives#
The failure mode is not the first translation, it is the fifth edit to the English page that never reaches the other eleven.
- Model translations as linked versions of one content item, so the system knows they belong together.
- Track which translations are outdated relative to the source, and show it in the editing interface.
- Decide what happens when a translation is missing: fall back to the default, or do not publish that URL at all.
- Never publish a URL that has no translation — a page that half-renders in another language is worse than not existing.
- Keep a review date per language, not per content item.
- Give translators context: a screenshot or a preview beats a spreadsheet of strings.
- Decide who owns each language. Unowned languages go stale first.
Machine translation as a starting point is fine; publishing it unreviewed is not. Unreviewed output reads as unreviewed, and it is exactly the kind of low-value content search engines are increasingly explicit about.
Beyond text#
Translation is the part everyone budgets. These are the parts that get missed and cause visible errors.
| Item | What changes |
|---|---|
| Dates and numbers | Format and separators differ by locale |
| Currency | Symbol, position and rounding conventions |
| Addresses and phone numbers | Field order and validation rules |
| Names | Given and family name order is not universal |
| Text length | German and Finnish run long; layouts must flex |
| Reading direction | Arabic and Hebrew need logical CSS properties |
| Images with text | Need a version per language, or no text in the image |
| Legal pages | Requirements differ by jurisdiction, not only by language |
Frequently asked questions
Should I redirect visitors to their language automatically?
No. Automatic redirection based on IP or browser language interferes with crawling — a crawler from one country may never see the other versions — and it overrides deliberate choices, which is infuriating for anyone reading in a second language. Show a dismissible suggestion and let the visitor decide.
Is machine translation acceptable?
As a first draft, yes, and it saves real money. Published without human review it produces content that reads as machine-generated, which affects both users and search quality assessment. The pragmatic approach is machine translation plus a native reviewer, especially for pages that sell or explain something important.
What breaks hreflang most often?
Non-reciprocal tags: page A lists B, B does not list A, and the whole cluster is ignored. Second is mismatched codes between HTML and sitemap. Both are avoided by generating hreflang from a single source of truth rather than maintaining two lists.
Do I need to translate the whole site?
No, and partial translation is normal. Translate what has demand in that market and let the rest exist only in the source language. What you must not do is publish an empty or half-translated URL — either the page exists properly in that language or it does not exist at all.
multilingual websitehreflangwebsite translationinternational seomultilingual cmslocalization
