Multilingual Website Setup for Swiss Businesses

6 min read

By Tiago Basilio

Switzerland’s Multilingual Reality

Switzerland has four official languages: German, French, Italian, and Romansh. In practice, most Swiss businesses need their website in at least German and French, often English too, and sometimes Italian. If you’re targeting all of Switzerland, a single-language website means you’re ignoring a significant portion of your market.

But multilingual isn’t just “translate the text.” It affects your URL structure, SEO strategy, content management workflow, and even your frontend architecture. Getting it right from the start saves you from painful rewrites later.

I’ve built multilingual sites for Swiss businesses across different tech stacks. This article covers the architecture decisions you’ll face and how to make them.

URL Structure: The First Decision

How you structure multilingual URLs affects SEO, user experience, and implementation complexity. The three main options:

example.ch/de/produkte
example.ch/fr/produits
example.ch/it/prodotti

Pros: Single domain, shared domain authority, straightforward to implement, easy to manage in one codebase.

Cons: Slightly more complex routing.

Option 2: Subdomains

de.example.ch/produkte
fr.example.ch/produits
it.example.ch/prodotti

Pros: Clean separation, can be hosted independently.

Cons: Each subdomain builds domain authority separately. More DNS and hosting configuration.

Option 3: Separate Domains (ccTLDs)

example.de/produkte
example.fr/produits
example.it/prodotti

Pros: Strong local SEO signal for each country.

Cons: Most expensive, most complex to maintain, and Switzerland doesn’t have language-specific TLDs, and .ch covers the whole country.

My recommendation: Subdirectories for most Swiss businesses. You keep all your SEO authority on one domain, the implementation is clean, and it maps well to Switzerland’s multi-language-single-country reality.

SEO: hreflang and Language Targeting

Google needs to know which language version to show to which users. This is where hreflang tags come in.

Implementation

Every page must include hreflang link tags pointing to all its language variants, including itself:

<link rel="alternate" hreflang="de-CH" href="https://example.ch/de/produkte" />
<link rel="alternate" hreflang="fr-CH" href="https://example.ch/fr/produits" />
<link rel="alternate" hreflang="it-CH" href="https://example.ch/it/prodotti" />
<link rel="alternate" hreflang="x-default" href="https://example.ch/de/produkte" />

Key rules

  • Use language-region codes: de-CH, not just de, since Swiss German content may differ from German German content.
  • Include x-default: this tells search engines which version to show when no language match exists. Typically your primary language (German for most Swiss businesses).
  • Every page must reference all variants: if a page exists in 3 languages, all 3 pages must have all 3 hreflang tags.
  • URLs must match exactly: including trailing slashes. A mismatch between the hreflang URL and the actual URL will cause Google to ignore the tag.
  • XML sitemap: include hreflang annotations in your sitemap as well. This serves as a backup signal for search engines.

Common mistakes

  • Forgetting to add hreflang tags to new pages
  • Having hreflang tags pointing to pages that return 404
  • Using de instead of de-CH (this targets all German speakers, not Swiss German specifically)
  • Not including the self-referencing hreflang tag

Content Management

Multilingual content management is where most projects get painful. The question is: how do you store, edit, and deploy content in multiple languages?

Approach 1: Parallel Content Files (Static Sites)

For static site generators (Astro, Next.js, Hugo), create parallel content directories:

content/
  de/
    produkte/
      product-1.md
  fr/
    produits/
      product-1.md
  it/
    prodotti/
      product-1.md

Pros: Simple, no CMS dependency, version-controlled.

Cons: Hard to keep translations in sync. Easy to update one language and forget the others.

Approach 2: Database with Language Column (Dynamic Sites)

For Laravel or other dynamic frameworks, store translations in the database:

products table:
  id | slug_de | slug_fr | name_de | name_fr | description_de | description_fr

Or better, use a dedicated translations table:

products table: id, sku, price
product_translations table: product_id, locale, name, slug, description

Pros: Easy to query, keeps translations linked to the source content.

Cons: Schema gets complex. Every query needs a locale filter.

Approach 3: Headless CMS with Localization

Services like Storyblok, Contentful, or Strapi have built-in localization features. Editors can see all language versions side by side and track translation status.

Pros: Best editor experience, built-in translation workflows.

Cons: External dependency, cost, API latency.

My recommendation

For marketing sites and blogs, parallel content files work well if your team is disciplined. For e-commerce and data-heavy applications, the translations table approach in Laravel gives you the most control. For content-heavy sites with non-technical editors, a headless CMS is worth the cost.

Frontend Implementation

UI Translations (Labels, Buttons, Error Messages)

Don’t hardcode text in your templates. Use a translation system:

  • Laravel: Built-in trans() / __() helpers with JSON or PHP translation files
  • Vue/React: Libraries like vue-i18n or react-intl
  • Astro: i18next integration or custom translation utilities

Keep translation files organized by page or component, not in one massive file.

Language Switcher

The language switcher should:

  • Link to the same page in the other language (not the homepage)
  • Show the language name in its own language (Deutsch, Français, Italiano, not German, French, Italian)
  • Be visible and accessible, typically in the header or top navigation
  • Preserve the current page context (filters, pagination, etc.) where possible

Date, Number, and Currency Formatting

Switzerland has its own formatting conventions:

  • Dates: 14.02.2025 (DD.MM.YYYY), not 02/14/2025
  • Numbers: 1'234.56 (apostrophe as thousands separator), not 1,234.56
  • Currency: CHF 49.90, not 49.90 CHF or $49.90

Use the Intl API with the appropriate locale (de-CH, fr-CH, it-CH) for formatting. Don’t build custom formatters.

Automatic Language Detection

Should your site auto-detect the user’s language? Maybe. Here’s the trade-off:

Redirect based on browser language (Accept-Language header):

  • Good for first-time visitors
  • Can be annoying if it guesses wrong (a German-speaking tourist in Geneva gets the German version)
  • Must still provide an easy way to switch

Redirect based on IP geolocation:

  • Unreliable and often wrong (VPNs, mobile networks, tourists)
  • Not recommended as the sole detection method

My approach: Detect the browser language on first visit and suggest (not force) a redirect. Store the user’s preference in a cookie. Never redirect returning visitors away from their chosen language.

Key Takeaways

  1. Choose subdirectories for your URL structure unless you have a strong reason not to
  2. Implement hreflang correctly from day one. Fixing it retroactively is tedious
  3. Pick a content management approach that matches your team and update frequency
  4. Don’t hardcode text: use proper i18n tooling for UI strings
  5. Respect Swiss formatting conventions for dates, numbers, and currency
  6. Suggest, don’t force language detection

Building a multilingual site for Switzerland isn’t just a translation job, it’s an architecture decision that touches every layer of your stack. Plan for it early, and it’s straightforward. Bolt it on later, and you’re in for a rewrite.

Need help building a multilingual site for the Swiss market? Get in touch or visit tedbin.com.

#Switzerland #SEO #Web Development #Internationalization