01Decision log / Multilingual websites
A language switcher is not a multilingual architecture.
The visible translation is only one layer. A maintainable multilingual website needs clear URLs, equivalent pages, reliable language links, and one operation behind every version.
Published 25 August 2026 · REAL COMPANY
LIVE / EN- Based on
- A live three-language project
- Covers
- Content, routes, SEO, and operation
- Useful for
- Company and product websites
Core premise
Give every language a stable, crawlable home.
A language that only appears after a JavaScript toggle is difficult to share, measure, and maintain. Each important language version should have its own URL and return complete HTML that users and search engines can reach directly.Four decisions / 01—04Start with the URL
Give every language a stable, crawlable home.
A language that only appears after a JavaScript toggle is difficult to share, measure, and maintain. Each important language version should have its own URL and return complete HTML that users and search engines can reach directly.
For Real Company we use clear language paths and connect equivalent pages with hreflang. The same rule shaped Delux: a user should land on the right language, move to its equivalent, and keep the page context.
- One canonical URL per language
- Reciprocal hreflang links
- An x-default for the primary route
- A sitemap containing every indexable version
Protect parity
Equivalent does not mean word-for-word translation.
Every language should complete the same user job, but the copy does not need to preserve English syntax. Labels, examples, reassurance, and calls to action should feel native to the reader.
Parity is operational: the vehicle, service, price, availability, or contact path must describe the same reality. Localization is editorial: the wording should make that reality clear in language people actually use.
- Match the offer and factual state
- Localize the sentence, not only the words
- Keep calls to action practical
- Review RTL as a real interface
ONE FACTIn stock / موجود / Stokta
THREE VOICESNatural ≠ identical
One operation
Do not create three separate websites by accident.
The public pages can be separate while the business truth remains shared. Inventory, contact behavior, product status, and reusable media should come from one maintainable source whenever possible.
Otherwise every update becomes a synchronization task and the least-used language slowly becomes inaccurate. The architecture should make the correct update easier than the incomplete one.
See the Delux projectThe working checklist
Test the path, not only the translation file.
Open every important route directly. Switch languages from deep pages. Check canonical and hreflang relationships. Verify mobile navigation in LTR and RTL. Confirm that forms, phone numbers, dates, and external links still make sense.
A multilingual website is finished when each language can carry the complete journey without borrowing context from another version.
- Direct route returns 200
- Language switch keeps page context
- Metadata is localized
- Structured data matches visible content
- Mobile links are complete in every language
What should survive
Planning a multilingual website?
Bring the languages, content reality, and operating constraints—not only a list of pages to translate.Start a project ↗FAQ
Questions, answered directly.
Should each language have a separate URL?
Yes for indexable pages. Stable URLs make each version shareable, crawlable, measurable, and easier to connect with hreflang.
Does every language need identical text?
No. Each version should preserve the same factual offer and user outcome while using natural language, examples, and interface wording.
Can a multilingual site use one data source?
Yes. Shared operational data often reduces errors while the public pages and editorial copy remain language-specific.