# Fix TranslatePress Redirect Errors in Google Search Console
When you add a new language to a WordPress site, the last thing you expect is a wave of errors in Google Search Console (GSC). Yet that is exactly what can happen with TranslatePress: shortly after enabling a second language, the Coverage report fills up with **”Redirect error”** entries, almost all of them pointing at the newly created translated pages. The pages look fine in a browser, but Googlebot sees something it does not like—and crawls fail silently in the background.
This guide walks through what causes those redirect errors, how to confirm the problem with a quick `curl` test, and the single TranslatePress setting that resolves it.
## What a GSC Redirect Error Actually Means
Before fixing anything, it helps to understand what Google is telling you. A **Redirect error** in Search Console means that when Googlebot followed a URL, it encountered a redirect chain or loop that it could not complete. Common triggers include:
– A redirect loop (page A → page B → page A, endlessly)
– A chain so long Googlebot stops following it
– A redirect to a URL that returns an error or is itself blocked
– A redirect that points to an unreachable or non-resolving destination
Unlike a soft 404 or a blocked resource, a redirect error is specifically about the redirect response itself. When TranslatePress is the culprit, the typical pattern is a **301 redirect** on the translated URL that leads somewhere Google cannot finalize.
## The Typical Pattern: Errors Concentrated on Translated Pages
The hallmark of a TranslatePress-induced problem is that the redirect errors cluster on a single language. If your default language pages crawl cleanly but every `/en/…` page throws a redirect error, the multilingual plugin is the obvious suspect. That concentration is the first diagnostic clue.
This is exactly what happens when TranslatePress migrates its slug-rewrite mechanism. A change in how the plugin rewrites translated URLs can cause the server to issue a 301 redirect that loops or misbehaves for Googlebot—even though the same URL renders perfectly in a desktop browser with cookies and caching in play.
## Confirm the Problem With curl
Browsers are forgiving. They follow cookies, respect cached redirects, and quietly resolve issues that a raw HTTP client will expose. Before changing any settings, test the problematic URL directly from the command line:
“`bash
curl -I https://yourdomain.com/en/sample-page/
“`
The `-I` flag fetches only the headers, which is all you need to inspect the response code. A healthy page returns `HTTP/1.1 200 OK` (or `200` over HTTP/2). If the server instead responds with a **301 Moved Permanently**, and the `Location` header points somewhere that loops or fails, you have confirmed the redirect is the problem—not Google’s crawler.
Run the same command against a default-language page for comparison. If the default page returns `200` and the translated page returns `301`, the translation layer is where the breakage lives.
## The Fix: Enable the Legacy SEO Pack Add-On
Inside TranslatePress’s settings there is an SEO-related section that most users scroll past. At the bottom of that section you will find a toggle labeled **”Load legacy SEO Pack Add-On.”** Its description reads:
> *”In case the recent migration to the new slug rewrite is causing trouble, set this to Yes to use the old method.”*
That single sentence is the fix. Setting it to **Yes** reverts TranslatePress to its older URL-slug rewriting logic—the one that existed before the migration that introduced the problematic redirects.
Here is the step-by-step:
1. In your WordPress dashboard, navigate to **Settings → TranslatePress** (or the TranslatePress menu, depending on your version).
2. Open the **SEO** settings tab.
3. Scroll to the last option: **Load legacy SEO Pack Add-On**.
4. Set it to **Yes**.
5. Save changes.
6. Clear your site cache and any CDN cache.
After saving, return to the terminal and run the same `curl -I` command against a previously failing translated URL. A correct result now returns **200 OK** with no 301 redirect, confirming that the legacy slug-rewrite method handles the URL the way Google expects.
## Verify the Fix in Google Search Console
A passing `curl` test proves the server is behaving, but you still need to tell Google. In GSC:
1. Go to **Settings → Crawl stats** or open the **URL Inspection** tool for a specific affected page.
2. Request **Live Test** to confirm Googlebot can now fetch the page without a redirect error.
3. Once the live test passes, click **Request Indexing**.
4. For a bulk recovery, return to the **Coverage** report, select the error category, and click **Validate Fix**.
Google will re-crawl the affected pages over the following days to weeks. The redirect errors should clear as each URL is successfully re-fetched.
## Why This Happens: The Slug-Rewrite Migration
TranslatePress, like most actively maintained plugins, periodically updates its internal URL-handling architecture. The “new slug rewrite” method referenced in the setting’s description is a rewrite of how translated URLs are generated and resolved server-side. For the majority of configurations the new method works transparently. But in certain setups—specific server environments, particular permalink structures, or interactions with other SEO/caching plugins—the new rewrite logic produces a redirect where the old logic served the page directly.
Because the problem is server-environment specific, it does not affect every TranslatePress user, which is why the plugin ships the legacy toggle rather than rolling back the change entirely. It is a compatibility escape hatch.
## General Troubleshooting Principles for WordPress Redirect Issues
The TranslatePress fix is narrow, but the methodology behind it applies broadly. When chasing redirect or crawl errors on any WordPress site:
– **Reproduce reliably before concluding.** A single transient failure is not a diagnosis. Confirm the issue with `curl` or a header-checking tool several times.
– **Record the full context.** Note your WordPress version, plugin versions, permalink structure, server (Nginx/Apache), and the exact response codes. This information is essential if you need to ask for help.
– **Change one variable at a time.** Enable a setting, re-test, then move on. Mixing multiple changes obscures which fix actually worked.
– **Back up before touching production.** Redirect and rewrite changes can take a site offline. Always have a restore point—database and files—before modifying server or plugin behavior.
– **Suspect caching first.** A surprising number of “redirect errors” are stale entries in a page cache, object cache, or CDN. Flush every cache layer before assuming a deeper problem.
– **Check plugin interactions.** SEO plugins, security plugins, and caching plugins all manipulate URLs and headers. A conflict between two of them is a frequent hidden cause.
## A Note on Recency
TranslatePress is under active development, and its settings interface can change between versions. The “Load legacy SEO Pack Add-On” toggle described here was present as of the plugin version current in mid-2025. If you cannot locate the exact setting, consult the official TranslatePress documentation or changelog for your installed version—the option may have been renamed, relocated, or resolved entirely in a newer release. Always verify against the plugin you actually have installed rather than relying on any single tutorial, including this one.
## Conclusion
GSC redirect errors after adding a language with TranslatePress are intimidating at first glance—hundreds of failed URLs in the Coverage report—but the root cause is usually narrow: the plugin’s updated slug-rewrite method interacting poorly with your specific setup. A quick `curl -I` test confirms the redirect, and flipping the **Load legacy SEO Pack Add-On** setting to Yes restores the old, crawler-friendly behavior. After clearing cache and requesting re-validation in Search Console, the errors clear as Google re-crawls. Keep this fix bookmarked, test in a staging environment if you have one, and remember that for any WordPress redirect mystery, the answer is most often found one layer at a time.
