Multilingual site architecture.

Multilingual site architecture is the full set of structural decisions that serve the same content’s versions in different languages correctly to both people and search engines.

Opening a site to a second language looks, at first glance, like a translation job. In practice it is not: the address structure, the language declaration, the reciprocal links, the sitemap, the schema, the typography and the content management — each demands its own decision, and when one is made wrongly, the benefit of the others evaporates.

This guide takes those decisions in order. The order is not arbitrary but a chain of dependencies: without the address structure chosen, hreflang cannot be set up; without hreflang, the search engine cannot show the right version; and without the right version shown, translation quality has no meaning.

A frame up front: being multilingual is not a technical feature but a market decision. Which languages to open depends on whether business will really be done in them — and a language version whose maintenance cannot be sustained is worse than none. A stale translation directly damages trust in that market.

Seven decisions

The decisions to make when building a multilingual architecture gather under these seven headings. Each is covered on its own page in this cluster; here is the map.

1. The address structure — subfolder, subdomain or country domain? The hardest decision to reverse.
2. The language declaration — every page must tell both the browser and assistive technology which language it is in.
3. The reciprocal links — the hreflang set; every version must declare the others AND itself.
4. The default version — what shows when no language matches? x-default exists for this.
5. Discovery — the sitemap and internal links must make every version findable.
6. The content — translation or localization? Two different jobs with different costs.
7. Maintenance — when a page is updated, what happens to the other languages?

The last item is the most skipped and, in the long run, the most expensive. Opening a site to three languages is not a one-off project but a permanent load — and languages opened without an arrangement to carry that load drift apart within months.

This site’s own measures

A concrete example so it does not stay abstract. This site is trilingual: Turkish at the root, English and German in subfolders. The core pages exist in all three languages; the cluster content is translated language by language — the GEO cluster is in three languages today, the remaining guides and the glossary Turkish-only for now. The sitemap therefore does not grow symmetrically: the Turkish side grows with every new guide, the English and German sides with every translation slice.

Pages existing in all three languages carry four hreflang links: three languages and one default. Turkish-only pages carry two — themselves and the default — because hreflang cannot declare a translation that does not exist. The links repeat in the sitemap, and the total comes from a multiplication: every trilingual URL four lines, every single-language URL two. In the measurement of 22 August 2026 that made 480 lines for 183 URLs. A complete set at both page and map level — but the set is not the same size on every page.

The address structure is deliberately localized: the service page carries one slug in Turkish, another in English, another in German. That raises the translation cost but puts each language’s searched term into the address bar.

And on the typography side there is a measured compensation: German text is markedly longer than Turkish and English. The width axis of the display typeface is narrowed for German, so the same heading stays on the same number of lines. The value was chosen by measurement, not by guess.

German text is long; not measuring that means accepting that the design breaks in German.

Measurement from two managed B2B sites

The two textile sites this studio manages are live in seven languages each, and the same rule holds on both: the set complete, or not at all. If a page exists in seven languages, all seven declare one another; if one language is missing, that language is not declared at all.

The rule looks harsh but the reason is practical: an incomplete set is an inconsistent signal to the search engine, and inconsistent signals end up ignored entirely. A half-built hreflang setup is less useful than none.

On this site the same rule is protected by code: when a language has no content, no page is generated for it and it does not enter the hreflang set. The missing field is not rendered — left empty instead of filled with a fabricated translation.

Three frequent mistakes

The recurring mistakes in multilingual setups resemble one another, and three of them explain the bulk of the problems.

First, automatic redirection: looking at the user’s location or browser language and forcing them to a version. It sounds helpful; in practice it traps both the user and the crawler — and Google explicitly warns against this behavior.

Second, missing reciprocity: page A declares B, but B does not declare A. A one-way declaration counts as invalid and the set does not work.

Third, publishing machine translation unreviewed. Translation quality is a trust problem before it is a search engine problem: a faulty German page tells a customer in that market about the studio’s carelessness.

Against the third risk this site carries a contract: translated strings are marked in the file with a translation note and await the owner’s approval. An unapproved translation can go live, but its record is kept — which text a human has verified is always knowable.

Where to start

For someone considering a second language, a starting list ordered by impact.

1. Validate the market — will you really do business in that language? Can you carry its maintenance?
2. Choose the address structure — the hardest decision to reverse; to be made first and with care.
3. Set up the language declaration — the language tag on the root element; one line, large effect.
4. Complete the hreflang set — reciprocal, self-inclusive, complete.
5. Define x-default — what shows when nothing matches?
6. Carry it to the sitemap — repeat the page-level links at map level.
7. Build the maintenance arrangement — when a page updates, how do the other languages find out?

The first item is not technical, but it is the most decisive. A language opened but not maintained drifts from the main language within months, and at that point two options remain: closing it, or living with stale content. Both are worse than never opening it.

A practical checklist

Turning this page into an audit step, here is what to check in a multilingual setup. The list is kept short because long lists do not get walked; six items fit in one sitting, and most take a few minutes.

1. Was the address structure chosen, and is its rationale written?
2. Does every page declare its language — on the root element, without exception?
3. Is the hreflang set reciprocal and self-inclusive?
4. Was x-default defined — what shows when nothing matches?
5. Does the sitemap carry the language links?
6. Is the maintenance arrangement in place — when the source changes, how do the derivatives find out?

The sixth item, being non-technical, is the most skipped yet the most decisive in the long run: a language opened but not maintained drifts from the main language within months, and at that point two options remain — closing it, or living with stale content.