The Complete Guide to Multilingual Website Design and Development

Expanding into new international markets can be a good way to grow, but only if your website is set up properly. A multilingual site is not just your English site with translated text dropped in. It needs the right structure, a clear user journey, solid technical foundations and a way to keep everything up to date.

When it is done well, it helps more people find your business, understand what you offer and feel confident enough to buy or enquire. When it is done badly, it can create duplicate content, poor search performance, mixed messages and a lot of extra work for your team.

This guide explains how to plan, design, build and manage a multilingual website that is useful for users and manageable for the business.

 

 

What is a multilingual website?

A multilingual website gives users content in more than one language. That might sound straightforward, but it affects much more than the words on the page. It can shape how the site is structured, how easy it is to use, how well it appears in search and how likely people are to take action.

For ecommerce, lead generation and service-based businesses, this is especially important because language has a direct impact on trust. When users struggle to understand your offer, delivery terms, product details or checkout process, they are less likely to convert.

Multilingual vs multi-regional websites

A multilingual website and a multi-regional website are not the same thing. A multilingual website serves content in more than one language. For example, a Canadian website with English and French versions is multilingual.

A multi-regional website targets users in different countries or regions. For example, separate US and UK sites are multi-regional, even if both use English.

Some websites are both multilingual and multi-regional. A business might have US English, UK English, Canadian English and Canadian French versions. In that case, the website needs to account for both language differences and regional differences, such as spelling, pricing, delivery options, legal requirements, or product availability.

Your website structure should match what the business is trying to do. If you only need to offer two languages in one country, you probably do not need the same setup as a brand selling across ten countries with different currencies, delivery rules and stock ranges.

When this is not thought through properly, it can create a lot of extra work. You can end up with duplicate content , confusing URLs, weaker search performance and a website that is harder to manage than it needs to be.

Translation vs localisation vs internationalisation

Translation, localisation and internationalisation are often used together, but they solve different problems:

Put simply: translation changes the wording, localisation adapts the page for the audience, and internationalisation makes sure the website can support both.

A common mistake is to start and stop with translation. That might make a page readable, but it does not always make it useful. Users still need to understand prices, delivery information, forms, product details, legal wording and the next step they are being asked to take.

A good multilingual setup looks at the whole journey, from finding the page in search through to buying, enquiring, booking or submitting a form.

 

Why multilingual website design matters

If your website only works well in one language, you limit who can find it, understand it and buy from it. That might be fine for a local business, but it becomes a problem when you want to reach international markets.

Users are more likely to engage with a site when content is available in their preferred language. They can understand the offer faster, compare products or services more easily, and complete forms, check delivery details or make purchase decisions without second-guessing what something means.

Language matters because it affects the full website journey:

Done properly, a multilingual website makes things easier for the user. They can find what they need, understand what they are being offered and feel more confident taking the next step.

 

Start with strategy before translation

Don’t start a multilingual website project by translating pages straight away. Instead, start by working out where the real opportunity is, what users in those countries or regions actually need, and what the business can realistically support. The translation work should come after that.

Without a clear plan, these projects can get expensive quickly. Teams can end up translating too much content, choosing the wrong markets, building a setup that is more complicated than it needs to be, and then struggling to prove whether the work was worth it.

Identify target markets and languages

Start with your analytics. Look at where your current international traffic comes from, which languages users prefer, and where engagement or conversion already shows signs of demand.

That gives you a useful starting point, but it should not be the only input. Before entering a new region, look at:

Prioritise the markets that matter most instead of launching in every language at once. A smaller launch is usually easier to manage, as it gives you a chance to test demand, see what works, fix problems and learn from the results before adding more languages or regions.

Define goals and KPIs

A multilingual website needs clear goals from the start. Something like “more international traffic” is too vague. Instead, you need to know what success looks like by language, country or locale.

Useful key performance indicators (KPIs) include:

• Organic traffic by country
• Conversion rate by language
• Leads by region
• Revenue by market
• Engagement by locale
• Indexed pages by language
• Rankings for local keywords
• Support demand by language

These metrics help you see what is actually working, not just what is getting visits. For example, one language version might bring people to the site but not lead to many sales or enquiries. Another might rank well in search but create extra support queries because key information is unclear. A smaller market might bring in fewer visitors but generate more value from each one.

