Quick answer: WPML and Polylang are the two most common ways to run a multilingual WordPress site. WPML is a paid suite with deep features for complex sites and WooCommerce. Polylang offers a free core plugin with paid Pro upgrades, often lighter to start. Both let you translate posts, pages, taxonomies and menus. Pick WPML when you need mature ecommerce and translation-management integrations; pick Polylang when you want a simpler start and are comfortable assembling add-ons.
What multilingual WordPress actually involves
A second language is not a Google Translate widget. Proper setups include:
- Translated content for pages, posts and key custom types
- Language switcher UX that does not strand users
- URL strategy (directories, domains or parameters)
- Menu, widget and media decisions per language
- SEO: hreflang, localised metadata, separate sitemaps as needed
- Forms, emails and legal pages in each language
Plugins help with structure. Humans (or professional translators) still supply quality wording. Machine translation can draft, but review matters for anything customer-facing.
WPML overview
WPML (WordPress Multilingual Plugin) is a commercial product with tiers. Typical strengths by early 2020:
- Broad compatibility marketing and long market presence
- Translation management tools and agency workflows
- WooCommerce multilingual extensions
- Support for many page builders with varying smoothness
- Sticky links between translations
Costs are ongoing subscriptions depending on tier. For shops and large content sites, the fee is often smaller than the labour of a brittle free stack. Review performance after install; any multilingual plugin adds queries and complexity. Pair with WordPress speed optimization habits.
Polylang overview
Polylang’s free version covers core translation relationships for posts, pages, categories, tags and menus. Polylang Pro adds features such as URL options, shared slugs across languages, improved duplicate workflows and priority support depending on the offer at purchase time. Lingotek and other services have partnered historically for translation.
Polylang is popular for brochure sites and publishers who want less plugin weight. WooCommerce support typically needs Polylang Pro / WooCommerce-related add-ons; verify current packages before promising a shop client a free-only stack.
Feature comparison (practical view)
| Topic | WPML | Polylang |
|---|---|---|
| Core cost | Paid tiers | Free core + paid Pro |
| Beginner brochure site | Capable | Excellent fit |
| Complex / WooCommerce | Strong ecosystem | Possible with Pro/add-ons |
| Translation agencies | Mature workflows | More DIY / integrations |
| Performance footprint | Heavier on big sites | Often lighter if kept lean |
| Learning curve | Admin UI is broad | Generally simpler UI |
Always test your actual theme and builders on a staging site. Compatibility anecdotes go stale when page builders update.
URL strategies
Common patterns:
- Directories:
example.com/fr/page/(often simplest) - Subdomains:
fr.example.com - Separate domains:
example.fr
Directories keep authority concentrated. Separate domains suit legal entities and strong local brands but need more SEO work. Decide before you invent hundreds of URLs. WordPress permalinks choices interact with language directories; plan carefully and avoid changing structures after launch without redirects.
SEO checklist for either plugin
- Unique titles and meta descriptions per language
- Correct hreflang implementation (plugin settings + verification in Search Console)
- Localised sitemap entries
- Translated slugs that read naturally (not always word-for-word)
- Avoid auto-redirecting users solely by IP in ways that block Googlebot from language variants
- Separate Google My Business style local profiles when locations differ by country, independent of the plugin choice
Translation workflow tips
- Freeze source language structure before mass translation
- Translate high intent pages first (home, services, contact, checkout)
- Keep a glossary for product names that must not be translated
- Assign reviewers who speak the target language in context (legal vs marketing tone)
- Re-translate when source pages change; stale mixes of languages erode trust
Custom post types need explicit configuration in both ecosystems; see custom post types if your site depends on them.
Performance and hosting
Multilingual sites multiply content and sometimes media. Use caching that understands language cookies or URL prefixes. Object cache helps on bigger installs. Hosting for WordPress development projects should include staging so you can test language switchers before go-live.
When to choose which
Choose WPML if you run WooCommerce across languages, need established translation management, or your agency already standardises on it.
Choose Polylang if you want a free or lower-cost start on a marketing site, prefer a lighter admin feel, and your feature list fits free + Pro without exotic requirements.
Consider alternatives (TranslatePress, MultilingualPress, fully separate sites) when your constraints differ: visual inline translation, multisite networks, or strict separation by country legal entities.
Media and attachments
Decide whether images are shared across languages or duplicated. Shared media is simpler; duplicated media helps when screenshots include text that must be localised. Alt text needs translation either way. Large media libraries multiply backup sizes on multilingual shops; budget storage.
Forms and notifications
Contact forms must deliver in the right language and route to teams that can reply in that language. Translating the form UI without translating notification emails produces a poor handoff. Test each language path fully, including autoresponders.
Language switcher UX
Place the switcher where users expect it (header). Sending someone from a deep translated article to the home page of another language frustrates them; prefer linked translations of the same page. When a translation is missing, fall back honestly rather than showing a random page.
Editor training
Authors need a short guide: how to create a translation, what not to copy-paste from machine tools and how to mark content ready for review. Most multilingual failures are process failures, not plugin bugs.
Extra practical notes
Take a day to write down your current process before changing tools or structures. The written process reveals which steps are real and which are habit. Share the draft with the people who do the work daily; they will correct assumptions faster than any vendor demo.
After you ship a change, schedule a two-week check: did the metric you cared about move, and did any new failure mode appear? Keep a short changelog so future you knows what was attempted.
WooCommerce specifics
For shops, translate product content, categories, attributes that appear storefront-side and critical emails. Shipping classes and tax configuration may stay global depending on how you sell. Test a full purchase in each language including payment gateway redirects. Abandoned cart emails should match the language of the browse session when possible.
FAQ
Can I switch from Polylang to WPML later?
Migration tools and services exist but are never push-button perfect. Choose carefully up front when possible.
Is machine translation enough?
For internal drafts maybe. For customer-facing pages, budget human review.
Do I need a second domain for each language?
No. Directories on one domain are a solid default for many businesses.
Will multilingual plugins break my theme?
They can strain poorly coded themes. Test menus, widgets and page builder templates per language on staging.
Pick the plugin that matches the workload
WPML vs Polylang is less about a universal winner and more about shop complexity, budget and workflow. Prototype on staging with your real theme before you buy annual licences in bulk. If you want a multilingual WordPress site planned and built properly, see our Turn visitors into customers service.
