Multilingual Website SEO: hreflang, URL Structure, Mistakes

Why Separate Language Versions Matter for SEO

Search engines do not index “websites” or “languages” — they index URLs. If your Russian, English and Ukrainian copy lives at the same address and gets swapped by a script, Google sees one page with one set of content: whatever the server returned. A single URL cannot rank for queries in three languages — it has one title, one snippet and one content language.

Separate language versions solve several problems at once:

Independent indexing. Each version is a standalone document with its own title, description and body text that accumulates relevance for queries in its language.
Correct snippets. A user coming from English search results sees an English headline and description, not a Russian one.
New keyword universes. Every language is a whole layer of queries your site simply never appeared for before.

That is why the first step of multilingual SEO is not translation — it is architecture: every language version gets its own URL.

URL Structure: Subdirectories, Subdomains, ccTLDs or ?lang=

There are four common ways to separate languages by address, and they are far from equivalent.

Subdirectories (site.com/en/, site.com/uk/). All versions live on one domain and inherit its authority: backlinks, age, history. For most projects this is the optimal choice.
Subdomains (en.site.com). Search engines tend to treat subdomains as partially independent sites, so link equity gets split. Justified when the versions are technically different products.
ccTLDs (site.de, site.fr). The strongest geo signal and maximum trust from local audiences, but every domain starts from zero: its own link profile, its own budget, its own risks.
A GET parameter (?lang=en). The worst option: parameters often get collapsed by canonicalization, duplicates multiply easily, and the address tells neither users nor crawlers anything about the language.

Our default recommendation is subdirectories: the best balance of SEO impact and maintenance cost. You can see real implementations in our portfolio.

Client-Side JS Translation vs Pre-Rendered HTML

A common shortcut is to “go multilingual” with a JavaScript dictionary: the page loads in the primary language and a script swaps the strings once a language is picked. From an SEO standpoint, such a site remains monolingual.

There are several reasons. First, if all languages share one URL, separate indexing is impossible by definition. Second, content that only appears after JS execution is indexed slower and less reliably: rendering is a deferred, resource-intensive stage for Google, and many other crawlers — social network bots, LLM crawlers — do not execute JavaScript at all.

The right solution is pre-rendering, or “baked” translation: translations are injected into templates at build time or on the server, and every language URL returns ready-made HTML in the right language — with translated title, description and a proper lang attribute.

This is exactly how we built both our own studio site and the multilingual freelance marketplace 24freelance: three languages, separate /en/ and /uk/ paths, and fully translated markup in every server response.

hreflang Done Right: Reciprocity, Self-Reference, x-default

The hreflang attribute tells search engines that a group of URLs is the same page in different languages, and helps them serve the right version in the results. Annotations can live in three places: <link rel="alternate" hreflang="…"> tags in the <head>, an HTTP header, or the sitemap.

The key rules:

Reciprocity. If the Russian page points to the English one, the English page must point back. One-way annotations are ignored.
Self-reference. Every page includes an hreflang pointing to itself — without it the cluster is considered incomplete.
x-default. A dedicated annotation for the “fallback” version shown to audiences that match none of your languages. Usually the primary version of the site or a language-selector page.
Valid codes. Language per ISO 639-1, region (optional) per ISO 3166-1 Alpha-2: ru, en, uk or en-GB, pt-BR. The code for the Ukrainian language is uk, not ua — UA is a country code and is invalid in the language slot.
Absolute URLs — with protocol and domain.

And remember: annotations belong on every translated page, not just the homepage.

Common hreflang Mistakes

In our audit experience, hreflang is the most fragile part of multilingual SEO. These mistakes come up most often:

Missing return links. Page A points to B, but B does not point back to A — the annotation pair simply does not work.
Invalid codes. en-UK instead of en-GB, ua instead of uk, made-up regions. An invalid code is an ignored annotation.
hreflang pointing to redirects or 404s. Every URL in a cluster must return 200; a link to a redirect or an error page breaks the cluster.
Conflicts with noindex and canonical. A page blocked from indexing or canonicalized to another URL cannot participate in a cluster.
All versions pointing to the homepage. The alternate of an English article is the same article in other languages, not the site root.
“Alternates” with different content. hreflang connects translations of one page; linking pages with different meaning is not allowed.

Verify annotations with tools: Search Console reports and any SEO crawler surface broken pairs in minutes.

Canonical Tags on Language Versions

Canonical and hreflang solve different problems: canonical merges duplicates of the same page, hreflang connects different pages that are translations of each other. Translations are not duplicates, so the rule is simple: every language version points its canonical at itself.

The most destructive mistake on multilingual sites is a canonical from every language to the “main” version — say, from /en/services.html and /uk/services.html to the Russian /services.html. That tag explicitly tells the search engine “do not index the translations”, and they drop out of the results no matter how much hreflang you add. When signals conflict, Google usually trusts the canonical.

Practical rules: the canonical is absolute and self-referencing on every language version; hreflang references only canonical URLs (no parameters, no stray variants).

Sitemaps with xhtml:link: All Alternates in One Place

Instead of the <head>, hreflang can live directly in the sitemap via the xhtml:link extension. For every <url> entry you list all of its language alternates, including the URL itself:

