TranslatePress It did a great job for the first six months. After that, two years of actual use On my WordPress site, my opinion is clearly negative.
I can't recommend it to you as it stands, and I'll explain why.
I installed this multilingual translation plugin in 2022 to translate my pages into more than 15 languages. At first, the extension is really handy, and the visual translation keeps its promises.
The problem is that the longer the site stays on this platform, the worse it gets—to the point of being almost disastrous. The issues pile up over time, and that's exactly what nobody tells you before you set it up. TranslatePress.
I decided to write this review after sending dozens, if not hundreds, of emails to customer support.
Explanatory video in French by Alucare, ideal complement to the page. View video (you can use YouTube's automatic translation)
In this video, I share my unfiltered opinions on TranslatePress. Be sure to read the rest of this carefully before installing this plugin.
What exactly is TranslatePress?
TranslatePress is a WordPress translation plugin that lets you make your website multilingual.
How it works: You translate your content directly from a visual interface, by clicking on the text you want to edit on the page.
The plugin connects to Google Translate Where DeepL for the machine translation, generates a dedicated URL for each language and manages the metadata for the Multilingual SEO.
On paper, it's all there. In reality, my experience after two years is much more nuanced.
The main issue with TranslatePress:
The extension translates everything. And when I say everything, I really mean everything. If you write an article about a game like SUTOM, a game in French where the word of the day is PATATE; the plugin will translate it into the 15 languages. As a result, it costs you a few euros each time.
The worst part is that these translations are useless. These pages won't get any visitors in other languages.
And if someone wants to try the game in another language, they’ll never be able to answer “PATATE,” because they’ll see “POTATO.” With more complex words, it’s even worse.
I did the math, and I must have spent more than 2,000 € machine translation in posts that were only useful in French. You might say: the plugin surely has a button to disable translation when creating the post. Unfortunately, no.
Yet that is the change I asked support to make late 2022 : a simple button to prevent a specific article or page from being translated. Still nothing so far.
The only option available from the start is Do not translate certain paths. Except that to use it, the site needs to have categories in the URLs. But in SEO, that's not recommended.
On an existing WordPress site, you'll need to add this structure and make some 301 redirects, which changes all the URLs on the site. It's a real hassle for a feature that should be basic.
It generates hundreds of thousands of 404 errors
![]()
The real problem arises when you’re cleaning up your website. Imagine dozens of translated articles that are no longer useful—for example, content about daily games published on June 10, 2022, which is no longer needed today.
Delete the original post and post a 301 redirect to avoid a 404. So far, so good. Except that the 15 translated URLs The links related to this article, on the other hand, return a 404 error.
The reason is simple: TranslatePress doesn't make the connection. The plugin doesn't understand that if the original post is redirected with a 301 or 410 status code, its translations should follow suit. It doesn't inherit the redirect.
While doing some simple cleaning at Alucare.fr, I ended up with more than 150,000 404 errors. I contacted support to find out what steps would be taken. The official response: manually create 301 or 410 redirects for each translated URL.
The problem is that these translated addresses aren't visible nowhere. Before each deletion, you have to manually retrieve the translated URL in each language. On a real website Multilingual WordPress, it's impossible to manage on a day-to-day basis.
Switching from Google Translate to DeepL: The Real Problem
Do you want to switch from Google Translate at DeepL Want to improve the quality of your translations? Bad news. Your previously translated content is still stuck on the old engine.
To truly make the switch to DeepL, you have to empty the entire database existing translations. Otherwise, only new articles benefit from the new engine. I tried a workaround: deleting an article and then republishing it to force a new automatic translation.
It's not working. The plugin keeps the old translations in memory.
In practical terms, if you switch translation engines partway through, you'll have to start almost from scratch on all your already-translated pages. On a large website Multilingual WordPress, it's a real obstacle.
As for me, TranslatePress could become an excellent translation plugin. It is missing three essential features:
- A button to turn off translation a specific article or page
- The List of Translated URLs visible when you edit an article
- A real Handling 404 Errors, or at least an automatic safeguard
Updated 08/21/2024:
New episode, brought to you by TranslatePress. Quick summary: Their intervention led to My entire website showed a 404 error for 16 hours, and Google crawled the site right during that time frame. Here's what happened, in order.
The initial bug
TranslatePress created 404 Error on Custom Slugs on the site. I had edited a lot of slugs manually. The plugin didn't keep up with the translations of those URLs, so the translated pages were broken.
What the support team did
I was advised to Disable my SEO plugin. I'm testing it: yes, it fixes the bug. Except that I refuse to leave it disabled, precisely because I had modified a lot of slugs using it.
The support representative then logged into my site themselves. They made the change and emailed me to say that everything looked good. I wasn't available to check it afterward.
The Consequences
I'm logging back in 16 hours later. And then, a bunch of 404s. The SEO plugin had indeed changed the URLs, but the translation of these URLs had not been made. Result: The translated website was broken.
We're talking about more than 70,000 pages translated They all became 404 errors at once. Google had kept the old URLs in its cache and crawled all those errors in the meantime.
The underlying problem remains the same: TranslatePress ignores the URL history. If a page returns a 404 error, it does not automatically redirect to the new one. No recovery, no automatic redirection.
If you notice any other issues that are holding you back on TranslatePress, feel free to let me know in the comments.