Choose the multilingual model that fits your business

Not every business needs the same multilingual setup. The right approach depends on your markets, operating model, content volume and how different the user experience needs to be.

A simple way to decide is to choose one of three options:

For some markets, translated copy may be enough. For others, it will not go far enough because the site will still feel like it was built for someone else. Choose the approach that matches the business need, not the one that sounds the most complete.

 

Choosing the right multilingual website model

There is no single best way to design and develop a multilingual website. The right approach depends on how much the site needs to change between languages, countries, and customer groups. In practice, most multilingual sites fall into one of three models.

Model 1: Translated-copy websites

A translated-copy website is the simplest option. The site stays much the same, with pages, products, pricing, checkout and main content not changing in any major way. You are mainly making the same website available in another language.

This works best when:

• Markets see the same products, pricing, checkout and content
• The main requirement is language coverage
• The site is relatively simple or already exists
• You need a faster route to launch
• You do not need market-specific customisation

Typical use cases include:

• Small business websites
• Marketing sites
• Basic service websites
• Simple bilingual or trilingual sites

This approach can work well when the commercial goal is clear and the market differences are limited. It keeps build complexity lower, and can also help you test demand in the short term.

Common tools differ by CMS, but include:

Model 2: Localised market experiences

A localised market experience goes further than translation. Each market gets an experience shaped around how users in that region search, compare, buy and get support. The language changes, but so do the commercial and operational details around it.

This model works best when each market needs different:

• Product catalogues
• Pricing logic
• Tax handling
• Payment methods
• Checkout flows
• Compliance journeys
• Local content
• Support models

This is usually the right model when the business is serious about revenue growth in a specific market. It gives you more control over the customer journey and removes more friction from the buying process.

The downside is that there is more to manage. A localised market experience needs proper planning and clear ownership. For example, marketing, development, ecommerce, legal, operations and customer support all need to be aligned. Without that, the site can quickly become messy, inconsistent and hard to keep up to date.

Tools and approaches for this model include:

Model 3: Centrally governed multisite networks

A centrally governed multisite network is about managing several related websites from one place. It is less about translation itself and more about keeping control, avoiding duplication, and making sure the sites are managed consistently.

This works best when you need central control over the technical setup, such as plugins, themes, users, security, updates, and shared infrastructure.

In WordPress, this usually means using WordPress multisite. It lets you run multiple sites from one WordPress installation, with central admin across the network. If you need a fuller explanation of how that works, we have a separate guide on what a WordPress multisite is .

This model works best when:

• You manage multiple related WordPress sites
• You need central control over plugins, themes, users, security and updates
• Sites are separated by region, brand, franchise, department, campaign or partner network
• Local teams need control over their own content
• The business needs consistency without removing local flexibility

WordPress multisite can work well, but only when someone is clearly responsible for it. If ownership is unclear, it can get messy quickly. One bad plugin, missed update or unclear process can cause problems across the whole network.

 

Planning your website structure

Multilingual website structure affects how easy the site is to find, use, manage and grow. If the structure is wrong, you can end up with duplicate content, indexing issues, messy reporting and extra development work. If it is right, the site is easier to manage, measure and improve over time.

Choose your URL and domain structure

Your URL structure tells users and search engines how your multilingual or multi-regional site is organised. The main options are:

Option	Example	Best for
Subdirectory	example.com/fr/	Closely related language or regional pages
Subdomain	fr.example.com	More independent regional experiences
ccTLD or separate domain	example.fr	Strong country targeting or separate brand identity
URL parameter	example.com?lang=fr	Generally not recommended

There is no perfect structure for every business. The right choice depends on how separate each market needs to be, how much control local teams need, how important country targeting is, and how much technical overhead the business can manage.

Subdirectories

A subdirectory structure places each language or regional version inside the main domain. For example:

• example.com/fr/
• example.com/de/
• example.com/en-gb/

This is often the best choice for businesses that need multilingual content but do not need completely separate regional websites.

Subdirectories are usually easier to manage because everything sits under one domain. They are lower maintenance than separate domains and help keep search authority in one place.

They also make analytics, tracking and governance simpler. You can segment performance by folder, compare language versions and manage technical standards from one central setup.

However, if markets become very different over time, subdirectories can feel limited. Separate pricing logic, fulfilment rules, legal journeys or local content ownership may create operational complexity inside one domain.

