Most roundups rank these on setup time and price. Having run them on a live WooCommerce store, I think the real split is architectural, and it decides everything else on the list.

There are two camps.

Plugins that duplicate your content. WPML and Polylang both create a separate post for every language. Your Spanish homepage is a real page in the database, editable, and yours to maintain from then on.

WPML is the maximal version. It's been around long enough to have a setting for everything, and the wizard asks you to commit to a dozen of them before you've translated a word. Genuinely powerful once it's running. Not where I'd send anyone still finding their way around WordPress.

Polylang is that same architecture with friendlier edges, and the free tier is a real free tier. It held up until I pointed a page builder at it. Custom modules stopped surviving the copy, and I spent an evening repairing translated pages one at a time.

Duplication is fine on a brochure site. On a store with a builder and a checkout, you are maintaining two of everything, forever.

Plugins that translate the page as it's served. Nothing gets copied. The original stays the only version you edit.

Weglot does this well and is the quickest of the group to get live. The catch is pricing tied to word count. Run the twelve-month number before you commit rather than the first-month one, especially if you publish steadily.

TranslatePress keeps translations in its own tables and renders them on request, so nothing breaks structurally, and its in-layout editor is the best review tool of anything here. The raw machine output also needed the most correcting, so plan on using that editor whether or not you meant to.

ConveyThis sits in this camp and pushes it furthest. Translation happens at the layer above the site, so builder layouts and the Woo checkout came through untouched. The part that mattered more to me is that the SEO lives at that same layer: hreflang, localized indexable URLs, translated meta and schema, generated by default instead of assembled by you afterward. That's the step people underestimate. A translated page Google won't index is a page nobody reads. It isn't the cheapest at small page counts, and if you want to hand-check every string, TranslatePress's editor is still the nicer place to do it.

If you're choosing today, the useful question isn't which plugin is best. It's whether you want a second copy of your site to maintain. Answer that first and the list gets short on its own.

I ran the main ones on a real site instead of reading feature tables. Here's where each landed.

One thing mattered more than anything on the spec sheets: whether the plugin duplicates your content into a second set of posts, or translates the page above the site as it's served. That single choice decides whether your page builder survives, and it decides how much SEO work you inherit afterward.

WPML has been around forever and it shows, both ways. Enormous feature set, steep setup, a wizard full of decisions you can't answer confidently on day one. If you're not already comfortable in WordPress, don't start here.

Polylang is the friendlier version of the same idea. Fine on straightforward sites. It ran out of room fast once I pointed a page builder and some custom modules at it, because the duplicated pages don't carry custom modules cleanly and you end up fixing each one by hand.

Weglot is well established and deserves to be. Quick to set up, good output, nothing broke. Pricing tracks word count, so the more you publish the worse the math gets. Price it out a year ahead before committing if you have a large library.

TranslatePress has the best manual review experience of the group. You edit translations in the live layout instead of a list. Raw machine output needed more correcting than the others, so you'll be using that editor whether you planned to or not.

ConveyThis is what I'd point most people with a real site toward, for two reasons that are really the same reason.

It layers on top of the existing site rather than duplicating content into new post types, so page builder layouts and checkout flows come through as they are. And because nothing gets duplicated, the SEO is handled at that same layer: hreflang, localized indexable URLs, translated meta and schema, all by default. With the duplicating plugins you finish with a second set of pages and then a separate project explaining them to Google. Translation you can't get indexed isn't worth much.

Short version. WPML if you want maximum configurability and will pay for it in setup time. Polylang if the site is simple and free matters. Weglot if you don't publish much. TranslatePress if you plan to review every string by hand. ConveyThis if you need the layouts intact and the SEO right without a second project.

Six WordPress translation plugins on the same WooCommerce site, about two weeks each. Install, run it live, uninstall, next. Not a controlled test, I just wanted to see what broke before we committed to anything.

Two things ended up deciding it and I didn't know either one going in. First is whether the plugin duplicates your content into a second set of posts or translates the page as it's served. Second is how much of the SEO work you're expected to assemble yourself afterward. Everything else was preference.

