gptranslatefredrik

Hi,

Thanks for the detailed report and the suggestion — that makes sense. We already have a similar safety mechanism in place that stops the crawl after too many consecutive pages where the language switcher can’t be found, so extending that same logic to also cover consecutive empty/failed translations is a reasonable idea and something we can implement in the next update.

That said, it would help to understand why you’re seeing this many consecutive failures in the first place — we haven’t run into this pattern with other users, so there might be something specific worth looking into. If you happen to find out what’s causing it on your end, please do let us know.

Thanks again for the feedback!

Best regards,
John

Hi,

version 2.34.4 has now been released with the fix for this issue: when a translation request fails, times out, or is rate-limited (regardless of the cause), GPTranslate no longer saves an empty translation record. The page correctly stays untranslated instead, so it will be retried automatically on a later visit or crawl run rather than getting permanently stuck.

As mentioned, it’s still worth checking your hosting/security setup (Wordfence, Cloudflare, or your host’s own rate limiting) if you notice translations failing repeatedly during a large crawl, since that’s the most likely reason requests were failing in the first place — but the plugin itself will no longer leave pages in a broken state because of it.

Marking this as resolved for now, but please let us know if you run into any further issues or need us to investigate anything else after updating — happy to keep looking into it with you.

Thank you again for the detailed report, it made pinning this down much easier.

Best regards,
John

Hi,

Thank you very much for the detailed report, and I’m sorry for the trouble.

You’re right that this isn’t caused by any IP restriction built into GPTranslate itself — the plugin has no such limitation, and bulk crawling uses the exact same translation mechanism as a normal page visit, just triggered many times in a row. What you’re most likely running into is a rate limit or IP block on your own server/hosting side (a security plugin like Wordfence, a firewall, Cloudflare, or your host’s own protection against a high volume of requests to admin-ajax.php/the REST API in a short time) — which would explain why translations start failing after a while and work again once you switch to a new IP.

That said, you’ve identified a useful gap that we can fix regardless of the underlying cause: when a translation request fails or the save doesn’t go through cleanly, GPTranslate currently doesn’t prevent an effectively-empty result from being saved as a translation record — exactly as you suggested, it should instead leave the page untranslated so it can be retried automatically. We’re going to address this.

I’d really appreciate it if you could open a thread on our support forum with these same details, so we can track the investigation and confirm the fix with you there. In the meantime, could I kindly ask you to remove the 3-star review and wait until we’ve resolved this together? We’d like the chance to fix this properly and have you confirm it works before any rating is left — that seems fairer to both of us than rating it while the issue is still open.

As an immediate workaround, try slowing down the crawl: check if your GPTranslate settings have a request delay option, and increase it, or check your hosting/security plugin’s rate-limit settings/logs to see if your own server is the one blocking the requests during the crawl.

Thank you again for reporting this and for your patience — much appreciated as a paying customer.

Best regards,

John

@rutger520 the first test that i recommend would be to disable any cache plugin and switch to DOM Document server translations.

In this way it’s possible to test again the result to discover if that was the problem.