LingoWP
Hreflang Points to a 404 Page in TranslatePress: What to Check
An SEO audit finds a French language link on your English page. You open the listed address and get “Page not found.”
The original page still works, but the language counterpart promised by hreflang does not.
When hreflang points to a 404 page, first determine whether the content exists at another address, should be restored, or was intentionally removed. Correct the generated link to the working language URL, restore the intended page, or omit the unavailable alternate.
The right fix depends on why the destination is missing. Here is how to investigate it in TranslatePress, followed by what LingoWP’s handling of missing translation text and error pages helps address.
Published by LingoWP. External guidance was checked on 6 October 2026. LingoWP behavior described below is based on the developer review for version 1.5.
What the warning actually means
Hreflang identifies a page’s language or regional counterparts. A 404 warning means one of the listed destinations returns an HTTP “not found” response.
For illustration:
| What you check | Result |
|---|---|
English page: /about/ |
Opens correctly |
French alternate listed in hreflang: /fr/about/ |
Returns 404 |
Current French page: /fr/a-propos/ |
Opens correctly |
In this example, the content is available. The annotation uses the wrong address.
Screaming Frog groups unavailable alternate URLs under Non-200 Hreflang URLs and recommends using correct canonical, indexable destinations. A successful 200 response is one check; the destination must also contain the appropriate language counterpart. See its hreflang check.
Google does not index URLs that return 404 or 410 responses. If a previously indexed URL starts returning those responses, it can be removed from the index over time. That makes a missing destination unsuitable as the live language counterpart you are advertising. Google explains HTTP status handling here.
Check the response before choosing a fix
Similar-looking warnings can describe different situations:
| Finding | Meaning | What to investigate |
|---|---|---|
| 404 | The requested address is not found | Wrong URL, deleted content, or broken routing |
| 410 | The resource is indicated as gone | Whether removal was intentional |
| 301 or 302 | The address redirects | The final destination and the URL used in hreflang |
| 200 with a “not found” message | The server reports success despite missing content | A possible soft 404 |
A working page marked noindex |
The page exists but asks search engines not to index it | Whether that indexing choice is intended |
A noindex directive does not make a page return 404. An error message displayed inside a page does not prove the server returned 404 either. Use the response information from your audit alongside the page you can see. If the alternate redirects rather than failing, see what to do when hreflang points to a redirect.
Google’s Page indexing documentation distinguishes these indexing and error states.
How to fix hreflang links to missing pages in TranslatePress
1. Record the page and the broken alternate separately
An audit can identify both the page containing the language annotation and the destination that fails. Keep those two addresses separate.
Record:
- The page containing the hreflang entry.
- The language code attached to it.
- The listed target URL and its response.
- Any verified working replacement.
For a manual check, open the page, choose View Page Source, and search for hreflang. Find the entry that matches the unavailable destination.
If several pages share the problem, look for a pattern. Does every broken URL belong to one language, one content type, or one category base? That can help you investigate a shared setting rather than editing each page individually.
2. Look for the current language URL
Check the current page in WordPress and open its language version. Compare that address with the one listed in hreflang.
If the slug changed, the page may exist under a new address. TranslatePress’s documentation identifies changed page or language slugs and removed languages as possible reasons older translated URLs stop working. Read its 404 troubleshooting guide.
For translated slugs, the paid SEO Pack provides slug editing through the translation interface and String Translation → Slugs. Check the relevant entry against the current content. Follow the official slug instructions.
Confirm that any replacement shows the equivalent content in the intended language. A homepage or unrelated page is not a suitable substitute merely because it loads.
3. Check whether the page or language was intentionally removed
If the page should still exist, check its publication status and whether it was moved to the trash or made unavailable. Restore the intended public content where appropriate, then verify its language URL.
If the content was intentionally retired, decide whether there is a genuine replacement. Where one exists, use that replacement and update the annotations accordingly.
Where there is no replacement, the old address can correctly remain unavailable. The hreflang output should stop presenting it as a live alternate. Have the component generating the entry omit that unavailable version; if there is no setting for the case, send the specific example to its support team.
Do not redirect every missing translated page to the homepage just to remove an audit warning. Preserve the relationship between equivalent content.
4. Investigate routing when content exists but the URL fails
A published page can still return 404 when its address is constructed incorrectly or the server does not recognize the route.
Compare the working and broken paths. Check language folders, translated slugs, and fixed sections such as event or category bases. If the broken path repeats its language folder, such as /fr/fr/, follow the guide to the TranslatePress double language prefix.
TranslatePress’s troubleshooting documentation recommends checking that pretty permalinks work. It also describes cases where server rewrite rules prevent translated subdirectories from resolving. If translated pages show a plain server error rather than your site’s normal error page, ask your host to inspect the routing. See the official troubleshooting guidance.
For custom content, include the plugin that defines the URL in your investigation.
In one Events Calendar support discussion, a user reported translated category bases leading to routes that did not exist. Support supplied workarounds for the affected bases, and the user reported improvement. This is a documented integration example, not proof that every current TranslatePress setup behaves that way. Read the discussion and supplied remedies.
5. Correct the source of the broken annotation
Once you know the appropriate outcome, make the corresponding correction:
| Diagnosis | Appropriate correction |
|---|---|
| The language page exists at a different URL | Make the generated alternate use its current address |
| The public page was accidentally removed | Restore it and verify the intended language route |
| The page or language is intentionally unavailable | Omit the unavailable alternate from the published annotations |
| A plugin or hosting rule breaks a valid route | Correct that integration or rule, then recheck the URL |
Fix the generating setting or integration rather than manually editing cached HTML. If the old URL has a legitimate replacement, preserve an appropriate redirect for existing links while hreflang points directly to the working destination.
If your sitemap lists a different address from the page’s HTML, see what to do when hreflang and sitemap URLs don’t match.
A useful support request is concrete:
This English page lists /fr/about/ as its French alternate, but that address returns 404. The current French page works at /fr/a-propos/. Here are the affected page and my TranslatePress, add-on, and SEO plugin versions.
6. Refresh the output and check both sides
After correcting the cause, clear relevant caches and inspect the public pages while logged out.
Check that the working page no longer lists the dead destination. If you restored a page, confirm that it opens directly, contains the correct language content, and is available for indexing as intended.
Then inspect the language counterparts. Google requires return links between the relevant versions; correcting one destination is not the whole check. See Google’s localized-page requirements.
Rerun the affected audit. Search Console’s Not found (404) information can help track URLs Google has encountered, but that listing does not itself prove they came from hreflang. Inspect the annotation separately. Older retired URLs may remain in reports while Google revisits them; they do not all need to be restored.
How LingoWP handles missing translation text
An unfinished translation and a missing page are different problems. Missing translated text alone is not a diagnosis of a TranslatePress 404.
In the reviewed LingoWP behavior, language versions use the same underlying WordPress page. When translated text is missing on an existing page, LingoWP can display the original text as a fallback.
For the site owner, this keeps the content available while translation work continues. You can complete the missing text in the central workspace instead of treating an incomplete sentence as a missing page.
Fallback also needs editorial attention. An address labelled French that still displays substantial English content is not a completed French translation. Google determines language from the actual content rather than relying on hreflang to define it. Review the main content before promoting that language version in search.
Error pages do not advertise language alternatives
The developer review for LingoWP 1.5 reports that 404 pages do not emit hreflang annotations, and that this behavior is covered by tests. That prevents the error page itself from presenting a language set as though it were normal published content.
This is separate from checking links on working pages. A live page could still reference an address affected by an external redirect, a removed language, or an integration problem. LingoWP’s reported 404-page test does not establish universal coverage of those cases, or of 410 and noindex behavior.
LingoWP is worth assessing if you want a central translation workflow with source-text fallback and deliberate handling of error-page annotations. Check your actual affected routes and integrations on a copy of the site before migrating. For a broader look at both plugins, read LingoWP vs TranslatePress.
Explore LingoWP to see its translation workspace and evaluate it for your site.
Frequently asked questions
Is a 410 page different from a 404 page?
A 410 explicitly indicates that a resource is gone; a 404 says it was not found. Neither should be listed as an available language counterpart. Whether to restore the content depends on whether its removal was intended.
Does every 404 need a redirect?
No. If content has a suitable replacement, redirecting the old address can preserve existing links. If it was removed without a replacement, an unavailable response can be appropriate; stop advertising it in current language annotations.
Can I fix the issue by requesting indexing?
Correct the URL or restore the intended content first. An indexing request does not repair a broken route or stale hreflang entry. If the page was intentionally removed, requesting indexing is not the appropriate next step.