Multilingual Websites: URL Structure, hreflang, and Translation Workflow

The most common multilingual mistake costs a site half its potential search visibility, and it is invisible from the front end: both language versions live at the same URL, so search engines index one and the other effectively does not exist.

Everything below follows from getting that right first. For remote production teams, a related reference is further reading, which looks at how activity signals should be interpreted.

Decide the URL structure

Three workable options.

Subdirectories — example.com/en/, example.com/fr/. The usual recommendation. Both languages accumulate authority on one domain, hosting is simple, and the structure is unambiguous to search engines.

Subdomains — fr.example.com. Workable. Slightly more setup, and authority is split more than most people expect. A useful archive of related web practice is available at A List Apart.

Separate domains — example.com and example.fr. Worth it when the two markets are genuinely separate operations with different content, not translations of each other. More expensive to maintain and each domain builds authority independently.

What does not work: swapping content in place at the same URL. Search engines see one page, and your second language is invisible to them regardless of how good the translation is.

hreflang, done properly

Each language version declares itself and its counterparts:

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

Five rules that catch people:

Annotations must be reciprocal. If the English page points to French, the French page must point back. One-directional annotations are ignored entirely.
Absolute URLs, always.
Every page needs its own set, pointing at its own counterpart — not at the homepage.
Include a self-reference. Each page's set should include itself.
x-default declares the fallback for users whose language you have not covered.

Language versus region. Use plain language codes (fr, de) when the content is the same for all speakers of that language. Use language-region codes (en-GB, en-AE) only when the content genuinely differs — different pricing, different legal terms, different products. Splitting identical content by region creates duplication for no gain.

The language switcher

A small component with disproportionate impact.

Label each language in its own name — "Français", "Deutsch" — not with flags. Flags represent countries, and languages are not countries. Several languages are spoken across many countries, and several countries have many languages.
Link to the equivalent page, not the homepage. Dropping a user from a deep page back to the front is the fastest way to lose them.
Use real crawlable links, not JavaScript handlers. If a search engine cannot follow the switcher, it may not discover the other version.
Detect and offer, do not force. Automatic redirection based on IP or browser language frustrates users and can prevent search engines from reaching versions. Suggest, remember the choice, and always allow an override.

Translation workflow

This is where multilingual sites decay, usually within a year.

Decide what gets translated and what gets rewritten. Product specifications translate. Marketing copy usually does not survive translation as persuasion — the references, rhythm, and humour belong to the original. Budget for rewriting the pages that have to persuade.

Machine translation is visible. On a commercial site it costs more credibility than having no second language at all. Use it for internal drafts if you like; have a human finish anything customer-facing.

Assign an owner per language. Without one, the second language falls out of date the first time the English changes, and nobody notices for months.

Plan for content drift. Every update to the primary language creates a task in the others. Build that into your process rather than discovering it after six months of divergence.

Translate everything, not just pages. The items most often forgotten: form validation messages, error states, email templates, PDFs and invoices, alt text, meta titles and descriptions, and 404 pages.

Design consequences

Text length varies significantly. German and Russian commonly run 20–35% longer than English; some languages run shorter. Layouts tuned to English text length develop overflow or awkward gaps. Design components to tolerate both.

Typography. Confirm your typeface covers the character sets you need — accented Latin, Cyrillic, Greek, and so on. Missing glyphs are substituted from a fallback font, and the mismatch is obvious.

Dates, numbers, and currency. Formats differ by locale: date order, decimal separator, thousands separator, currency position. Use locale-aware formatting rather than hard-coding.

Images with text in them. These require a separate version per language, and they are the reason to avoid text in images generally.

Technical checklist

[ ] Each language version has its own URL
[ ] lang attribute set correctly on every page
[ ] hreflang annotations reciprocal, absolute, self-referencing, per page
[ ] x-default declared
[ ] Sitemap includes all language versions, or one sitemap per language
[ ] Language switcher uses crawlable links to equivalent pages
[ ] No automatic redirection that blocks crawlers or overrides user choice
[ ] Meta titles and descriptions translated, not duplicated
[ ] Structured data localised where it contains text
[ ] Forms, error messages, and transactional emails translated
[ ] Both versions confirmed indexable in Search Console

Measuring it

Set up separate views or filters per language in your analytics, and check indexed page counts per language in Search Console.

The failure mode to watch for: one language ranking well while the other has almost no impressions. That usually points to an hreflang error or a crawlability problem in the switcher rather than to a content quality difference.

Is a second language worth it?

Not always. A second language doubles your content maintenance permanently, and a half-maintained version damages credibility more than a single well-maintained one builds reach.

It is worth it when you have evidence of demand — search volume in the target language, enquiries you currently cannot serve, a market you are actively selling into. It is rarely worth it as a speculative gesture.

If you are unsure, a smaller commitment works: translate the pages that convert — services, pricing, contact — and leave the blog in one language. Partial coverage done well beats full coverage done badly.

Строим сайты с расчётом на несколько языков с первого дня, а не дорабатываем потом. Услуги веб-дизайна