How to plan a multilingual website for a small business.

Decide which languages, and why

Start from the customers you have and the ones you want, not from the languages you could add. Look at the evidence:

• The languages enquiries already arrive in, by email, form and phone.
• The countries and searches in Search Console, which show where visitors come from and what they type.
• The languages of your Google reviews.
• The languages your team can reply in.

The last one decides more than the others. A page in a language nobody on the team speaks brings enquiries nobody can answer well. If you add one anyway, plan how those replies get written before launch, not after the first message arrives.

Three typical cases: a guesthouse in the Slovenian mountains with English and German guests; a physiotherapy practice in Brussels whose patients speak French or Dutch; a dental clinic in Barcelona with patients who use Catalan, Spanish and English. Each needs a different set of pages in each language, which is the next decision.

Translate the pages that bring enquiries first

You rarely need the whole site in every language. Translate the pages a customer passes through on the way to an enquiry, in this order:

• The home page.
• Each main service page, with its prices or what the price depends on.
• The contact page, with directions, parking and opening hours.
• The booking page or booking request.
• Every part of the form: labels, error messages, the thank-you message and the confirmation email.
• The privacy notice and the cookie banner, if you have one.
• The 404 page.

Leave the news page, old blog posts and the company history for later, or for never. A page you translate is a page you must keep up in that language.

If one page exists only in your main language, say so in the link: "Our team (in English)". Google warns that translating only the menus and buttons while the main text stays in another language makes a poor page, so translate a page fully or link to it honestly.

Give each language its own address

Google recommends a separate address for each language version of a page, rather than one address whose language changes with a cookie or the browser's settings. There are three ways to do it:

• Folders on one domain: example.com/de/ and example.com/fr/.
• Subdomains: de.example.com and fr.example.com.
• A domain per country: example.de and example.fr.

Google advises against addresses with a language parameter, such as example.com/page?lang=de.

For a small business, choose folders. You keep one site, one hosting plan, one set of email records and one Search Console property, and every language sits on the domain your customers already know. A domain per country makes sense when you run separate businesses in separate countries, with different prices and teams.

Translate the words in the address too, so a German visitor sees /de/zahnreinigung/ and not /de/teeth-cleaning/. It reads naturally, and it tells the visitor at a glance they are on the right page.

Tell Google which version is which

Hreflang tags tell Google that pages are versions of each other, so it shows the French page to people searching in French. Google's rules are strict, and a mistake makes it ignore the tags:

• Each version lists itself and every other version, and every version carries the same set. If two pages do not point to each other, Google ignores the tags.
• Use full addresses, starting with https.
• Language codes are two letters, such as fr, nl or de. Add a region only when versions differ by country, such as de-AT for Austria. A region on its own is not valid.
• Use GB for the United Kingdom: Google says UK in a region code has no effect. And be is the code for Belarusian, not Belgium.
• Add an x-default version for visitors whose language you do not cover, usually your main language or a page where they choose.

For the Brussels practice, each treatment page carries three entries: nl pointing to the Dutch page, fr pointing to the French page and x-default pointing to the French page as the fallback. The Dutch and French pages both list all three.

Put the tags in the head of each page or in the sitemap, not both. Google decides a page's language from its visible text, not from code, so keep each page in one language. Still set the page's language in the code, because browsers and screen readers use it.

Let visitors choose, and do not redirect them

Google advises against redirecting visitors automatically by their location or browser language, because it can stop people and Google's crawler from reaching every version. A tourist in Barcelona with an English phone may want the Spanish page to show a local friend. Let people choose:

• Put the language switcher in the same place on every page, usually the top corner, and on the phone menu.
• Write each language in itself: Deutsch, Français, Nederlands. A German speaker looking for German will not look for the word German.
• Use language names, not flags. A flag is a country: Belgium has three official languages, and German is spoken in Austria and Switzerland as well as Germany.
• Send each switch to the same page in the other language, not to that language's home page.
• Remember the visitor's choice for the rest of the visit.

If you want to help visitors whose browser is set to another language, show a small note they can close, such as "This page is also in Deutsch", instead of moving them.

Treat machine translation as a first draft

Tools such as DeepL or Google Translate produce readable drafts quickly. They also make mistakes a customer notices at once, and some that cost money:

• The wrong level of formality. German, French and Dutch each have a formal and an informal you, and a site that switches between them reads as careless. Pick one and keep it.
• The names of your services. A literal translation of a treatment, a legal service or a dish is often not what people in that language call it.
• Prices, numbers and dates. In German, 1.500 means one thousand five hundred, and 03/04 means 3 April in most of Europe and March 4 in the US.
• Conditions, cancellation terms and anything legal, where a small change of meaning matters.
• Allergy and safety information, which must be right or left out.

