Multilingual website: the short answer
A multilingual website gives each language its own version of every page that matters, at its own address. Hreflang tags tell Google which versions belong together, so it can show a searcher in Lyon the French page and a searcher in Leeds the English one. Whether it works is decided before and after the code: who writes each language, and who answers an enquiry that arrives in it.
This guide is for founders and managers at UK and EU companies adding a second language. Think of a British firm winning work in France, or a German company selling to British buyers.
One fact shapes everything below. Chrome already offers to translate pages for your visitors, free. So a French version earns its place only through what a browser can't do: French written for French buyers, local detail, and a reply in French.
We're a studio in Tirana. Albanian is our first language, we work with UK clients in English, and we wrote and built the KOP44 site in French for a contractor in Nantes. This is how we'd approach a business website in more than one language, including when not to.
Choose languages by where your enquiries come from
Start from the enquiries you get and the market you're going after, not from a map. Open your analytics and look at visitors by language and country. Then count last year's enquiries by the language they arrived in.
A language that brings visits but no enquiries may need better pages. A language that brings enquiries nobody can answer needs a person before it needs a website.
That's the rule we'd hold to: don't add a language you can't answer in. A French page promises a French reply. Say you run a 30-person engineering consultancy in Leeds and you've won two clients in Lyon. A French site that sends French enquiries to an inbox nobody in Leeds can read does more harm than an English one.
Choose by who you serve, too. Our Guidoo case study, for a travel platform in Albania, lists support in Albanian, because that's who the platform serves.
Then choose the pages. Most companies need these in each language:
- The homepage and every service or product page.
- An about page, with the people and proof a buyer checks.
- The contact or quote form, and the thank-you page after it.
- Your privacy notice, cookie text and terms.
A page is either in a language or it isn't. Google warns that translating only the menus and footer, while the main text stays in one language, can make a poor experience in search. If your case studies stay in English, link to them from the French pages with a clear "(in English)" label.
Translate, or write each language for its market
Most buyers want your site in their own language. CSA Research, a firm that studies the translation market, surveyed 8,709 consumers in 29 countries in 2020. It found that 76% prefer to buy products with information in their own language, and 40% will never buy from websites in other languages.
There are five routes to a French version, and each fits different pages.
| Route | What the reader gets | Where it fits |
|---|---|---|
| Nothing: the visitor's browser translates | A rough version you don't control | Occasional visitors from abroad |
| Machine translation, published unchecked | The same rough version, now with your name on it | Nowhere a buyer decides |
| Machine translation, checked by a fluent reviewer | Accurate text that can read stiffly | Long reference pages, product details, help articles |
| A professional translation of the English | Text that says exactly what the English says | Terms, privacy notice, anything where meaning must match |
| Written for the market by a fluent writer | Pages that read as if the firm were local | Homepage, service pages, anything that sells |
The gap between the last two rows is where a second language earns its keep. A translation keeps the English page's structure and examples. A page written for the market uses the market's own examples, units and proof.
KOP44's site, written in French for a French market, sets out its service area by department, the French administrative unit. A visitor knows at once whether they're covered. A British trades site would list towns or postcode districts instead.
The same CSA survey found 65% prefer content in their own language even when it's poor quality. That supports checked machine translation for long reference pages. Your homepage and service pages still need a writer.
Have someone fluent read every page in place
Every translation needs a fluent reader who checks it on the finished page, not in a spreadsheet of phrases. In 2008 Swansea Council asked its in-house translation service for the Welsh version of a sign barring lorries from a road near a supermarket. The reply was an out-of-office message, and it went on the sign.
The Welsh on the sign read: "I am not in the office at the moment. Send any work to be translated." Welsh speakers spotted it only once the sign was up. The editor of a Welsh-language magazine told the BBC: "Ideally, they should be written separately in both languages."
Websites fail the same way. Text leaves a translator, lands in a content system run by someone who can't read it, and goes live.
Many translation tools hide a second failure. When a phrase is missing in French, the site quietly shows the English one. The page looks finished to anyone glancing at it, and a French buyer meets an English button at the moment they're about to enquire.
Ask your developer to report missing translations before launch, or to stop the release while any remain. Then have the fluent reader go through every page, form and email in place.
If your supplier is abroad, ask who writes and checks each language. Our guide to working with a software studio in Albania makes the same point: a developer who writes clear English isn't automatically a copywriter in German.
Give every language its own address
Each language version needs its own URL. Google recommends separate addresses over switching the language with cookies or browser settings. Its crawler usually visits from the US and sends no language preference, so a site that picks the language from settings may only ever show Google one version.
There are four common patterns.
| Pattern | Example | Good for | Watch out for |
|---|---|---|---|
| Country domain per market | example.fr | Trading as a local firm in one country | One domain to register and renew per country, each with its own eligibility rules |
| Subdomain per language | fr.example.com | Versions run by separate teams or systems | Readers can't tell whether "fr" means the language or the country |
| Folder per language | example.com/fr/ | Most companies: one domain, one site, one host | All languages share one server and one set of settings |
| Parameter, cookie or browser setting | example.com?lang=fr | Nothing: Google advises against it | Google may never find the other versions |
For most companies we'd use folders. The domain you already rank with carries every language, and there's one site to maintain.
Country domains come with rules. Afnic, which runs .fr, stopped accepting new registrations from UK residents after Brexit. The holder must be based in the EU, Iceland, Liechtenstein, Norway or Switzerland.
Whichever domain you use, register it in your company's name. Our guide to checking whether you own your website shows how.
Translate the page addresses as well as the pages: example.com/fr/nettoyage-de-bureaux/ rather than example.com/fr/office-cleaning/. Google doesn't use the URL to decide the language, but readers see it in search results and in shared links.
Adding a language can move pages you already have, for example into a new /en/ folder. That's a migration, and every old address needs a redirect. Our guide to website migration SEO covers the list, the redirect map and the tests. The simpler route is to leave your first language where it is and add the new one in its own folder.
Hreflang: tell Google which pages are versions of each other
Hreflang is a tag that lists every language version of a page, so Google can show each searcher the version in their language. It can go in the page's head, in an HTTP header or in the sitemap, and Google treats the three the same. For a service page in English and French, both pages carry the same three lines:
<link rel="alternate" hreflang="en" href="https://example.com/services/office-cleaning/">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/services/nettoyage-de-bureaux/">
<link rel="alternate" hreflang="x-default" href="https://example.com/services/office-cleaning/">Google's rules, in short:
- Each version lists itself and every other version.
- The links go both ways. If two pages don't point to each other, Google ignores the tags.
- Addresses are written in full, starting with https://.
- The language code comes first, with an optional country after it. English for Britain is en-GB: Google says UK and EU have no effect in hreflang. A code on its own is read as a language: be is Belarusian, not Belgium.
- The x-default value names the page for visitors whose language you don't offer.
Hreflang goes wrong often. In a 2023 study, Ahrefs checked 374,756 domains that use it and found at least one issue on 67% of them. On 16.9%, tags pointed at redirected or broken pages, and 15.3% had pages missing their return links.
Tags written by hand drift as pages change. Have the site generate them from the record that holds each page's versions.
The HTML lang attribute does a separate job. Google doesn't use it to detect a page's language; it reads the visible text. Screen readers do use it, to load the right pronunciation rules.
WCAG, the web accessibility standard, makes it a Level A requirement in success criterion 3.1.1. Set lang="fr" on French pages, and give the word "English" in a French page's switcher lang="en".
Let visitors choose their language, and remember the choice
Don't redirect visitors to a language you've guessed. Google advises against redirecting on what you think a user's language may be, because it can stop people and search engines reaching the other versions. Location is a poor guide anyway. A British buyer on a trip to Paris still reads English.
Treat the browser's language and the visitor's location as hints. Suggest a version, for example with a line at the top of the page saying "Cette page existe en français", and let the visitor decide. Once they choose, remember it for their next visit. The W3C, which writes the web's standards, makes the same point: once a visitor picks a language, remember it, even over their browser's settings.
Four rules for the switcher:
- Put it on every page, where someone who can't read the current language will find it.
- Link to the same page in the other language, not to the homepage.
- Name each language in that language: English, Français, Deutsch.
- Use words, not flags.
The W3C advises against flags for languages. Some countries have several languages, and some languages are spoken in many countries. Switzerland has four national languages, and French is spoken from Brussels to Montreal. A French flag asks a reader in Geneva to click on another country.
What stays in English after launch
Everyone reviews the pages. Multilingual sites break later, at the enquiry, in the parts nobody opens. Check each of these in every language:
- The form: labels, placeholder text, error messages and the thank-you page.
- The confirmation email and any automatic reply.
- The reply itself. Send the page's language with each enquiry, so it reaches someone who can answer in it.
- Dates, phone numbers, addresses and figures. A British page writes 1,250.50, and a French one writes 1 250,50.
- Text inside images, PDFs and videos, and the alt text that describes images.
- Page titles and meta descriptions, which are what search results show.
- The privacy notice and the cookie banner.
- The terms and the checkout, if you sell online.
Items 7 and 8 carry legal weight. The GDPR transparency guidelines endorsed by the European Data Protection Board say a privacy notice should be translated when you target people who speak other languages. They add that the translation must be accurate and make sense.
If customers order through your site, UK and EU e-commerce rules require you to tell them, before they order, which languages the contract can be concluded in. The rule is regulation 9 of the UK's Electronic Commerce Regulations 2002, and Article 10 of the EU's E-Commerce Directive. This is general information, not legal advice.
Keep every language up to date after launch
Language versions drift. The English service page gains a new offer, the French one doesn't, and a year later the two versions describe different companies. Three habits prevent it.
Give each language an owner: a named person, fluent in it, who approves changes and reads the whole version on a schedule, such as every quarter.
Link the versions in the content system. When someone edits the English page, the French page should show as out of date until its owner updates it. Many translation plugins and content systems can do this, so ask to see it working before you sign.
Keep facts in one place. Contact details and opening hours change, and a copy of each in every language will sooner or later disagree. Store each fact once and show it in every version.
Our website brief template has a section on languages. Use it to name the writer, the checker and the owner of each one before you ask for quotes.
When a multilingual website isn't worth it
Some companies shouldn't add a language yet, or at all.
- Your buyers already read and buy in English. If last year's enquiries all arrived in English, a second language may add upkeep and nothing else.
- Nobody can answer in the new language. Hire or partner first, then publish.
- One market matters most. Build that version properly before you start a second.
- Visitors from abroad are occasional. Their browser's translation covers them.
- You're testing a new market. One landing page in the market's language, written by a fluent writer, with its form routed to a fluent person, tells you more than a full translated site.
Start with last year's enquiries
This week, sort last year's enquiries by the language they arrived in, and note who answered each one. If one other language turns up often, and someone on your team can answer it well, that's your next language.
Then write four things down: the pages it needs, who will write them, who will check them in place, and who will own them after launch. That list is the start of a brief, and it's the first thing any agency, including us, should ask you for.
Questions
Does Google penalise machine-translated pages?
Not for being translated. Google's spam policies target pages produced in bulk with little value for readers, and they list automated translation of scraped content among the examples. Your own pages, translated for real readers and checked by someone fluent, are a different thing. Google also says language versions only count as duplicates when the main content stays untranslated. The bigger risk is the reader: a French buyer notices stiff machine French long before Google does.
France and Belgium both speak French. Do we need two French versions?
Only if the content differs. One French version tagged fr serves both. If the Belgian page needs different contact details, delivery terms or legal text, make two versions tagged fr-FR and fr-BE, each listing the other. Don't use be on its own: in hreflang, that's the code for Belarusian, not Belgium.
Can we launch in one language and add others later?
Yes, and it's often the right order. Choose the address pattern now, though. If the first language sits at the root and later ones go in folders such as /fr/, adding a language leaves every existing address where it is. Moving the first language into /en/ afterwards means redirecting every page, which is a migration in its own right.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.