← Back to articles

Multilingual site: hreflang, URLs, and common mistakes

A multilingual site without a clear URL scheme and correct hreflang often loses traffic: search engines mix up versions, show the wrong language, or treat pages as duplicates. Below - how to choose an address structure, how to link locales, and which mistakes show up most often in 2026.

  • hreflang - a signal to search engines about which language/region version is for which audience
  • URL - path prefix, subdomain, or separate domain; the scheme must be consistent and predictable
  • Canonical - must not break the locale relationship
  • Content - translation or localization, not unedited machine copy-paste
  • Rule - each locale points to all others and to itself

Why hreflang and a URL scheme matter

A user in Germany should see the German version, someone in Brazil the Portuguese one, someone in the US the English one. Without explicit signals, the search engine guesses from IP, browser language, and links - and often gets it wrong.

hreflang does not rank a page by itself. It helps choose the right version among peers. The URL scheme decides how people and bots find those versions: via /de/, de.example.com, or example.de.

URL schemes for multilingual sites

Scheme Example Pros Cons
Path prefix example.com/de/blog/ One domain, simpler analytics and certificates Needs discipline in routing and sitemaps
Subdomain de.example.com/blog/ Flexibility for hosting and teams Harder shared domain strength, more infrastructure
Separate domain example.de/blog/ Strong local signal Costlier to maintain, separate SEO campaigns

For most corporate sites and blogs in 2026, a path prefix is the practical choice: one stack, one analytics setup, simpler deploys. Subdomains and ccTLDs make sense with a strong local brand, separate legal entities, or a dedicated market team.

Lock in the default language: either the root without a prefix (/) or an explicit /en/. Mixing "sometimes with a prefix, sometimes without" leads to duplicates.

How to set up hreflang correctly

  1. On every page, list all available equivalents: hreflang="ru", hreflang="en", hreflang="de", and so on.
  2. Add a self-reference: the page also points to itself.
  3. The set must be reciprocal: if A links to B, B links to A.
  4. Use BCP 47 codes: language (en) or language-region (en-GB, pt-BR).
  5. When useful, add x-default - the default page for unmatched locales (often a language selector or EN).
  6. Mirror the same annotations in HTML <link rel="alternate" hreflang="..."> and/or in the XML sitemap.

Example fragment in <head>:

<link rel="alternate" hreflang="ru" href="https://example.com/blog/post/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/post/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/post/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/post/" />

Common mistakes

1. No reciprocity

The Russian page links to EN, but the English page has no back-link to RU. The search engine may ignore the whole group.

2. Canonical points to the "main" language

The Russian page's canonical points to the English page "as the original." Locales then look like duplicates, not alternatives. Canonical should point to itself (or the canonical URL of the same locale), not another language.

3. Auto-redirect by IP / Accept-Language

Users and bots cannot reliably open the intended version. Better: a dedicated URL per locale + a language switcher, without forcing a redirect from the root to a "guessed" language for everyone.

4. Incomplete locale set

The menu shows 5 languages, hreflang lists 2. Or one article has a translation and the next does not, yet the map still exposes broken alternates. Prefer an honest set: only URLs that actually exist.

5. Confusing language and region

de is German. de-AT is German for Austria. If the content is the same for DE/AT/CH, do not invent three near-identical pages without real localization of prices, shipping, and legal copy.

6. Different meaning under one "translation"

The URL is "translated," but the offer, currency, and CTA still belong to another market. For SEO that is no longer an equivalent - hreflang can hurt here.

7. Forgotten sitemap and internal links

Tags exist in <head>, but the XML sitemap has no xhtml:link, and the footer language link always goes to the homepage instead of the current article's equivalent. Internal cross-links between locales strengthen the signal.

Pre-launch checklist

  1. One URL scheme across the whole site.
  2. Every indexable page has a full reciprocal hreflang set plus self.
  3. Canonical does not merge different languages.
  4. No aggressive geo-redirect that blocks indexing.
  5. The sitemap includes all locales and annotations.
  6. The language switcher goes to the equivalent, not only the homepage.
  7. 404 and "not translated yet" are handled explicitly (soft fallback or honest 404), without silently serving another language under the same URL.

Bottom line

A multilingual site works when each audience has a stable URL and hreflang honestly links equivalents. Pick one address scheme, keep annotation reciprocity, do not break locales with canonical or geo-redirect - and the search engine stops guessing the language for you.

If you need a URL scheme, hreflang, and sitemap designed for your stack - or a check of your current site for these mistakes - get in touch.

Frequently asked questions

Do I need hreflang if there are only two languages?

Yes, if both versions should appear in search for their audiences. Even a RU/EN pair without reciprocal annotations often shows the wrong language or feels like duplicates.

What is better: /en/ in the path or a subdomain?

For most projects - a path prefix. A subdomain makes sense with separate hosting, team, or strong market isolation. A separate ccTLD - when the brand and legal entity are truly local.

Is x-default required?

Not required, but useful. It usually points to a language selector or the main international version (often EN). Without it, the search engine chooses its own fallback.

Can I put hreflang only in the sitemap?

Yes, Google understands sitemap annotations. In practice it is safer to duplicate them in HTML and in the sitemap - easier to debug and less risk of drift on partial deploys.

Why is the language in search still wrong after setting hreflang?

Often the tags are fine and the surrounding signals are not: canonical to another language, redirects, thin/machine "translation," broken URLs in the set, or no internal links to the equivalent. Check reciprocity and that both pages are actually indexed.

Contacts