# Multilingual Websites: URL Strategy, hreflang and Translation

How to build a multilingual website properly: i18n vs l10n, URL strategies, hreflang with x-default, translation workflows, RTL layouts and SEO per market.

by Alexander Herling Published 22 October 2026 7 min read

![Abstract illustration: stacked, rounded language tags in shades of blue emerging from a shared cloud](https://degoya.digital/blog/multilingual.svg)

A multilingual website is more than a translated website. It has to be found in every language, make sense in every market and keep evolving without doubling the maintenance effort. Multilingual websites and apps have been one of our core services for many years. This article sums up what matters in planning, engineering and editorial work.

## Internationalisation and localisation

Two terms that are often confused:

- **Internationalisation (i18n)** is the technical groundwork: the software can handle multiple languages, writing systems, and date and number formats. Text is not hard-coded but lives in translation files or the CMS.
- **Localisation (l10n)** is adapting to a specific market: translation, but also images, examples, units, legal texts, payment methods and tone.

You do internationalisation once, ideally early. You do localisation for every market. Retrofitting i18n usually costs several times as much.

## Choosing a URL strategy

Every language version needs its own stable URL. Switching languages by cookie or JavaScript under the same address is invisible to search engines.

| Option                 | Example              | Pros                                            | Cons                                                   |
| ---------------------- | -------------------- | ----------------------------------------------- | ------------------------------------------------------ |
| Subdirectory           | example.com/de/      | One domain, consolidated authority, easy to run | Weaker local signal                                    |
| Country domain (ccTLD) | example.fr           | Strong country signal, local trust              | Several domains, link building per domain, higher cost |
| Subdomain              | de.example.com       | Can be run as a separate system                 | Often treated like a separate site                     |
| URL parameter          | example.com/?lang=de | Little effort                                   | Not recommended by Google, error-prone                 |

For most businesses, subdirectories are the best choice. Country domains make sense when you operate independently in individual countries, with your own entity, product range and team.

Distinguish between language and country. `/de/` is a language version for all German speakers. `/de-at/` and `/de-ch/` are country versions with their own prices, shipping terms or legal texts. Only create country versions where the content actually differs.

The URL paths themselves can be localised too: `/en/services/` in English, `/leistungen/` in German. That helps users and search, but requires a clean mapping between the pages.

## Getting hreflang right

hreflang annotations tell search engines which pages are translations of each other and who they are meant for. Google then shows German users the German version and British users the English one.

An example for the HTML head:

```
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<link rel="alternate" hreflang="en" href="https://example.com/services/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/" />
```

The rules broken most often in practice:

- **Reciprocal:** every version references all others and itself. If the return link is missing, Google ignores the annotation.
- **Valid codes:** language in ISO 639-1 (`de`, `en`), optionally a region in ISO 3166-1 alpha-2 (`de-AT`, `en-GB`). `en-UK` or `en-EU` are invalid.
- **x-default:** sets the version for everyone who matches no other annotation, often the English version or a language picker page.
- **One canonical per language:** each language version's canonical tag points to itself, never to another language.
- **Indexable URLs only:** no redirects, 404s or `noindex` pages in hreflang sets.

You can declare hreflang in the HTML head, in HTTP headers (for PDFs) or in the XML sitemap. On large sites the sitemap is often easiest to maintain. What matters is that your system generates the annotations automatically from the page mapping. Maintained by hand, they go stale quickly.

Every page should also set the `lang` attribute on the `<html>` element. It matters mainly for screen readers and browsers, which use it for pronunciation and hyphenation.

## Translation workflows that scale

The hardest part of a multilingual website is not the launch but day-to-day operation. New pages, changed prices and updated legal texts must reach every language.

What works:

- **One source of truth.** Content lives in the CMS, interface strings in translation files. Both connect to a translation management system (TMS) or can be exported to one.
- **Glossary and translation memory.** Key terms are defined once and translated consistently. Previously translated sentences are reused.
- **Machine pre-translation plus post-editing.** Tools such as DeepL or large language models produce usable drafts today. For important pages, a native speaker with subject knowledge should review and adapt them.
- **Status per page and language.** Editors can see which translation is outdated when the source changes.
- **Context for translators.** Screenshots or preview links prevent errors in short strings such as buttons, whose meaning is unclear without context.

## Layout, type and formats

**Text length.** German and Finnish copy is often much longer than English. Buttons, navigation and tables have to cope. Test with pseudo-localisation: artificially lengthened strings with accented characters that expose layout bugs immediately.

**Right to left.** Arabic, Hebrew and Persian require `dir="rtl"` and a mirrored layout. With CSS logical properties (`margin-inline-start` instead of `margin-left`) one stylesheet works in both directions. Directional icons such as arrows need mirroring as well.

**Fonts.** Check that your web font covers every character you need, including diacritics for Polish or Czech, or Cyrillic. Otherwise the browser mixes in fallback fonts.

**Formats.** Dates, times, numbers, currencies and plural forms vary by language and country: €1,234.56 in Ireland, 1.234,56 € in Germany. The browser's built-in `Intl` API and ICU message format for plural rules take much of this work off your hands. Addresses, phone numbers and name order follow local conventions too, so do not validate them too strictly in forms.

## SEO per market

A translation does not automatically carry over the keywords of the original. People in Austria sometimes search with different terms than people in Germany, and British searchers differ from American ones. For every important market you need:

- keyword research in the target language
- translated title tags, meta descriptions, alt text and structured data
- local signals: address, phone number, currency, references from that market
- links from that country, where possible

Online shops add currencies, taxes and shipping. Our article on [Shopify internationalisation](https://degoya.digital/en/blog/shopify-internationalization) shows how that works on Shopify.

## How to get started

First decide which markets and languages you plan for over the next three years. That determines your URL strategy, which is expensive to change later. Then come i18n in code and CMS, the translation workflow and finally SEO per market. If you are looking for an experienced partner, see our [multilingual websites and apps](https://degoya.digital/en/services/multilingual-websites-apps) service.

## Frequently asked questions

Should I redirect visitors to their language automatically?

Not by force. Show a subtle prompt pointing to the matching language version and remember the choice. Automatic redirects based on IP or browser language can also stop search engine crawlers from seeing every version.

Is machine translation good enough for a website?

Often yes for internal or low-visibility content. For the home page, service and product pages we recommend machine pre-translation with expert post-editing by native speakers, including keywords for each market.

Do I need hreflang if I only have two languages?

Yes, hreflang pays off from two language versions onwards. It helps Google show users the right version and keeps language versions from being treated as competing pages.

## About the author: Alexander Herling

Founder and owner of DEGOYA.digital. A deep affinity for technology since early childhood and his first contact with 8-bit computers make him a digital native from day one. The command line is his friend. 35 years of experience in marketing and web development, specialising in SEO techniques.

Related service

[Multilingual websites & apps](https://degoya.digital/en/services/multilingual-websites-apps)

[Back to the blog](https://degoya.digital/en/blog)

Source: https://degoya.digital/en/blog/multilingual-websites-hreflang
