Replacing the Google Translate Widget: Alternative Website Translation for Site Owners

As of Oct 1st, 2026, Google officially retired its Google Translate Website translator, and it has no clean replacement. For years, the widget was the easiest translation option around. It was a free JavaScript snippet that added a machine-translation overlay to webpages, offering more than 100 languages through a dropdown menu.

Before Google started phasing the widget out around 2020 (limiting new sign-ups and commercial access to the widget), all you needed to get started was to create a Google Account, register your site’s URL in the Google Translate developer console, and paste a generated script tag into your page. The script rendered a small dropdown widget on the page, and when a visitor picked a language, it ran the visible text through Google’s translation engine in the browser. No new server changes and no new pages were needed; it was simply an overlay.

Why the widget ended

According to Google's own developer blog, Google started winding the widget down around 2020. It closed new sign-ups for general commercial use, then reopened access only to "government, non-profit, and/or non-commercial websites... that focus on COVID-19 response."

Commercial sites that already had the widget were allowed to keep it until the October 1, 2026 cutoff. That date has now passed.

Google hasn’t given a detailed reason for phasing out the free widget, but it has pointed users to their built-in browser translation and site owners to its paid Cloud Translation API.

Why is Chrome still translating my site?

Google still offers two different translation solutions that both do different things. The widget they’ve phased out, however, was different from both their existing browser auto-translate and the Google Translate app.

The Website Translator widget was their JavaScript embed described above. It was code you added to your own site.

They still offer browser auto-translation, built into Chrome and other Chromium-based browsers, and it doesn't require installing anything. Chrome detects a page's language and offers to translate it for the visitor. That's why some visitors see a translation prompt on your site even though you never installed a widget.

It's also why the prompt sometimes doesn't show up. Translation detection relies on language signals in the page, things like the lang attribute or the visible text itself. Pages with mixed language or heavy JavaScript rendering can confuse it.

Separate from both the widget and auto-translate is the Google Translate app. People use it on a phone or desktop to translate text, speech, photos, and conversations. It has nothing to do with embedding translation into a website.

If you want visitors to be able to translate your pages themselves, browser auto-translate already does that for free. But if you want your site to show up in another language, with control over the wording and pages that search engines can find, none of these three will do that job.

The widget never helped your SEO

Although convenient (and free), the widget was never a genuine localization solution because it translated only what the visitor saw in the moment and not the underlying page.

Google's crawler only ever saw your original language. There was no Spanish URL, no French URL, nothing separate to index or submit to Search Console.

For a business trying to reach an international audience, this was a problem. If a French-speaking user searched in French, your site did not have a French URL for that query to surface. The widget helped people who had already landed on your site. Unfortunately, it did nothing to help new people find you.

What to use instead

For a commercial site, the options break down like this:

• Browser auto-translate and extensions. Free, and fine for visitors who want them. But you can't control the output, and search engines never see it.
• The Google Translate app. It’s useful for a person translating on their own device, but it’s not a substitute for your site presenting itself in another language.
• Google Translate API (Cloud Translation). A developer-facing service you can call directly. It gives translation quality similar to what the widget used, but you build everything around it yourself, including which pages get translated, where the translated text lives, how URLs and metadata work, and how someone reviews it before it goes live.
• Website localization platforms. These sit between your site and a translation engine. They handle the URL structure, the review process, and upkeep as your content changes.

Bablic: a snippet install with more control

Bablic is a website localization platform that uses machine translation too. The difference is how much control you have over the result.

Setup will feel familiar. You add one JavaScript snippet to your page's <head>, with no server changes. New projects start in Private Mode, so installing the snippet doesn't make anything public. You review the translated pages first and then decide when to go live. After that, the script swaps in translated text each time a page loads, and a language selector takes the place of the old dropdown.

The first thing most people notice with machine translation is that it translates things it shouldn't, like the company name. That's what the glossary is for. You list the terms that should stay as they are, such as brand names, product names, and addresses, and set how specific phrases should read every time they appear.

If there is a whole section you want left alone, you add a CSS class to the element, and Bablic skips it. These are called No Translate Rules.

When a translation reads wrong, anyone on your team who speaks the language can fix it in the in-context visual editor. They open the translated page as a visitor would see it and change the wording, instead of working through a spreadsheet of strings.

For sites that need full professional review rather than machine translation with spot-checks, a dedicated localization service is going to be more useful. It's a different budget and a different timeline, so it helps to know which one you need before you commit.

How to move off the widget

1. Assume it can break any day. Google isn't fixing it anymore, and if your site is commercial, you've been outside its terms for a while.
2. Decide what you need. Letting visitors translate a page themselves is not the same as having French pages that rank in French search results. Most commercial sites need the second one.
3. Choose the layer as well as the engine. Translation engines are fairly interchangeable. What’s more important is who manages URLs, reviews, and exclusions.
4. Plan your language selector before you launch. Where the switcher sits and how it's labeled affects whether people use it.
5. Track it like any other traffic channel. Once translated pages are live, measure them the way you'd measure any acquisition channel. Our website translation ROI guide covers what to track.

None of this requires rebuilding a site. It requires replacing a snippet that no longer works with one that's built to keep working and to be found.

What Bablic costs

Bablic's free trial ends after 30 days or after 500,000 translated words, whichever comes first. You don't need a credit card to sign up. You only add a payment method in order to upgrade, either during the trial for features it doesn't include, or afterward to keep your translated site live.

If you're weighing this against building on Google's Cloud Translation API, keep in mind that the engineering time usually costs more than a subscription. Our translation cost per word piece walks through the numbers at different volumes.

FAQ

How do I add Google Translate as a widget? Historically, this meant registering your site's URL with Google's Website Translator tool and pasting a generated script into your page, which rendered a language dropdown. That stopped being supported on October 1, 2026, per Google's own confirmation. So for anything commercial, a maintained website translation platform is the current answer instead.

Is there a translation widget on the iPhone? Not in the sense of a website embed. On iPhone, translation happens through the Google Translate app itself, or through Safari's built-in translation feature, which works similarly to Chrome's browser-level auto-translate: it detects the page's language and offers to translate it for that visitor, without any code added by the site owner.

Does the widget work offline or require internet? The website widget always required an internet connection, since the translation call happened live, in the browser, against Google's translation service each time a visitor selected a language. The separate Google Translate mobile app does support offline use for some language pairs via downloaded language packs, but that's a different product from the website embed.

Why does Chrome sometimes fail to offer translation for certain sites? Chrome's built-in auto-translate relies on detecting the page's language from signals like the lang HTML attribute and the visible text itself. Pages with missing or incorrect language metadata, heavily mixed-language content, or text rendered late via JavaScript can confuse that detection, which is why the translate prompt doesn't always appear even on sites that need it.

Can you customize what language pairs the widget supports? The classic widget let site owners choose which languages appeared in the dropdown from Google's supported list, but that was the extent of the control: no way to exclude specific phrases, override terminology, or review translations before visitors saw them. Platforms built for business use, including Bablic's glossary and no-translate rules, extend that control considerably further.