Adding a second language to a website is rarely a translation project. It is a structural one. Have the copy translated but leave the URL structure, the hreflang annotations and the sitemap untouched, and you typically end up with two problems at once: search engines serve visitors the wrong language version, and the versions compete against each other for the same queries. This article walks through how to build a multilingual website that holds up technically — from the directory structure to reciprocal hreflang pairs with x-default, translated slugs and a sitemap that matches.
Multilingual is a structure problem, not a text problem
The commercial case is well documented. In a European Commission survey on language preferences online, roughly 90 percent (European Commission, Eurobarometer) of the internet users asked said they would open a website in their own language whenever they had the choice, and 42 percent (European Commission, Eurobarometer) said they would not buy products or services offered in another language. For a company that ships across a border, recruits staff from abroad or works with suppliers in several markets, language is therefore not a question of ambition but of reach. The European Union alone operates with 24 official languages (European Union), and a market such as Switzerland normally calls for more than one language version on its own. The point is less to offer as many languages as possible and more to deliver the languages you do offer in a way that keeps them findable.
The real effort does not sit in the copywriting. It sits in the bookkeeping. Every page now exists several times, every version needs its own durable URL, and every one of those URLs has to be known to all the others. With five pages that is a manageable chore. With fifty pages in three languages it becomes 150 URLs carrying roughly 600 cross references that have to stay consistent for years — and that have to be carried along with every new page, every rename and every deletion. That is where multilingual projects usually come apart: not at the translator, but at the maintenance. How a complete site is produced from a briefing today, and which structural work can be automated along the way, is covered in creating a website with AI.
Decide on the URL structure first
Before the first sentence is translated, decide where the language versions live. Three patterns are established: language folders below one domain, one subdomain per language, and separate country domains. All three work, but they differ sharply in effort, signalling and running cost. For small and mid-sized companies the language folder is usually the most durable choice: it concentrates every signal on a single domain, needs no additional certificates or DNS records, and can be extended with further languages later without moving the existing site. Separate country domains typically pay off only once each market has its own legal entity, its own price list and its own team behind it.
| Pattern | Example | What it means |
|---|---|---|
| Language folder | example.com/en/ and example.com/de/ | One hostname, one certificate, every signal concentrated; in our experience the pragmatic choice for mid-sized companies |
| Subdomain per language | en.example.com and de.example.com | Cleanly separable and separately operable, but more administration, separate certificates and split reporting |
| Separate country domain | example.com and example.fr | Strong country signal, but a domain, certificates, legal pages and editorial team per market |
| Language as a parameter | example.com/?lang=de | Poorly recognised by crawlers as a page in its own right; not advisable as a permanent language structure |
What matters is consistency in the implementation. If you choose language folders, the source language belongs in a folder too. A structure where English sits directly at example.com/ and German at example.com/de/ does work, but it regularly produces duplicate entry points: the home page is reachable at the root and at /en/, both variants collect links, and the hreflang cluster has to pick one of them. A cleaner setup keeps a neutral root that leads into the language versions while all content sits consistently under /en/, /de/ or /fr/. The overview of how a website project runs shows how that structure is produced in a real project.
Handle the root cleanly
What hreflang actually does
hreflang is not a ranking signal, it is a mapping signal. It tells search engines that a set of URLs carries the same content in different languages or for different regions. Without that mapping, a crawler treats the versions as separate pages with heavily overlapping content — with the risk that it settles on one version and rarely surfaces the rest. The language code follows the established standard for language tags (W3C, Internationalization): two lowercase letters for the language, optionally a hyphen and two uppercase letters for the region, so en, en-GB, de or de-AT. A region without a language is invalid — a value such as gb does not exist. Adding a region only makes sense when the content really differs by region, for example prices, delivery terms or contacts. Otherwise the plain language code is enough and keeps the annotation lean.
<link rel="alternate" hreflang="en-GB" href="https://example.com/en/services/">
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/leistungen/">
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/services/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services/">- Every language version lists all versions of the cluster — including itself.
- The references are reciprocal: if /de/ points to /en/, then /en/ has to point back to /de/.
- Every URL named answers with status code 200 and is indexable — no redirects, no noindex, no paths blocked in robots.txt.
- The URL in the reference is absolute, including protocol and hostname; relative paths are ignored.
- The language code is valid: language first, region optional, uppercase letters only in the region part.
- Exactly one URL carries x-default — and it is the same URL in every version of the cluster.
- The annotation lives either in the head, in the HTTP header or in the sitemap, but not contradictorily in several sources at once.
x-default: the entry that goes missing most often
x-default answers a simple question: what do we show someone whose language we do not offer at all? A site with an English and a German version has no exact match for a query from Spain. Without x-default the crawler decides by its own criteria; with x-default it receives a clear instruction. Two patterns are common: either x-default points at a language selection page in the root, or it points at the version that is most widely understood internationally, often the English one. What does not work is an x-default that resolves to a different URL in each language version. The entry belongs to the cluster, not to the individual page, and therefore has to be identical everywhere. If it is missing entirely that is not an error in the narrow technical sense, but it wastes a signal for every language area you do not cover — and with two or three languages that is the vast majority of the world.
The classic self-reference mistake
Translated slugs instead of automatic redirects
A multilingual website whose German pages sit at /de/services/ is only half finished. The path is part of the content: it appears in search results, it gets copied and forwarded, it ends up in quotes and email signatures, and it usually contains the most important term on the page. A German path such as /de/leistungen/ is therefore not a cosmetic detail but a findability and trust factor. In practice this means every page needs its own edited slug per language, and the mapping between those slugs has to be stored in the system — otherwise the language switch does not know where to point and falls back to the home page. How XICflow manages pages together with their structure, copy and metadata is described under services in detail.
One slug per language
The path is translated, not passed through. /en/services/ and /de/leistungen/ are independent, permanently stable URLs with their own history.
Fixed mapping
The system knows the counterpart of every page in the other languages. The switch jumps to the matching sub-page rather than to the home page.
Old paths stay reachable
If a slug changes later, a permanent redirect leads from the old path to the new one, so links from outside do not run into a dead end.
The second half of this rule matters just as much: no automatic language redirects based on browser language or IP address. Redirects like these look user-friendly at first glance, but they are problematic for three reasons. First, crawlers arriving from a given region see only one language version, so the remaining ones are barely picked up, if at all. Second, visitors lose control: someone who deliberately opens the English page in order to forward it does not want to be thrown onto the German one. Third, shared links break, because the recipient lands in a different language than the sender intended, which can make quotes and documentation useless. The established approach is a visible, keyboard-operable language switch, complemented by a discreet hint that the page is also available in another language.
Sitemap, status codes and crawling
hreflang can be delivered in three places: in the head of every page, in the HTTP header, or in the XML sitemap. For sites with many pages and many languages the sitemap variant is the most economical, because it keeps the annotations out of the HTML and therefore keeps every single page smaller. For smaller sites the head variant is the more transparent solution, because it can be checked directly in the source. What counts is using only one source: contradictory statements in head and sitemap tend to make search engines ignore the annotation altogether. If the page build is lean anyway — for example through static delivery with a PageSpeed score of 100 — the head variant leaves considerably more room, because a few extra lines of HTML barely register.
<url>
<loc>https://example.com/en/services/</loc>
<xhtml:link rel="alternate" hreflang="en-GB" href="https://example.com/en/services/"/>
<xhtml:link rel="alternate" hreflang="de-DE" href="https://example.com/de/leistungen/"/>
<xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/services/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/services/"/>
</url>The most common mistakes in multilingual projects
- Missing self-reference: the page lists every other language but not itself — which frequently invalidates the whole block.
- One-sided pairs: /en/ points to /de/, but /de/ does not point back. Only reciprocal statements are evaluated reliably.
- Relative URLs in the reference. Only absolute URLs with protocol and hostname are permitted.
- References to redirecting or non-indexable targets. Every URL named has to answer with status code 200 and must not carry noindex.
- Invalid language codes such as en-UK instead of en-GB, or a bare country code with no language in front of it.
- Automatic language redirects by IP address with no way back — crawlers then see one version only, and visitors lose the choice.
- Untranslated slugs, so that German content permanently lives under English paths.
- Half-translated pages: navigation and body copy translated, but form labels, error messages, the consent dialog and the legal pages left in the source language.
- Sitemap and annotation drifting apart, because the sitemap is only updated by hand when someone remembers.
The short version
Language switch, accessibility and legal pages
There is more to multilingual delivery than annotations for search engines. Every page needs a correct lang attribute on the HTML element, and passages in another language inside a page need their own lang on the enclosing element — both are success criteria of the accessibility guidelines (W3C, WCAG 2.2, criteria 3.1.1 and 3.1.2). Screen readers pick their pronunciation from that attribute; without it an English paragraph is read out with German pronunciation and becomes practically unintelligible. How widespread the gap is shows in the annual analysis of large home page samples: around 17 percent (WebAIM Million) of the home pages examined had no language declaration at all, and the share of pages with a valid language attribute sits at a good 80 percent (Google Web Almanac) in the analysis of the wider web corpus. What follows from this for companies operating in the European Union is set out in the article on the accessibility act and business websites. Mandatory legal pages belong in every language offered as well: imprint, privacy notice and the consent dialog have to exist in the language the page is served in — which is where the overview of GDPR-compliant cookie consent fits in.
An additional language does not double the amount of text, it doubles the number of states that have to stay consistent over time.
How XICflow manages several languages
In XICflow, language is a property of the page configuration rather than a copy of the website. A page exists once as a structure and carries a title, copy, metadata and its own slug per language. From that configuration the delivery step generates the language folders, the reciprocal hreflang pairs including x-default, the lang attribute, the sitemap entries and the language switch — without anyone maintaining link tags by hand or keeping a mapping table up to date in a spreadsheet. When another language is added later, the existing clusters are extended instead of every existing page being touched one by one. What that looks like in the finished result can be seen in the example websites; which language scope is included in which package is set out in the package and pricing overview.
- Language folders per language, with stable URLs and properly edited translated slugs
- Reciprocal hreflang pairs including x-default, generated automatically from the page mapping
- lang attribute per page and per foreign-language section, in line with WCAG 2.2
- Sitemap covering all language versions, rewritten on every publish
- A language switch that points to the matching sub-page instead of the home page
- Legal pages, forms, error messages and the consent dialog in every active language
- Permanent redirects whenever a slug is changed later or a page is moved
What you can check right now
For an existing multilingual website a short inventory is worth the time, and it needs no specialist tooling. Open any sub-page in each language and look in the source for an alternate reference for every version, check whether the page's own URL is among them, and confirm that an x-default exists. Then verify that the URLs named answer directly with status code 200 rather than travelling through a redirect. Next open the sitemap and compare the addresses listed there with the ones that are actually reachable. Finally, click the language switch on a deep sub-page — if it lands on the home page, the page mapping is missing. If more than two of these points stay open, a structural rebuild is in our experience cheaper than patching afterwards; you can read who is behind XICflow, and further articles on structure and technique are collected in the XICflow blog.