Multilingual SEO: architecture, hreflang and localisation that holds up

Multilingual SEO comes down to three decisions. Put each language on its own set of URLs, usually a subfolder such as /de/ or /fr/, so every version is separately crawlable. Annotate those versions with hreflang so search engines know they are alternatives of each other rather than duplicates. Localise rather than translate, because the words people search for in a language are rarely the literal translation of the words they search for in yours. Get those three right and the usual failure modes disappear.

This page covers the architecture choice, hreflang implemented correctly, the difference between translation and localisation, and the mistakes that cost the most.

Language, country, or both

Decide first what you are actually varying. Three different situations get confused with each other:

• One language, several countries. English for the United Kingdom, the United States and Australia. Content is mostly the same and prices, shipping, legal text and spelling differ.
• Several languages, one country. French and Dutch for Belgium, or English and Hindi for India.
• Several languages and several countries. The full matrix, and the only case that needs language plus region codes throughout.

Build only the matrix you can maintain. A site with twelve half finished locales performs worse than the same site with four complete ones, because every extra version needs its own content, its own hreflang row and its own upkeep.

Architecture choices

Structure	Example	Strengths	Costs
Country code domain	example.de	Clearest geographic signal, strongest local trust, separate hosting and legal entity possible	Separate domain authority for each one, more infrastructure, more registration and renewal work
Subdomain	de.example.com	Easy to separate hosting and teams, simple to add	Signals are less consolidated than a subfolder, users read it as a different site
Subfolder	example.com/de/	One domain accumulating all signals, cheapest to run, easiest to get right	One hosting setup for everyone, and site wide problems affect all locales
Parameter or cookie only	example.com/?lang=de	Quick for developers	Versions are hard to crawl and index separately, so avoid it for anything you want found

Google's guidance on managing multi regional and multilingual sites accepts country domains, subdomains and subfolders, and asks for a URL structure that makes the different versions clearly separable. For most businesses the subfolder is the right default, and a country code domain is worth the extra work where local trust directly drives conversion or where a market needs its own legal entity.

Whatever the structure, serve one language per URL. Do not swap the page language based on the visitor's IP address or browser setting while keeping the URL the same, because a crawler then only ever sees one version and the others never get indexed. Offer a visible language selector instead, and let the user choose.

hreflang, done correctly

hreflang tells search engines that several URLs are the same page in different languages or for different regions. Google's reference is the page on telling Google about localized versions. Pick one of the three methods and use it alone: HTML link elements in the head, an HTTP header for non HTML files such as PDFs, or annotations inside your XML sitemap. Sitemap annotations are the easiest to manage at scale because one file holds the whole matrix.

The rules that decide whether it works:

• Every page in a set lists every page in the set, including itself. A missing self reference is the most common reason a correct looking implementation is ignored.
• Annotations must be reciprocal. If the English page points at the German page, the German page points back. One directional annotations get dropped.
• Use absolute URLs with protocol and hostname.
• Codes are language first, region second. Language in ISO 639-1, optional region in ISO 3166-1 Alpha 2: "de" for German anywhere, "de-AT" for German in Austria. "en-UK" is wrong; the country code is GB.
• A region on its own is not valid. There is no "at" without a language in front of it.
• Add x-default for the page that handles everyone you have not named, usually the global English version or the language selector.
• Point at indexable, canonical URLs that return 200. An hreflang pointing at a redirect, a 404 or a noindex page breaks the set.
• Keep canonicals self referencing. A German page canonicalised to the English page tells search engines to ignore the German page, which cancels the hreflang.

A valid sitemap entry for a three language set looks like this:

<url>
  <loc>https://example.com/pricing</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/pricing"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/preise"/>
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
</url>

Each of the other two URLs gets the same block of four alternates, with its own loc. Repeat it, do not vary it.

Translation against localisation

Translation converts your sentences. Localisation builds the page a local buyer would expect, and that includes the keyword research. Run keyword research natively in each language with a local speaker. The literal translation of your best English term is frequently not the term with the volume, and sometimes the English loan word is what locals actually type.

The items that need localising rather than translating:

• URL slugs, in the target language, where your market expects it.
• Titles and meta descriptions, rewritten to the local search phrasing rather than translated.
• Prices and currency, including local tax display conventions.
• Units, dates, addresses and phone formats.
• Examples, names and case studies, so the page reads as if it was written locally.
• Legal and compliance text, which is a local requirement rather than a copy task.
• Support details, including the hours in local time.
• Structured data, with currency and language fields matching the page.

Machine translation is a reasonable first draft and a poor final version. Have a native speaker edit every page that is meant to rank or convert, and keep the raw output off the site.

What breaks most often

• Automatic redirection by IP address. It blocks crawling of every version except one, and it annoys travellers and bilingual users.
• Canonical pointing at the English page. Leaves only English indexed.
• Missing self referencing hreflang. Invalidates the whole set.
• Partial rollout. Half the pages translated and the rest silently serving English behind a localised URL.
• Navigation and internal links that cross locales. Links inside the German pages should point at German pages.
• Codes that look right and are not. en-UK, zh-CN used for Taiwan, or a region code with no language.
• Locale code drift after a replatform. Re-crawl the hreflang set after any migration.

This page covers multilingual and multi regional sites: structure, hreflang and localisation. For the ordinary technical work that applies to all of them equally, indexing, speed and structured data, see a technical SEO checklist.

Questions buyers ask about Multilingual SEO

Is a subfolder or a country domain better?

A subfolder keeps all the signals on one domain and is the cheaper, lower risk default. A country code domain gives the strongest local signal and the highest local trust, and costs more to run. Choose the domain when the market is strategic enough to deserve its own operation, and the subfolder otherwise.

Do I need hreflang if I only have one language?

Only if you serve different versions to different countries, for example separate pages for the United States and Australia. One version for everyone needs no annotation.

Does translated content count as duplicate content?

No. Content in different languages is treated as different content. Duplication becomes an issue between near identical pages in the same language, such as US and UK English versions, which is exactly what hreflang is there to resolve.

Should URLs be translated?

Translated slugs help users and match local search phrasing, so prefer them. Keep a consistent locale prefix either way, and never change slugs later without redirects.

Where should a language selector live?

In the header, visible on every page, with each option as a crawlable link to the equivalent page in that language rather than a script that swaps content in place.

Can I use ccTLDs and subfolders together?

You can, and it adds a maintenance burden. Keep one pattern per language group, and if you inherit a mixture, write down which markets live where and make the hreflang matrix reflect it exactly.

The same question in Hindi, Spanish or German

Your hreflang tags tell Google which version of a page belongs to which market. An assistant has no such tag to obey. A buyer in Madrid and a buyer in Munich asking the same question in their own languages can be given different companies, and neither list has to resemble the English one.

Pick your three most important markets, write the buyer question in each language, and put it to two assistants. AI Knows Us can run the same question per language and show which pages were cited in each.