Building a Multilingual Website for the Swiss Market
Back to the journal / Web & design
By KORBI · 27 October 2026 · 3 min read
A Swiss language selector should lead to a complete, maintained version—not a translated button above content that never changed.
A multilingual website is a content and operating decision, not a translation toggle. Before choosing a URL pattern, decide which audiences the business serves, which languages its team can support and how a customer will move between language versions. In Switzerland, the answer may involve German, French, Italian and English, but not every company needs every language at launch.
Choose the language scope before translating
Start with the pages customers need to make a decision: services, product information, contact paths, policies and relevant help content. Decide who writes, translates, reviews and approves each version. A page should not be presented as fully available if key information, forms or calls to action remain in another language. Keep terminology consistent and record region-specific variants when a translation must be tailored rather than copied.
Give each language a stable URL
Separate, crawlable URLs make it easier to share, maintain and index language versions. The exact path structure is less important than consistency. Keep the same page intent across corresponding languages and avoid creating near-duplicate copies without a clear user reason. The visible language selector should link to an equivalent page only when that translation exists; otherwise, take the visitor to the translated index or another useful location.
Use reciprocal language annotations carefully
Google’s international-site guidance describes localized versions through `hreflang` annotations. For each translated page, annotate the language versions that actually exist and make the set reciprocal. Do not list missing or draft pages as alternates. Canonicals should identify the intended page version, while the sitemap and internal links should reflect the same route structure.[1][2]
Localize the whole experience
Translate titles, descriptions, headings, images and form states—not only article paragraphs. Check navigation labels, validation errors, confirmation screens and email language. Review dates, number formats, terminology and whether a button fits without wrapping awkwardly. A native reviewer can catch wording that is technically correct but unnatural for the audience.
Make ownership part of the system
Every language version needs an owner and a way to signal stale content. When one service changes, assign the corresponding translations for review. Keep a source language for editorial control but do not use it as an excuse for the other versions to drift. A content system can record translation status and revision dates; a small site can manage the same responsibility with an explicit checklist.
Privacy and region-specific content
A language or country selector does not by itself make a site compliant with local rules. Review which personal data is collected, what embedded services do and what the notice says about cookies. The Swiss FDPIC has issued specific guidance on cookies and similar technologies. Where a business serves people in the EU, review whether EU data protection obligations also apply; consult qualified advice for the organization’s actual processing.[3]
- Publish the most important customer journeys in every launch language.
- Use persistent language URLs and provide a clear route back to other versions.
- Create reciprocal `hreflang` only for complete, equivalent pages.
- Keep metadata and policy information aligned with the page language.
- Assign an owner to review translations whenever the source page changes.
Sources & further reading
- Managing multi-regional and multilingual sites — Google Search Central
- Tell Google about localized versions of your page — Google Search Central
- FDPIC guidelines on data processing using cookies and similar technologies — Federal Data Protection and Information Commissioner
Continue reading
- Website Redesign vs. Rebuild: Which Is Worth the Investment?
A visual refresh, a technical refactor and a rebuild solve different problems. Start with the evidence from the current site before choosing one.