A multilingual website is several websites sharing one design, one structure and one set of facts. Building it is the manageable part. The hard part is everything around the build: which languages to launch, who writes and approves each version, and what happens to the others the day a price changes in one.
These decisions are cheap before design starts and expensive after launch, when a translated button overflows its box or an enquiry arrives in a language nobody in the business reads. This guide covers them in order. Search set-up, from URL structure to hreflang, has its own multilingual SEO guide.
Planning a multilingual website: the short answer
To plan a multilingual website, settle six things before any page is designed:
- Languages: only those you can keep current and answer enquiries in.
- Scope: every page in every language, or a core set that grows.
- Method: translation, localisation or transcreation, chosen per type of content, with native review where it counts.
- Ownership: a named person who approves each language.
- Everything outside the pages: forms, emails, system messages and files.
- Design and platform: a switcher that uses language names, typography for every script, and a CMS set-up your editors can run.
Choose your launch languages and pages
Start from evidence
Look at the languages customers already use with you: enquiries, sales conversations, the Language dimension in Google Analytics (visitors’ browser or device language) and queries in other languages in Search Console. Then add your planned markets.
The test that decides it. For each candidate language, ask who will reply to an enquiry written in it, and how quickly. If the answer is nobody, the language isn’t ready. A page that invites enquiries you can’t answer does more harm than no page at all.
Full parity or a core set?
| Approach | What it means | Suits | Watch for |
|---|---|---|---|
| Full parity | Every page in every language | The same offer everywhere, with budget to maintain it | Every new page multiplies the work |
| Core set | Homepage, key service pages, about, contact and legal pages, growing over time | Most businesses adding a language | Links that lead into the other language |
| Single entry page | One landing page per language, leading to someone who speaks it | Testing demand first | Visitors who want more hit a wall |
For most businesses a core set is the better start: the pages that earn enquiries, translated properly, beat a whole site translated in a hurry. On a partly translated site:
- Keep every page in one language, including its menus, footer, buttons and forms.
- Build each language’s menu from the pages that exist in it. Website navigation design covers labels that still fit once translated.
- Label links that cross languages, so nobody lands on a page they can’t read without warning.
- Store shared facts once. Prices, phone numbers and specifications should come from one field, not be retyped per language.
Translation, localisation or transcreation?
Most sites need all three:
- Translation carries the meaning faithfully into another language.
- Localisation also adapts dates, currencies, units, phone formats, examples and references.
- Transcreation rewrites a message to have the same effect on a different audience, even if every word changes. It is closer to copywriting than translation.
| Content | Method | Signed off by |
|---|---|---|
| Headlines and calls to action | Transcreation | A native copywriter and the language owner |
| Service and product pages | Translation and localisation, with keywords researched per language | A fluent reviewer who knows the field |
| Specifications and datasheets | Translation against a glossary | A subject expert who reads the language |
| Legal pages and terms | Professional translation | Your legal adviser for that language |
| Forms, buttons and messages | Translation with context | A native reviewer, on the real layout |
| News and articles | Translate only what matters to that audience | The language owner |
When native review is non-negotiable
Machine and AI translation produce fluent drafts, and fluency hides errors: to someone who doesn’t read the language, a confident mistranslation looks like a good page. Have a native speaker review anything that sells, anything with legal or safety weight, and every short interface string. One word on a button can be a noun or a verb, and a translator working from a spreadsheet can’t tell which. Writing website copy with AI sets out a drafting workflow that keeps a fluent human in charge.
Brief translators like writers
Give every translator the same pack:
Your website branding is what makes every language sound like the same company.
Give every language an owner
Multilingual content management is mostly a people problem, and a language without an owner drifts. Name one person per language, ideally a native speaker inside the business, who approves every change in it. Then agree a website translation workflow:
- Approve the source content first. Translating a draft means paying twice.
- Send the brief pack with the approved text.
- Translate in the CMS or a connected tool, not in a document someone later pastes in.
- Review in place on staging. Text that reads well in a spreadsheet can still overflow a button.
- The language owner approves, and only then does it go live.
Decide, too, what must change everywhere at once: usually prices, contact details and legal terms. News can follow later, and a campaign may run in one language only. Preparing content for a new website covers who writes what, and by when; website governance covers keeping versions in step.
Translate what sits outside the pages
Pages get translated. The pieces around them get forgotten.
Forms. Labels, help text, errors, the button and the confirmation page. Don’t rely on the browser’s built-in validation messages: they follow the browser’s language, not the page’s. Check that name, address and phone fields accept formats from everywhere you serve; the W3C’s article on personal names around the world explains why one full-name field is often safer than first and last. More in our web form design guide.
Emails. The automatic reply should arrive in the visitor’s language, and the notification to your team should say which language the enquiry came in. A hidden field recording the page language makes both possible.
System messages. The 404 page, empty search results, the cookie notice, “Read more”, pagination and dates. Many come from the theme or plugins, not the page editor, so check each.
Files and media. Brochures and datasheets need their own versions, or a link that says which language the file is in. Translate alt text, captions and social sharing images, and keep text out of images so it can be translated at all.
Design a language switcher people can find and trust
Use language names, not flags
A flag stands for a country, yet many languages span several countries and many countries use several languages, so any flag confuses or excludes someone. Write each language’s name in that language, so a visitor who can’t read the current page still recognises their own. A globe icon helps people spot the switcher; the names stay as text.
Keep it consistent, and keep visitors in place
Put the switcher in the same spot on every page, usually the top right of the header, and repeat it in the footer. On phones, keep it outside the menu or at the top of it. Switching should open the same page in the other language; if there isn’t one, go to the closest equivalent and say so, rather than dropping people on the homepage.
Suggest, never force
Don’t switch language automatically based on location or browser settings: travellers, people living abroad and anyone on a shared device end up with the wrong one. A dismissible suggestion, written in the suggested language, is enough, and once someone chooses, remember it. Automatic redirects can also stop search engines seeing every version, as the SEO guide explains.
Build it accessibly
Use plain links, not a drop-down that loads a new page as soon as the selection changes. In some browsers, keyboard users trigger that just by arrowing through the options, and WCAG’s On Input criterion (3.2.2) doesn’t allow a change of context on input without advance warning. Mark each language name with its own lang attribute so screen readers pronounce it correctly (WCAG 3.1.2, Language of Parts). See accessible website navigation for keyboard and focus details.
Plan typography and layout for every script
A new language changes shapes, lengths and sometimes direction:
- Glyph coverage. Your brand typeface may not cover every script you publish in. Pick a companion with similar weight and tone, and test with real content.
- Line height. Scripts with marks stacked above and below letters need more room. Adjust per language with the CSS
:lang()selector. - Text length. Translations run longer or shorter. Let buttons, menus and cards stretch, and test every template with your longest language.
- Line breaks and emphasis. Some scripts don’t put spaces between words, and many have no capitals or italics. Check where headings break, and use weight or colour for emphasis.
- Direction. Right-to-left scripts mirror the layout, from navigation order to arrows. Building with CSS logical properties from the start costs far less than retrofitting.
Web typography for business websites covers font files, loading and licences.
How WordPress handles several languages
At the time of writing (June 2026), WordPress core can set a site’s language but can’t publish the same content in several languages side by side. Native multilingual support is on the project’s long-term roadmap; until it arrives, WordPress multilingual sites rely on a plugin or a multisite network:
| At a glance | Plugin: a linked page per language | Plugin: translated text on one page | Multisite: a site per language |
|---|---|---|---|
| How it works | Each language is its own page, linked to its equivalents | One page, its text translated and stored by the plugin or an external service | Separate sites in one network, usually linked by a plugin |
| Best for | Most business sites | Near-identical content everywhere | Different structures, teams or content per language |
| Main risk | Page builder and form compatibility | Hard to diverge; check where translations live | More administration; every plugin must support multisite |
Well-known plugins include WPML, Polylang, TranslatePress and Weglot, which take different approaches. Whichever you consider, check:
Still choosing a platform? How to choose a CMS weighs languages alongside everything else.
Frequently asked questions
How many languages should a website launch with?
As many as you can keep current and answer enquiries in, and no more. If the structure is planned for extra languages from the start, adding one later is a content project rather than a rebuild.
Is AI translation good enough for a business website?
For first drafts and low-risk content, often yes. For pages that persuade, anything with legal weight and short interface text, a fluent editor who knows your field should revise and approve every word.
Do all language versions need the same design?
They should share one design system, so every version is recognisably the same company. Within it, layouts flex for text length, and images, examples and campaigns can differ where the audience does.
What to do next
If you can answer each section of this guide in writing, you are ready to brief a build. If you can’t, those gaps are the place to start.
Our website design and development projects settle these decisions at the planning stage, so templates, forms and editing work in every language from launch, each with its own SEO. Grow includes a two-language structure and Corporate supports more, as our pricing shows. Adding languages to an existing site often means reworking its structure in a website redesign. Not sure where to start? Talk to us about what your website needs.