Hreflang Points to a Redirect in TranslatePress: How to Fix It

Your translated page opens correctly. The language switcher seems to work. Then an SEO audit tells you that a hreflang URL redirects.

Usually, the warning means a language link still points to an address that sends visitors somewhere else. The page can look perfectly normal because your browser follows the redirect automatically.

To fix it, identify the final working URL for that language and correct the setting or integration that generates the old hreflang address. Keep any useful old-URL redirect in place, clear the relevant caches, and check the language links again.

Here is how to work through that process in TranslatePress, and how LingoWP helps keep those links aligned when page addresses change.

Published by LingoWP. External guidance was checked on 6 October 2026. The product explanation below draws on LingoWP 1.5’s developer review.

What does “hreflang points to a redirect” mean?

Hreflang tells search engines where to find the language or regional versions of a page. For example, a French event page can identify the equivalent Dutch event page.

A redirect warning means the address listed for one of those versions does not serve the page directly. It returns a redirect response, such as 301 or 302, before reaching another URL.

Consider this illustrative example:

What you check	URL	What happens
Dutch URL listed in hreflang	https://example.com/evenement/summer-concert/	Redirects to another address
Current Dutch event page	https://example.com/event/summer-concert/	Opens the intended page directly

The hreflang entry should use the current address in the second row.

Screaming Frog classifies redirecting alternate URLs under its Non-200 Hreflang URLs check and recommends pointing annotations to the correct canonical, indexable pages. A 200 response means the request succeeded; you still need to confirm that the page contains the expected content. See its explanation.

Why the page can work while the warning remains

A visitor who opens the old URL can be redirected to the correct page without noticing the address change. That is useful when someone follows an older bookmark or link.

However, your site’s language annotations should already identify the current destination. Leaving an old address in hreflang creates an unnecessary step and makes the relationship between language versions less clear.

This warning alone does not establish that you have lost rankings. Hreflang helps Google understand language relationships, and Google requires return links between the relevant versions. An audit should check those relationships at the final URLs. Google’s guidance explains the requirements.

The practical goal is straightforward: each language entry should lead directly to the correct version of the same content.

How to fix redirecting hreflang URLs in TranslatePress

1. Find the exact alternate URL that redirects

Start with one affected page from your audit. Record:

• The page containing the hreflang entry.
• The language code attached to it.
• The URL listed in that entry.
• The final URL reached after the redirect.

If you need to check the page manually, open it, choose View Page Source, and search for hreflang. You only need to identify the listed address; you do not need to edit the page’s code.

If you already use Screaming Frog, look in Hreflang → Non-200 Hreflang URLs. Its report separates the page containing the annotation from the target that needs investigation.

2. Confirm the correct destination for that language

Open the final page and check that it contains the expected content in the expected language. An event should lead to the corresponding event, and a product should lead to the corresponding product.

Use your audit’s response information to confirm that this final URL returns 200 directly. Simply seeing a page load is insufficient: the browser may have followed another redirect.

If the supposed French URL ends at an English page or the homepage, investigate that routing problem first. Substituting that destination into hreflang would describe the wrong language relationship. If the chain ends at an error instead, follow the steps for when hreflang points to a 404 page.

3. Identify what changed in the address

Compare the old and current URLs. The difference usually tells you where to look.

Difference	What to investigate
The page name changed	The WordPress slug and its translated slug
A section such as /event/ changed	The plugin or settings that control that content’s URL base
The language folder changed	TranslatePress language URL settings and existing redirect rules
HTTP changes to HTTPS, or the hostname changes	Site URL and hosting redirect settings
Only a trailing slash changes	Whether generated links follow the site’s current URL format

These are possible causes, not a diagnosis of every TranslatePress installation. Start with the difference you can actually observe.

4. Correct the setting that generates the stale URL

For a translated page slug, check the translation against the current WordPress slug.

TranslatePress’s documentation places slug translation in the paid SEO Pack. With it active, you can open Translate Page and select the post slug. You can also search for slugs in String Translation → Slugs when the relevant entry is not available in the page editor. Follow the official slug translation instructions.

