How to Make a WordPress Site Multilingual
To make a WordPress site multilingual, you pick one of four approaches: a WordPress Multisite network with one site per language, a single-site plugin that stores translations in your own database, an external service that holds and serves the translations, or manually duplicated pages. WordPress core does not translate your content by itself, so the choice is mostly about where translations live and who controls them. Whichever you choose, search engines need a separate URL for each language and links connecting the versions.
Does WordPress translate content by itself?
No. WordPress is built so that code can be translated: its developer documentation describes internationalization as preparing strings for translation, and the Site Language option in Settings is documented as the language of the dashboard. That is about the interface, not about your posts, pages and products. Translating the actual content, creating language URLs and wiring the versions together is left to one of the approaches below.
This matters because every approach adds something core does not provide: a place to store the translated content, a way to assign a language to each URL, and a language switcher. Those three pieces are also where multilingual sites most often break, so keep them in mind when comparing options.
What are the four ways to run a multilingual WordPress site?
| Approach | Where translations live | Typical URL shape | Main trade-off |
|---|---|---|---|
| Multisite, one site per language | A separate site (and set of database tables) per language | example.com/fr/ or fr.example.com |
Strong separation, more administration |
| Single-site database plugin | Your own database, inside one site | Usually subdirectories | One dashboard, but content and plugins become tightly coupled |
| External service plugin | The vendor's servers, often cached on your site | Subdirectories, subdomains or domains, depending on the service | Fast to start, dependency on a third party |
| Manual duplicated pages | Ordinary pages and posts you create yourself | Whatever you build | Full control, high effort |
The sections below describe each one generically. Which products implement them is deliberately left out here; the approach matters more than the brand, and products change faster than architectures.
How does WordPress Multisite handle languages?
WordPress Multisite lets you run several sites from one installation. According to the WordPress developer documentation, the sites can share resources such as themes and plugins while keeping different content, each site has its own database tables, and the user table is shared. A network can be path-based (subdirectories) or domain-based (domains or subdomains).
For languages, the pattern is one site per language: for example a main site in English and a second site in French at /fr/. Each site has its own pages, menus, media library and settings, and a site can have its own language setting, since WordPress looks up the locale per site on a network. The documentation page on Multisite itself does not mention languages, so treat this as a common usage pattern rather than a feature Multisite advertises.
Strengths: clean separation, per-language permissions (a French editor can be limited to the French site), and the ability to give each language a different theme or plugin set if you need one.
Costs: content is not linked between sites by default, so you need something to connect a page with its translation, to build the language switcher and to output hreflang. Plugin and theme updates multiply across the network, and the setup is harder to undo than a plugin.
How do single-site plugins store translations in the database?
In this approach everything stays in one WordPress site. The plugin stores each translation either as an additional post or page linked to the original, or as translated strings attached to the original content, and adds a language to every URL. Editors work in one dashboard and switch language when editing.
Strengths: one install to maintain, translations live in your own database and are included in your backups, and the site keeps working if a vendor disappears (you may still need to migrate the content to another system).
Costs: the database can grow substantially, because every language adds rows. Every plugin that stores content, such as forms, sliders or page builders, must be compatible with the translation layer, or its content will not be translatable. Plugin switching later usually means a migration project. Page speed also depends on how the plugin queries translations; test it, rather than assuming.
How do external translation services work with WordPress?
Here a plugin connects the site to a service that stores the translations and often provides machine translation, a glossary and an editor. The translated pages may be served from the vendor's infrastructure, or rendered by your site from a cached copy.
Strengths: the fastest route to a working multilingual site, less database load on your server, and built-in machine translation with human review.
Costs: you depend on the service for availability and pricing, and exports may be limited. The questions to ask are practical: Is the translated HTML in the server response or injected by JavaScript after load? What happens to the translated pages if the service is unreachable, or your subscription ends? Can you export every translation in a standard format? We cover these in avoiding translation vendor lock-in and, for the rendering question, in client-side vs server-side translation and SEO.
When are manually duplicated pages enough?
For a small site with a handful of pages in two languages, you can simply create a second page for each page, translate it, and add links between the versions. There is no translation layer to break.
Strengths: no plugin dependency, full control of URLs, titles and content for each market, and no ongoing fee.
Costs: everything is manual. You must write the hreflang tags yourself (in the page head, HTTP headers or a sitemap, as Google's documentation describes), keep the pairs in sync when content changes, and build the language switcher with custom links or menu items. It scales poorly beyond a few dozen pages, and shops with changing catalogs usually outgrow it.
How do I choose the right approach?
Work through these questions in order:
- How much content, and how often does it change? A brochure site tolerates manual pages. A blog or shop with frequent updates needs automation.
- Who edits? If separate regional teams need independent control, Multisite fits. If one team handles everything, a single-site approach is simpler.
- How much dependency can you accept? A vendor-hosted approach trades control for speed. Decide it deliberately, not by default.
- What URL structure do you want? Subdirectories, subdomains and country domains are different SEO and operations trade-offs, covered in subdirectories vs subdomains vs ccTLDs.
- How good must the translation be? Raw machine output, edited machine output and professional translation have different costs; see machine vs human vs hybrid translation.
What should I check before committing to a setup?
Whatever you pick, test it on a staging copy first and verify the following in the page source and in Google Search Console:
- Each language has its own crawlable URL, and the main text is present in the HTML response rather than only appearing after JavaScript runs.
- Each page links to all its translations and to itself, using absolute URLs. Google documents this as the hreflang requirement, with return links on every version:
<link rel="alternate" hreflang="en" href="https://example.com/page/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />
- The
<html lang>attribute matches the page language. WordPress themes print it with thelanguage_attributes()function, which depends on the locale the setup sets for that page. - The language switcher uses plain links to the real translated URLs, and the site does not force visitors to a language based on a guess. Google advises against redirecting users based on assumed language, which can keep users and crawlers away from some versions.
- Translated pages are not marked as canonical duplicates of the original. Google advises that, with hreflang, the canonical should be a page in the same language; pointing translations at the original risks having them treated as duplicates.
The WordPress-specific details, such as permalinks, sitemaps and SEO plugin interactions, are in WordPress multilingual SEO. We are building ResilientLang to keep translated pages available even when a translation vendor is not, but it is not released yet, and you do not need it to apply any of the checks above.
Key takeaways
- WordPress core internationalizes the interface; translating content requires Multisite, a plugin, an external service or manual pages.
- The four approaches differ mainly in where translations are stored and who controls them.
- Multisite gives strong separation but more administration; database plugins keep data in your hands; external services are fast but create a dependency; manual pages are simple but do not scale.
- Pick the approach you can maintain, then verify the output: separate URLs, hreflang with return links, correct
lang, plain-link language switcher. - Always confirm you can export your translations before you commit.
Sources
- Multisite – Advanced Administration Handbook – what Multisite is, shared themes and plugins, per-site tables, path-based and domain-based networks
- Internationalization – WordPress Developer Resources – internationalization means preparing strings for translation
- Settings General screen – WordPress documentation – Site Language is the dashboard language
- get_locale() – WordPress Developer Resources – how the locale is determined, including per-site options on multisite
- Localized versions of your pages – Google Search Central – hreflang requirements and the three implementation methods
- Managing multi-regional and multilingual sites – Google Search Central – URL structures, separate URLs per language, avoiding automatic redirects
Frequently asked questions
Does WordPress support multiple languages out of the box?
Only for the interface. WordPress core is internationalized, so the dashboard and many themes and plugins can be shown in other languages, but the Site Language setting is documented as the dashboard language. Translating your posts and pages into several languages needs Multisite, a plugin, an external service or duplicated pages.
Which approach is best for SEO?
No approach is inherently better for rankings. Google needs a separate crawlable URL per language, links between the versions (hreflang), and content in one language per page. Any of the four approaches can deliver that. The better question is which one you can keep correct and maintain for years.
Can I mix approaches on one site?
Yes, but it adds risk. A common mix is a plugin for pages and posts plus manually written pages for a few markets. Mixing two systems that both try to output hreflang or language URLs can produce conflicting signals, so decide which tool owns each part of the site.
What happens to my translations if I stop using a tool?
It depends on where they are stored. Translations kept as normal WordPress content or in your own database stay with you, though they may need cleaning up. Translations held on a vendor's servers may be hard to export or may stop displaying. Check export options before you commit.