Subdomains

A subdomain structure separates language or regional versions from the main website while keeping them connected to the parent domain. For example:

• fr.example.com
• de.example.com
• uk.example.com

Subdomains give you more separation than subdirectories. They can work well when regional teams need more control, or when content, campaigns and operations differ by market. They are also useful when a market has a semi-independent experience but does not justify a separate country domain.

The downside is that subdomains can be treated more like separate sites, both by search engines and by the teams managing them.

From an SEO point of view, this can make it harder to build authority in one place. Instead of all language or regional content sitting under the main domain, search signals may be split across separate subdomains. You may also need separate tracking, reporting, sitemaps, Search Console properties and more careful internal linking.

Furthermore, a subdomain like fr.example.com might suggest French-language content. A subdomain like uk.example.com suggests a country-specific site. If the structure mixes language and country signals without a clear system, users and search engines can get confused.

ccTLDs and separate domains

A country code top-level domain (ccTLD) uses a country-specific domain extension. For example:

• example.fr
• example.de
• example.co.uk

This can send a strong local trust signal. Users may feel more confident when they see a familiar country domain, especially in markets where local presence matters.

ccTLDs and separate domains are useful when the business has:

• Separate brands by market
• Country-specific operations
• Different legal or compliance requirements
• Local teams with strong ownership
• A need for clear country targeting

However, separate domains cost more to manage. They need more technical governance, more infrastructure planning and more ongoing website maintenance . Like subdomains, they can also impact SEO, because each domain has to build its own visibility and trust. That can slow growth if the business does not have the budget, content capacity or link authority to support each domain properly.

URL parameters

URL parameters use query strings to change the language version of a page. For example: example.com?lang=fr

This is usually not the best option for multilingual or multi-regional sites.

Firstly, it is not very clear for users. A URL like this does not show the language or country as clearly as a subfolder, subdomain or local domain.

It can also make things messier behind the scenes. Reporting, crawling, indexing and page management are harder when language versions sit behind parameters instead of having their own clean URLs.

For SEO, URL parameters are usually best avoided. Search engines need crawlable URLs for each language or regional version. Parameters can work in some cases, but they often add complexity for no real benefit.

 

 

Preparing your site for multiple languages

Internationalisation is the work that gets your website ready for translation and localisation before the content is translated.

The codebase, templates, content model and user interface all need to handle different languages, scripts, formats and regional rules without causing layout, content or usability problems.

If this step is skipped, the issues usually appear later. Teams start translating pages and then find that the website cannot handle longer labels, different date formats, right-to-left languages or market-specific content properly. That leads to delays, fixes and avoidable rework.

Code and content separation

This is where the setup needs to be practical, not just technically “multilingual”. Copy, labels, form messages and system text all need to be managed in a way that makes translation and updates straightforward. Core requirements include:

• Extract text strings from templates and code
• Use structured resource files or translation files
• Avoid hard-coded copy in buttons, menus, forms and error states
• Prepare dynamic user interface (UI) components for translation
• Make sure system messages, validation text and transactional content can be translated

Dynamic content needs extra care. Product names, filters, availability messages, pricing labels and checkout errors often come from different systems. If those strings are missed from the translation workflow, users can end up with a mixed-language experience.

Character encoding and script support

A multilingual website needs to handle the characters used in the markets you are targeting.

For some languages, that might mean supporting accents and special characters. For others, it could mean supporting a completely different script, such as Arabic, Cyrillic, Greek, Hebrew, Hindi, Japanese, Korean or Chinese.

In most cases, this means using Unicode, usually UTF-8, across the site, database and any connected systems. That helps prevent broken characters, missing symbols or text displaying incorrectly.

The site should support:

• Unicode and UTF-8 encoding
• Accents and special characters
• Non-Latin scripts
• Search inputs using different scripts
• Internationalised URLs where relevant

Layout flexibility

Different languages take up different amounts of space. A short English label can become much longer in German or Finnish. In other languages, the same message might be shorter. The layout needs to cope with both without looking broken.

This is where rigid designs can cause problems. Fixed-width buttons, narrow navigation, tightly packed cards and inflexible forms may work in English, then struggle once the content is translated. Text can wrap badly, get cut off, or make key actions harder to use.