For an event, product, category, or another custom content type, also check the plugin that controls its address. A correct translated page name will not fix an incorrect section base elsewhere in the URL.

If the settings look correct but the output remains wrong, investigate the integration on a staging copy of the site. Record your TranslatePress version, active add-ons, SEO plugin, and redirect plugin. Check the TranslatePress changelog for relevant fixes before assuming an older report still applies.

If your XML sitemap lists a different address from the page’s hreflang, see what to do when hreflang and sitemap URLs do not match.

A useful support request is specific:

On this page, the Dutch hreflang entry uses the old event address. It returns a 301 to the current Dutch address. Here are both URLs, the affected page, and my active plugin versions.

That gives support a reproducible starting point.

5. Keep the old redirect and refresh the affected output

If the old address has moved permanently, its redirect may still be needed for bookmarks, external links, and previous search results. Correct the hreflang entry to use the current address while preserving that useful redirect.

After correcting the generating setting, clear the relevant page, hosting, or CDN cache so the public page can show the updated annotations. Then check the page as a logged-out visitor.

If the stale address immediately returns, continue investigating the component that generates it. Repeated cache clearing will not correct an unchanged URL rule.

6. Recheck the language versions together

Check the original page and its translated counterparts. Google specifies that language versions should reference themselves and the other versions, with return links between the relevant pages.

For the affected pages, verify that:

• Hreflang entries use the intended final addresses.
• Those addresses open directly and return 200.
• Each destination contains the correct language and corresponding content.
• The language versions link back to one another.
• Canonical settings agree with the intended language pages.

Google recommends a canonical page in the same language when using hreflang, where one exists. Review any custom canonical setting that points a translated page somewhere inappropriate. Read Google’s canonical guidance.

Rerun the audit after the change. For a site with many similar pages, check the shared page type as well as the first example you fixed.

How LingoWP keeps language links current

When you rename a page or update a translated title, maintaining the language links should be part of the same workflow.

LingoWP uses the current WordPress permalink when generating a page’s language addresses and derives translated slugs from translated titles. Its developer review describes invalidating the relevant URL cache when posts or slugs change.

For the site owner, the benefit is fewer places to correct after an address change: LingoWP’s language links are generated from the current page information.

The review for LingoWP 1.5 reports tests covering hreflang targets that avoid WordPress old-slug redirects, and old-slug redirects that preserve the visitor’s language. These support the specific page-renaming behavior described here.

That makes LingoWP worth considering if keeping translated addresses aligned has become a recurring maintenance task. You manage the page and its translations in a central workspace, while the plugin handles its language links using the current content information. For a broader look at both plugins, read LingoWP vs TranslatePress.

Third-party routing still matters. The review did not test the specific Events Calendar configuration used in the supplied example, and external redirect rules can change what any generated URL does. Test those integrations on a copy of your site before switching.

Explore LingoWP to see its translation workspace and assess whether it fits your site’s workflow.

Frequently asked questions

Should I remove the 301 redirect to fix hreflang?

If the redirect correctly takes an old address to its replacement, keep it and update the hreflang entry to use the replacement directly. Removing a useful redirect can leave older links without a working destination.

Does “Page with redirect” in Search Console prove a hreflang error?

No. It describes a URL that redirects and is not indexed as that URL. You need to inspect the language annotations separately to establish whether hreflang uses that address. Google’s live URL Inspection test follows redirects, so a successful live test also does not prove the original URL returns 200 directly. See the Page indexing documentation.

Can clearing the cache fix the warning?

It can help when the underlying address has already been corrected and visitors are receiving older cached output. If a setting or integration still generates the wrong address, correct that cause first.

Do I need to switch plugins to solve this?

A stale slug, configuration mismatch, or integration issue may be fixable in your current setup. Consider LingoWP when you also want its translation workflow and approach to maintaining language links. Verify the affected URLs after any change, including a migration.