Bilingual FR/EN website for a Swiss SME
Bilingual FR/EN website for a Swiss SME: why auto-translation isn't enough, hreflang explained simply, and the setup I recommend.
In Switzerland, many small businesses need two versions of their site. French for the French-speaking region. English for international clients. On paper, it sounds simple. In practice, this is where most sites fall apart.
I will explain how I build a bilingual site that holds up. No jargon. With one clear focus on a tag few people know well: hreflang. This tag tells Google which language to show to which visitor. Set up badly, it can make your English version vanish from search results.
Why bilingual is not enough
Having two languages on a site is not just translating the words. It is building two sites that talk to each other.
Here is the classic trap. You translate the homepage. You translate "Services" and "Contact". And you stop there. The result: an English-speaking visitor clicks a blog article and lands on French. They leave. Trust breaks in three seconds.
A real bilingual site means full parity. Every French page has its English match. Every internal link stays in the right language. The menu, the buttons, the form error messages, all of it follows. If a single piece is missing, the visitor feels it.
I have done this work for real. My first delivered project is the website for Ahmed Ghattour & Co, an audit firm based in Tripoli. The site is bilingual English and Arabic. Arabic reads right to left, which complicates everything: the menu, the margins, the text alignment, all of it must flip. Around twenty pages, two languages, two reading directions. You can see the result on the Ghattour case page.
The key point: if I can handle English and Arabic with two reading directions, the French and English pair is simpler. Both languages read left to right. The method stays the same. Parity, language routing, SEO tags: it is the same work, made easier.
The auto-translation trap
The temptation is strong. Google Translate, DeepL, a plugin that translates everything in one click. Why pay for translation when a machine does it for free?
Because it costs you more in the end. Here is why.
First, quality. A machine translation sounds right about 80 percent of the time. The remaining 20 percent hurts. A Geneva law firm showing an off-tone phrase in English loses credibility. Your international clients judge your seriousness on these details. A Swiss SME sells precision. Sloppy text says the opposite.
Second, SEO. Auto-translation plugins often generate pages that Google sees as duplicate or low-quality content. Google may decide not to show them at all. You have two languages on your site, but only one exists for the search engine.
Third, control. With a fully automatic plugin, you control nothing. You cannot fix a sentence. You cannot adapt a heading so it reads better in English. You just take what you get.
My method is different. I separate content from code. Each text lives in a translation file, one language per file. You, or a human translator, write both versions. The site displays them cleanly. You keep your hand on every word.
A machine translates words. A human translates intent. On a site meant to sell, intent matters more than words.
In practice, here is what it looks like on the technical side. Two files, one per language, with the same keys:
// fr.json
{
"contact": {
"title": "Parlons de votre projet",
"cta": "Demander un devis"
}
}
// en.json
{
"contact": {
"title": "Let's talk about your project",
"cta": "Request a quote"
}
}The code calls the key contact.title. Depending on the visitor's language, it shows the right sentence. No risk of forgetting a translation: if a key is missing, it shows up at once.
hreflang in plain English
Here is the technical term of the article. I will make it simple.
hreflang is a small invisible tag in the code of each page. Its job: to tell Google "this page exists in French, and here is its exact address; it also exists in English, and here is the other address". The word comes from two parts: "href" means the address of a link, "lang" means the language.
Without this tag, here is what happens. A client searches for your firm on Google in France. Google has found your English page and your French page. It does not know which to show. It picks one at random, sometimes the wrong one. Your French-speaking visitor lands on English. Or worse, Google thinks your two pages are copies and hides one.
With hreflang, you remove the doubt. You tell Google: French version for French speakers, English version for English speakers. Each visitor arrives in their own language, from the first click.
Here is what the tag looks like in the code of a page:
<link rel="alternate" hreflang="fr" href="https://example.ch/contact" />
<link rel="alternate" hreflang="en" href="https://example.ch/en/contact" />
<link rel="alternate" hreflang="x-default" href="https://example.ch/contact" />Three lines, three roles. The first says: "for French, go to this address". The second says: "for English, go to that one". The third, x-default, is the fallback version. It is the one Google shows when it recognizes neither French nor English in the visitor. Here, I chose French as the default, because the SME is in French-speaking Switzerland.
Three rules I always follow, and that many people forget:
- Reciprocity. If the French page points to the English one, the English one must point back to the French one. Otherwise Google ignores everything. It is like a handshake: you need both hands.
- Full addresses. Always the complete address with
https://, never a shortcut. Google does not like to guess. - One default only. A single
x-defaultfor the whole site, not one per page in a contradictory way.
The good news: on a well-built site, these tags generate themselves. I set them up once in the system, and every new page gets them automatically. You do nothing by hand. That is exactly what I do on my projects: the language and the tags are wired in from the start.
2 setups: subdomains vs subfolders
Now comes a real decision: where does the English version of your site live? Two paths are possible. I will explain both, then tell you which one I pick.
Option 1: subdomains. Your English version lives at a separate address. For example en.example.ch. The "en." in front of the domain name creates a separate address. Google sometimes treats this subdomain like an almost independent site.
Option 2: subfolders. Your English version lives in a folder of your main site. For example example.ch/en/. The "/en/" after the domain is just internal filing. Everything stays under the same main address.
The difference is not just looks. It changes the SEO.
When your site gains reputation in Google's eyes, that reputation builds around your domain name. With subfolders, your two languages share the same reputation. All the work benefits both versions. With subdomains, Google may split the accounts. Your English version starts almost from scratch to earn its place.
Here is a simple table to compare:
| Criterion | Subdomain (en.example.ch) | Subfolder (example.ch/en/) |
|---|---|---|
| SEO reputation | Often split by language | Shared across languages |
| Setup | More server configuration | Simpler |
| Readability for the client | Fine | Very clear |
| Maintenance cost | Higher | Lower |
Subdomains keep a legitimate use. If your two versions are run by different teams, or hosted in different places, it can be justified. For a large group with ten markets, sometimes yes. For a Swiss SME with two languages, almost never.
My recommended choice for a Swiss SME
For a Swiss SME, I recommend subfolders. Main address in French on the root, English in /en/. That is exactly what I set up by default.
Three concrete reasons.
First, SEO. Your two languages share your domain's reputation. In French-speaking Switzerland, your name is your main asset. Everything should work for it, not split across two addresses.
Second, cost. One address to manage, one security certificate, one configuration. Fewer parts, fewer breakdowns, a smaller maintenance bill. For an SME paying for a site, that matters.
Third, clarity. example.ch/en/contact is readable for a human and for an engine. You see the language, you see the page. No surprise.
Here is how I structure a typical bilingual site:
- French on the root:
example.ch/,example.ch/services,example.ch/contact - English in a subfolder:
example.ch/en/,example.ch/en/services,example.ch/en/contact hreflangtags placed automatically on each page- One translation file per language, parity checked on every build
One detail I always add: on the French root, I do not put /fr/ in front of the addresses. Since French is the default language for a French-speaking Swiss SME, its version stays on the short address. Cleaner, more natural for your Swiss clients.
A word on budget, because the question always comes up. A simple showcase site starts at CHF 2,500. An advanced, multilingual showcase sits between CHF 3,000 and CHF 12,000, depending on the number of pages and complexity. Bilingual adds real work: double the content, language tags, testing in both versions. But it is work I know. The full pricing is on my pricing page.
To sum up. Bilingual does not mean "half translated". It means two complete sites that talk to each other, with the right tags so Google sends each visitor to their language. Auto-translation saves you an hour and loses you clients. Subfolders beat subdomains for an SME. And hreflang is the invisible piece that holds it all together.
Got a bilingual project in mind? First see what my showcase offer covers. Or look at the Ghattour bilingual case to see the work for real. Twenty minutes on the phone is usually enough to know if we move forward together.