A process that works: write a short glossary first, with your service names, how you address customers and the words you never use. Run the draft through it. Then a fluent speaker, ideally one who knows your trade, reads every page on a phone, along with the form, the confirmation email and the error messages. A legal text such as the privacy notice deserves a professional translator or your adviser.

One page a fluent person checked beats five pages nobody did.

The details that break in a second language

Most of these only show when someone tries the site in that language. Check each one on a phone:

• Length. German and French text often runs longer than English, so buttons wrap, menus overflow and headings break in odd places.
• Letters. Make sure the font has every letter you need, such as the Polish ł or the Czech ř, or those letters appear in a different font.
• Formats. Dates, times, phone numbers, postcodes and decimal commas follow the language and country, and the form must accept them, including a phone number with a country code.
• Emails. The confirmation goes out in the language of the page the form was sent from, and the notification to your team says which language the customer used.
• Your booking tool. Check that it shows its pages in each language, where your booking software allows it, or the customer meets a different language at the last step.
• Images with words in them. Each one needs a version per language, or no words.

Search in each language

Each language needs its own page titles, descriptions and headings, written in the words people search with in that language. That is not always the dictionary translation. In Belgium, Dutch speakers usually call a physiotherapist a kinesitherapeut, while in the Netherlands the word is fysiotherapeut. Ask the fluent reviewer what customers actually type, then check Search Console after launch.

One Domain property in Search Console covers every language folder, and you can filter its reports by the folder, such as /de/, to see each language separately. Put every language version in the sitemap.

Translated pages are not duplicates of each other, so they do not compete. Versions in the same language for different countries, such as German for Germany and Austria, are near copies, and that is what hreflang with regions is for. If the two would say the same thing, keep one page in German for both.

A worked example: a guesthouse in three languages

The guesthouse in the Slovenian mountains gets most of its bookings from English and German speakers, and some from Slovenians at weekends. The owner reads and writes all three, and her husband handles German enquiries when she is away.

The plan they settle on:

• Slovenian, English and German, each in its own folder: /sl/, /en/ and /de/.
• In all three: the home page, the rooms with their prices and what is included, getting here by car and by bus, the booking request form, the house rules and the privacy notice.
• In English only, for now: a page of walks from the door, linked from the other languages as "Walks (in English)".
• Hreflang on every page with sl, en and de, and English as the x-default for everyone else.
• The confirmation email in the language of the form, and the subject of each notification starting with the language code, so the right person picks it up.
• A note in the owner's calendar every spring to check the prices and the bus times in all three languages before the season.

Nothing here is complicated. What makes it work is that each language has a person who can reply in it, and a date when someone checks it.

A chatbot in the visitor's language

A chatbot can answer a visitor in the language they write in and pass the conversation to your team with everything said so far. It is useful where your pages exist in two languages and some visitors speak a third, or where questions arrive at night in languages your team reads but cannot answer at once.

The risk is in the answers. When your pages exist in one language only, answers in another need extra checks, above all on prices, policies and anything about safety. When we build an AI chatbot, each language is tested with real questions written in that language before launch.

Decide who reads handovers in each language, and what the chatbot says when nobody can: for example, that the team replies in English or Spanish on the next working day. More on what it should and should not answer is in customer service chatbot.

Decide who keeps each language right

The hard part of a multilingual site is the second year. Prices go up, a service changes, the clinic closes for a week in August, and the change reaches one language and not the others. A customer who reads the old price in French has every reason to expect it.

Set three rules before launch:

• No change goes live in one language only. Every update lists the pages to change in each language.
• One named person is responsible for each language, with a backup.
• Each language gets a read-through every few months, on a phone, by a fluent speaker.

If you cannot keep a language up, remove it, with each of its pages redirected to the same page in your main language. A stale translation does more harm than no translation.

The order to do it in

• Choose the languages from the evidence, and who will reply in each.
• List the pages each language needs.
• Write the glossary.
• Finish and approve the text in your main language. Translating text that is still changing doubles the work.
• Translate, then have a fluent person review every page, the form and every email.
• Build each language in its own folder, with hreflang, a switcher and translated titles.
• Test each language on a phone: every page, a form sent, a confirmation received.
• After launch, watch enquiries in each language and Search Console by folder.

Each language needs its own pages, page addresses, forms and confirmation emails, plus the tags that tell Google which version to show, so it adds to the price of a build: the prices page names more than one language among the things that make a project cost more, and what decides the price of a website explains why. The checks for launch day are in the website launch checklist, and how we build sites is on websites.