Multilingual Web Design 2026: An Architecture That Holds Up

A second language version is quick to set up technically and rarely thought through properly. Translate and publish without more, and you give away most of what a multilingual website can actually deliver.

When multilingual is worth it

A second language version pays off where a genuinely relevant audience actually searches in that language: international B2B positioning, offerings relevant to Austria or Switzerland, or brands with a clear ambition beyond German-speaking markets. For a purely local trades business with no international customers, a second language rarely delivers a measurable benefit and mostly means extra maintenance.

URL architecture: subdirectory, subdomain, or separate domain

The core technical decision comes down to three options that differ meaningfully in maintenance effort and SEO impact:

Our own website uses a subdirectory model with /de/ and /en/, built with next-intl: every route exists under a localised path, and every language version stays part of the same domain, benefiting from its overall strength. For most multilingual small and mid-sized business sites, that is the more pragmatic solution, since it stays maintainable with a manageable technical footprint.

Getting hreflang right

Whichever architecture you choose, hreflang tags are the signal that tells Google which version is meant for which language and country. Miss that signal, or set it incorrectly, and Google can surface the wrong version in the wrong results, or the two versions end up competing against each other unintentionally. On our own site, every page is linked to its counterpart in the other language via hreflang, including x-default for visitors without a clearly matching language setting. How to get this right specifically across several German-speaking countries is covered in Hreflang for DACH.

Translation is not localisation

Translation replaces words; localisation adapts content to a market. For most small and mid-sized business sites, a clean translation with local context is enough: prices in the target market's currency, dates formatted the way that market expects, address forms matching local convention. A purely machine-translated draft without review is fine as a starting point, but it should always be checked by someone with a feel for the language before publication. Copy that reads as visibly translated rather than written costs trust at exactly the moment a visitor decides whether to keep reading or leave.

What to actually translate

• Service pages, pricing, and the contact page: always translated in full
• Frequently asked questions: translated, since they directly shape trust and decisions
• Blog content: selective by market relevance, not every article by default
• Legal pages such as imprint and privacy: adapted to the relevant jurisdiction, not just translated
• Meta titles and descriptions: written independently for each language, not carried over word for word

Concrete steps for the next 90 days

• Days 1-30: check the target market and actual demand in the second language, decide on the URL architecture
• Days 31-60: translate and localise core pages, set and test hreflang tags for every language version
• Days 61-90: set up separate Search Console and analytics reporting per language, compare early results across languages

Conclusion

Decide the URL architecture first, because it is the only one of the three points that can later be corrected solely through a full redirect chain. hreflang can be retrofitted and copy can be sharpened - a badly chosen domain or directory structure, by contrast, stays with you for the entire life of the site. How these principles connect to the rest of a website's technical foundation is covered in Web design trends 2026. Details on our own bilingual setup are on the pricing page.