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.

PluginHow it worksWhere translations liveCost model
WPMLCreates a separate, linked copy of each post/page per languageYour databaseAnnual licence, tiered
PolylangSame duplication model, built on native WordPress taxonomiesYour databaseFree core, optional Pro
TranslatePressTranslates the rendered page, edited visually on the front endYour database (string tables)Free core, optional Pro
WeglotHosted service that serves translated versions of your pagesWeglot's cloudSubscription by words and languages
MultilingualPressOne WordPress site per language on a multisite networkEach site's own databaseAnnual 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
  • hreflang tags are output for every page, including a self-reference and x-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 builderWPML
Straightforward bilingual brochure site, developer-maintainedPolylang (free core is often enough)
The client wants to edit Arabic copy themselves, visuallyTranslatePress (with the SEO Pack)
Many languages, needed fast, subscription is acceptableWeglot
Genuinely separate content and teams per marketMultilingualPress 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

Adnan Basra

Written by Adnan Basra

Senior Web Developer & E-Commerce Manager based in Kuwait, with 13+ years building websites and driving organic growth for businesses. Get in touch →

Planning a bilingual Arabic/English site?

I'll tell you which setup fits your project — and what it will actually cost to run.

Contact Me