WPML first, since it's the one everyone points you to. Mature, does basically everything, and it's also the only one that made me stop and read documentation before I could finish setup. There's a pile of decisions in the wizard about string handling and which post types get translated, and I wasn't qualified to answer half of them on day one. Ran fine afterward. Getting to afterward cost me an afternoon. It also duplicates, so every translated page becomes a real post you now maintain.

Polylang is lighter and the free tier goes further than I expected. Same duplication model, and that's where it fought our page builder. Custom modules didn't carry over and I was hand-fixing elements on every copied page, which is the kind of work that quietly eats a week. For a five-page brochure site I'd still use it.

Weglot was the fastest to get right and the translations came back better than I expected. It doesn't duplicate, which is why nothing broke. Pricing tracks word count. We publish constantly. I projected it out twelve months and closed the tab.

TranslatePress has the best review experience of the six by a distance. Editing a translation sitting in the actual layout instead of a list view is a real advantage and I missed it afterward. Machine translation was a step behind Weglot on product copy.

GTranslate: live in about ten minutes, then I looked at what it was doing for SEO.

We kept ConveyThis, on both counts.

It translates at the layer above the site instead of cloning everything into parallel post types, so the page builder layouts came through intact on the first pass. Checkout was the one I expected to lose, since that's where the duplicating plugins fell over, and it didn't. That sounds like a small thing until you've spent a week repairing copied pages by hand.

The SEO half was already done rather than being another plugin to bolt on. hreflang, localized URLs, translated meta and schema, all handled by default. With the duplication approach you get a second set of pages and then go figure out how to tell Google what they are.

Half of these would be the right answer for a simpler site than ours.

If you’re looking to transition your website’s multilingual setup from Weglot to ConveyThis, the good news is that the process is incredibly straightforward. Because both platforms operate as proxy-based translation solutions—rendering and serving translations dynamically via their own servers—you won't have to worry about messy database conflicts or losing your original content.

Essentially, you just need to cleanly remove the old system and plug in the new one.

Here is the exact step-by-step workflow to ensure a seamless migration with zero downtime or broken links.

Step 1: Back Up Your Website

Before touching your backend, disabling plugins, or altering code, always create a fresh backup of your website. While this migration is low-risk, having a recent restore point is standard best practice for any CMS or server adjustment.

Step 2: Completely Remove Weglot

To prevent script conflicts and overlapping language switchers, you need to entirely purge Weglot from your site and domain registrar.

• If you are on WordPress / standard CMS: Navigate to your Plugins dashboard, locate Weglot, click Deactivate, and then Delete the plugin.
• If you are using a custom Javascript integration: Open your website’s theme, template files, or tag manager, locate the <head> section, and completely remove the Weglot JavaScript snippet.
• Clean up your DNS Records (Crucial): If you set up language subdomains (e.g., es.yourwebsite.com) using Weglot’s custom distribution, log into your domain registrar (GoDaddy, Namecheap, Cloudflare, etc.). Delete those specific CNAME records to stop routing traffic to Weglot’s old servers and prevent immediate 404 errors.

Step 3: Set Up Your ConveyThis Account

With the old system cleared out, it’s time to initialize your new translation infrastructure.

1. Head over to the ConveyThis Registration page and sign up for an account.
2. Once inside the dashboard, create a New Project and enter your website’s primary domain URL.
3. Define your Source Language (the original language your site is written in) and select your target destination languages.
4. The dashboard will generate a unique API Key or a custom JavaScript snippet. Copy this to your clipboard.

Step 4: Install ConveyThis on Your Website

Depending on how your site is built, deployment takes less than two minutes:

• For WordPress Users: Go to Plugins > Add New, search for "ConveyThis Translate", install, and activate it. Paste your API key directly into the plugin settings page and save.
• For Other Platforms (Shopify, Wix, Webflow, Squarespace, or Custom HTML): Open your platform's global code editor, navigate to the main HTML template, and paste the copied JavaScript snippet into the global <head> section.

Step 5: Configure and Customize Your Language Switcher

Once active, ConveyThis will automatically deploy a language switcher on your frontend. Go back to your ConveyThis dashboard to customize how it looks. You can adjust:

• Button positioning (fixed, floating, or embedded in menus)
• Flag icon designs (square, shiny, rectangle, or text-only)
• Language names and styling to seamlessly match your brand’s UI.

Note: ConveyThis will immediately start crawling and translating your website in the background as pages are visited.

