A multilingual website in Uzbek, Russian and English: structure, hreflang, translation

A multilingual website for Uzbekistan is usually built in three languages — Uzbek (Latin script), Russian and English — with each version in its own subfolder: /uz/, /ru/, /en/. So that search engines show people the right version, pages are linked with hreflang tags, and texts are not simply translated but adapted to each language's audience. Structure, URLs and meta tags must be consistent across all versions.

Let us look at how to choose languages, set up URLs and the technical side, organise translation and avoid the mistakes that cause one of the versions to "drop out" of search.

Which languages your site needs

The set of languages depends on your audience, not on a wish to "be like everyone else".

• Uzbek (Latin) — the state language and the main one for a broad audience, especially in the regions. For government websites and companies serving mass-market customers, this version is essential.
• Russian — still widely used in business, in Tashkent and in B2B communication. For many companies it is the main language of enquiries.
• English — for exporters, tourism, IT, and companies with foreign partners and investors.
• Uzbek in Cyrillic — sometimes needed for an older audience. Add it deliberately: it is one more version to maintain.
• Languages of target markets — if your buyers are in specific countries and prefer to read in their own language.

Decide in advance which language is primary (the one source content is written in) and whether every section will exist in every language. It is acceptable for the blog to run in only two languages — what matters is that this is a conscious decision, not an accident.

URL structure: subfolders, subdomains or domains

There are three ways to separate language versions:

• Subfolders (site.uz/ru/, site.uz/en/) — the most common and practical option. All versions live on one domain, share the site's authority and are easier to maintain.
• Subdomains (ru.site.uz, en.site.uz) — convenient if versions are technically different or run by different teams, but search engines treat them as more separate.
• Separate domains (site.uz, site.com) — justified when different countries need different brands, product ranges and legal entities.

For most companies subfolders are the best choice. What matters is that each language version of a page has its own permanent URL. A setup where the language changes via a cookie or script while the URL stays the same indexes poorly: the search engine sees only one version.

A separate question is whether to translate the page addresses themselves. Localised URLs are slightly clearer to users, but a single Latin URL across versions is easier to maintain. Pick one approach and stick to it across the whole site.

hreflang and technical SEO

The hreflang tag tells search engines that a page has versions in other languages and helps them show users the right one. Basic rules:

• Each language version references all the others and itself: uz, ru, en.
• Add an x-default value for the page shown when the user's language matches none of the available ones.
• References must be reciprocal: if the Russian page points to the English one, the English page must point back to the Russian.
• Each version's canonical points to itself, not to a "main" language version.
• The HTML lang attribute matches the page language.
• Titles, descriptions, image alt text and structured data are translated rather than left in one language.
• The sitemap includes all language versions.

Do not force-redirect users by IP or browser language: someone in Tashkent may prefer Russian, while a foreign partner may want to see the Uzbek version. It is better to suggest a language unobtrusively and remember the visitor's choice.

The language switcher: convenience in the details

• Place the switcher where it is easy to see — usually the top right corner of the header — and repeat it in the mobile menu.
• Write language names in the languages themselves: O'zbekcha, Русский, English. Avoid flags: a language is not a country.
• Switching should take the user to the same page in the other version, not to the home page.
• If a page does not exist in some language, say so honestly and offer the closest available version.

Translation and localisation

Machine translation is handy as a draft today, but a native speaker should edit it before publication. This is especially true for Uzbek: a literal translation from Russian often sounds unnatural, and industry terms get mistranslated.

1. Build a glossary — how your products, services, job titles and key terms are named in each language. This keeps every page consistent.
2. Define the tone — level of formality, how you address the reader, whether conversational phrases are acceptable.
3. Adapt rather than translate — examples, arguments and even the order of blocks may differ for a foreign buyer and a local customer.
4. Research keywords for each language separately: people phrase queries differently, and a direct translation of a Russian query does not always match what people search for in Uzbek.
5. Set up the process in your CMS so you can see which pages are untranslated or outdated after the source text was edited.

For more on writing copy in two languages, see our article on website copy in Uzbek and Russian.

A multilingual website is not one site with a translate button but several complete versions sharing one structure. Each must be equally convenient, clear and findable in search.

Designing for several languages

• Different text lengths. The same phrase takes up different space in Uzbek, Russian and English. Buttons, menus and headings must fit the longest version without awkward wrapping or truncation.
• Fonts. You need a typeface with full Cyrillic and Latin support that renders the apostrophe in o' and g' correctly. More in our article on fonts for Cyrillic and Latin.
• Text in images. Avoid it or prepare separate images for each language.
• Forms and error messages must be fully translated, including hints and confirmation emails.
• Downloadable documents — catalogues, presentations, price lists — in the same languages as the site, or clearly labelled with the file's language.
• Date, number and phone formats — consistent and familiar to the reader of each version.

How to keep versions up to date

The main difficulty of a multilingual site begins after launch. Prices, terms, contacts and news change, and if an edit is made in only one version, six months later the versions seem to describe different companies. To prevent this, agree on a few simple rules:

• Assign an owner for each language version — someone who proofreads and publishes texts.
• Any change to the source text automatically flags translations as needing an update.
• Critical data — prices, phone numbers, addresses, company details — is stored in one place and inserted into all versions rather than typed in by hand.
• Once a quarter, check the site against a list: do all pages exist in all versions, do the switcher and forms work, has any text appeared in the "wrong" language.

Such a routine takes little time but preserves the main advantage of a multilingual site — equal trust across all audiences.

Common mistakes on multilingual websites

• One language version is complete while the others are half-filled, with gaps and outdated texts.
• The language switches without changing the URL — search engines see only one version.
• No hreflang, or references that are not reciprocal.
• Meta tags and page titles left in one language across all versions.
• Machine translation published without editing.
• Mixed Latin and Cyrillic in the Uzbek version, different apostrophe variants on the same page.
• The switcher leads to the home page instead of the same page.
• New content is published in only one language, and over time the versions drift further apart.

Multilingual support is best planned from the start: adding languages to a finished site that was not designed for them is usually harder. If you are planning such a site, the Dasta Creative team designs the structure, sets up the technical side and helps localise content — see our web development page.