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
I found two issues:
Issue 1: Visiting a nonexistent page in another language still creates a translation record
Observed behavior: When I visit a nonexistent page in another language, the page correctly returns a 404. However, a translation record is still created in the admin area, and the URL is added to /wp-json/langora/v1/sitemap.xml.
Expected behavior: Pages that return a 404 should not generate translation records or be included in the sitemap. This would prevent invalid database entries and avoid potential SEO issues.
Issue 2: Translation records are missing from the sitemap after URL alias rewriting is disabled
Steps to reproduce:
- Enable “Rewrite URL alias for translated pages”.
- Crawl pages to generate translation records. The records appear correctly in
/wp-json/gptranslate/v1/sitemap.xml.
- Disable “Rewrite URL alias for translated pages”, delete all translation records, and crawl the pages again.
Actual behavior: The translation records are created successfully in the admin area, but /wp-json/gptranslate/v1/sitemap.xml is empty.
Expected behavior: After disabling URL alias rewriting and crawling the pages again, the generated translation records should still appear in the sitemap.
