Setting up multilingual websites: hreflang, addresses, pitfalls
A second language is the cheapest way to gain reach — the substance already exists. It is also where most technical mistakes happen, because four things have to be right at once and three of them are invisible.
In short
- Subdirectories (
/en/) are the right choice for most companies — simpler than separate domains, more effective than parameters. - hreflang has to be reciprocal: every version points to all the others, to itself, and to a default version.
- Addresses belong translated too. An English text under a German address is half a move.
- Automatic redirection by browser language is the most common serious mistake — it locks out crawlers and users alike.
The technical side of a multilingual site is manageable if you set it up correctly once — and laborious if you correct it afterwards. Which is why the half hour beforehand pays off.
The address structure
| Variant | Example | Suits |
|---|---|---|
| Subdirectory | example.com/en/ | nearly everyone – one domain, one strength |
| Subdomain | en.example.com | separate systems or operators |
| Country domain | example.de | independent market presences with their own team |
| Parameter | example.com/?lang=en | nothing – avoid |
Subdirectories win nearly always, because every language version benefits from the strength of the same domain. Separate country domains require each to be built up individually — worth it only with a team per market.
Getting hreflang right
Four rules that have to hold together. Break one and the whole group is often ignored.
- Reciprocal. If the German version points to the English one, the English one has to point back. One-sided annotations get discarded.
- Self-reference. Every page also points to itself. Frequently forgotten and not optional.
- Specify a default. An
x-defaultfor all languages not covered. - Absolute addresses. Complete with protocol and domain, no relative paths.
de for German generally, de-CH for German in Switzerland. If you have only one German version, use de — not de-CH. Otherwise German and Austrian visitors will not have the version matched to them.
Six mistakes that make a multilingual site invisible
1. Automatic redirection by browser language
The most serious mistake. Crawlers usually arrive with an American language setting and then never see the other versions. Users also no longer reach where they intended to go.
Right: show a notice with a suggestion, but do not redirect. Remember the choice.
2. Addresses not translated
/en/impressum/ instead of /en/legal-notice/. It reads as a half-finished version — and throws away the search term in the address.
Right: translate address segments per language, fix them permanently, and do not change them again.
3. Canonical pointing at the main language
If the English page gives the German one as its canonical address, you are saying: this page is a duplicate, take the other. It disappears from the index.
Right: every language version is its own canonical address.
4. Missing lang attribute
<html lang="de"> missing, or identical across all versions. This affects not only search engines but screen readers — where it produces unintelligible pronunciation.
Right: the correct code per version, set automatically.
5. One sitemap for everything, with no language annotations
Without hreflang annotations in the sitemap, the connection between versions is missing at the place where it would be recognised most easily.
Right: hreflang either in the sitemap or in the <head> — consistently in one place.
6. Partly translated pages
Headings translated, body text still in the original. For search engines that is a page with no clear language — and for visitors a trust problem.
Right: better fewer pages complete than all of them half done.
Worth knowing
Translating alone is not enough — four things have to be adapted to the country rather than only the language: amounts in the local currency, the applicable legal position, locally familiar examples, and date formats.
An English version quoting Swiss francs and the revised Swiss Data Protection Act is not a version for the British market but a translation of the Swiss page. That can be deliberate — but it should be a decision, not an oversight.
Upkeep is the actual problem
Setting it up is a one-off effort. Upkeep is permanent — and that is where multilingual sites fail more often than on the technology.
After a year the typical picture looks like this: the main language has 40 pages, the second 31, the third 22. Changes were made in the main language and forgotten in the others — and nobody knows any more which version is current.
Only one structural decision helps: a change counts as finished only when it has been carried into every language. If you cannot sustain that, offer fewer languages — three maintained ones clearly beat eight outdated ones.
Checklist before launch
- Every page points via hreflang to all versions, to itself, and to x-default
- Every version is its own canonical address
<html lang>is set correctly per version- Address segments are translated and permanently fixed
- No automatic redirection by browser language
- The language selector is visible and works without JavaScript
- Amounts, legal references and examples are adapted, not only translated
- There is a fixed process carrying changes into every language
Check the multilingual setup of my website. Details: - Domain: [address] - Languages: [list with language codes] - Address structure: [subdirectory / subdomain / own domain] - hreflang block of a sample page: [paste block] - Canonical annotation of the same page: [paste] - lang attribute of the same page: [paste] - Is there automatic redirection by browser language? [yes / no] - Are the address segments translated? [example per language] Tasks: 1. Check the four hreflang rules: reciprocal, self-reference, x-default present, absolute addresses. Name every breach individually. 2. Check whether the language codes are chosen correctly – particularly whether a region annotation is drawn too narrowly. 3. Check canonical and lang attribute for contradictions with the language version. 4. Name the points from my details that could make a language version invisible, sorted by severity. 5. Output the corrected hreflang block in full. Do not invent addresses – mark anything missing as [to be added].
In closing
Technically, a multilingual site is decided in four places: address structure, reciprocal hreflang, its own canonical address per version, no automatic redirection. Get those four right and the rest follows.
The real question afterwards is organisational: can you carry every change into every language? If not, fewer languages is the better decision.
Common questions
Which address structure is best for multilingual websites?
Subdirectories such as /en/ for nearly all companies: every language version benefits from the strength of the same domain, and administration stays simple. Separate country domains only pay off for independent market presences with their own team; language parameters in the address should be avoided.
What has to be considered with hreflang?
Four rules at once: the annotations have to be reciprocal, every page has to point to itself as well, there has to be an x-default for languages not covered, and all addresses have to be absolute. Break one rule and the entire group is often ignored.
Should visitors be redirected automatically to their language?
No. Crawlers usually arrive with an American language setting and then never see the other versions; users do not land where they intended. The right approach is a notice with a suggestion that remembers the choice made — without automatic redirection.
Do the addresses have to be translated?
Yes. An English text under a German address reads as half-finished and throws away the search term in the address. Address segments should be translated per language and then fixed permanently — later changes cost the visibility already built up.
How many languages make sense?
As many as can be maintained permanently. The most common state after a year is versions of differing completeness where nobody knows any more which is current. Three maintained languages work considerably better than eight outdated ones — what decides is a fixed process carrying every change into every version.
Marketing that sets itself up
The Studio Engine beta is live. Claim your spot and help shape it from the start.
Join the beta →