Multilingual WordPress: WPML vs Polylang Setup Guide

Every few weeks a customer writes in with some version of the same request: "we added a Hindi (or Spanish, or Arabic) version of our WordPress site and now something's broken." Usually it's WPML or Polylang, usually the plugin itself is fine, and usually the real issue is how it was set up. Here's what actually goes wrong and how to fix it.

The symptoms customers report

Multilingual WordPress problems rarely show up as a clean error message. They show up as:

• Google Search Console flagging the English and translated pages as duplicate content
• The language switcher missing from the menu after a theme or plugin update
• Elementor or Divi pages that "translate" but still show the original English text in a few sections
• WooCommerce checkout breaking or showing prices in the wrong currency on the translated store
• wp-admin getting noticeably slower once a third or fourth language is added

None of these are bugs in WPML or Polylang specifically. They're what happens when a multilingual plugin gets bolted onto a site that wasn't built with translation in mind — or when the setup skipped a step that only becomes a problem months later.

Why it happens

Both plugins work by treating each translation as its own post, linked back to the original through a table (icl_translations for WPML, term_relationships tied to a hidden language taxonomy for Polylang). That approach is solid, but it depends on every other plugin and theme cooperating with it.

Three things break that cooperation most often:

• Page builders storing content outside normal post fields. Elementor and Divi save layout data as one big serialized blob. If "Translate Everything" (Elementor) or the equivalent isn't turned on, the translation plugin never sees the text inside that blob — so only the title translates, not the content.
• Caching serving the wrong language to Google. Full-page cache plugins that don't vary the cache key by language cookie will happily serve an English page to Googlebot when it requests /hi/, which is exactly what triggers duplicate-content flags.
• Missing or wrong hreflang tags. Both plugins add hreflang automatically, but if a caching layer strips headers or an SEO plugin adds a conflicting canonical tag, search engines get confused about which page is which.

WPML vs Polylang: which one fits your site

We get asked this constantly, so here's the short version we actually give customers:

If you're running a small business site with two or three languages and want to keep hosting costs down, Polylang is usually the better call. If you're translating a WooCommerce store with a real content team, WPML's workflow tools pay for themselves.

Setting up WPML without the common mistakes

1. Install WPML, then run the setup wizard and pick your language pairs — don't add languages "just in case," each one adds overhead.
2. Under WPML → Translation Management, decide upfront whether you're translating manually, sending content to a service, or using automatic translation. Mixing methods later gets messy.
3. Go to WPML → Theme and Plugins Localization and run "Strings translation scan" — this is the step people skip, and it's why menu items, widget titles, and theme text stay in English.
4. If you use Elementor, enable WPML → Settings → Translate Elementor content so the page builder data itself gets scanned.
5. Confirm your SEO plugin (Yoast or Rank Math) is WPML-aware — both have official integrations that stop duplicate canonical/hreflang conflicts.

Setting up Polylang without the common mistakes

1. Install Polylang, add your languages under Languages → Languages, and set one as the default.
2. Assign a language to every existing post, page, and menu — Polylang won't auto-guess, so anything untagged silently stays out of the language switcher.
3. Rebuild your navigation menus per language under Appearance → Menus. This is the step that gets missed after a theme switch, which is why the switcher "disappears."
4. For Elementor users, install the free Polylang connector or manually duplicate widget-level text — Polylang's free tier doesn't scan builder data as thoroughly as WPML does.
5. If you sell products, budget for Polylang Pro + Polylang for WooCommerce rather than trying to force the free version to handle variable products across languages.

Fixing the breakages you're probably dealing with right now

Language switcher missing after an update

This is almost always a menu location that didn't carry over. Go to Appearance → Menus, check that each language has its own menu assigned to the theme's primary location, and re-save. If you're on WPML, also check WPML → Languages → Language Switcher Options to confirm it's still set to display.

Elementor content not translating

Check WPML → Settings (or your Polylang connector settings) for "Translate Elementor content" or equivalent. If it's on and content still isn't picked up, clear the Elementor CSS cache from Elementor → Tools → Regenerate Files after retranslating — stale cached CSS/HTML can mask a successful translation.

Google flagging duplicate content

Pull up your live source with curl and confirm hreflang tags are actually present:

curl -s https://yourdomain.com/hi/ | grep hreflang

You should see one <link rel="alternate" hreflang="..."> tag per language plus an x-default. If they're missing, your cache is likely serving a stale version — purge LiteSpeed/WP Rocket/Cloudflare cache and re-check. If they're present but Search Console still complains, give it 2-3 weeks; hreflang re-indexing isn't instant.

wp-admin slowing down with more languages

Each additional language roughly multiplies your post count in the database. On shared cPanel hosting this shows up as slow admin screens once you pass 3-4 languages on a content-heavy site. Two fixes: switch to object caching (Redis, if your plan supports it) to cut repeated query load, or move to a VPS where you control PHP memory and MySQL tuning directly.

Preventing this the next time you add a language

• Take a full backup before installing WPML or Polylang — translation plugins touch nearly every table in the database.
• Add one language at a time and test the switcher, checkout, and SEO tags before adding the next.
• Re-test after every theme or page builder update — this is the single most common trigger for "the switcher disappeared."
• Keep an eye on Search Console's International Targeting report monthly, not just when something looks broken.
• If your store is growing past two languages, budget for the Pro/WooCommerce add-ons upfront rather than patching the free tier.

Multilingual WordPress isn't fragile by design — it just has more moving parts than a single-language site, and each part needs to be checked once rather than assumed. Get the setup right the first time and the maintenance afterward is minor.