Layouts need to be flexible from the start. Allow room for longer text, test with real translated content, and avoid designs that only work neatly in English. Buttons, menus, product tiles, filters, tabs and checkout steps are the areas most likely to need attention. The aim is for each language version to feel properly designed, not squeezed into a layout that was only built for English.

Right-to-left language support

Some languages read from right to left, including Arabic, Hebrew, Persian and Urdu. Supporting these languages is not just a case of moving the text to the right; parts of the interface may need to change too. That can include:

• Mirrored layouts
• Navigation alignment
• Form field direction
• Menu behaviour
• Icon placement
• Progress indicators
• Directional elements, such as arrows

Icons need checking carefully. An arrow that means “next” in an English layout may need to point the other way in a right-to-left layout.

Forms also need proper testing. Labels, input fields, validation messages and mixed-language entries can behave differently if right-to-left support has not been handled well.

If right-to-left languages are likely to be needed, plan for them early. Adding support later usually takes longer and creates more problems.

Local formatting

Localisation also means getting the basic formats right. People expect dates, times, prices and addresses to look familiar. If they look odd or confusing, the site can feel like it was not really built for that market.

Plan for local differences in:

• Dates
• Times
• Numbers
• Currencies
• Units of measurement
• Addresses
• Phone numbers

These details matter because users rely on them to complete simple tasks. A delivery date needs to be clear, pricing needs the right currency and format, and a phone number field needs to accept local numbers. An address form needs to work for that country, not force everyone into the same UK-style format.

 

Designing a clear multilingual user experience

A multilingual website should make it obvious which language someone is using and make it easy to change it.

People should know which version of the site they are on and how to switch if they need to. If they cannot understand the page, find the right language or feel sure they are in the right place, they are less likely to stay and buy.

Make language switching obvious

Place the language selector where users can find it quickly.

The header is usually better than the footer because users often need to change language before they engage with the page. Hiding the selector at the bottom of the page forces them to search before they can even start.

For a small number of languages, a simple visible selector can work well. For larger multilingual sites, use a dropdown that keeps the interface tidy without making the options hard to access.

Users should always be able to choose their language themselves. Browser settings, location or previous visits can suggest a language, but they should not lock people into it.

Avoid relying only on flags

Flags represent countries, not languages. That creates problems because many languages are spoken in multiple countries. For example, Spanish is not only used in Spain, and English is not only used in the UK or the US.

Furthermore, some countries also have more than one official language. For example, a Canadian flag does not tell the user whether the page is in English or French.

Use native language names instead, such as:

• Deutsch
• Français
• Español

This is clearer for users because they can recognise their own language in its own form.

Flags can still support country or regional selection in some contexts, but they should not be the only language indicator.

Do not force automatic redirects

Location and language are not the same thing. For example, someone in Germany might want to read in English, or a customer on a work network might even appear to be in a completely different country.

Avoid forcing people into a language or regional version based on IP address, browser settings or location. These signals can be useful, but they can also get it wrong. Forced redirects can frustrate users and make it harder for search engines to find every version of the site.

Use detection to suggest, not decide. For example, show a simple prompt saying the site is available in another language or region, then let the user choose whether to switch.

Keep each page in one clear language

Each page should have one clear main language. Avoid showing two translations side by side as the main page layout, as it can make the page harder to read and more awkward to manage.

Also avoid translating the navigation but leaving the main content in another language. Someone might understand the menu, then lose trust when the product content, forms or checkout are still in a different language.

Search engines need a clear signal too. Mixed-language pages can be harder to understand and rank properly.

Keep the language consistent across the page. If it is the French version, the title, headings, body copy, navigation, forms, buttons and important messages should all be in French.

Design for different devices and connection speeds

Device habits are different from market to market. In some places, people are more likely to browse and buy on mobile while, in others, desktop may still be important for research, comparison or business enquiries.

Connection speeds can vary too. A heavy site with large scripts, oversized images and too many third-party tools can be a problem in markets with slower or less reliable connections. To fix this, avoid bloated templates, unnecessary tracking scripts and media-heavy pages that add load time without helping people buy.

If a translated page loads slowly, people may never get to the content you worked hard to localise.

 

Localising content, visuals and key details

Localisation is not only about copy. Users also judge whether a site feels relevant through imagery, video, product details, support options and trust signals. If those elements feel generic or mismatched, the translated content has to work harder than it should.

