Is Weglot good for SEO? It depends which mode you use — and who owns the translations

Weglot has two modes, and only one is built for SEO

Most of the confusion around “is Weglot good for SEO” comes from treating Weglot as one thing when it’s really two. In its subdirectory or subdomain integration, Weglot performs the translation server-side: the translated content is embedded directly into your page’s HTML source, so it’s fully visible and indexable, and Weglot automatically creates dedicated URLs like yoursite.com/es/ and adds hreflang tags to connect the language versions (Weglot, 2026). Used this way, Weglot follows Google’s multilingual best practices, and translated pages get indexed without extra work from you.

Its third option, the JavaScript integration, works differently: it inserts translations in the browser after the page loads. Weglot’s own documentation is refreshingly direct about this — the JavaScript integration is better suited to development, staging environments, or internal apps where SEO indexing isn’t a concern (Weglot, 2026). In other words, the company that makes Weglot tells you not to use the JavaScript mode for pages you want found. That single fact resolves most of the debate: the answer to “is Weglot good for SEO” is “yes, in the server-side mode; no, in the JavaScript mode.” The trouble is that the JavaScript snippet is the fastest to install, so it’s the one many people reach for first.

Why JavaScript-injected translations are a search risk — and invisible to AI

It’s worth being precise about why the JavaScript mode fails, because the reason has shifted in 2026. For traditional Google SEO, the picture is murkier than it used to be: Google renders JavaScript now, so it may eventually pick up client-side translations, but with the delay and unpredictability that comes with any content that only exists after scripts run — which is exactly why Weglot steers SEO-minded users to the server-side mode.

For AI search, there’s no ambiguity at all. The crawlers behind ChatGPT, Claude and Perplexity don’t execute JavaScript — a study of over 500 million crawler fetches found zero JavaScript execution (Averi, 2026). So when your translations, and the hreflang and canonical tags that go with them, are injected by script, an AI crawler receives the initial HTML, finds none of it, and either shows the wrong language or treats your pages as duplicates (Prerender, 2026). This is the same rendering gap that makes AI-built single-page sites disappear from AI answers, covered in our look at whether Lovable is good for SEO — translation tools just hit it from a different angle. The reliable rule is the one every serious multilingual source agrees on: each language must be real HTML at its own crawlable URL, present in the source before any JavaScript runs.

The URL setups that quietly kill multilingual SEO

Even without Weglot, a few structural choices sink multilingual visibility no matter how good the translation is, and they’re worth naming because they’re common defaults. The first is serving multiple languages at the same URL and switching based on a cookie or JavaScript — where yoursite.com/about shows English to one visitor and Spanish to another. Search engines can only index one version, so your translated content never appears in results, and anyone who shares the link may send visitors to the wrong language (Weglot, 2026). The second is language parameters like ?lang=es; while technically functional, Google recommends separate URLs over parameters, and crawlers often ignore or deprioritise parameterised ones (Weglot, 2026).

The correct structure is unglamorous and consistent: a distinct, crawlable URL per language — a subdirectory like /es/ is usually best because it consolidates domain authority — with reciprocal hreflang tags, translated metadata, and each version in your sitemap (Weglot, 2026). Google’s John Mueller has called hreflang one of the most complex aspects of SEO, and even experienced developers misconfigure it (Weglot, 2026), which is a good argument for building the structure in from the start rather than layering it on.

The ownership catch: you rent your translations

Here’s the part most Weglot reviews skip, and it’s the one that matters most if you think of your website as an asset. Even in the server-side mode that works well for SEO, Weglot serves your translated content from its servers on every page request. Your translations live on Weglot’s side, not yours — which means they’re rented, not owned. Stop paying, and your multilingual site stops working and you lose the translations entirely (IntlPull, 2026).

That’s a meaningfully different arrangement from tools that store translations in your own repository or database, where the translated content stays with you even after you cancel (IntlPull, 2026). It’s the multilingual version of the ownership question our pillar on owning your website runs through every hosted service: convenience now, in exchange for a dependency you can’t easily leave. For a company that has invested real money translating and localising its site, discovering that half of the asset evaporates when the subscription lapses is an unwelcome surprise — and an avoidable one.

The pricing catch: two caps at once

There’s a practical cost dimension too. Weglot caps every plan on two axes simultaneously — a fixed word count and a hard language limit — so growing into one more language or one more region can double or quadruple your bill overnight (Verbi, 2026). That’s the single biggest hidden cost in the category, and it’s easy to miss during evaluation because the entry price looks reasonable. It’s not a reason to avoid Weglot outright — the tool is genuinely polished and fast to set up, which is why it has over a hundred thousand customers — but it’s a reason to model your two-year cost across all the languages you actually plan to add, not only the first one.

What owned multilingual SEO looks like

Set against all this, the alternative is straightforward, and it’s what we build. Each language is its own real, crawlable HTML page — yoursite.com/en/… and yoursite.com/es/… — with the translated text baked directly into the source, reciprocal hreflang tags in the head, translated titles and meta descriptions, and every version in the sitemap. Because the content is static HTML, it’s visible to Google, to the AI crawlers behind ChatGPT and Perplexity, and to a visitor with JavaScript disabled, with no rendering step to wait on and nothing injected after load.

And because the translations live in the site you own rather than on a vendor’s servers, they don’t disappear if you change providers or stop a subscription. This site is the working example: it’s fully bilingual, every page has a real counterpart at a mirrored URL, the hreflang is reciprocal in the source, and the Spanish is transcreated rather than machine-swapped — adapted for the reader, not word-substituted. That’s the structure our guide on being readable by AI treats as the baseline for any site meant to be found in more than one language.

What we’d tell you

If you’re already on Weglot and it’s working, the advice is simple: confirm you’re on the subdirectory or subdomain (server-side) integration, not the JavaScript one, for any page you want found — you can check by viewing your page source and confirming the translated text is there before any script runs. Fix any same-URL or ?lang= setups. And go in clear-eyed about the two things reviews gloss over: your translations are rented, and your price scales on two axes as you add languages.

If you’re choosing now and multilingual reach is core to the business, weigh whether renting your translations is a trade you want to make for the convenience, or whether owning them — in a site built to serve real HTML per language from the start — is worth building once. Weglot is a good tool used the right way; it’s simply not the only way, and for a site where the translated content is a long-term asset rather than a quick add-on, ownership changes the math. Either way, the non-negotiables are the same: real URLs per language, reciprocal hreflang in the source, and content a machine can read before it runs a single line of JavaScript.