Adding additional languages to a WordPress site touches content structure, URLs, SEO, and every plugin that renders text — it's a genuine architectural decision, not a translation task you bolt on at the end. Here's what actually differs between approaches.
The two dominant plugin approaches: WPML and Polylang
WPML is a premium, comprehensive solution with broad third-party plugin/theme compatibility (most commercial themes and plugins explicitly test against it), built-in translation management workflow (assign translators, track translation status per string), and support for professional/machine translation integrations. It's the more common choice for larger sites, agencies managing client sites, and WooCommerce stores needing multilingual product catalogs.
Polylang has a solid free tier (with a paid "Pro" version adding features like multilingual custom post type support and REST API compatibility), a simpler mental model, and is a common choice for smaller sites or teams that don't need WPML's full translation-workflow tooling. Its free tier is genuinely capable for straightforward multilingual sites; WPML's premium features earn their cost mainly at scale or with complex translation workflows.
Both plugins fundamentally do the same core thing: create a translated copy of each piece of content, linked to the original, with language switching and URL structure handled around that relationship. The differences are in ecosystem compatibility, workflow tooling, and how deep the "Pro" feature set goes.
URL structure: decide this early, it's expensive to change later
Common patterns:
- Subdirectories (
example.com/fr/) — simplest to set up, keeps everything on one domain (good for consolidated SEO authority), and what most sites should default to absent a specific reason otherwise. - Subdomains (
fr.example.com) — useful if you need genuinely separate hosting/infrastructure per language/region, but splits SEO signal more than subdirectories. - Separate domains per language/country — the heaviest option, appropriate mainly for large operations with genuinely distinct regional businesses (different legal entities, different domains already established per market), not just a language preference.
Changing URL structure after a multilingual site is live and indexed means a full redirect strategy across every translated URL — decide this up front rather than defaulting to whatever the plugin picks.
hreflang tags: the detail most multilingual sites get wrong
hreflang annotations tell search engines which URL to show a searcher based on their language/region, and prevent your translated pages from being seen as duplicate content competing against each other. Both major plugins handle this automatically for content they manage — but any content outside their scope (custom templates, some page-builder content) needs to be checked, since a missing or incorrect hreflang setup is a very common and very invisible SEO problem — the site looks fine, the tags are just wrong.
Don't rely on machine translation as the sole finishing step
Automated translation integrations are useful for a fast first draft, especially for high-volume content, but shipping unreviewed machine translation as final copy — especially for anything customer-facing like checkout flows or legal/policy pages — produces real trust and comprehension issues native speakers notice immediately. Budget for human review at least on high-visibility and transactional content.
Beyond plugins: date, currency, and RTL support
Multilingual isn't just translated strings — number formats, date formats, currency display (critical for WooCommerce), and for right-to-left languages (Arabic, Hebrew), actual layout direction all need to adapt per locale. Verify your theme has genuine RTL stylesheet support if you're adding an RTL language; not all themes do, and a translated site with a broken LTR-only layout is a worse experience than not offering that language.
The takeaway
Choose WPML for complex sites, deep third-party compatibility needs, or managed translation workflows; Polylang for simpler sites where its free tier covers what you need. Whichever you choose, decide URL structure early, verify hreflang coverage explicitly rather than assuming the plugin caught everything, and treat machine translation as a draft, not a deliverable.
