Most "best WordPress translation plugin" comparisons line up five tools, score them on features, and crown a winner. That framing hides the decision that actually matters. The plugins you're choosing between aren't variations on one idea — they represent three fundamentally different architectures for where your translated content lives and who controls it. Pick the wrong architecture and no amount of feature polish saves you, because the architecture decides your data ownership, your SEO ceiling, your performance budget, and your monthly bill long after you've forgotten which checkbox a plugin had.

So this comparison is organized around the fork, not the feature table. Get the architecture right first; the specific tool inside it is a secondary, reversible choice.

The three architectures (and what they actually commit you to)

1. Single-install translation: WPML, Polylang, TranslatePress

One WordPress installation holds every language. Translations are stored in your own database — as duplicate posts linked together (Polylang, WPML) or as a separate translations table keyed to the original strings (TranslatePress). URLs are usually subdirectories: /es/, /fr/.

The defining property here is ownership. Your translations are rows in your MySQL database. You can export them, migrate hosts, cancel the plugin licence, and the Spanish content is still sitting in wp_posts. This is the architecture you want if multilingual is a permanent part of the business rather than an experiment.

2. Separate installs / multisite: MultilingualPress

Each language gets its own full WordPress site, connected through a WordPress Multisite network. MultilingualPress links equivalent posts across the network and wires up the hreflang relationships between them. Nothing is shared at the content level — German editors work in the German site, entirely decoupled from the English one.

You're trading coupling for isolation. A plugin conflict, a bloated revision table, or a runaway editor on one language can't drag the others down. The cost is real operational overhead: every site needs its own updates, backups, and security surface. This architecture earns its keep when each language is a genuinely separate market with its own team and substantially different content — not a mirror translation of one source.

3. External proxy / SaaS: Weglot, Bablic

Your WordPress site stays monolingual. A service crawls your rendered pages, translates the text on its own infrastructure, and serves the translated versions from URLs it controls (typically a subdomain or path it proxies). The plugin is a thin connector; the translations live on the vendor's servers.

Setup is genuinely the fastest of the three — often live in an afternoon, hreflang and language switcher included. But understand the trade you're making, because it's the one most comparisons gloss over: you do not own these translations.

The lock-in question nobody benchmarks

This is the single most important and most under-discussed axis. With a proxy service like Weglot, the day you stop paying, your translated content stops existing. There's no Spanish site to fall back to — those pages were rendered on demand from the vendor's translation store. You can usually export a glossary or a translation memory file, but you cannot trivially rehome thousands of live, indexed multilingual URLs back into your own site without a migration project.

Single-install plugins sit at the other end. WPML and Polylang write translations as standard posts and postmeta you fully own. Even there, migrating between plugins is painful — Polylang's post-relationship model and WPML's translation tables don't map cleanly onto each other, so switching usually means a conversion plugin and manual cleanup. But the content never leaves your database. Decide early how much portability you're willing to mortgage for setup speed.

SEO: where the URL structure outranks the plugin

Google ranks each language version as its own page, so the mechanics of how those pages are exposed matter more than which plugin generated them. Three things have to be correct:

A distinct, crawlable URL per language. Subdirectories (example.com/de/) are the pragmatic default — they inherit the root domain's authority and are cheapest to run. Subdomains (de.example.com) and country-code domains (example.de) signal stronger geo-targeting but split authority and multiply hosting and certificate overhead. Most sites should use subdirectories unless they're targeting countries, not just languages.
Reciprocal hreflang annotations. Every language version must point to every other version, the references have to be mutual, and you need an x-default entry telling Google what to serve when no language matches. A one-directional or self-inconsistent hreflang set is silently ignored. TranslatePress and Polylang generate these automatically; WPML does too once configured; MultilingualPress coordinates them across the network but warrants a spot-check; proxy services handle it server-side.
Genuinely translated body text, not an overlay. A widget that swaps text client-side without a unique server-rendered URL gives Googlebot one indexable page, not several. This is the failure mode that quietly wastes the whole effort.

The honest takeaway: every mature option here can be made SEO-correct. The differences are in defaults and how easy it is to misconfigure, not in whether multilingual SEO is achievable.

Performance: the cost that compounds per request

Multilingual is rarely free at the page-weight or server level, and each architecture taxes you differently:

Single-install plugins add database work. Every request resolves the current language, fetches the right translation, and rewrites links. WPML in particular is query-heavy on complex sites; aggressive object caching (Redis) and full-page caching that's language-aware are non-negotiable. Cache fragmentation is the catch — you're now caching N copies of every page, so plan cache storage accordingly.
Multisite spreads the load but multiplies what you maintain and cache across separate sites.
Proxy services add a network round-trip. Translated pages route through the vendor's edge, which can help (their CDN) or hurt (an extra hop) depending on geography. You're also dependent on their uptime for your non-default languages.

Whatever you choose, hold the line on Core Web Vitals — an LCP under 2.5 seconds and a TTFB target around 200ms shouldn't degrade just because a page is now Spanish.

The recurring-cost trap: translation credits

The licence is rarely the real bill. WPML's Multilingual CMS tier (around €99/year for a few sites) bundles a pool of automatic-translation credits; burn through them on a large site and you top up per word. Weglot's pricing is metered by translated word count and number of languages — its free tier covers only tiny sites (roughly a couple thousand words, one language), and costs scale with content as your catalogue grows. Polylang and TranslatePress let you supply your own DeepL or Google API key, which means a separate per-character translation bill flowing straight to those providers. Model the ongoing word-volume economics before committing, not just the sticker licence.

So which architecture, for whom

Small site, 2–3 languages, owns its content: single-install — Polylang (lean, generous free tier) or TranslatePress (visual, in-context editing translators love).
Content-heavy site, many languages, WooCommerce and custom post types: WPML, accepting the credit costs and query weight for unmatched feature coverage.
Multiple distinct markets, separate teams, divergent content: MultilingualPress on Multisite, paying maintenance overhead for editorial independence.
Need it live fast and treating multilingual as an experiment: Weglot — eyes open about the lock-in and metered billing you're signing up for.

Translation quality, finally, is orthogonal to all of this: none of these tools write good translations, they manage them. Machine translation for the first pass plus human review is what produces content that ranks and reads naturally. Choose the architecture for ownership and scale; choose the workflow for quality. They're separate decisions, and conflating them is how multilingual projects go wrong.

WordPress Translation: The Honest Comparison of Methods