Multilingual website: how to plan one

The short answer

To plan a multilingual website, choose languages from real customer demand, give every language its own web address, decide who translates and reviews the text, add language annotations such as hreflang, and assign someone to keep every version updated. Machine translation can produce a draft, but a fluent person should check anything customers rely on.

Start with the audience, not the language list

A multilingual website presents the same business in more than one language, each version written for a defined audience. Begin by listing who you want to reach and which language they would choose to read about you in. Useful evidence includes enquiries that already arrive in another language, customers who ask for it, search demand in that language and the languages shown in your analytics.

Language and country are different things. A Spanish version for customers in the USA is not the same as one for customers elsewhere, and English for the UK, Australia, Singapore and the UAE differs in spelling, formats and local expectations. A business serving the UAE often needs Arabic and English side by side. A site aimed at the general public in Japan will normally need Japanese. Singapore has several languages in daily use, so choose by your actual customers.

Each language is a commitment. Someone must answer enquiries, update pages and support customers in that language. Do not offer a language you cannot serve once the visitor clicks.

Start small: which pages to translate first

You do not have to translate everything at once. Translate the pages that bring in or close business first: the home page, the main services or products, the contact route, booking or checkout, and the policies that affect a purchase. A restaurant serving visitors from abroad might translate the menu, opening hours, location and booking page first, and leave the history page for later; what a restaurant website needs lists what has to be there.

Be clear about what is translated. A half-translated page looks careless. Where a page has no equivalent in a language, either hide the switcher on that page or send the visitor to the nearest page that does exist and say so.

Should I translate by machine or by a person?

Many sites combine these approaches. The more a page influences a buying decision, or carries legal weight, the more it needs a person who reads the target language natively. Build a glossary of brand names, product names and key terms, give it to every translator, and decide which words stay in the original language.

Google's spam policies describe scaled content abuse, which includes producing many pages by automated means, including translation, where little value is given to users. A reviewed translation written for real customers is a different thing, but publishing unreviewed machine output in bulk carries risk. Check the current Google Search Central spam policies. Legal pages such as terms and privacy notices should be translated by someone qualified and checked by a lawyer, because a translation is not automatically equivalent in law; website terms and privacy policy: do you need them covers why they matter.

How do I structure the URLs?

Give every language its own web address. Google recommends separate URLs for each language version instead of changing the content with cookies or browser settings, because a crawler can only index what it can reach by an address. The usual patterns are below.

Pick one structure and use it everywhere, with the same page structure in each language so that equivalent pages match. Google also advises against adapting content by the visitor's location alone, because crawlers do not visit from every country, and against redirecting visitors automatically from one language version to another. Offer a visible link to the other versions instead.

Tell search engines which version is which

Hreflang annotations tell Google which pages are equivalent versions in different languages or for different regions. Google's documentation says each version must list itself and all the others, and the links must be reciprocal, otherwise they can be ignored. Addresses must be fully qualified, and language codes can carry an optional region code. An x-default entry names the page to show when none of your versions fits the visitor. Use one method only: link tags in the page head, HTTP headers, or the sitemap.

Google works out the language of a page from its visible content, not from hreflang or the language attribute in the code. Still set the language attribute properly, because screen readers and browsers use it. The usual mistakes are missing return links, wrong codes and annotations that point at addresses that redirect.

Language switcher and navigation

• Put the switcher in the same visible place on every page.
• Write each language in its own language, such as Español or 日本語, and not in the language of the current page.
• Use text, not flags. A flag represents a country, and many languages are used in several countries.
• Switch to the equivalent page, not to the home page, and send the visitor to the home page of the other version only when no equivalent exists.
• Remember the visitor's choice without forcing a redirect on the next visit.

Design for different scripts and directions

Arabic is written right to left, and a proper right-to-left layout mirrors the whole page, including the menu order and the position of icons as well as the text. Japanese needs fonts that contain the characters, so confirm that your chosen web fonts include them. Text length varies between languages, so buttons, menus and cards must be able to grow or shrink. Check date, time, number and address formats for each market, and show currency in the form that customers there expect. Images that contain text must be redone for each language. Test every version on a phone before launch.

Translate everything a visitor sees

• Page titles, descriptions and image alt text.
• Form labels, error messages, confirmation pages and automatic emails.
• Cookie banners, checkout steps and policies.
• Structured data and any text inside images or videos.
• The route to a real person. Each language needs a contact method that someone can answer in that language, as described in what a contact page should include.

Keep a multilingual website up to date

The ongoing cost of a multilingual site is higher than the build. Decide who updates a translation when the source page changes, how outdated pages are flagged, and how new pages enter the process. The factors that drive upkeep are set out in what website maintenance includes and what affects its cost.

If you use a translation plugin or service, check its current documentation for how it creates addresses, what it stores, and what happens to your translated pages if you stop using it. Tools that generate language versions are another part that can fail, so include them in your recovery plan; what to do when your website goes down explains the steps.

A planning checklist

1. List the audiences and their languages, with evidence for each.
2. Choose the first pages to translate, and who answers enquiries in each language.
3. Decide the translation method for each page type, and write the glossary.
4. Choose the URL structure and apply it to every version.
5. Plan hreflang annotations, the language switcher and right-to-left support if needed.
6. Translate everything visible, including emails, forms and policies.
7. Assign an owner for updates, and add the translated versions to your maintenance plan.

If the site must be rebuilt to support several languages, the website development service page describes the build work.

Related guides

• Website development
• Website terms and privacy policy do you need them
• Contact page what to include
• Restaurant Website: What to Include and How to Set It Up
• Website content plan what to write first
• Website caching explained

Questions and answers

How do I plan a multilingual website?

Choose languages from real customer demand, give each language its own web address, decide who translates and reviews the text, add hreflang annotations, build a language switcher, and assign someone to keep every version updated. Start with the pages that bring in business and add others later.

Should I translate by machine or by a person?

Machine translation is useful for a quick draft, but anything customers rely on should be checked by a fluent person. Pages that sell, legal pages and safety information should be handled by a translator who reads the target language natively. Unreviewed bulk machine translation carries risk with search engines and with customers.

How do I structure the URLs?

Give each language its own address, using subdirectories such as example.com/ar/, subdomains such as ar.example.com, or country domains. Google recommends separate URLs over cookies or browser settings. Choose one pattern and use it consistently, and avoid adapting content by the visitor's location alone.

Do I need a separate domain for each language?

No. Many sites use subdirectories or subdomains on one domain. Separate country domains give a clear country signal but need separate registration, upkeep and often separate content. Choose based on how many markets you serve and how much you can maintain.

How many languages should I start with?

As few as your customers need. Add one language, serve it well, and learn what it costs to maintain before you add another. Each language needs someone to answer enquiries and update pages, which a translated website alone does not provide.

Will a multilingual website hurt my SEO?

Not if each language has its own address, uses hreflang correctly and contains useful, reviewed content. Thin, duplicated or unreviewed translated pages are the risk. Check the current Google Search Central documentation on multilingual sites for any changes.