---
title: "How to make a website multilingual: a decision guide"
description: "The six decisions behind a multilingual website, from URL structure to upkeep, what Google documents for each, and the route for WordPress and other platforms."
url: "https://www.langrelay.com/guides/multilingual-website"
---
1. [Home](https://www.langrelay.com/)
2. [Guides](https://www.langrelay.com/guides)
3. How to make a website multilingual: a decision guide
GuideHow-to
# How to make a website multilingual: a decision guide
The six decisions behind a multilingual website, from URL structure to upkeep, what Google documents for each, and the route for WordPress and other platforms.
[Chris Jayden](https://www.langrelay.com/about)
Founder
Published
6 October 2026
Updated
8 October 2026
Reading time
9 min read
On this page
1. Decision 1: give each language its own URL
2. Decision 2: decide where the translations live
3. A separate page per language
4. Translating the rendered page
5. Translating in the visitor's browser
6. Decision 3: choose how the text gets translated
7. Decision 4: let visitors choose their language
8. Decision 5: tell search engines how the versions relate
9. Decision 6: keep every language current
10. The route for WordPress
11. The route for other platforms
12. A short pre-launch checklist
13. Questions people ask about multilingual websites
14. Can I make my website multilingual for free?
15. How many languages should I start with?
16. Does a multilingual website help SEO?
17. What does a multilingual website look like in practice?
18. What is the difference between a multilingual and a multi-regional website?
To make a website multilingual, you give each language its own URL, get the text translated, let visitors switch between languages, tell search engines which pages are versions of each other, and set up a way to keep every language in step when the original changes. The tools differ a lot, but every working multilingual site has made those same decisions, whether on purpose or by accepting a plugin's defaults. Below, each decision comes with what Google's documentation says about it, followed by the shortest route for WordPress and for other platforms.
## Decision 1: give each language its own URL
The first choice is whether a French visitor and an English visitor load the same address and see different text, or load different addresses. Google's guide to multilingual sites recommends "using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page."
The reason is how Googlebot crawls. Google says its crawler usually originates from the US and sends requests without an `Accept-Language` header. A site that picks the language from a cookie or the browser's settings will show Googlebot one language, and the others may never be indexed.
Once you have separate URLs, you choose a structure. Google's documentation lists four:
| Structure | Example | What Google notes |
| --- | --- | --- |
| Country domain | `example.de` | Clear geotargeting, but expensive, more infrastructure, and only one country per domain |
| Subdomain | `de.example.com` | Easy to set up; users may not know whether "de" means the language or the country |
| Subdirectory | `example.com/de/` | Easy to set up and low maintenance on one host |
| URL parameter | `example.com?loc=de` | Not recommended |
For most sites that add languages without opening a business in each country, a subdirectory per language is the simplest to run, with one domain and one hosting setup. That is what LangRelay serves on WordPress (`/fr/`, `/de/`). Our article on [subdomain vs subdirectory for multilingual SEO](https://www.langrelay.com/blog/subdomain-vs-subdirectory-multilingual-seo) goes into the trade-offs.
## Decision 2: decide where the translations live
This decision shapes how much work every future edit costs. There are three common models.
### A separate page per language
The CMS stores a French copy of every page next to the English one. You can give each language its own layout, images and text, which suits sites where markets need different content. The cost comes later: when someone changes the English page, the French copy does not change with it, and somebody has to notice and update it.
### Translating the rendered page
The CMS keeps one page. A plugin or service reads the page as it is rendered, translates its text, and serves the translated version at the language URL. An edit to the original shows up in every language's queue for translation, because there is only one page to edit. The trade-off is that every language shares the same layout and images unless the tool lets you vary them.
### Translating in the visitor's browser
A script on the page replaces the text after it loads. It is the quickest to add and needs no change to the server. The translated text is not in the HTML the server sends, so a search engine that reads the HTML sees the original language only.
LangRelay uses the second model on WordPress: it translates the rendered page, so your posts stay as they are and WordPress keeps one post per page. On other platforms it uses the third, which we describe below with its limits.
## Decision 3: choose how the text gets translated
You can pay translators, use machine translation, or combine them. The combination is what most sites use now: machine translation for the first draft, and a person who reads the language to check what visitors will see.
Two settings make machine output much better before anyone reviews it. A glossary tells the engine which terms to keep or translate a fixed way, such as your brand name or a product feature. A formality setting fixes how the site addresses the reader in languages that distinguish formal and informal "you". LangRelay has both: glossary terms with per-language translations and a keep-as-source option on paid plans, and a formality register for German, Spanish, French, Italian, Dutch and Turkish.
Then decide who approves. Some tools can publish machine output as soon as it exists, and others wait for a person. LangRelay puts translations live by default, with free checks that hold a page with untranslated text, the wrong language or a changed price; if you choose Ask me first, every page waits for your approval, which costs some review time and means nobody in a new market reads a sentence your team has not seen.
If you are weighing the options, our article on [automatic website translation](https://www.langrelay.com/blog/automatic-website-translation) explains what "automatic" covers and where review fits.
## Decision 4: let visitors choose their language
Visitors need a visible way to switch, on every page, that takes them to the same page in the other language and not back to the homepage.
Google's guidance here is direct: avoid automatically redirecting users from one language version to another based on what you think their language is, because "these redirections could prevent users (and search engines) from viewing all the versions of your site." It recommends hyperlinks to the other language versions so people can choose. A banner that suggests a language, without moving anyone, keeps both benefits.
Show each language in its own name, so a Spanish speaker on the English page looks for "Español" and not "Spanish". Our guide to [language switcher best practices](https://www.langrelay.com/blog/language-switcher-best-practices) covers placement, flags and accessible markup.
## Decision 5: tell search engines how the versions relate
Separate URLs are half of it. Search engines also need to know that `/fr/pricing` is the French version of `/pricing`, so they show each searcher the right one. That is what hreflang does.
Google supports three equivalent ways to declare it: `` elements in the HTML head, HTTP headers, or a sitemap. Its rules apply to all three. Each language version "must list itself as well as all other language versions." The URLs must be fully qualified, with `https://`. And Google suggests an `x-default` entry as the fallback for visitors whose language you do not serve.
Two more details catch many sites. Google decides a page's language from its visible content, not from the HTML `lang` attribute or the URL, so a page whose navigation stays in English around a French article sends a mixed signal. And a translated page should have its own translated title and meta description, since those are what appear in search results. Our [hreflang guide](https://www.langrelay.com/guides/hreflang) has worked examples and a validation checklist.
On WordPress, LangRelay's plugin emits all of this: hreflang for every language with `x-default`, a canonical URL per language that points to that language's own page, and translated titles and meta descriptions.
## Decision 6: keep every language current
The original site keeps changing after launch, through edits and new pages. Before launch, decide how a change in the original reaches the translations and who checks it.
With a page per language, this is a manual process: someone edits the English page, then remembers to update each translation or flags it for a translator. With a rendered-page tool, the tool can see the change and translate the new text. Either way, a person should still review it if your process requires review.
When an editor saves a change in WordPress, the LangRelay plugin passes it on within about a minute, and LangRelay translates the new sentences. Text that has not changed is not translated again or counted against your plan, so the monthly cost follows how much your site changes. On other platforms, a Change hook does the same job: a secret URL that your CMS, a deploy script or a scheduled job calls when content changes.
## The route for WordPress
On WordPress, LangRelay provides the tooling behind each of these decisions, and your team does the reviewing:
1. Install the LangRelay plugin and connect it to your LangRelay account. You approve the connection in the dashboard and return to WordPress.
2. Choose your languages when you create the Site. LangRelay crawls the site and translates the pages it finds.
3. Review the translations in the dashboard, page by page and language by language, or in the Visual editor on the rendered page. Ask Relay, our agent, for a change in a sentence if that is quicker.
4. Your first page waits for you to approve it. After that, pages go live as they are ready, unless the free checks hold one; choose Ask me first if you want to approve every page. The plugin serves each live page from your own server at its subdirectory, with hreflang and a canonical per language.
On a WooCommerce store, product and shop pages are translated like any other page, and so are the titles and meta descriptions Yoast or Rank Math print. Keeping the language on the cart, checkout and account addresses WooCommerce builds itself is on the roadmap; the [WooCommerce guide](https://www.langrelay.com/guides/translate-woocommerce-store) covers what works today. Our step-by-step guide to [translating a WordPress site](https://www.langrelay.com/guides/translate-wordpress-site) covers each screen.
## The route for other platforms
If your site runs on a hosted builder or a custom stack, start with your platform's own documentation, since some builders include a multilingual option of their own and it will fit their URL and SEO model best.
LangRelay's option for these sites is a script tag. You add one `