You want your WordPress site in more than one language, perhaps English and Hindi, or English, French and German for customers in Europe. You search for how to do it and find a dozen plugins, each claiming to be the easy option, plus advice about “hreflang” that sounds important and is hard to follow.
This post sorts that out. It covers the main ways to run a multilingual WordPress site, the plugins most people choose between, and what Google actually needs to understand which page to show to whom. It is about translating your content. If your problem is the dashboard or theme text not switching language, that is a different setting, covered in our post on why the WordPress language is not changing.
WordPress does not do this on its own
WordPress can show its own interface in many languages, but it has no built-in way to hold two versions of the same page and link them together. For that you need either a plugin or a WordPress Multisite network with one site per language. For most small business sites, a plugin is the simpler choice.
The main plugin options
These are the names you will see most often. All of them are widely used. They differ mainly in where translations are stored and how you edit them.
| Plugin | How it works | Worth knowing |
|---|---|---|
| WPML | Each translation is a separate post or page linked to the original | Paid only. Long-established, with wide support for themes, WooCommerce and page builders |
| Polylang | Also separate, linked posts per language | Free version on WordPress.org, with a paid Pro version for extra features |
| TranslatePress | You translate on the front end, seeing the page as you work | Free version available, with paid add-ons. Comfortable for people who dislike the editor |
| Weglot | A hosted service. Translations are stored on Weglot’s side and served through the plugin | Subscription based. Quick to start, but your translations depend on that service |
Before you choose, check three things against your own site: whether the plugin works with your theme and page builder, whether it handles WooCommerce if you sell online, and whether it works with your SEO plugin, such as Yoast or Rank Math. Most of the well-known ones cover these, but “covers” can mean anything from full support to a basic workaround, so test on a staging copy first.
Also think about leaving. With WPML and Polylang, translations live in your own database as normal posts. With a hosted service, they live with the provider, so check how you would export them if you ever stopped paying.
What Google needs
Google’s own guidance on this is in its documentation on telling Google about localized versions of your page. The practical points are below.
1. A separate URL for each language
Every language version needs its own address. Do not switch languages on the same URL using a cookie or the visitor’s browser setting, because Google will generally see only one version. Common structures are:
- Subfolders, such as example.com/fr/. The easiest to manage on one WordPress site, and what most plugins use by default.
- Subdomains, such as fr.example.com.
- Separate country domains, such as example.fr. Useful if you target countries rather than just languages, but more to manage.
Google advises against relying on URL parameters like ?lang=fr for this.
2. hreflang annotations
hreflang tells Google which pages are translations of one another, so it can show a French searcher the French page. It can be added in three ways: as link tags in the page’s head, as HTTP headers, or inside your XML sitemap. You only need one method, and a good multilingual plugin adds them for you.
The rules people get wrong:
- Each version lists itself and all the others. The English page points to English, French and German; the French page points to all three as well.
- The links must be returned. If page A points to page B but B does not point back to A, Google may ignore the annotation.
- Use proper codes. The language uses an ISO 639-1 code such as “en”, “hi”, “bn” or “fr”. You can add a region using an ISO 3166-1 alpha-2 code, as in “en-GB” or “fr-BE”. “en-UK” is a frequent mistake: the code for the United Kingdom is GB.
- Use x-default for the fallback, the page to show when no listed language matches, often your English version or a language chooser.
hreflang is a signal, not a command. Google can still show a different version if it decides that page is more relevant.
3. Canonical tags that point to the right page
Each language version should have a canonical tag pointing to itself. A common setup mistake is every translation pointing its canonical at the English page, which tells Google the translations are copies it can ignore. View the source of a translated page and check the canonical URL is that page’s own address.
4. Visible content in the right language
Google works out a page’s language from its visible content. A page with a translated heading and English body text is confusing for visitors and for search. Translate the whole page, including navigation, buttons and footer, and keep one language per page. Still set the correct lang attribute on each page, because browsers and screen readers use it.
Translations made purely by machine and published without review can also fall foul of Google’s spam policies when done at scale. Have a fluent person check every page.
5. No forced redirects by location
It is tempting to send visitors to a language automatically based on their location or browser. Google recommends against redirecting automatically, partly because its crawler may not be able to reach the other versions. Offer a clear language switcher instead, and if you want, a polite banner suggesting the visitor’s language.
Sitemaps and Search Console
Make sure every language version appears in your XML sitemap. Most multilingual plugins work with SEO plugins to include translations, but check by opening the sitemap and looking for the /fr/ or /hi/ addresses. If the sitemap itself is broken, our guide on fixing a WordPress sitemap that is not working covers the common causes.
In Google Search Console, use URL Inspection on a translated page to confirm Google can fetch it and sees the canonical you expect.
A short checklist before launch
- Each language has its own URL, and the switcher goes to the matching page, not the home page.
- hreflang links on every page include itself, all other versions and an x-default.
- Each translated page’s canonical points to itself.
- Menus, buttons, forms and footer are translated.
- The sitemap includes all language versions.
- No automatic redirects based on location.
For the content side, including translation quality, fonts and URLs for Indian languages, see our companion post on building a Hindi or Bengali version of your website. The wider guide to what business websites need now explains where multilingual fits.
Getting it set up
The plugin choice matters less than the setup and testing afterwards. If you want a multilingual WordPress site configured and checked, or an existing one reviewed for hreflang and canonical problems, our WordPress support service can do the technical part and write up what it found.
Next in this series: Progressive Web App vs App: When a Website Is Enough
