跳至正文
技术 SEO 与抓取索引 · Google SEO

hreflang points to a 301 or 404: how to audit and fix language mappings

// / / 光算科技

A page that returns 200 with a perfectly valid hreflang block can still break its language mapping, because one of the annotated targets does not return 200 itself. If hreflang="ja" points at a URL that 301s elsewhere, or at a page that now returns 404, Google may ignore that part of the annotation or feed users to the wrong version. The fix is not to rewrite the language page — it is to audit every alternate target, resolve it, and point the annotation at the final, live URL.

This is the operational check. It is deliberately narrower than a general overview of the seven technical reasons hreflang tags stop working: here we only ask "does each target resolve, and do the versions point back at each other".

Google Search Central official page 'Tell Google about localized versions of your page', showing the situations where localized annotations are recommended and the note that localized versions are only duplicates when the main content stays untranslated
Official localized-versions guidance, captured 2026-10-02 from developers.google.com. Google notes it may still find alternates without annotations, but recommends declaring them explicitly.

The four rules that decide whether the mapping survives

  • Every version must list itself and all others. The set of <link rel="alternate"> elements is identical on every language version.
  • Alternate URLs must be fully qualified — with scheme and host. //example.com/ja/ or /ja/ is not valid.
  • Links must be reciprocal. If page X points to page Y, page Y must point back. Google's documentation says annotations may be ignored otherwise. This is the single most common silent failure.
  • Codes must be valid. The first code is an ISO 639-1 language; the optional second code is an ISO 3166-1 alpha-2 region. You cannot specify a region alone, and codes that are not listed (such as es-419), or reserved codes like EU, UN and UK, are not applied by Google Search.

Audit it as a table, not as one page

For each language version of one logical page, collect three things and put them in a grid:

  1. Source URL and its own status (should be 200).
  2. Each declared alternate: its hreflang value, the raw href, and the resolved result — status after following redirects, and the final URL.
  3. Reciprocity: open the target and confirm it lists the source back at the matching code.

Where to read the annotations: the rendered <head> (HTML method), the Link: response header (useful for PDFs and non-HTML files), and the sitemap's xhtml:link entries. Google treats the three methods as equivalent; pick one and keep it consistent so you are not comparing apples to oranges.

Audit table for hreflang language mapping, comparing the healthy writing against the case to fix for target status, reciprocity, language codes, region format and x-default fallback
Original audit grid. The healthy/fix columns mirror Google's localized-versions guidelines; the ja / ko / ru / fr / zh-TW row set is our own example.

What "points to a 301 or 404" actually looks like

Two families of problem, with different fixes:

Target 3xx (redirect)

Common when you change URL structure and forget the annotations. A crawler resolving hreflang="fr" reaches a 301 and lands somewhere else. The clean fix is to replace the hreflang URL with the direct destination URL so no redirect is needed. If the redirect exists for a deliberate reason, the annotation should still name the final target, not the intermediate hop.

Target 4xx (deleted or mistyped)

A language version was removed, or the href has a typo, or the encoded path does not match. Options: restore the page, or remove that URL from the annotation set — but only after checking whether the language is still supposed to exist. If you remove one language from the set, the remaining versions still need to link to each other, so re-check reciprocity for all of them.

Validate the code itself against BCP 47

The site in front of you probably uses a handful of locales. Check each against the standard rather than against the folder name:

FolderCorrect annotationWatch out for
/ja/hreflang="ja"Do not use a region unless you actually target one.
/ko/hreflang="ko"Same; Korean has no script variant you need here.
/ru/hreflang="ru"Russian pages often mix in English spec tables; text language does not change the annotation.
/fr/hreflang="fr" or fr-FRRegion only if you serve a specific market.
/zh_tw/hreflang="zh-TW" (or zh-Hant)Region codes are uppercase; the script is derived from the country.

If your site also has a generic fallback page, add one x-default annotation for users whose language matches none of the versions — usually a language selector. Do not point x-default at a random product page.

A repeatable check

  1. Crawl every URL that carries a language version, one locale at a time.
  2. Extract the hreflang/href pairs (HTML, header and sitemap).
  3. Resolve every href; keep the final status and final URL.
  4. Compare the full set of pairs across versions to catch asymmetry and missing self-references.
  5. Fix the annotation URLs, then re-run only the changed set.
  6. Record the run date; language maps drift when a page is renamed.

For sites that change URL structure often, run this alongside the bulk redirect and status check so the two reports share one export. If some pages legitimately have no translation yet, decide the launch conditions first — the question of whether to publish hreflang before the whole site is translated is a policy decision, not a tag decision.

When a multi-language site is being built or repaired, the Russian website build service and the Google SEO service are the relevant scopes; Shopify stores have their own variant of this in Shopify Markets and hreflang.

Sources