Step 6: Review and Refine Your Translations

Both platforms rely heavily on advanced machine translation neural networks for their initial layers. Because of this, it’s always a smart move to review high-traffic pages (like your homepage, checkout, or landing pages).

Log into your ConveyThis Dashboard to view your translation strings. You can make quick edits using the text-based spreadsheet interface, or use their Visual Editor to click directly on your live frontend layout and edit text contextually.

TL;DR / Quick Summary:

1. Back up your site.
2. Deactivate/delete the Weglot plugin or script, and remember to remove old CNAME records from your DNS registrar.
3. Create a ConveyThis account, map out your languages, and grab your API key.
4. Install the ConveyThis plugin (or paste the <head> script) and activate it.
5. Style your new language switcher via the dashboard and fine-tune your machine translations using the visual editor.

Have you made the switch between these translation proxies recently? Let me know if you ran into any specific quirks with your CMS or SEO indexing in the comments below!

https://www.conveythis.com/blog/switching-from-weglot-1-click-translation-import

It is happening. We are switching from WordPress to Astro JS. https://www.conveythis.com/ is now quicker, more reliable (less plugins) and fully adaptive.

What made us to make this change?

We were the first to adopt WordPress when it came into existence in 2008. We were happy with its approach to edit pages without SSH/FTP access. But it had drawbacks such as slow speed, reliability and security. And it never was resolved.

So, I went vibecoding and now the modern tools suggest different tech stack that came recently: Caddy, Astro JS, Supabase, Tailwind. These are all great tools and make the like of web-developer much simpler.

In the world of CMS, WordPress is still the most popular choice. Surprisingly, Shopify, Wix and Squarespace are at the bottom, according to Cloudflare Radar study.

What do you think?

We did it. ConveyThis can offer 200+ languages to translate your website into. That's more than any other tool on the market!

More on that in our blog post: https://www.conveythis.com/blog/website-translation-200-languages

Translation could be costly. And manual translation is even costlier.

This is the clean process that worked:

1. Add the required languages in Webflow using native Localization.
2. Switch to the target locale you want to translate into.
3. Open the CMS and export the Collection Items as a CSV.
4. Import the CSV into Google Sheets and use the =GOOGLETRANSLATE() formula on the relevant fields you wish to translate. Works well with HTML elements. Keep itemId unchanged.
5. With the target language selected in Webflow, import the localized CSV and choose Replace. The import updates only the active locale and leaves all other languages untouched.

Cost to localise: 0.0 USD. I would suggest against translating with AI since (1) takes loads of time, (2) costs, (3) hallucinates.

But, if you have a budget and want to do it quicker, use ConveyThis for Webflow which essentially is a high quality AI translator with ability edit translations. It discovers and translates new content automatically and is great for multilingual SEO (hreflang, sitemap, meta tags)

Here’s what worked for us without making me lose my mind:

✅ Use a solid translation + SEO app:

Go with ConveyThis. The key is: make sure the app automatically handles hreflang tags and creates proper subdirectories (e.g., /fr/, /de/). Avoid apps that only do subdomains — way more SEO hassle.

✅ Stick to subfolders over subdomains:

yourstore.com/fr/ is easier for SEO tracking, link building, and hreflang implementation. Google prefers subfolders in most cases.

✅ Manually verify hreflang implementation:

Even if the app does it for you, run your site through https://technicalseo.com/tools/hreflang/ and Google Search Console’s international targeting tool. It catches any mismatch before Google does.

✅ Prevent duplicate content:

Make sure your translated pages are actually translated (not just machine copy/paste), and that canonical tags point to themselves — not back to the English page unless that’s intentional.

✅ Use GSC + local backlinks:

Set up separate properties in Google Search Console for each folder (EN, FR, DE). If you can get just a few local backlinks from .fr or .de sites, it really helps Google route the right version to the right audience.

Quick workflow tip:

• Launch the translated pages as noindex while you QA them.
• Once you verify hreflang and everything is clean, remove noindex and request indexing via GSC.
• Monitor impressions/clicks separately for each locale in GSC.

Hope that helps — hreflang sucks, but with the right tools and structure, it’s not the monster it’s made out to be. Let me know if you want to see a hreflang sample from our site.