hreflang points to a redirect or error page
hreflang_target_errorShort answer
One or more hreflang URLs on this page do not return 200: they redirect, or they answer 4xx or 5xx. Google needs each alternate to be a live page; a redirected or broken target breaks the pair, and that language version can lose its place in search. Replace each listed URL with the final address of that language version, on every page of the set.
Why it matters
Redirects are a common silent cause: a site moves to https://, adds or drops a trailing slash or www, and the hreflang values keep the old form. Each target then costs Google an extra hop, and if the redirect lands somewhere else (the home page, another language) the relationship is lost. Error targets mean a translation was deleted while the other versions still point to it.
How Glimana detects it
Glimana checks the targets of every hreflang annotation on pages that return 200. When a target is a page Glimana has crawled and its status is a redirect, 4xx or 5xx, the source page is reported. Targets on other domains, or URLs Glimana has not crawled, are not judged. The evidence lists up to five failing targets with their status and, for redirects, where they lead.
How to fix it
- Find the affected pages in Glimana. Open Issues › hreflang points to a redirect or error page. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
For each failing target in the evidence:
- Redirect: replace the URL with the final destination, exactly as it is served (scheme,
www, trailing slash). - 404/410: the translation is gone. Remove it from the set on every page, or restore the page.
- 5xx: fix the server error; the URL itself may be right.
Old-format URLs usually come from a changed permalink structure or a domain move. Save Settings → Permalinks once, clear the WPML/Polylang cache, and check that the plugin's language URLs (directory, subdomain or domain) match the live site. For a deleted translation, unlink it in the post's Languages box.
Markets generates hreflang from your domains. A redirecting target usually means a market domain or subfolder that redirects (for example to the primary domain). Check Settings → Domains and Settings → Markets so each market's URL is the one actually served.
Generate hreflang from the canonical URL builder, not from stored strings. Add a release check that requests every hreflang target of a sample of pages and fails on any non-200 answer.
- Redirect: replace the URL with the final destination, exactly as it is served (scheme,
-
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when every hreflang target on the page returns 200 directly. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
The next crawl re-checks the status of each crawled hreflang target; the task closes when none redirects or errors.