Guide
Language folders, subdomains or separate domains
For a Swiss organisation serving several language groups, one domain with a folder per language (example.ch/de/, example.ch/fr/) is the simplest structure to run, and it is the default we suggest unless there is a specific reason to separate. Subdomains and separate country domains each solve particular problems, and each brings costs that are easy to underestimate.
The four options Google describes
Google's guidance on multi-regional and multilingual sites sets out four ways to give each version its own address, with advantages and drawbacks for each 1. Paraphrased, with the Swiss situation in mind:
| Structure | Example | What Google lists in favour | What Google lists against |
|---|---|---|---|
| Country domain | example.ch, example.fr | Clear geotargeting; server location irrelevant; easy separation | Expensive, may have limited availability, more infrastructure, sometimes strict registration rules, one country per domain |
| Subdomain | fr.example.ch | Easy to set up; servers can differ; easy separation | Readers may not tell whether "fr" means a language or a country |
| Subdirectory | example.ch/fr/ | Easy to set up; low maintenance on one host | One server location; versions harder to separate; same ambiguity for readers |
| URL parameter | example.ch?lang=fr | None given | Marked as not recommended; segmenting by address becomes difficult |
The last row settles one question quickly: parameters are the option Google marks as not recommended, so they should not be the plan for a new site.
Why a language folder fits one country with several languages
Take a Swiss site in German, French and Italian that is aimed at Swiss readers. Country domains exist to separate countries, which is not the problem being solved here. Subdomains exist to separate infrastructure, which one organisation does not need for language alone. That leaves folders, which keep everything on one domain, one certificate, one analytics property and one content system.
Folders also make the structure readable for people. A reader who sees /fr/ in the address can guess what /it/ will hold, and an editor can see at a glance which language a page belongs to.
When subdomains make sense
Subdomains earn their place when the versions really are run separately. Examples: a French version maintained by a regional partner on its own platform, or a shop in one language that lives on a hosted commerce service while the rest of the site sits elsewhere. Google notes that subdomains allow different server locations 1, which matters when separate teams or systems are involved.
The cost is that each subdomain behaves more like a site of its own. Internal links cross between them, cookies may not carry across without extra set-up, and every tool that reports on the site has to be told that fr.example.ch belongs with www.example.ch.
When a separate domain makes sense
A separate country domain is the right call when the organisation genuinely addresses different countries with different offers, prices or legal terms: a Swiss company that also sells in France under French conditions, for instance. Then example.fr signals clearly that the content is for France, and Google lists clear geotargeting as the main advantage 1.
The point to absorb is that a country domain targets one country, not one language. A French-language version for Swiss readers belongs on the Swiss domain. Putting it on a .fr domain would tell search engines it is for France, and Swiss French readers would be the ones misled.
Translated slugs or matching slugs
Within a folder structure there is a second decision: whether page addresses are translated. Compare /fr/a-propos/ with /fr/about/. Translated slugs read naturally and look right in search results; matching slugs make it easier for editors to pair versions by eye.
Hreflang does not care which you choose, because it links pages by full address, not by matching names 2. Choose translated slugs if your platform can store a separate slug per language, and write the rule down so that new pages follow it. Avoid characters that some systems mishandle; ueber-uns is safer than über-uns.
What the root address should do
With language folders, something has to answer at example.ch/ itself. There are three workable answers:
- A short language chooser page, with each language named in itself. This page is a natural target for
x-default. - The main-language version served at the root, with the other languages in folders. Workable, but it makes the structure uneven: German at
/, French at/fr/. - A redirect to one language folder. Simple, but if it is based on guessing the visitor's language, see the cautions in our guide to automatic redirects.
We lean towards the first option for organisations with no dominant language and the second for those where one language clearly carries the business, provided the uneven structure is documented.
Changing structure later
Moving from one structure to another means changing every address on the site, with redirects from each old address to its new one, updated hreflang, new sitemaps and corrected internal links. It is possible, and sometimes necessary, but it is far more work than choosing well at the start. That is the main argument for settling this question before design begins rather than leaving it to whoever builds the templates.
A short decision path
- Do the versions serve one country in several languages? Use language folders on your national domain.
- Do some versions serve another country with different offers or conditions? Consider a domain for that country, and keep the Swiss languages together on
.ch. - Is a version run by a different team or system? A subdomain may be the honest reflection of that.
- Still unsure? Write down which pages exist in which language and who maintains them; the pattern in that list points to an answer. Our project planner produces that list.
Sources
Not sure which structure fits?
Tell us about your audiences and platform. Our reply by email says whether we could help you decide.
Ask about structure