Most multilingual WordPress projects start the same way: someone picks WPML or Polylang based on a blog post they read, configures it in an afternoon, ships it, and six months later the site is bleeding performance, the editorial workflow is a mess, or there’s a translation gap that nobody can explain.
This site runs in four languages (EN/PT/ES/FR) on a custom approach because none of the plugins fit my requirements cleanly. That decision wasn’t dogmatic — it was the third option after I’d seriously considered the other two. Here’s the decision framework I actually use, based on real projects.
The three real options
Forget the marketing pages of each plugin for a moment. At an architectural level you have three serious choices:
- WPML — premium, full-featured, heavy. Each translation is a separate post linked to the original.
- Polylang — free core / paid Pro, lighter, same separate-posts model.
- Custom — anything from a serialised i18n array in the theme to a custom post meta strategy to a query-var-based language switcher.
Multi-domain or sub-domain WordPress multisite is technically a fourth option, but it’s a different beast — you’re running multiple WordPress installs. I’m not going to cover it here; if you’re at that scale you’re not asking “WPML or Polylang”, you’re asking “do I split this into separate sites”.
WPML — when it earns its weight
WPML is the default answer for agencies because it covers the broadest set of cases out of the box: posts, pages, custom post types, taxonomies, ACF fields, WooCommerce strings, theme strings via the String Translation module, menus, widgets, media library — everything is translatable.
Where it works
- Editorial-heavy sites with a translation team that needs a translation dashboard, machine translation integration, and a clear workflow for “what’s new in source, what still needs translating”
- WooCommerce stores selling in multiple languages with localised product names, descriptions, attributes, and prices in different currencies
- Sites built on heavy plugins (Elementor, Divi, complex ACF setups) — WPML has integrations for almost everything
Where it breaks
- Performance. WPML adds ~30 to 60 extra database queries on a typical page load. On a homepage that already runs 150+ queries because of plugin bloat, WPML pushes it past 200. Cacheable, but the moment you have logged-in users or session-based content, you feel it.
- Database size. Every translation is a row in
wp_posts, every translated meta is a row inwp_postmeta. A 4-language site with 500 posts becomes a 2,000-post site at the database level. - Conflicts with newer plugins. WPML’s “Custom XML config” approach to telling it which strings to translate works, but it ages — every plugin update can require config tweaks.
Cost: €99/year for Multilingual CMS, €199/year for Multilingual Agency. Worth it on a sufficiently complex editorial site; overkill for a 4-page brochure.
Polylang — lighter, same shape
Polylang uses the same conceptual model as WPML — one post per language, linked together — but the implementation is lighter and the free version is genuinely usable for non-WooCommerce sites.
Where it works
- Custom themes with custom post types where you have full control over what gets translated and don’t need the kitchen-sink coverage WPML provides
- Sites where the editorial team is small and can live without a dedicated translation dashboard
- Budget-sensitive projects where €99/year for WPML doesn’t fit; Polylang free + Polylang Pro (€99 one-time) is comparable
Where it breaks
- WooCommerce. Polylang for WooCommerce works but is less polished than WPML’s WooCommerce Multilingual. If your store is the primary driver, this matters.
- Theme strings. Polylang Pro’s String Translation is more manual than WPML’s. You’ll either ship your theme with full
load_theme_textdomain.mo files or rely on Polylang’s slower interface. - Visual page builders. Integrations exist but break more often than WPML’s.
Custom — when neither fits
The custom path isn’t one approach — it’s a category of approaches. The two I see most often:
Approach A: i18n arrays in the theme
For sites where the content is highly structured and editorially stable — landing pages, marketing sites with a fixed set of sections — define every translatable string as a key in a PHP array per language, accessed via a t()-style helper. URL takes a ?lang=xx query parameter (or a path prefix), and the active language is decided once per request.
Strengths: zero performance overhead, no extra database queries, version-controlled translations, deploy them like code. Editors translate by editing the array (or via a custom admin UI that writes to it).
Weaknesses: doesn’t fit a blog with frequently-added posts, doesn’t fit a WooCommerce catalogue of 500 products. The moment editors expect WP admin to be the source of truth for translations, this approach starts to feel wrong.
Approach B: post meta strategy
Each post has a set of meta fields per language: title_pt, title_en, etc. A small filter chooses the right field at render time based on the active locale. One post, multiple translations, single row in wp_posts.
Strengths: half the database rows compared to WPML/Polylang. Faster admin (no juggling between post translations). Cleaner permalinks if you use query params or a custom rewrite.
Weaknesses: SEO requires manual hreflang generation (which you’d do anyway on a serious site). Editorial UI needs custom work — out of the box, the WP editor only shows one set of fields, not four. ACF or custom metaboxes solve this but add complexity.
The decision framework
Strip away the feature comparisons and ask four questions:
1. Who is translating?
External agency / translation service expecting a familiar workflow → WPML. In-house bilingual team → Polylang or custom. You alone → custom is fine.
2. How structured is the content?
Frequently-changing blog posts and pages with rich variation → WPML or Polylang. Highly structured marketing site with stable sections → custom i18n is faster and lighter.
3. Is there WooCommerce?
Multi-language store with multi-currency → WPML. Multi-language store with single currency → Polylang for WooCommerce is workable. No store → either plugin or custom.
4. What’s the performance target?
Sub-1.5s LCP at the 75th percentile on mobile → custom is the only path that consistently hits it without an aggressive edge cache. WPML or Polylang with full-page caching at the edge → 2 to 3s on the first request, sub-1s on cached.
SEO considerations across all three
The plugin doesn’t excuse you from getting hreflang right. Every translated page needs reciprocal hreflang tags pointing to its siblings, plus an x-default for the language-neutral fallback. WPML and Polylang generate these automatically, but I’ve seen both produce subtly wrong output (missing one language, wrong region code, duplicated query params).
Verify in the rendered HTML, not in the plugin settings. Use the Google Search Console “International Targeting” report to catch cluster errors over time.
Canonicals deserve the same attention: each translated page should be self-canonical (it’s the canonical URL for that language version), not pointing at the original-language version. WPML and Polylang get this right by default; custom approaches need explicit work.
What I actually do
On agency projects, the default is WPML — the workflow expectations of agency clients and translation services align with how it presents.
On corporate platforms with custom architecture, Polylang or custom — depending on whether the editor team needs a per-post translation UI.
On marketing sites with highly structured content (like this one), custom i18n via a PHP array, served via ?lang=xx. Zero database queries for translations, version-controlled, deployed like code. Trade-off: editing requires touching a file, not the WP admin.
None of these choices is permanent. The migration paths between them are well-trodden: WPML → Polylang is straightforward, Polylang → custom is mechanical, and custom → either plugin is the easiest of all.
What you don’t want is the migration away from a setup that was wrong from the start because nobody asked the four questions above.
