glimanaDocs Open Glimana →

Issue guide · International

Invalid hreflang language/region code

SeverityMedium
CategoryInternational
ScopePer page
EffortSmall
Verified byRe-crawl after you mark the task done
Rule keyhreflang_invalid_code

Short answer

One or more hreflang values on this page are not valid codes, so Google ignores those entries and may serve the wrong language version. The language code must be ISO 639-1 (two letters: en, tr, ja), with an optional ISO 3166-1 Alpha-2 region (two letters: en-GB, pt-BR). Common mistakes: en-UK (correct: en-GB), jp (correct: ja), a country code alone (us), three-letter language codes and numeric regions such as es-419. Fix the codes in the evidence.

Why it matters

This issue affects whether language versions are matched correctly. An invalid entry is silently dropped, and because hreflang must be reciprocal, the versions that point to the invalid one lose their confirmation too. The symptom is users in one country seeing another country's prices or language.

How Glimana detects it

Glimana validates every hreflang value on the page against ISO 639-1 language codes and ISO 3166-1 Alpha-2 regions (x-default is allowed). The evidence lists up to five invalid codes found.

How to fix it

  1. Find the affected pages in Glimana. Open Issues › Invalid hreflang language/region code. 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.
  2. Apply the fix on your platform.

    Wrong Right Why
    en-UK en-GB The UK's ISO country code is GB
    jp ja jp is the country, ja is the language
    us en-US A region must follow a language
    eng en Three-letter codes are ISO 639-2, not accepted
    es-419 es or es-MX Numeric UN M.49 regions are not accepted
    en_GB en-GB Hyphen, not underscore
    zh-Hans zh-Hans is valid (script subtag); zh-CN also works

    The code comes from the language's locale setting in WPML/Polylang (Languages › edit language › "Language code" / "hreflang"). Correct the code there; it changes site-wide.

    Shopify Markets uses valid codes. An invalid one means a custom hreflang block in the theme; fix the value in theme.liquid.

    Validate the locale list at build time against the ISO tables; map internal locales (en_UK, jp) to valid hreflang values when rendering.

  3. 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.

  4. 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 value on the page is valid. 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

Re-crawl; the task closes when every hreflang value on the page is valid.

Sources