Almost every WordPress project I take on in Kuwait needs two languages: Arabic and English. The question that decides how the whole build goes isn't "should we be bilingual" — it's which multilingual plugin you commit to, because that choice shapes your URLs, your database, your page speed, and how painful it is to change your mind two years later.
Here's an honest comparison of the main options — WPML, Polylang, TranslatePress and Weglot — based on how they actually behave on client sites, not on their feature pages.
First, understand the four different models
These plugins are often compared feature by feature, which hides the thing that matters most: they work in fundamentally different ways. Get this part right and the rest of the decision follows.
| Plugin | How it works | Where translations live | Cost model |
|---|---|---|---|
| WPML | Creates a separate, linked copy of each post/page per language | Your database | Annual licence, tiered |
| Polylang | Same duplication model, built on native WordPress taxonomies | Your database | Free core, optional Pro |
| TranslatePress | Translates the rendered page, edited visually on the front end | Your database (string tables) | Free core, optional Pro |
| Weglot | Hosted service that serves translated versions of your pages | Weglot's cloud | Subscription by words and languages |
| MultilingualPress | One WordPress site per language on a multisite network | Each site's own database | Annual licence |
The practical consequence: with WPML, Polylang and TranslatePress your translations are yours, sitting in your database. With Weglot they live on someone else's platform, and if you stop paying, the translated versions of your pages stop existing. That single difference matters more over a three-year horizon than any feature list.
WPML — the mature option, and usually the safe one
WPML has been the default for serious bilingual WordPress builds for years, and the reason is boring but important: compatibility. Page builders, WooCommerce, custom fields, form plugins, membership plugins — WPML has spent a decade making sure they translate properly, and it maintains dedicated add-ons for the big ones.
On a corporate site with custom post types, ACF fields, a page builder and a store, WPML is the option least likely to produce something broken at 11pm before launch.
Where it bites: it's paid-only — no free tier to test on a small project. The entry tier is deliberately limited; for String Translation (translating theme and plugin text), WooCommerce and custom fields, you generally need the CMS-level licence. It also adds real weight — extra database tables and queries — so on cheap shared hosting an unoptimised WPML site can feel sluggish. Caching and a decent host solve it, but you should budget for both.
Polylang — light, free to start, more hands-on
Polylang uses the same duplicate-per-language model as WPML but is built on native WordPress taxonomies, which makes it lighter and, in my experience, faster on modest hosting. The free version on WordPress.org is genuinely usable for a straightforward bilingual brochure site — which is exactly what a lot of Kuwaiti businesses actually need.
Where it bites: fewer official integrations. WooCommerce support requires a separate paid add-on, and some page builders and plugins need more manual work to translate cleanly. There's more configuring and less hand-holding — fine if a developer is managing the site, frustrating if the client is doing it themselves.
TranslatePress — the one clients can actually use
TranslatePress translates what's rendered on the page, and you edit it by clicking directly on text in a live preview of your site. For a client who wants to fix their own Arabic copy without learning the WordPress admin, nothing else comes close for usability. It also handles text that other plugins struggle with, because it works on the output rather than the database record.
The free version supports one additional language — perfect for Arabic + English — and it can pre-translate with DeepL or Google Translate, giving you a draft to correct rather than a blank page.
Where it bites: the SEO essentials — translated slugs, meta titles and descriptions, hreflang — sit in the paid SEO Pack. For a bilingual site that needs to rank, that's not optional, so treat the Pro licence as the real price. The string tables also grow with your content, so keep an eye on database size on large sites.
Weglot — fastest to launch, most expensive to keep
Weglot is the quickest path from monolingual to multilingual: connect it, and it detects your content, machine-translates it, and serves translated pages on their infrastructure with hreflang handled for you. If you need five languages live next week, it's very hard to beat.
Where it bites: billing scales with translated word count and traffic tier, so the cost grows as your site grows — usually overtaking a one-off annual licence on a content-heavy site. And because the translations live on Weglot's platform rather than in your database, leaving means re-doing the work. It's a rental, not a purchase. That's a fair trade for speed and low maintenance — as long as you make it knowingly.
A note on the free translation widgets
Tools that drop a Google Translate–style dropdown onto your site — GTranslate's free mode and similar — translate in the browser without creating real pages. There's no separate URL for the Arabic version, so there's nothing for Google to index. Your Arabic content will not rank, because as far as search engines are concerned it doesn't exist. If the goal is visibility rather than convenience for someone already on the site, this is not a solution.
The Arabic problem no plugin solves for you
This is where most bilingual Kuwaiti sites go wrong, and it has nothing to do with which plugin you picked.
- RTL is a theme problem, not a plugin problem. The plugin switches the language and sets the direction; whether your layout actually mirrors correctly depends on your theme shipping proper RTL styles. Test menus, sliders, forms, icons and anything with an arrow before you promise a launch date.
- Machine-translated Arabic reads as machine-translated. It's fine as a first draft to edit. Published untouched on a corporate site, it quietly costs you credibility with exactly the audience you built it for.
- Arabic fonts are heavy. A full Arabic webfont can be several hundred kilobytes. Subset it and use
font-display: swap, or your Arabic pages will be measurably slower than your English ones. - Translating your keywords isn't Arabic keyword research. The literal Arabic translation of your best English keyword is often not what people actually type. I've covered this in detail in bilingual Arabic/English SEO in Kuwait — it's the most commonly skipped step, and the most valuable one.
The SEO checklist that applies whichever plugin you choose
Before you sign off on a bilingual build, confirm all six of these. Any decent setup can do them; a careless one does none.
- Each language has its own crawlable URL — a
/ar/subdirectory is the simplest structure to keep authority in one place hreflangtags are output for every page, including a self-reference andx-default- Slugs, meta titles, meta descriptions and image alt text are translated — not just body copy
- The language switcher is a real
<a>link, not a JavaScript-only control a crawler can't follow - Your XML sitemap contains both language versions
- You are not auto-redirecting visitors by IP address — Googlebot usually crawls from the US and will only ever see your English site
What it costs over three years
Licence prices change, so check current pricing before you buy — but the shape of the cost is stable. WPML, Polylang Pro and TranslatePress Pro all sit in the same broad band of roughly a hundred to a couple of hundred US dollars per year for a single site, and renewals are usually discounted. Weglot is billed on translated words and traffic, which means a small brochure site can be cheap while a growing content site keeps climbing tiers.
For a two-language site you intend to keep for years, the database-owned options are almost always cheaper in total — and you keep the translations at the end of it.
So which one should you use?
| If this is your situation… | Start with |
|---|---|
| Corporate site with WooCommerce, custom fields or a page builder | WPML |
| Straightforward bilingual brochure site, developer-maintained | Polylang (free core is often enough) |
| The client wants to edit Arabic copy themselves, visually | TranslatePress (with the SEO Pack) |
| Many languages, needed fast, subscription is acceptable | Weglot |
| Genuinely separate content and teams per market | MultilingualPress on multisite |
If you're switching from one to another
Migrating between multilingual plugins is a real project, not a plugin swap. Each one stores translations differently, so there's no clean export path between them — expect to move content manually or rebuild it. Whatever you do, keep your existing URLs or 301-redirect every one of them, because your Arabic pages have their own rankings and backlinks, and losing them is how a redesign quietly costs you traffic.
The bottom line
There's no best multilingual plugin — there's the one that matches your stack, your budget model, and who's going to maintain the site. WPML if compatibility matters most, Polylang if you want light and cheap, TranslatePress if the client edits their own copy, Weglot if speed beats ownership.
What actually determines whether a bilingual site succeeds is the part underneath: proper URLs, correct hreflang, real Arabic keyword research, and a theme that handles RTL without falling apart. I build bilingual Arabic/English sites as part of my web development work in Kuwait, with the SEO set up correctly from the start. If you're weighing this decision for your own site — or already regretting one — feel free to get in touch.
Related reading
Related services
Planning a bilingual Arabic/English site?
I'll tell you which setup fits your project — and what it will actually cost to run.