WPML and Weglot both make a WordPress site multilingual, and they differ in one structural way that causes every other difference between them: WPML stores your translations in your own WordPress database, and Weglot renders them on its servers. Setup effort, editing workflow, the shape of the bill and what you keep if you stop paying all follow from that. WPML suits teams who want control and ownership; Weglot suits teams who want coverage fast without staffing it.
One thing to notice before reading any comparison of these two, including this one: the two highest-ranking comparisons of WPML and Weglot are published by WPML and by Weglot. Most of the rest earn a commission on the click.
Working through itBecause of who publishes them. Search for this comparison and the top two results are wpml.org's page about Weglot and weglot.com's page about WPML. Below those sit affiliate sites that earn a referral fee when you buy. That does not make any of them dishonest, and several are genuinely thorough, but it does mean the framing is never neutral: each vendor's page presents its own architecture as the sensible default and the other's as a complication.
It is a thirty-second thing to verify yourself, and it changes how you read everything else. We sell a managed localisation service, so we have a stake too. Ours is not in which of these two you choose, which is why this page declines to pick one.
WPML is a self-hosted WordPress plugin: your translated content is written into your own WordPress database and served by your own site. Weglot is a hosted service: it reads the HTML your site renders, translates it on its own infrastructure, and serves the translated version from there. Everything else in this comparison is a consequence.
Because WPML lives in your database, it gives you granular control over every URL slug, meta description and alt tag, and it can reach content a rendered-HTML approach cannot see. That control comes with setup: WPML is several plugins rather than one, with core translation, String Translation for text outside posts and pages, and Translation Management among them. Both vendors agree on this fact and disagree entirely on whether it is a burden or a feature.
Because Weglot works on rendered output, installation is close to instant: connect it, and the whole site is translated in a first pass within minutes, drawing on DeepL, Microsoft, Yandex or Google depending on the language pair, which you then refine in a visual editor with live preview. Weglot states that two-thirds of its customers never edit their translated content at all, which is its own figure rather than an independent finding, and tells you the workflow is designed around not needing to.
They are not priced on the same axis, which is why feature tables cannot answer this. WPML sells fixed annual licences: Multilingual Blog at €39, Multilingual CMS at €99 and Multilingual Agency at €199 per year, the last two including 90,000 and 180,000 AI translation credits respectively. Weglot sells a subscription that scales with translated words multiplied by the number of languages, from a free tier of 2,000 words in one language and paid plans from about €15 per month billed annually.
The detail that makes WPML's number legible, and which almost nothing in this SERP explains, is that a credit is not a word. WPML consumes 2 credits per word for Google or DeepL, 1 credit for Azure, and 4 credits for its own PTC engine. So a 90,000-credit allowance is roughly 45,000 words through DeepL, or 22,500 through PTC. Size your catalogue in words, pick your engine, and the annual licence resolves into a real number.
| WPML | Weglot | |
|---|---|---|
| Pricing axis | Fixed annual licence | Translated words × languages |
| Entry price | €39/yr (Blog), €99/yr (CMS) | Free tier 2,000 words; from about €15/mo annually |
| What scales the bill | Nothing, until credits run out | Catalogue size and language count, together |
| Translation allowance | 90,000 credits on CMS; 1 to 4 credits per word by engine | Word ceiling per tier, fixed rather than monthly refill |
| Where translations live | Your WordPress database | Weglot's servers |
| Setup | Several plugins, granular control | One connection, whole site in minutes |
The crossover is straightforward once stated: a large or fast-growing catalogue in several languages favours the fixed licence, and a contained site in a small number of languages where you value the editing workflow favours the subscription. Estimate your translated word count and your final language list, then price both against those numbers rather than against a feature list.
This is the question each vendor answers only in the half that flatters it, and the two halves together are the honest picture. Stop paying WPML and your translations remain where they always were, in your WordPress database, serving normally; you lose updates and support rather than your content. Stop paying Weglot and the translated pages stop serving, because they were being rendered by a service you are no longer subscribed to. An export is offered.
Neither is a defect. They are the terms of two different models, and the hosted model buys speed and zero maintenance with a dependency. The mistake is not choosing one, it is choosing without knowing which you chose. If you expect to run this for five years, ask yourself which of those two positions you would rather be in during a budget review.
Yes, both do. Each serves translated pages server-side on dedicated URLs with hreflang tags, which is what allows search engines to crawl, index and rank each language version separately. Claims to the contrary about either product are worth checking against the vendor's documentation before you act on them, because this is the point the category most often gets wrong about whichever tool it is not selling.
Where they differ is in control rather than capability. WPML lets you hand-edit every slug, meta description and alt tag, which matters if you run a deliberate per-market keyword strategy. Weglot automates the same fields, with URL translation available on its higher tiers. A comparable point comes up between other plugins in this space, and our read of how GTranslate and Weglot compare on WordPress works through the same parity question in more depth.
A store is a harder case than a website, in three specific ways that general WordPress comparisons skip. Product variations and attributes multiply the string count well beyond what a page count suggests. The catalogue turns over, so translation is recurring work rather than a launch task, and on a metered model that churn is what consumes your allowance. And content that never renders to a public page, notably WooCommerce transactional emails such as order and shipping notifications, sits outside what a rendered-HTML approach can reach, which is a structural property of the model rather than a bug.
The practical consequence is that a WooCommerce store should size both options against its real product data rather than its page count, and should check specifically how transactional email gets translated, because that is the gap a customer notices immediately after paying you.
Read it off your own site rather than off a verdict.
Both are tools your team operates. Somebody owns the glossary, reviews the machine output, checks that this week's products came through, and notices when a page is half-translated. At two languages that is minor. At six languages with weekly drops it is a standing job, and it appears on no invoice, which is exactly why it never enters the comparison.
The managed alternative moves the work rather than the tooling: you add a product on your source store and it is live in every language without anyone touching it, with AI translation refined by models specialised per language and reviewed by human proofreaders. Whether that is worth it depends on how much your catalogue moves. For scale: in live 50/50 A/B tests across more than 40 merchants and 50 site and country combinations, translated stores lifted conversion by an average of 40% at launch, individual results from 15% to 100%, measured against an untranslated experience in the same market. The guide to ecommerce translation sets out the four routes, and managed ecommerce localisation is what the fourth one looks like.
Neither is better outright. WPML reaches content in your database, including strings a rendered-HTML approach cannot see, and suits stores wanting per-market SEO control. Weglot gets a large catalogue live faster with less setup. Size both against your product data rather than your page count.
It depends on catalogue size and language count. WPML is a fixed annual licence from €39, with AI credits consumed at 1 to 4 per word depending on engine. Weglot scales with translated words multiplied by languages. A large multilingual catalogue usually favours WPML; a contained site can be comparable on either.
Translations are hosted on Weglot's servers and an export is offered, but the translated pages stop serving if the subscription ends. WPML writes translations into your own WordPress database, where they remain either way. That is a difference of model, not of quality.
Storing translations in your own database adds load, and large multilingual sites usually want decent hosting and caching. Weglot serves from its own infrastructure, so that load sits elsewhere. Both trade-offs are manageable; neither is a reason on its own.
Weglot offers an export, but moving that data into another plugin's structure is not a one-click job. If you expect to change tools later, starting in your own database avoids the migration entirely.
Yes. Both serve translated pages server-side on dedicated URLs with hreflang tags, so search engines can index each language version separately. WPML gives you more manual control over the SEO fields; Weglot automates them.
Not a third column in the table above. If the plugin is fine and the upkeep is not, see what it looks like when the operating work moves.
See your store localised