An hreflang annotation is not valid

LowHigh confidenceQuick winseo.hreflang.invalid

What this check looks for

‹count› of the page's hreflang links are malformed. Search engines discard the whole annotation set when it cannot be parsed, so the other language versions are not connected to this page.

Why it matters

The point of hreflang is to show the right language version to the right reader. When an entry is invalid, the set fails and readers may be shown a version in a language they do not read.

When the check passes, your report says: “Every hreflang annotation on the page is valid”.

What it costs your score

When this check fails it removes 6 points from your SEO score, before the status, confidence and repeat multipliers are applied. SEO carries a weight of 5 in the overall score.

It shares the seo.i18n family ceiling of 8 points: however many findings that family produces, together they cannot remove more than that from SEO. One underlying problem showing up in several places is still one problem.

Severity: low
Default confidence: high
Status when triggered: warn
Deduction: 6 points
Family cap: seo.i18n · 8
Category: SEO
Module: Seo audit
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Correct the malformed hreflang entries.

A set that cannot be parsed is discarded, so none of the language versions are connected.

Use a hyphen, not an underscore: en-GB, never en_GB.
Use a language subtag first, then the region: en-GB for British English. uk is the language tag for Ukrainian, not a region code for the United Kingdom — a mistake this check cannot catch for you, because uk is a perfectly well-formed tag.
Use absolute URLs including the scheme.
Verify the return links too — every page named must name this one back. Search Console's international targeting report checks this.

How to confirm it worked

curl -sS ‹url› | grep -i hreflang — confirm the corrected tags

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Page HTML

<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/page/">
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr-fr/page/">
<link rel="alternate" hreflang="x-default" href="https://example.com/page/">

Every page in the set carries the full set, including a link to itself. Omitting the self-link is the most common reason a correct-looking set is ignored.

Technical detail

‹problems›

Two things are checked: the language value must have the **shape** of a BCP 47 tag, and the href must be an absolute http: or https: URL. That catches an underscore instead of a hyphen (en_US), a tag with the subtags in the wrong order, and a relative href.

**We do not check the values against the language and region registries.** uk means Ukrainian and not the United Kingdom, and en-UK is not a valid region — both are well-formed in shape and both pass this check. So a clean result here means the syntax is right, not that you named the languages you meant to.

**What this check cannot verify:** hreflang must be bidirectional — every page the set names must name this page back — and confirming that means fetching every alternate. We do not, so a result with no findings here means the annotations on *this* page are well formed, not that the set as a whole is correct. Use the international targeting report in Search Console for the return-link check.

A correct x-default entry is also worth having. It names the page to show a reader whose language matches none of the versions, and it is not validated as a language tag because it is not one.