Localise imagery and video

Use images and videos that feel familiar to the people you’re trying to reach. That might mean showing local homes, streets, weather, clothing, family setups, room sizes, or everyday situations. A homepage image that feels natural in one country might look odd, staged, or unrealistic somewhere else.

The same goes for product photos. Sometimes a product needs to be shown in a local setting, with the right accessories, packaging, measurements, safety details, or ways of using it.

You do not need to change every image just because you are launching in a new market. Focus on the visuals that help people quickly understand the product, trust the brand, and picture it in their own lives.

Video should be treated in the same way. Captions, subtitles or dubbing can help, but bigger sales videos may need more than a straight translation. The examples, script and calls to action may need rewriting so they feel natural for that market.

Consider cultural meaning

Design choices can mean different things in different places. A colour, icon, gesture or joke that works well in one market might not land the same way somewhere else. Some things may feel confusing, out of place or even careless if they have a different local meaning.

Before launching, check the big creative choices, especially:

• Colours
• Icons and symbols
• Gestures and hand signals
• Humour and informal language
• Idioms, metaphors and wordplay
• Who is shown in your visuals

Representation matters too. Different markets may have different expectations around how age, gender, family life, work, lifestyle and community are shown.

You do not need to redesign your whole brand for every market. Just make sure the creative work feels natural, respectful and clear for the people you want to reach.

Localise ecommerce details

Ecommerce localisation is about more than translating product descriptions. People need to know exactly what they are paying, how delivery works, what happens with tax, and how returns are handled. When those details feel unclear, people are more likely to drop out before buying.

Make sure the key buying details feel right for each market, including:

• Currency
• Natural local price points
• Payment methods
• Tax handling
• Shipping information
• Returns policies
• Product availability
• Sizing and measurements

Pricing is a good example. A direct currency conversion might be accurate, but it can look odd. €47.36 may feel less trustworthy than a price that has been properly set for that market.

Payment options matter too. In some places, people expect to pay by card. In others, they may prefer bank transfers, wallets, invoice payments or local payment providers. If customers cannot pay in the way they expect, translated copy will not solve the problem.

Localise support and trust signals

People need to feel confident that they can get help if something goes wrong. That is why support details and trust signals should feel local too, not just the main website copy. This can include:

• Native-language help centres
• Chatbots
• Human support
• Local phone numbers or addresses
• Local reviews, testimonials or case studies
• Market-specific legal or compliance messaging

A help centre in the user’s own language can make support easier, but it must stay accurate. Outdated or badly translated guidance can cause more confusion than it solves.

Chatbots need the same care, especially around checkout, delivery and returns. Weak answers in another language can quickly make the experience feel unreliable.

Local reviews, testimonials and case studies can also help users feel more confident, because they show that the business has already served people like them.

Legal and compliance messages may need local review too, especially around privacy, returns, guarantees, financial claims and regulated products.

Good localisation supports the whole customer journey, giving people clearer answers before they buy and fewer reasons to worry afterwards.

 

 

Choosing the right translation approach

Good translation is about more than making the words readable. It helps people trust your site, understand what you sell and feel confident enough to buy.

But not every piece of content needs to be translated in the same way. A homepage, checkout message or legal page needs more care than a low-risk internal document or a first draft.

That is why most translation work falls into three broad approaches: human translation, machine translation and a hybrid workflow that uses both.

Human translation

Human translation is the safest choice when the wording really matters. Use it for pages where people are making decisions, spending money or looking for important information. A human translator can understand the context, pick up on tone and spot wording that might be technically correct but still feel odd or unclear.

Human translation is best for:

• Homepages
• Product pages
• Landing pages
• Checkout journeys
• Legal and compliance pages
• Brand messaging
• Support content
• High performing sales pages

This does not mean every piece of content has to be translated slowly from scratch. It means the important pages should not be left unchecked. For example, a checkout message needs to be clear. If the wording feels vague or awkward, it can make someone pause right before they buy.

Machine translation

Machine translation can be useful, especially when you need to work quickly or translate a lot of content. It works best for first drafts or internal materials where perfect tone is less important.

Use machine translation for:

• First drafts
• Large volumes of lower risk content
• Internal content
• User-generated content with review
• Speed-sensitive workflows

