Engineering multilingual web platforms: routing, content and SEO

Multilingual is an architecture decision, not a translation task

Most teams treat multilingual support as a content task to schedule after launch. In practice, the decisions that make or break a multilingual platform — URL structure, content modeling, fallback behaviour — sit deep in the architecture, and retrofitting them is among the most expensive migrations a web platform can undergo. We engineer trilingual and larger platforms regularly, and the pattern is consistent: teams that fix their locale strategy in week one launch new markets in days, while teams that bolt it on later spend a quarter untangling routing, caching and SEO regressions.

Pick a URL strategy and commit

Search engines and CDNs want the same thing from you: one stable, crawlable URL per locale. Three strategies dominate, and mixing them is worse than any single choice.

• Path prefixes (/de/leistungen): one domain, one certificate, one deployment. hreflang, analytics and caching stay simple — this is our default.
• Subdomains (de.example.com): justified when markets run separate teams or infrastructure, at the cost of extra DNS, certificates and fragmented analytics.
• Country-code domains (example.de): the strongest geo signal and the highest operating cost — reasonable only when a market is a business unit in its own right.

Whatever you pick, never vary content by Accept-Language header or cookie on the same URL — caches and crawlers both punish it. Locale detection belongs in a single redirect from the bare root, and the user's explicit language choice must always override the guess.

Translation workflows that survive release velocity

Hardcoded strings are how multilingual platforms rot. Every user-facing string lives in a keyed catalog per locale, and the key set is a contract enforced in CI: a build with missing or orphaned keys fails, exactly like a failing type check. That one gate eliminates the most common production bug in multilingual systems — a silent English fallback in the middle of a German page.

The second failure mode is treating translation as word-for-word conversion. Strong locales are adaptations: legal copy in German follows different conventions of tone and sentence length than its English source. Give translators context — screenshots, character limits, adjacent copy — rather than spreadsheet rows of isolated strings, and route every locale through a native reviewer before release.

hreflang is unforgiving, so generate it

hreflang has one rule teams keep tripping over: annotations must be reciprocal. If the English page declares a German alternate, the German page must declare the English one back — otherwise search engines discard the entire cluster and pick winners themselves.

• Generate alternates for every locale plus x-default from the routing layer's single source of truth; hand-maintained hreflang always drifts.
• Localize slugs (/de/leistungen, not /de/services) and keep a per-entity slug map so alternate URLs stay resolvable.
• Point each locale's canonical to itself, and list the alternates in the sitemap so crawlers discover the full cluster in one pass.

Performance: a locale must not cost a round trip

Locale-in-URL pays for itself at the CDN: the cache key is the URL, so every localized page can be statically rendered or edge-cached without Vary-header gymnastics. Split message catalogs per route so a visitor never downloads three languages to read one, and subset fonts per script — Albanian diacritics and German umlauts should not force a full extended-Latin font onto every visitor. Above all, avoid client-side locale detection that renders one language and repaints another: it is a layout shift and a trust problem at once.

Model the database translation-first

The schema decision matters most. Never widen tables with title_en and title_de columns — model each translatable entity as a base row holding identity, relations, media and publishing state, plus a translations table keyed by entity and locale that carries name, slug, body and SEO fields.

• Adding a locale becomes a data operation, not a schema migration.
• A unique constraint on (locale, slug) gives every language clean, collision-free URLs.
• Fallback policy becomes explicit and queryable per content type: show the default language, or hide the entry until its translation ships.

Done right, multilingualism is invisible: every market gets a platform that feels native, ranks locally and performs identically. That is the standard worth engineering for — three languages that behave as one platform.