Multilingual WordPress: Comparing the Main Approaches

WordPress core is translatable but not multilingual: it will happily run in French, but it has no native concept of the same page existing in French and English at once. Everything multilingual is therefore an architectural choice layered on top, and it is one of the harder choices to reverse later, because each approach stores translations differently. It deserves more thought than it usually gets.

First, agree what multilingual means for you

Before comparing plugins, pin down the requirement. Fully mirrored content in every language is a different project from an English site with a dozen translated landing pages. Who translates: an in-house team working in the admin, an external agency exchanging XLIFF files, or machine translation with human review? And do different regions need different content, not just different words? Pricing, legal pages and campaigns often diverge by market, which quietly turns a translation problem into a content-strategy problem.

The main approaches

Polylang

Polylang models each translation as its own post, linked to its siblings. It is light, predictable and close to how WordPress already thinks, which is why it is our default recommendation for straightforward sites. The free tier covers a lot; string translation for theme and plugin text and better e-commerce support sit in the Pro version. Its simplicity is also its limit: complex translation workflows are not really its territory.

WPML

WPML is the heavyweight: translation management with jobs and translator roles, professional agency integrations, and compatibility work with a vast plugin list, including deep WooCommerce support. The cost is complexity, with additional tables and more moving parts than any alternative. Where there is a genuine workflow, with multiple translators and review steps, that machinery earns its keep; on a small site it is more machine than the job needs. Recent releases have improved performance considerably, but test with your own content volumes rather than taking anyone's word for it.

TranslatePress

TranslatePress takes a different angle entirely: you translate the rendered page from the front end, and it stores translations of the output rather than duplicating posts. Editors love the visual approach, and it copes well with text that other plugins struggle to reach, such as page-builder output. It fits best when the site structure is identical across languages and translation really is translation, not per-market content.

Multisite, one site per language

Running a network with a site per language gives each market full independence: its own plugins, menus, editorial team and content. Linking translations across sites needs a plugin such as MultilingualPress, and every network-level cost of multisite applies. This is the right shape for organisations whose country sites are genuinely different products, and overkill for anyone who just wants the same page in three languages. Shared media libraries and cross-network search are solvable, but every solution is one more moving part to own.

Choosing without regret

• Match the tool to the workflow, not the feature list: the best plugin is the one your actual translators will use.
• Check SEO fundamentals early: clean language URLs and correct hreflang output are non-negotiable.
• Audit compatibility with your specific plugin stack on a staging copy before committing.
• Budget for ongoing translation as an editorial process; the plugin is the cheap part.

Two practical notes apply whichever way you go. Translation plugins touch every request, so test against your caching setup early; language-aware page caching needs the language in the cache key, which not every host does by default. And count the strings that live outside posts, menus, form labels, email templates and checkout text, because they all need a translation route and they are where projects discover a tool's limits late.

Migrating between these approaches after launch is possible but painful, so prototype with real content first. Choosing a multilingual architecture is one of the questions clients bring to STRCLI most often, and we are happy to talk yours through.