<url><loc>https://site.com/en/page.html</loc> <xhtml:link rel="alternate" hreflang="en" href="https://site.com/en/page.html"/> <xhtml:link rel="alternate" hreflang="ru" href="https://site.com/page.html"/> <xhtml:link rel="alternate" hreflang="x-default" href="https://site.com/page.html"/></url>

The advantages: the markup does not weigh down every page's HTML; all relations sit in a single file that is easy to generate at build time; there is less risk of pages drifting out of sync.

The requirements are the same as for head tags: reciprocity, self-reference, absolute URLs, status 200. And remember to declare the xhtml namespace on the root <urlset> tag, or the file will fail validation.

Translating Meta Tags, Open Graph and Markup

Translating the visible content is half the job. It is the small things that betray a language version, and they are the ones most often left untranslated:

Title and description. They form the snippet and drive CTR. Do not translate them literally — rewrite them for the queries of each language.
The lang attribute on <html>. Helps search engines, screen readers and browser translators identify the document language correctly.
Open Graph and Twitter Cards. og:title, og:description and og:locale must match the page language, or social shares will display a headline in the wrong language. Use og:locale:alternate for the other versions.
Structured data. Text inside JSON-LD — organization name, descriptions, FAQ questions — must be translated too: rich snippets are assembled from it.
Alt texts, buttons, error pages, form emails. They do not affect rankings directly, but a half-translated site loses user trust.

Default Language and Auto-Redirects by Geo or Accept-Language

Which language should the site root serve? Usually the language of your primary audience, with the other versions moved into /en/ and /uk/. It also makes sense to declare the root version as x-default.

A dangerous temptation is to automatically redirect visitors to “their” version based on IP geolocation or the Accept-Language header. Here is why we advise against it:

Googlebot crawls predominantly from US IP addresses. A site with geo-redirects will stubbornly send it to the English version, and the other languages risk staying under-crawled.
Redirects break direct links: someone shares a Ukrainian page, and a recipient in another country lands on the English one.

The friendly alternative is an unobtrusive banner — “Looks like you might prefer the … version” — that remembers the choice. And crucially: the language switcher must be plain crawlable <a href> links to the same page in the other version — not a JS-only menu, and not a link to a foreign homepage.

Translation Quality: Machine, Human, Hybrid

Technically flawless multilingual architecture will not save weak translations. Search engines explicitly warn that machine-translated content published without editing or added value can be treated as scaled content abuse.

The workable scheme for most projects is a hybrid: machine or LLM translation as a draft, then proofreading by a person who knows the language and understands the domain. Special attention goes to:

Terminology. One glossary across all pages: if “order” is translated three different ways in the UI, the articles and the emails, trust erodes.
Closely related language pairs. Proximity is deceptive: for Russian and Ukrainian, raw machine output looks plausible but is riddled with calques and mixed forms. A classic false friend: Ukrainian “nedilia” means Sunday, while the near-identical Russian word means week.
Keyword research, not keyword translation. Queries are not translated — they are researched from scratch for each language: the same need is phrased differently across languages.

Multilingual Implementation Checklist

A consolidated list for launching or auditing a multilingual website:

URL structure chosen; every language version has its own address.
Content is served by the server as ready-made HTML: pre-rendering or SSR, no client-side string swapping.
Every version's <html> tag carries the correct lang attribute.
hreflang: a complete cluster on every page — self-reference, reciprocity, x-default, valid codes (uk, not ua).
The canonical on every version is self-referencing; no canonicals pointing to the “main” language.
The sitemap lists all versions — with xhtml:link alternates if needed.
Titles, descriptions, OG tags, JSON-LD and alt texts are translated and adapted.
The language switcher links to the equivalent page, not the homepage.
No geo/Accept-Language auto-redirects; a suggestion banner instead.
Translations proofread by a native speaker; keyword research done per language.

If you need a multilingual website built end to end — from URL architecture to baked translations, as in our 24freelance case study — take a look at our services and get in touch: we will discuss your project and propose a setup for your languages and markets.

FAQ

How many languages should we start with?

Start with the languages where you actually have an audience and demand — usually two or three. Every version needs translation, proofreading and maintenance, so it is better to launch two languages flawlessly than six half-done.

Can we just use an auto-translate widget like Google Translate?

For the convenience of an occasional visitor — yes; for SEO — no. A widget translates the page in the user's browser: the translations have no URLs of their own, are not indexed and bring no search traffic. Only separate language versions served by the server as ready HTML deliver an SEO effect.

Where should hreflang live — in the head or in the sitemap?

Both methods are equivalent for Google; pick one and stick to it. For large sites the sitemap is more convenient — annotations are generated and validated centrally; for small sites, head tags are easier to inspect on a specific page.

What is x-default and is it mandatory?

x-default specifies the version for users whose language matches none of the available ones. Formally the annotation is optional, but we recommend always adding it and pointing it at the primary version or a language-selector page — it makes the site's behavior in international search results predictable.

Will the main version lose rankings after we launch translations?

Not if the implementation is correct. Translations do not compete with the original: they rank for queries in their own languages, and hreflang explicitly tells the search engine these are connected versions of one page. The risk only appears with mistakes — for example, canonicals pointing from translations to the original.

Should URLs (slugs) be translated as well?

Preferably, but it is not critical. A translated slug is more readable in the results and can slightly improve CTR, yet keeping Latin or English slugs across all versions is also a valid practice that simplifies maintenance.