Contents

A multilingual website should give each language version its own URL, link the versions with hreflang markup and never force-redirect users by browser language. For most projects, language folders on one domain — /en/, /de/ — work best: they are easier to maintain and inherit the main site's authority.

Here is how to choose a URL structure, mark up hreflang correctly, detect language and organise translation.

Which URL structure should you choose?

There are three options: folders on one domain, subdomains or separate country domains. Folders are the simplest to maintain and best for SEO; separate domains make sense when the business really differs by country — its own prices, legal entities and range.

Structure Example Pros Cons
Folders site.com/en/ One domain, shared authority, easier upkeep Harder to host versions in different countries
Subdomains en.site.com Can be spread across servers Search engines partly treat them as separate sites
Separate domains site.de, site.fr Strong country signal Expensive: each domain is promoted separately
URL parameter site.com/?lang=en — Poorly indexed, not recommended

The primary language usually lives without a prefix and the others in their folders. What matters is that every page version has its own stable URL.

How do you mark up hreflang correctly?

Hreflang is a set of links in the page code or sitemap telling search engines: "this page has versions in these languages, here are their URLs". The markup must be reciprocal — each version references all the others and itself — and list only translations that exist.

<link rel="alternate" hreflang="ru" href="https://example.com/blog/multiyazychnyj-sajt" />
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/multilingual-website" />
<link rel="alternate" hreflang="x-default" href="https://example.com/blog/multiyazychnyj-sajt" />
<link rel="canonical" href="https://example.com/en/blog/multilingual-website" />

Markup rules:

  1. Each language version lists every version, including itself.
  2. x-default is the version for visitors whose language is not supported.
  3. Each version's canonical points to itself, not to the primary language.
  4. Pages without a translation are not listed in hreflang.

For other technical requirements, see technical SEO checklist before launch.

A desk globe in warm light Photo: Unsplash

How do you detect the user's language?

Better not to impose a language: search engines already show people the version in their query's language, and the site can gently suggest switching if the browser language differs. Forced redirects by language or IP hurt both users and crawlers, which may never see some versions after such a redirect.

What to do:

  • open the version whose URL the user arrived at;
  • show an unobtrusive "This page is available in your language" banner instead of redirecting;
  • remember the user's choice and do not ask again;
  • keep the language switcher visible and point it to the same page, not the home page.

How do you organise content translation?

Organise translation so every entity — article, product, page — has fields in every language, including the URL slug, title and meta tags. Translate not just the text but slugs, image descriptions, emails and error messages.

  • slugs in the page's language: /en/blog/multilingual-website, not a transliteration;
  • meta tags and search descriptions in each language;
  • formats — dates, currencies, units, phone formats;
  • interface — buttons, errors, emails, notifications;
  • process — who translates, who proofreads and how you know a translation is outdated.

If the site runs on a JavaScript framework, every language version must be served pre-rendered from the server — see SEO for JavaScript websites and Nuxt vs Next.js.

What are the most common mistakes?

The most common mistakes involve hreflang and incomplete translations: markup pointing to pages that do not exist, versions not referencing each other, and half-translated pages mixing languages and looking like duplicates.

  • forced redirects by browser language or IP;
  • one URL changing language depending on a cookie;
  • every version's canonical pointing to the primary language;
  • only the interface translated while the content stays in the original language;
  • the language switcher leading to the home page instead of the current page.

In short

  • Every language version gets its own stable URL; folders on one domain are easiest.
  • Hreflang is reciprocal, includes x-default and lists only existing translations.
  • Do not force-redirect by language — suggest switching instead.
  • Translate slugs, meta tags, formats and the interface, not just the text.
  • Do not show untranslated pages in a language version.

FAQ

  • Can machine translation be used?

    As a draft, yes — modern models translate well. But key pages, legal texts and marketing copy should be proofread by a native speaker: mistakes there cost trust and conversion.

  • What about pages that have no translation?

    Do not show them in that language version and do not list them in hreflang. An empty page or a page in another language under a foreign URL is worse than no page.

  • Does each language need its own sitemap?

    Not necessarily. Language versions can be listed in one sitemap via alternate links, or each language can have its own file — what matters is that every version is listed and they reference each other.