Multilingual Websites for Swiss Companies: Getting German, French, Italian and English Right
Four languages, one site. URL structure, hreflang, translation workflow and the mistakes that cost Swiss companies rankings in their own market.
A Swiss multilingual site is not one site translated three times. It needs a URL structure that search engines can map — subfolders per language, not automatic redirects — correct hreflang between every equivalent page including x-default, translated URLs and metadata rather than body text alone, and a workflow that keeps the versions from drifting apart. The most common failure is not poor translation. It is a German version and a French version that stopped matching each other years ago.
Published 31 July 2026 · Last updated 31 July 2026
The Swiss constraint: four languages, four search behaviours
Switzerland is not one search market with four interface options. Each language region searches with its own vocabulary and phrasing, so the same product is described differently in Zurich, Lausanne and Lugano. Localisation is therefore a keyword-research problem before it is a translation problem.
Keyword research has to be run separately in each language, by someone who searches in it. Translating the German list into French produces terms that are grammatically correct and commercially wrong: German buyers tend to search compact compound nouns, French buyers use longer descriptive phrases. A translator working from a finished German page cannot recover the query that page was written to answer.
More than 99% of Swiss companies are SMEs and they account for two thirds of employment, according to Swiss Federal Statistical Office figures (STATENT, 2023) published on KMU.admin.ch. At that size there is no in-house localisation team, so the workflow matters more than the technology. Decide first which language regions generate revenue today and which are aspirational: the first group justifies full localisation, the second one well-made page.
URL structure: subfolder, subdomain or ccTLD?
For nearly every Swiss company, subfolders on a single domain are the right answer: example.ch/de/, example.ch/fr/, example.ch/it/, example.ch/en/. One domain accumulates one set of authority signals, one certificate, one deployment. The alternatives solve problems most Swiss SMEs do not have.
| Option | Example | What it does well | Maintenance cost | Reasonable when |
|---|---|---|---|---|
| Subfolder per language | example.ch/fr/ | Keeps authority on one domain; simplest to crawl and operate | Lowest: one domain, one stack, one deployment | The default for a Swiss company serving its own market |
| Subdomain per language | fr.example.ch | Allows separate hosting or a separate platform per language | Moderate: separate certificates and configuration | A language version runs on different infrastructure |
| Country-code domain (ccTLD) | example.de | Strongest country signal; matches local expectations abroad | Highest: each domain ranked and maintained separately | You operate as a distinct entity abroad, not just in another language |
| Parameter or session switch | example.ch/?lang=fr | Little, from a search perspective | Cheap to build, expensive to unwind | Rarely; only for an unindexed internal tool |
Whatever structure you choose, do not redirect visitors automatically by IP address. Automatic redirection sends every request from a given location to one version, so a crawler requesting the French page from outside Switzerland may never see it, and a version without a stable URL struggles to be indexed. Serve the URL requested, show a dismissible suggestion when the browser language differs, remember the choice, and keep a visible switcher.
hreflang without breaking it
hreflang is an HTML annotation that tells a search engine which language and region a page is written for, so that equivalent pages are treated as one piece of content in several versions rather than as duplicates. It is the element most often implemented incorrectly, because it has to be right on every page at once.
Every page points to every equivalent, including itself
Annotations work as a closed set. If the German page lists the French one, the French page must list the German one, and each must list itself. A one-way reference is discarded, which is why partial implementations produce no benefit at all.
Map pages one to one: the German services page points to the French services page, not to the French homepage. Pick one implementation method — tags in the <head>, HTTP headers or the XML sitemap — and keep to it.
de-CH, fr-CH, it-CH, en-CH and when to use plain de or fr
A language code on its own, such as de, targets speakers of that language anywhere. A language-region pair, such as de-CH, targets speakers of that language in that country. The region half is a targeting instruction, not a quality signal.
Use the regional form when the page is genuinely Swiss-specific: prices in Swiss francs, Swiss delivery terms, Swiss legal references. Use the plain code when the page also serves German speakers in Germany and Austria. en-CH is legitimate and often overlooked, describing an English page written for people in Switzerland, which is what most Swiss B2B English pages are.
x-default and what it should point to
x-default is the hreflang value that names the fallback version, the one served when a visitor's language and region match none of the alternatives listed. Point it at the version most usable by someone you did not anticipate, usually the English page. What it should not be is a redirect.
The three errors Search Console flags most
Three failures recur, and all three are silent: the site keeps working, the annotations simply stop counting. The first is missing return links, which appears when a language is added and only the new pages are annotated. The second is an invalid code: a region used where a language belongs, or an underscore instead of a hyphen. The third is annotations pointing to URLs that redirect or are set to noindex, which cancels the whole set. Re-check all three after any migration.
What actually has to be translated?
Everything a visitor or a crawler can read, which is more than the body copy in your CMS. Half-translated sites are common because translation is scoped as "the pages", and the rest of the interface is discovered after launch by a customer.
- The URL slug. A French page at
/fr/unsere-leistungen/reads as an afterthought. - Title tag and meta description. An untranslated title costs the click before the page is read.
- Navigation and microcopy. Menu labels, breadcrumbs, pagination, "read more".
- Image alt text. Part of the accessible experience and of what a crawler reads.
- Structured data. Schema names and FAQ text should match the page carrying them.
- Form labels and validation messages. Error strings are often hard-coded in a plugin and missed.
- Transactional emails. Confirmations sent after the visitor switched language.
- PDFs and downloads. A German data sheet on a French page is a gap the visitor notices.
- Cookie banner and consent categories. Purpose descriptions, not only the buttons.
- Legal pages. Terms, privacy notice and imprint, reviewed rather than machine-translated.
- Checkout terms. Payment methods, shipping options and returns policy.
- Search, filters and the 404 page. Where people land when something has gone wrong.
The commercial pages deserve attention. Swiss online consumption reached CHF 15.8 billion in 2025, up 6%, of which CHF 2.8 billion was spent with foreign retailers, according to HANDELSVERBAND.swiss with NIQ/GfK and Swiss Post (2026). Domestic sellers compete with foreign ones for the same basket, and a checkout that reverts to German at the payment step is a self-inflicted disadvantage, as our article on selling online in Switzerland sets out.
Translation workflow that survives contact with reality
A workflow that holds up has four elements: one source language, one named owner per target language, a rule that fires whenever the source changes, and a report that reveals drift before a customer does. Without the fourth, the first three decay within a year.
Version drift is the gap that opens between language versions when one is updated and the others are not, and it is the defining failure of Swiss multilingual sites because it produces no error message. The German page gets a new price; the French page keeps the old one and continues to rank.
Fix the source language first, usually German. Every substantive change starts there and propagates outwards, which prevents two versions being edited independently and reconciled by nobody. Give each target language a named owner with authority to declare a translation ready, and add review by a native speaker working in that region: a technically correct French text written outside Switzerland reads as foreign to a Romandy buyer. A translation memory is a database of previously approved source and target segments, used to keep terminology consistent as pages are revised.
Propagation is a natural candidate for process automation for Swiss SMEs: when a source page is published, create the translation tasks, attach the changed sections and notify the owners. The drift report is simpler, a scheduled list of every page whose source is newer than its translations. Circulating it monthly does more for quality than any style guide.
Machine translation: where it is fine and where it isn't
Machine translation is appropriate for a first draft and for low-stakes pages, and inappropriate wherever a wrong word carries a cost. The line follows from consequence, not principle.
It works as a productivity tool: a first pass that a human editor corrects, internal documentation, and long informational archives such as older blog entries. Post-editing — a translator revising machine output against the source rather than translating from scratch — is a legitimate workflow and materially cheaper than full translation.
It is the wrong tool for legal text, pricing and contractual terms, compliance information, product-critical specifications and the pages carrying your positioning. This market is unusually sensitive to language quality: a French page that reads as translated German signals, accurately, that the Romandy customer was an afterthought. There is a search dimension too, since large volumes of unreviewed output add nothing over what already exists in that language.
Performance cost of a multilingual build
A multilingual build is slower than the single-language site it grew out of, and the cost is paid at the database and caching layers rather than in page weight. Budget for it before launch.
Most of these projects are plugin decisions rather than platform decisions: WordPress powers 41.1% of all websites and holds 59.1% of the CMS market, according to W3Techs (2026). A translation plugin adds queries to almost every request, keeps string tables joined at runtime and rewrites URLs on the fly. Add translated media and per-language menus, and a site that passed comfortably in one language stops passing in four.
The thresholds are not generous. Only 48% of sites pass all three Core Web Vitals on mobile, with the "good" thresholds set at LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile, according to the Web Almanac 2025 from HTTP Archive and the web.dev thresholds it applies. Multilingual sites are frequently in the failing half. Cache per language, and measure each language separately on mobile: the German homepage passing tells you nothing about the Italian product page.
What does a multilingual site cost and how long does it take?
Cost is driven by four variables: how many languages, how many pages per language, whether translation is in scope, and whether you need full localisation or only the technical layer. For the Swiss market DINOLABS quotes implementation at [RANGE TO BE CONFIRMED] and ongoing maintenance at [RANGE TO BE CONFIRMED] per month.
Separate three lines that are often quoted as one. The technical layer covers URL structure, hreflang, per-language caching, translated metadata fields and the switcher; it barely changes with page count. Translation is priced per word and scales with volume, which is where a large archive becomes expensive. Maintenance covers new pages, propagating changes and running the drift report, and it is the line most often left out of a first budget.
The technical layer is the short part of the schedule. Delivery windows for the Swiss market are [RANGE TO BE CONFIRMED] and depend on page count and reviewer availability. One planning note proves consistently accurate: internal review takes longer than translation, and two reviewers with full-time roles will not clear two hundred pages in a fortnight. To have the scope priced against your actual page count, request a confidential assessment.
A pre-launch checklist for a Swiss multilingual site
Twelve points to verify before a multilingual site goes live. Each is cheap to fix beforehand and awkward to fix once the pages are indexed. Copy the list into your project documentation.
☐ 1. Languages chosen from where revenue and pipeline are, not from the map ☐ 2. Keyword research run separately per language by someone who searches in it ☐ 3. Subfolder structure live, one stable URL per language version ☐ 4. No automatic redirection by IP; suggestion offered, choice remembered, switcher visible ☐ 5. hreflang reciprocal on every page, self-reference included, one method only ☐ 6. x-default present and pointing to a usable page, not a redirect ☐ 7. Slugs, title tags, meta descriptions and alt text translated rather than copied ☐ 8. Forms, error messages, transactional emails and PDFs tested end to end ☐ 9. Legal pages, cookie banner and checkout terms reviewed in-market per language ☐ 10. Core Web Vitals measured per language on mobile, not only on the German homepage ☐ 11. Named owner per language, plus a written rule for when a source page changes ☐ 12. Drift report scheduled: every page whose source is newer than its translations
Points 5, 6 and 12 fail silently. Re-run them after any plugin update touching URLs.
When should you not build a multilingual site yet?
In five situations a multilingual build is the wrong next investment: it produces a site that costs more to maintain without being more effective.
All revenue comes from one language region and there is no pipeline elsewhere. A French version built on the assumption that it will create demand rarely does. One well-written French landing page with a real contact route tests the market for far less.
Nobody internally owns the second language. If no one can approve a French text, the version will be published once and never updated. Half a maintained site is worth more than a full one visibly out of date.
The source site is still moving. If architecture, pricing or positioning is under revision, every change multiplies across the versions. Multiplying an unstable site by four multiplies the rework by four.
The single-language site already fails on performance. Adding a translation layer to a site that misses the Core Web Vitals thresholds will not improve matters. Fix the base, then translate.
There is no budget for ongoing translation. Maintenance is the majority of the lifetime cost, so if only the build is funded, the honest recommendation is fewer languages, properly maintained.
Frequently asked questions
Do we need all four languages?
Usually not. Decide from where revenue and pipeline come, not from the linguistic map. Most Swiss SMEs are well served by German and French, adding Italian when there is real business in Ticino or a tender that requires it, and English when clients or recruitment are international. If a region is aspirational rather than active, build one well-made page there with a genuine contact route and measure it over two quarters.
Should we use de-CH or just de?
Use de when the page serves German speakers anywhere, including Germany and Austria. Use de-CH when it is specifically Swiss: prices in Swiss francs, Swiss delivery and payment terms, Swiss legal references. The region half of the code is a targeting instruction rather than a quality signal, so it narrows the audience rather than strengthening the page. Both can coexist if the two versions are genuinely different pages.
Is WPML the right tool?
It is a reasonable default on WordPress, not an automatic one. WPML is mature and handles what matters for search — translated slugs, title tags, meta descriptions and hreflang — but it adds database queries and administrative weight. Polylang is lighter with a smaller feature set; a multisite installation gives full isolation at the price of maintaining several sites. Choose on page count, who maintains them and your performance budget.
Can we auto-redirect visitors by IP?
It is not advisable. Automatic redirection sends every request from a given location to one version, so a crawler requesting your French page from outside Switzerland may never reach it, and pages that cannot be retrieved at a stable URL struggle to be indexed. Serve the URL requested, show a dismissible suggestion when the browser language differs, remember the choice, and keep a visible switcher.
How much does a multilingual site cost?
For the Swiss market DINOLABS quotes implementation at [RANGE TO BE CONFIRMED] and ongoing maintenance at [RANGE TO BE CONFIRMED] per month. Four variables move the figure: the number of languages, the number of pages per language, whether translation is in scope or supplied by you, and whether you need full localisation or only the technical layer. Ask any supplier to quote those three lines separately: maintenance is the one most often omitted.
How do we stop the language versions from drifting apart?
Four things, and the fourth makes the first three hold. Fix one source language in which every substantive change originates. Give each target language a named owner with authority to approve a translation. Write down what happens when a source page is published, so translation tasks are created rather than remembered. Then run a scheduled drift report listing every page whose source is newer than its translations, and circulate it monthly.
DINOLABS is a Colombian company that builds websites, process automation and AI agents for businesses in Colombia, Mexico, the United States and Switzerland.