How to make a website multilingual: a decision guide

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:

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 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 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 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: <link> 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 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 covers what works today. Our step-by-step guide to translating a 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 <script> to the site, and it translates approved text in place in the language the visitor picks, with a language switcher. It is quick to set up, and the same checks and settings apply. It also has a clear limit: it makes no SEO claim. Search engines see the source page, no hreflang is added, and the translated text is not indexed. Use it when visitors need to read your site in their language and search traffic in that language is not the goal. A Change hook keeps the translations current when content changes.

If indexed translations on a non-WordPress site matter to you, LangRelay is not the right tool today, and a service that serves translated HTML on your platform will fit better. Our buyer's guide compares LangRelay with seven alternatives on exactly this point.

A short pre-launch checklist#

• Open three translated pages in a private window and switch languages from each. You should land on the same page in the other language every time.
• View the source of one translated page and check that hreflang lists every language, including itself and x-default, with full https:// URLs.
• Check that the canonical of each translated page is that page, not the original.
• Search your translated pages for leftover source-language text in menus, buttons, footers and form messages.
• Make one edit to an original page and watch how long it takes to reach each language, and who gets asked to review it.

Questions people ask about multilingual websites#

Can I make my website multilingual for free?#

For a small site, yes. LangRelay's Free plan covers one Site in one language with 2,000 words a month, plus a one-time welcome grant of 4,000 words. Weglot's free plan, as listed on 2026-10-06, covers 2,000 words in one language. Larger sites need a paid plan or paid translation.

How many languages should I start with?#

One or two. Each language multiplies the translation and the review work. Start with the language that already sends you visitors, get the process right, then add more.

Does a multilingual website help SEO?#

It lets your pages appear in searches made in other languages, which the source pages cannot. It only works if each language has its own URL, the hreflang annotations are correct, and the translated text is in the HTML that search engines read.

What does a multilingual website look like in practice?#

Google's documentation uses two examples. A Canadian business with English and French versions of its site is multilingual. A manufacturer that ships to both Canada and the United States, with a version for each country, is multi-regional. Each version sits at its own URL, such as example.com/fr/ for French, with a switcher on every page and hreflang that lists all versions. To look at examples yourself, open a site you know in two languages and check the address bar, the switcher and the page source for those three things.

What is the difference between a multilingual and a multi-regional website?#

Google draws the line this way: a multilingual site offers content in more than one language, and a multi-regional site explicitly targets users in different countries. A site can be both. Our website localization guide covers the regional side, from currencies to legal pages.

If you want to see the WordPress route on your own site, book a demo.