Russian/Uzbek multilingual sites: Cyrillic, Latin and clean SEO
Two language versions are standard on Uzbek projects. The complication is that Uzbek has two scripts, and most sites break indexation on exactly that.
Three URL structures and which one to pick
Subdirectories (site.uz/ru/, site.uz/uz/) are the sane default. All link equity accumulates on one host, and in Next.js it is a [locale] segment in the App Router plus middleware redirecting the root to the default language.
Subdomains (ru.site.uz) require separate SSL handling and split domain authority. Separate ccTLDs only make sense with distinct legal entities and pricing, which is rare locally.
Query parameters like ?lang=uz are the worst option: the crawler sees one URL with shifting content. If you inherited this, migrating to subdirectories with 301 redirects is the first job.
Cyrillic and Latin: two languages, not three
Building three versions — ru, uz-latn, uz-cyrl — is tempting since older readers prefer Cyrillic. But to a search engine those are two near-identical documents, and you get internal cannibalisation across all Uzbek keywords.
The practical answer: one canonical Uzbek version in Latin script, with Cyrillic offered as an optional client-side transliterator. The script switch changes rendering via JavaScript while URL, canonical and hreflang stay untouched.
Transliteration hooks into text rendering: a function walks text nodes and substitutes characters from a mapping table, with the choice persisted in localStorage. One document stays indexed; the reader gets their familiar script.
Getting hreflang right
Every page needs a complete set of reciprocal links: hreflang="ru", hreflang="uz" and a mandatory hreflang="x-default". Reciprocity matters — if the Russian page points at the Uzbek one, the Uzbek page must point back, or Google discards the whole cluster.
Codes follow BCP 47. uz-Latn and uz-Cyrl are valid when scripts are explicit, but with a single Uzbek version plain uz is correct. Add a region only when currency or delivery differs: ru-UZ versus ru-RU.
In Next.js hreflang comes from alternates.languages in the metadata object and must appear in server-rendered HTML. Links injected by scripts after load are frequently ignored.
What breaks in practice
The most common failure is a canonical pointing from the Uzbek version to the Russian one, which drops Uzbek pages from the index entirely. Canonical must be self-referential; hreflang alone expresses the language relationship.
Second is automatic redirection based on Accept-Language or IP geolocation. Googlebot crawls from US addresses and only ever sees one version; the other never gets indexed. Language detection belongs in a dismissible banner.
Third is half-translated pages where headings are Uzbek but product cards fell back to Russian. Google classifies those as thin content. Better to withhold a section than ship it half done.
Small technical details that show
The html lang attribute must change with the version — hyphenation, spellcheck and screen readers depend on it. The Uzbek Latin apostrophe (o‘, g‘) is U+02BB, not a typewriter quote; otherwise search for gʻisht and g'isht return different results.
Uzbek strings run noticeably longer than Russian, and buttons overflow. Test narrow UI elements against the longest locale, not the Russian one.
Use a single sitemap with xhtml:link blocks inside each <url>, so Google receives language relationships even for cached HTML.
Organising the translations themselves
Keep interface strings in per-locale JSON dictionaries and content in a CMS with a field per language. Do not mix the two flows: the interface changes with releases, content changes constantly.
Build in a fallback: a missing translation renders the default language but flags the page for an editor. A silently empty field is worse than an untranslated one.
Budget for professional Uzbek translation runs roughly 300,000 to 800,000 UZS per notional page depending on subject matter. Machine translation is unacceptable for legal and medical sections.