When you need a second language version
Not “just in case” — supporting each language costs money continuously: content, updates, replies to customers. A version is needed when there is a real audience segment: exports, foreign B2B clients, tourists, foreigners inside the country. A sign: analytics already shows traffic from other countries or with non-Russian browser languages.
URL structure: three options
- Subfolders — site.com/en/. The best option for most: all link weight works on one domain, cheap to maintain. This is where to start.
- Subdomains — en.site.com. Technically convenient for separating infrastructure, but search engines partly treat a subdomain as a separate site — the weight is diluted.
- Separate domains — site.de, site.fr. Maximum trust from a local audience and maximum cost: each domain is promoted from scratch. Justified for a large business with offices in the countries.
What not to do: language via a GET parameter (site.com/?lang=en) and, most importantly, automatic redirect by IP without a choice. Googlebot comes from the US: by forcibly redirecting all “Americans” to the English version, you hide the rest from it.
hreflang: telling search engines which language is where
The hreflang attribute links language versions of one page so that each user is shown their version in the results:
<link rel="alternate" hreflang="ru" href="https://site.com/ru/page/" />
<link rel="alternate" hreflang="en" href="https://site.com/en/page/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/en/page/" />The rules everyone stumbles over:
- The links are reciprocal: if the Russian page links to the English one, the English one must link back to the Russian one. One-sided hreflang is ignored.
- Each page links to itself too.
- x-default — the version for “all other” languages, usually English.
- hreflang goes on specific counterpart pages, not “homepage to homepage”.
Localization ≠ translation
Running the site through a translator is a road to zero conversion. What real localization means:
- Semantics from scratch. English queries are not a translation of Russian ones: the audience has different wording and different demand. The keyword core for each language version is built separately.
- Currencies, units, formats of dates and phone numbers.
- Ways to get in touch: WhatsApp instead of Telegram, local messengers and payment systems.
- Legal and trust: company details, certificates, case studies relevant to the market.
- Proofreading by a native speaker. Machine translation as a draft — fine; publishing without editing — not: both people and search engines spot it instantly.
Technical details that surface later
- A language switcher — on every page, leading to the same page of the other version, not the homepage.
- Untranslated pages — exclude them from the switcher and hreflang rather than showing an English heading with Russian text.
- A sitemap — with all language versions.
- Forms, emails, SMS, the “Thank you” page — also get translated, and everyone always forgets them.
Takeaway
Multilingualism is subfolders, reciprocal hreflang and honest localization for each market’s demand. Done once and carefully — it works for years. Planning an English version — we’ll help with the structure and implementation.
