A Multilingual Website Without the Pain: hreflang, Localisation and the Mistakes That Cost Rankings
A second language usually gets added like this: take the copy, send it to a translator, paste the result back, put a switcher in the header. Three months later it turns out Google is showing the English page to Ukrainian visitors, the Ukrainian one to Poles, and some pages have dropped out of the index entirely.
Multilingual sites do not break on translation. They break on technical details, each of which costs rankings.
Three ways to organise languages
| Structure | Example | Advantages | Drawbacks |
|---|---|---|---|
| Subdirectory | site.com/en/ | Domain authority stays shared, simple to maintain | Harder to separate by country |
| Subdomain | en.site.com | Can be split across servers | Authority is divided, more configuration |
| Separate domain | site.co.uk | Strongest country signal | Most expensive, each domain ranks on its own |
For most companies the right answer is the subdirectory. Separate domains are justified when each country has its own legal entity, its own pricing and effectively a different business.
How hreflang works
It is a hint to the search engine: here is the same page in another language. Without it the versions compete with each other and the wrong one surfaces in results.
Three rules, violated more often than any others:
- Reciprocity. If the English page points to the German one, the German page must point back. A one-way reference is ignored entirely.
- Self-reference. Every page must include an hreflang pointing at itself. This is almost always forgotten.
- Absolute URLs. Full addresses with protocol only; relative paths do not work.
Set x-default separately as the version for visitors whose language matches none of yours.
Mistakes that cost rankings
| Mistake | What happens |
|---|---|
| Wrong language code | ua instead of uk. That is a country code, not a language, and the whole annotation is ignored |
| hreflang pointing at a non-canonical page | Conflicting signals, the engine decides for itself |
| Automatic redirect by IP | A crawler in a US data centre sees only English and never indexes the rest |
| One sitemap with no language annotation | Half the signals about version relationships are lost |
| Untranslated system pages | 404, cart and form messages stay in the original language |
| Identical titles and descriptions | Pages look like duplicates |
The most insidious is the automatic geo-redirect. It feels like consideration for the user, but in practice it blocks the crawler from every version but one. The correct solution is to suggest a switch with a banner and leave the choice to the visitor.
Translation and localisation are different things
Translation carries the words. Localisation carries the meaning and accounts for the market context.
What changes beyond the text:
- Formats. Dates, numbers, separators, currency, units of measurement.
- Length. German runs roughly a third longer than English, and buttons stop fitting their labels.
- Examples and case studies. A reference to a local company works better than an abstraction.
- Contacts. Phone format, address, opening hours in local time.
- Legal text. Privacy policies and terms are not translated literally; the requirements differ.
Technical traps
- The lang attribute. The
<html lang="en">tag must change with the version. It affects both search and screen readers. - Non-Latin slugs. They encode into unreadable strings, look poor in results and break when copied. Latin characters are safer.
- A switcher that goes to the homepage. Someone reading an article switches language and lands on the homepage. The switcher must lead to the same page.
- Unlinked versions in the CMS. If the system does not know these are translations of one page, hreflang will not be generated automatically.
- Cache that ignores language. The classic cause of visitors seeing the wrong language.
Pre-launch checklist
- Every page has hreflang for all versions, including itself.
- Language codes are correct:
uk,en,bg, notua. x-defaultis set.- The
langattribute matches the version. - No automatic redirects by IP.
- Titles and descriptions are unique per language.
- The switcher leads to the equivalent page, not the homepage.
- System pages and form messages are translated.
- Slugs use Latin characters.
- The sitemap contains all versions with language annotations.
A multilingual site pays off because the same work starts drawing traffic from several markets. But only if the search engine understands which version to show to whom. Anything less is one page competing against itself.