The main thing to remember is that machine translation is not quality control. It can miss context, tone, legal meaning and local wording. It can also sound fluent while still being wrong.

Hybrid translation workflows

For many businesses, the best option is a mix of both. Machine translation can give you a quick first draft, then human review can tidy it up, check the meaning and make sure it feels right for the market.

This keeps costs and turnaround times under control, without taking risks on the pages that matter most. A simple workflow could be:

• Use machine translation for the first draft
• Prioritise human review for sales, legal and customer-facing pages
• Check key terms against an approved glossary
• Review tone, clarity and local relevance
• Test important journeys before launch

Whichever approach you use, consistency and context make a big difference. A glossary and style guide help translators, reviewers and tools use the same terms across every page. This should cover approved wording, product names, tone of voice, formatting rules, market-specific language and SEO keywords for each language.

Translators also need to know where the content will appear and what it is meant to do. A button, product description, checkout message and support page all have different jobs. Sharing the page purpose, audience, tone, character limits, product details and screenshots helps translators make better decisions, not just accurate ones.

 

Setting clear roles and workflows

A multilingual website needs clear rules for who does what. Without that, pages can end up going out of date, different markets end up using different wording, and local teams make changes in isolation. Then, when something goes wrong, nobody is quite sure who owns it.

Good governance is not about adding red tape. Instead, it is about helping teams move quickly without creating problems for customers or the business.

Define ownership

Every multilingual website needs clear owners for content, translation, technical setup and performance. If “everyone” owns the site, it usually means nobody owns the final result.

Be clear on who owns translation, local review, SEO, development, UX, design, legal checks, analytics, platform access and regional content. When roles are unclear, simple updates take longer than they should. A good setup gives each team a clear role and a clear way to publish safely.

For example, the SEO team may own metadata and hreflang checks, while regional teams own local wording and market feedback. Your legal may only need to review high risk claims, not every small copy change.

Build a repeatable workflow

A multilingual website needs a workflow that can be used again and again. One-off manual processes might work for a small launch but they do not work well once you have several languages, regular updates or local teams making changes.

A practical workflow should cover how content is written, translated, reviewed, approved, published, tested and updated. It should also include reporting, so teams can see what is working by language, market or region.

Manage access carefully

Permissions become more important as a multilingual site grows. Too much access creates risk, but too little access slows everyone down. The aim is to give people enough control to do their jobs, without letting every user change the whole platform.

For example, a translator should not need full admin access to update copy. A regional editor should not be able to break shared templates. And a local team should not be blocked from making simple updates they are best placed to manage.

Common roles might include central admins, site admins, editors, translators, SEO teams, developers and regional teams.

Access should match responsibility. It should also be reviewed regularly, especially when people change roles, agencies leave, new markets launch or old users no longer need access.

Keep things consistent across markets

Consistency does not mean every market has to look and sound exactly the same. It means every version of the site should feel like the same brand, with the same level of quality and trust.

Shared design systems, components, brand guidelines, glossaries, style guides, translation memory, SEO templates and approval rules all help with this, while also saving time. For example, teams do not have to make every decision from scratch.

 

Testing and launching a multilingual website

Before launch, test each language version like a real user would. Click around the site, read the pages, use the forms, switch languages, search for products and test checkout. The aim is to catch anything that could confuse people, stop them buying or make the site harder to find. With this in mind, focus on four areas:

Once testing is complete, launch in a controlled way. This includes submitting the right sitemaps in Google Search Console, as well as making sure analytics and conversion tracking are set up by language, country or region, so each version can be measured from day one.

After launch, watch the early signs closely. Look for crawl errors, indexing problems, hreflang issues, unusual user behaviour and weak conversion rates.

 

Maintaining and scaling a multilingual website

A multilingual website still needs looking after once it is live. Products change, prices change, legal wording changes and customer expectations change too. Keep the process simple, but make sure it happens regularly:

A multilingual site is never really “done” after launch. Pages need updating, search performance needs checking and local teams need a clear way to keep content accurate.

As you add more languages or markets, keep an eye on what is worth maintaining. It is better to have fewer strong local versions than lots of thin ones that are out of date, hard to manage or not useful for customers.

The aim is simple: each market should be able to find the right pages, understand the offer and use the site without it feeling like an afterthought.