Enterprise WordPress multilingual your regional teams can run

There is no single answer, and anyone who gives you one has not asked enough questions. We choose against content volume, editorial structure and your stack.

• WPML: centralized, powerful, widely adopted, compatible with ACF and block content. Cost: performance weight and a real learning curve.
• Polylang: light and simple, free at the base tier. Cost: several functions you will want are Pro-only.
• MultilingualPress: one site per language on Multisite. Clean separation, strong performance, SEO-friendly. Cost: requires Multisite, most technical to operate.
• TranslatePress: visual translation editor, easy for editors, integrates with DeepL and Google Translate. Cost: less flexible on complex sites.
• Weglot: hosted, fastest to implement, very visual. Cost: price, an external dependency, and no full control of your SEO output.

We run Polylang Pro here, which is how our Spanish pages are served at /es/. That is our choice for our stack, not a default for yours.

It comes down to how separate your markets genuinely are. One site with a translation plugin keeps a single content model, media library and admin, which is simpler to keep in sync. Multisite with MultilingualPress gives each language its own site: clean separation, performance per locale, and no risk of one market’s change affecting another.

Multisite costs more to run: more environments, more update surface. We recommend it when markets have genuinely different content rather than translations of the same, or when regional teams need hard boundaries. Otherwise the plugin path is lighter. More on our multisite solutions page.

They survive if someone checks. What breaks most often: blocks rendered server-side through a render callback, Advanced Custom Fields values, custom post types, taxonomy terms, and Gravity Forms labels and confirmations. None of those are translated by installing a plugin.

Each is handled explicitly, then tested on staging: translated copy changes length, and long strings break layouts that looked fine in English.

For drafts, yes. As the published version, no.

DeepL and Google Translate integrations are supported by several of these tools, and they are useful for putting a first pass in front of a reviewer. What they cannot do is hold your brand voice, or catch a term of art that means something else in your industry.

Machine output publishes only after human review, and that review is somebody’s named responsibility. If nobody can review a language, launch fewer languages.

In three places, all configuration rather than content. URL structure determines whether Google can tell your locales apart. hreflang determines which version reaches which market. Translated metadata determines whether that result is worth clicking.

The failure mode is not a penalty. It is Google serving your English page to a Spanish-speaking visitor, or two locales competing for the same query. Both are cheaper to prevent than to fix, which is why this runs alongside enterprise WordPress SEO rather than after it.