A multilingual site breaks somewhere other than where it gets tested. The translations can be excellent and the layout identical, and the versions will still either compete with one another in search or fail to appear at all. What follows is in order, including the failures that only show up in server logs.
1. One page, one URL, one language
Each language version needs its own address. A folder (/uz/) works, a subdomain works — what matters is that the address is stable and distinct.
What does not work: serving a different language at the same address based on a browser header. A crawler arrives with one set of headers and sees exactly one version; the rest do not exist as far as it is concerned.
2. hreflang has to be reciprocal
Every version lists all the others, including itself. If the Russian page points at the Uzbek one but the Uzbek page does not point back, the relationship is not counted and both pages stand alone.
Check this from every language, not from one. A one-way link is the single most common implementation mistake.
3. x-default is not "English by default"
x-default names the page for visitors whose language matched none of the ones listed. It is not a synonym for the English version and not "the homepage". The most sensible target is either a page where the visitor can choose, or the most complete version you have.
Without it nothing breaks, but the search engine has no answer to "what should everyone else see".
4. Language codes differ by layer — and that produces broken links
This one can cost you half a day. The same language may be named differently in three places:
-
in the URL — whatever you decided:
/kz/,/zh-CN/; -
in hreflang — per BCP 47:
kkfor Kazakh,zh-Hansfor Simplified Chinese; -
in the database or API — whatever the developer called it.
That is fine in itself, as long as the conversion between them lives in one place. The trouble starts when someone builds a link from a code taken from the wrong layer, and gets an address that does not exist.
5. Case in the URL: links lost quietly
If any language segment contains capitals — and zh-CN does — sooner or later it will reach you lowercased. Mail clients, editors, some proxies and people typing by hand all lowercase URLs.
Check what happens to /zh-cn/. The bad case: the server does not recognise the segment, treats it as part of the path, prepends the default language and redirects to an address that does not exist. Formally a 301, in practice a 404 at the end of the chain. The visitor is gone, and whatever inbound link pointed at you is wasted.
The fix is case-insensitive matching plus an alias table that folds any spelling into the canonical segment in a single redirect.
6. What the canonical should say when there is no translation
A common situation: an article exists in Russian and Uzbek, and the Korean URL shows the Russian text because that is how the fallback is configured.
If that page declares itself canonical, you are asking for Russian text to be indexed under a Korean address. It is better to point the canonical at the version whose text is actually being shown. Signals then collect on one page instead of spreading across seven copies of it.
And the converse: do not list languages in hreflang that have no translation. The set of alternates should match what actually exists.
7. The sitemap is part of hreflang too
Alternates can be declared in sitemap.xml via xhtml:link, not only in the <head>. That is easier to maintain: the relationship is described once, in a generated file, instead of being spread across templates.
Two conditions: only include addresses that return 200 without redirecting, and keep the set of languages in the sitemap identical to the set in the markup. A sitemap made of redirects is partly discarded.
8. Should the URLs themselves be translated
A translated slug (/uz/xizmatlar/sayt-yaratish rather than /uz/services/website-development) reads better and matches how people phrase the query.
The cost is that there is no way back. Once an address is indexed, changing it means redirecting the old one to the new one and keeping a history of those redirects. If you translate slugs, build the mechanism for storing retired addresses up front rather than bolting it on a year later.
9. The language switcher must not lose the page
Switching from any page should land on that page's equivalent in the other language, not on the homepage. Dropping to the homepage loses the visitor's context and breaks the relationship for the crawler.
Separately: switching must change the URL, not just the visible strings. If the address stays the same, a reload or a shared link reverts the language.
10. Translation is more than the visible text
The same things get forgotten every time:
-
<title>and the page description; -
the
langattribute on<html>; -
alttext on images; -
the strings inside structured data;
-
form error messages and the 404 page.
Checklist before launch
-
Every version has its own stable address.
-
hreflang is reciprocal — checked from every language, not one.
-
x-defaultpoints somewhere deliberate. -
A lowercased language segment does not end in a 404.
-
A page with no translation canonicalises to the version being shown.
-
The sitemap contains only addresses that return 200.
-
The switcher keeps the page and changes the URL.
-
title, description,
lang,altand the 404 page are all translated.
If a multilingual version is already live and you are not sure the relationships are set up correctly, we can check and show you where it breaks.