SEONER
website

How to Build a Multilingual Website the Right Way: Avoiding Hreflang Mistakes

9 min

A properly built multilingual website needs three things: a distinct URL for each language, correct hreflang attributes linking those URLs together, and content genuinely adapted per language rather than word-for-word translated. Here's how to build all three, and the mistakes that trip up most sites.

What a multilingual website actually is — and why translation alone isn't enough

A multilingual website isn't the same content copy-pasted into multiple languages. Each language audience searches with different phrasing, relies on different AI platforms, and expects content shaped for their own context. A properly built multilingual site therefore has two layers: a technical layer (URL structure, hreflang) and a content layer (genuinely adapted copy per language) — and both matter equally.

What hreflang is and how it works

Hreflang is a <link rel="alternate" hreflang="..."> tag (or an equivalent block in your sitemap) that tells Google "this page's French version lives at this URL, its German version at that URL." Google uses that signal to show visitors the version that matches their language or region. Without hreflang, the wrong language version can surface in search, or two versions can end up competing with each other and both underperform.

The most common hreflang mistakes

  • One-way links — page A points to page B via hreflang, but B doesn't point back to A. Google may disregard the signal entirely when it isn't reciprocal — hreflang links have to go both ways.
  • Missing self-reference — every page, including the one you're on, needs to hreflang-reference itself (e.g. the /en/ page also links to itself with hreflang="en"). This gets skipped surprisingly often.
  • Slug mismatches — if a translated version doesn't exist yet, or the hreflang tag points to the wrong URL, the result is a 404 or the wrong page entirely (see the real example below).
  • Missing x-default — with no fallback defined for visitors whose language/region doesn't match any listed option, Google effectively guesses.
  • Wrong language code — writing hreflang="en" as hreflang="eng" or another invalid ISO code causes Google to ignore the tag completely.

A real example: the hreflang bug on our own site

This isn't a theoretical risk — we hit it ourselves. Early on, our articles section gave each language version its own natural, locale-appropriate slug (e.g. /en/articles/what-is-seo vs. /uz/articles/seo-nima), but because the hreflang system didn't rely on a single shared identifier to link the versions together, some hreflang links pointed to URLs that didn't actually exist — resulting in 404s. The fix was adding a translationKey field to each article's metadata that stays identical across all its translations, then using that key to look up each language version's real, existing slug automatically. That approach lets every language keep its own natural slug while keeping hreflang links correct and reciprocal.

Choosing a URL structure

StructureExampleBest for
Subfoldersite.com/en/Recommended for most businesses — one domain's SEO authority is shared across all languages
Subdomainen.site.comLarger projects run by separate teams or infrastructure per region
Separate domainsite.comOnly when regions need fully independent brand strategies

For most small and mid-sized businesses, a subfolder is the simplest and most effective option — it's technically easier to configure, and the domain's overall authority isn't split apart.

How content should actually be prepared per language

The most common mistake is writing copy in one language, then translating it word-for-word into the rest. This hurts in two ways: first, each language has its own natural search phrasing that a direct translation loses (a French visitor doesn't search the way an English one does, even for the same underlying question). Second, AI tools are increasingly good at recognizing text that reads as a translation rather than native writing, and can rank it lower. The right approach is to research and write each language version from scratch for that language's search behavior, then link the versions together with a shared translation key — not translate first and adapt later.

How to check your multilingual setup

Google Search Console's International Targeting report automatically flags hreflang errors — invalid codes, one-way links, or mismatched URLs. You can also check manually by viewing a page's source (view-source:) and inspecting the <link rel="alternate"> tags directly — each referenced URL should load correctly and link back to the page you started from.

Bottom line

Building a multilingual website is more than translation — it's two layers of work: correct technical structure (URLs, hreflang) and content genuinely adapted per language. Hreflang mistakes cause slow, hard-to-notice traffic loss, so they're worth checking periodically even after launch. SEONER's website service builds multilingual sites on the right technical foundation from day one — see also how to build a website for a new business for the broader foundation this sits on.

Facing a similar problem? Get a free consultation

Submit a request

Frequently asked questions

Hreflang is an HTML attribute that tells Google which language or regional version of a page to show to which audience. Without it, Google may show the wrong language version to the wrong audience, or treat separate versions as duplicate content.

For most businesses, a subfolder (e.g. site.com/en/) is the simplest and strongest choice — it lets every language version share one domain's SEO authority (backlinks, trust), and it's technically easier to set up. Subdomains or separate domains usually only make sense for large projects run by fully separate regional teams.

No — and often they shouldn't. Each language has its own natural search phrasing (e.g. /en/what-is-seo vs. /es/que-es-seo), so slugs can and should differ. What matters is a shared internal identifier (a translation key) that links the versions together and correct hreflang tags pointing between them.

x-default tells Google which version to fall back to when a visitor's language or region doesn't match any of the listed hreflang options — typically your default language or a language-selector page. It's not mandatory, but it's recommended on any multilingual site; without it, unmatched visitors can land on a version by chance.