WordPress multilingual plugins: WPML, Polylang, TranslatePress and Weglot

WordPress can run in almost any language, but it cannot run in several languages at once without help. Core lets you choose one site language and translates the admin, yet it has no way to store an English page and its Spanish version as linked translations. Multilingual content is the fourth phase of the WordPress roadmap, and as of October 2026 that phase has not started in core.

That leaves plugins. The four most site owners compare are WPML, Polylang, TranslatePress and Weglot. They differ in how they store translations, how you translate (in the editor, on the live page or in a separate dashboard), what URL structure they produce, and how they handle SEO details such as hreflang tags and translated slugs.

This guide explains those differences, the SEO rules any multilingual setup has to follow, and how to evaluate a plugin before committing. It is a neutral guide, not a ranking. Switching translation plugins later is hard, so the choice deserves more care than most.

What WordPress core does (and does not do)

Core handles the language of the software and of a single site well: you can set the site language in Settings > General and install translations for the admin, themes and plugins. The WordPress roadmap lists four phases (Easier Editing, Customization, Collaboration and Multilingual) and Phase 3, Collaboration, is the one currently underway.

What core lacks: linking posts as translations of each other, a language switcher, per-language URLs and hreflang output. A multisite network with one site per language is a core-only workaround, but connecting the sites and their translations still needs a plugin or custom code.

The SEO rules any multilingual site must follow

Give each language its own URL

Google's guidance on multi-regional and multilingual sites describes four structures:

• Country-code domains (example.de): strong geotargeting, more cost and upkeep.
• Subdomains (de.example.com): easy to set up, but "de" can be unclear to users as language or country.
• Subdirectories (example.com/de/): simple to implement and maintain on one site.
• URL parameters (example.com?loc=de): Google says these are "Not recommended".

For most WordPress sites, subdirectories are the simplest choice. All four plugins in this guide can produce subdirectory URLs, and some also support subdomains or separate domains.

Add correct hreflang annotations

hreflang tells search engines which URL serves which language or region. According to Google's localized versions documentation, you can declare them in HTML link tags, HTTP headers or the XML sitemap, and "each language version must list itself as well as all other language versions". Missing return links can cause the annotations to be ignored. Use x-default for a fallback page, such as a language selector. Multilingual plugins generate these tags; your job is to check they are complete.

Translate everything visible

Google says it uses "the visible content of your page to determine its language" and does not use code-level language information such as the lang attribute or the URL. A Spanish URL with an English menu, English widgets and English product descriptions sends mixed signals. Translate menus, widgets, forms, image alt text, meta titles and descriptions, and slugs where it makes sense.

Let visitors choose

Offer a clear language switcher and do not force visitors (or crawlers) into a language based on browser settings alone. Search engines need to be able to reach every version.

For the strategy side of going international, see our article on scaling organic traffic with international SEO.

How multilingual plugins store translations

Separate posts per language (WPML, Polylang)

Each translation is its own WordPress post, page or term, linked to the original. You translate in the normal editor. This fits the WordPress data model well: each translation can have its own slug, SEO fields, featured image and even different content where markets need it. Polylang's listing says it supports translating "posts, pages, media, categories, post tags, custom post types and taxonomies" and setting language by URL code, subdomain or domain.

Translating the rendered page (TranslatePress)

TranslatePress lets you translate the page as visitors see it, in a visual front-end editor, "including output from shortcodes, forms and page builders". This makes it easy to catch every visible string, including theme and plugin text. Its settings include whether the default language also uses a subdirectory.

Translation as a service (Weglot)

Weglot connects your site to a Weglot account where translations are managed, with AI translation to start and manual editing on top. Its WordPress.org listing describes language-specific URLs in subdirectories or subdomains, "automatic hreflang tags", translated metadata and translatable URL slugs. Pricing depends on languages and word count, and it is a continuing subscription.

How to evaluate a multilingual plugin

1. Content model. Do you need different content per market (separate posts), or the same content translated (page-level translation works)?
2. Who translates. In-house editors, professional translators, machine translation or a mix. Check the workflow and any translation-management or agency features.
3. URL options. Confirm it supports your chosen structure, translated slugs and hreflang with x-default.
4. Compatibility. Test your theme, page builder, SEO plugin, forms and WooCommerce (products, variations, checkout emails) on staging.
5. Performance. Some approaches add database queries or external requests. Measure a translated page against the original.
6. Maintenance and security. Check "last updated", "tested up to" and forum activity on WordPress.org, or the vendor's changelog for premium-only plugins.
7. Cost model. Per-site license, unlimited-site license or a subscription tied to word count and languages. Model the cost at your size in two years.
8. Lock-in. Ask how you would export translations and keep URLs if you left. With a service, check what happens to translated pages if the subscription lapses.

Well-known multilingual plugins

Listed in no particular order. Install bands are from WordPress.org and pricing from each vendor's site, as of October 2026. Some vendors show prices in euros.

Sources: WPML purchase page, Polylang pricing and Weglot pricing. WPML's URL options come from its own documentation, which lists language directories, separate domains or subdomains, and a language parameter. Given Google's guidance, the parameter option is the one to avoid for public content.

SEO checklist after launch

• View source on a page in each language and confirm the hreflang set is complete, includes the page itself and points to live, indexable URLs.
• Check that each language has its own XML sitemap entries or that the sitemap includes hreflang links.
• Confirm translated pages have translated titles and meta descriptions, not copies of the original.
• Make sure canonical tags point to the page's own language version, not to the original language.
• Review machine-translated pages with a fluent speaker before indexing them, especially legal, medical or pricing content.
• Monitor each language in Search Console (by directory or property) for coverage and hreflang issues.

A technical SEO audit after launch catches most of these problems. If you ever change plugins or URL structure, plan redirects carefully with a 301 redirect map.

Conclusion

Decide on your content model and URL structure first, then choose the plugin that fits them. Use separate URLs (subdirectories are simplest), make sure hreflang is complete and reciprocal, translate everything a visitor sees, and check costs and exit options before you translate at scale. If you are planning a multilingual launch or cleaning up an existing one, eSEOspace offers WordPress SEO services. More guides are in our WordPress hub, including the SEO plugins guide.

Frequently asked questions