Structuring a multilingual website: subfolders, domains and hreflang

A multilingual website is one site that offers the same business information in two or more languages, with each language version reachable at its own address. Getting the structure right early matters, because changing it later means moving every page and redirecting every old address. The decision has three parts: where the language versions live, how search engines are told they belong together, and how translations are produced and kept current.

Choosing where each language lives

There are three common structures. All can work; they differ in cost, maintenance and how strongly they signal a country.

For a business with one team serving several markets, subfolders are usually the practical choice. Country domains make sense for larger organisations where each country is run separately, with its own content, staff and budget. Whichever you choose, note that language and country are different things: a /fr/ section can serve France, Belgium, Switzerland and Luxembourg at once unless the offer genuinely differs between them.

For example, a Lisbon engineering consultancy working in Portugal, Spain and France might use example.pt with /en/, /es/ and /fr/ subfolders, keeping Portuguese at the root. One domain, four languages, one hosting account.

How hreflang works

hreflang is an annotation that tells search engines a page has equivalents in other languages or for other regions, so they can show searchers the most appropriate version. Google supports it in three places: link elements in the page head (rel="alternate" with an hreflang value), HTTP headers (useful for PDFs), or the XML sitemap. Use one method consistently.

• Values use an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region code: de, fr, de-AT, en-GB. Note en-GB, not en-UK.
• Every page in a set lists all its alternates, including itself.
• Annotations must be reciprocal: if the English page points to the German page, the German page must point back. One-sided annotations may be ignored.
• Add an x-default entry for visitors whose language you do not cover, typically pointing to your main language or a language selection page.
• Each page's canonical tag should point to itself, not to another language version.
• Only annotate pages that are true equivalents. A page that exists in one language only needs no hreflang.

hreflang does not raise rankings on its own; it helps the right version appear for the right searcher. Google has said it identifies a page's language from its visible content rather than the html lang attribute, but set that attribute correctly anyway: screen readers rely on it, and Bing has said it gives weight to language signals such as the content-language meta tag and the lang attribute.

Addresses, switchers and redirects

• Translate the page addresses as well as the text: /de/leistungen/ reads better to a German visitor than /de/services/.
• Make the language switcher link to the equivalent page, not to the home page of the other language.
• Label languages in their own language (Deutsch, Français), not with flags, which represent countries.
• Do not automatically redirect visitors based on IP address or browser settings. Suggest a version if you wish, but let people choose. Forced redirects can stop search crawlers, which mostly crawl from one location, from seeing some versions.

A translation workflow that holds up

1. Fix the source language and finish the source pages before translating anything.
2. Build a short glossary of service names, product terms and phrases that must be translated consistently.
3. Translate with a professional translator, or machine-translate and have a fluent speaker review. Do not publish unreviewed machine translation on key pages.
4. Localise rather than only translate: currencies, date formats, phone number formats, local contact details and legally required pages.
5. Translate titles, meta descriptions, image alt text and form messages, not only body text.
6. Publish all language versions of a page together, with hreflang in place.
7. When the source page changes, flag the translations for update and record who owns each language.

Honest trade-offs

Every language you add is a commitment. An outdated or thin translation can do more harm than not having that language, because it suggests the business does not really serve that market. Start with the languages your clients actually buy in, keep the key pages complete in each, and add more only when you can maintain them. For some businesses, a fully translated core plus an English-only blog is a sensible middle ground.

Multilingual sites also need a privacy notice in every language, covered in our GDPR basics guide.

Questions and answers