Google ends support for the old Website Translator Widget, the Select Language dropdown. Google Translate itself stays. If your site still has that widget, plan a replacement.
What’s actually ending?
Google updated its Website Translator post: that embed is unsupported from the date above. If you’re looking for a Google Translate widget alternative, the important distinction is between replacing the old dropdown and building a genuinely multilingual website. If you still need automated translation, Google points you to the Cloud API.
Google Translate is not going away. Neither is Google Cloud Translation. What’s ending is the little embed people pasted into pages so visitors could pick a language from a dropdown.
When Google briefly brought the widget back, it was mainly for government, nonprofit, academic, and other non-commercial COVID-related sites. Everyone else was already steered toward Cloud Translation. Now that website widget is hitting end of support.
Is my site still using it?
Got a Google-looking language menu? Open the source and search.
Look for either of these in your HTML or scripts:
translate.google.com/translate_a/element.js google.translate.TranslateElementNo longer supported is not the same as vanishes at midnight. Still, you don’t want a public feature sitting on unsupported code. If international visitors use that switcher, migrate early so you have time to test.
Why just using the API isn’t the same fix
Google’s answer is the Cloud Translation API. It’s solid. It’s also a different job.
The API gives you translation. Your team still has to wire up requests, storage, display, language switching, URLs, auth, billing, and CMS glue.
Setup means a Cloud project, the Translation API turned on, and credentials. You pay by usage.
If you’re building a custom product, that can be perfect.
If you just need a dropdown back on the site, building around an API is usually way more work than the old widget.
Widget vs a real multilingual setup
Changing words in the browser is only part of the job now.
Old Google widget
- Language dropdown
- Support ending
- Mostly overlays text in the browser
- No language-specific URLs or hreflang
- No built-in translation management workflow
ConveyThis
- Custom language switcher
- Actively supported platform
- Language-specific URLs
- hreflang + translated metadata
- Editor, glossary, CMS plugins

Left: temporary overlay. Right: a real language URL Google can crawl.
Google asks for separate URLs per language plus hreflang. The old widget did not provide that. A localization platform does.
| What you get | Old Google widget | ConveyThis |
|---|---|---|
| Language switcher | Yes | Yes |
| Still supported | No | Yes |
| Auto translation | Yes | Yes |
| Translation management workflow | No | Yes |
| Language-specific URLs | No | Yes |
| hreflang | No | Yes |
| Translated meta tags | No | Yes |
| Glossary / term control | No | Yes |
| CMS integrations | Embed script | WP, Shopify, Wix, Webflow+ |
| Built for multilingual SEO | No | Yes |
ConveyThis works with WordPress, Shopify, Wix, Webflow, Squarespace, and plain JavaScript sites. You get language URLs, hreflang, translated metadata, and an editor for the lines that matter.
What should I use instead?
Three common options:
Cloud Translation API
Best when you're building translation into a custom app.
Catch: you own the whole website layer.
Browser translate
Best when a visitor just needs one page right now.
Catch: not a multilingual site strategy.
ConveyThis
Best when you want translation, a switcher, and SEO together.
Catch: it's a dedicated website translation service.
Building software around translation? Cloud may be the right call.
Running a public site and wanting French or German pages that Google can rank? A website translation platform is usually closer to what people thought the old widget was doing.
Why SEO makes this more than a maintenance ticket
A translation overlay and a multilingual site are not the same thing.
Say your page is:
example.com/pricing example.com/fr/pricing example.com/de/pricingThose are real pages. Google can crawl them. They can show up for searches in that language.
Google’s own guidance is separate URLs plus hreflang so Search knows which page matches which audience.
That’s the model behind ConveyThis multilingual SEO: language URLs and hreflang, not only rewriting text on the page the visitor already opened.
So this swap can be more than fixing a broken script. It can open a real international search channel.
How to move from the Google widget to ConveyThis
You don’t need to rebuild the site.

Five steps from the old widget to a working multilingual setup.
Find the old code
Plugin, theme file, header inject, Tag Manager, custom JS. Search for the Google Translate script or selector.
Start a ConveyThis project
Pick your original language and the languages you want.
Check the important lines
Product names, buttons, legal text, pricing, top landing pages. Auto translation gets you live; a quick edit pass protects what sells.
Check SEO, then delete the widget
Look at URLs, meta, hreflang, menus, and indexability. Then remove the Google script.
Do I have to finish before the deadline?
If customers use that widget, don’t start the day before. Moving early gives you room to test translations, mobile layout, the switcher, and indexing without a last-minute scramble.
Why ConveyThis fits as a replacement
People used the Google widget for one reason: a language menu without building a localization stack. That part should stay easy.
ConveyThis finds and translates site content, gives you a switcher you can style, lets you edit and lock terminology, and publishes language versions that work for SEO. It covers 200+ languages.
Google’s free plug-and-play Website Translator Widget is reaching the end of support. You still need a next step for the site layer.
FAQ
Is the Google Translate Website Translator Widget being discontinued?
Yes. Google said support ends on the date in the deadline box above. Details are in the official Website Translator update.
Will Google Translate stop working too?
No. This is about the website widget, not Google Translate as a whole or Cloud Translation.
Will my widget die the second support ends?
Google didn’t say every install fails at a set time. They said it won’t be supported. That’s enough reason to leave it. Don’t build a customer path on unsupported code.
What does Google want me to use instead?
The Google Cloud API, if you need ongoing automated translation and you’re ready to build around it.
What’s easier if I don’t want an API project?
A website translation service like ConveyThis. It handles the switcher, translations, editing, and multilingual SEO without a custom build.
Can translated pages show up in Google Search?
Yes, if Google can crawl them. Use separate language URLs and hreflang so Search can match the right page to the right language.
Don’t wait for it to break
The Google widget made adding a language box feel easy. Sites and search moved on: you need editable copy, crawlable language URLs, and a process that keeps up when the site changes. The deadline is on the calendar. Use the time you have.
Still on the Google Translate widget?
Replace it with ConveyThis before support ends. No API project. No rebuild.
Start translating your website