Hreflang Syntax: Why en_GB and en-gb Are Wrong and How Silent Failures Happen

Hreflang tags with underscores (en_GB instead of en-GB), lowercase region codes (en-gb), or uppercase language codes (EN-GB) are silently ignored by Google with no error message. Here's the ISO 639-1 and ISO 3166-1 case requirements, why self-referential tags and bidirectional return links are both required, the three implementation methods and why mixing them breaks the cluster, and when country-targeting without language differences works.

The hreflang annotation is case-sensitive in specific ways — language codes must be lowercase (`en`), region codes must be uppercase (`GB`), and the full tag must be `en-GB` not `en_GB` or `en-gb` — and violating these conventions causes the entire annotation to be silently ignored by Google without any error message

The previous articles on this site covered hreflang basics, international SEO beyond hreflang, common hreflang errors, geo-redirects vs hreflang, x-default, and why correct hreflang doesn't guarantee language targeting. This article addresses hreflang syntax precision — specifically the language and region code standards that govern valid hreflang values, the encoding requirements, and the specific malformed tags that appear most frequently in audits.

The language and region code standards

Hreflang uses two ISO standards:

ISO 639-1 (language code): two-letter lowercase codes.

en (English), fr (French), de (German), es (Spanish), pt (Portuguese), zh (Chinese), ja (Japanese), ar (Arabic)
Note: zh covers Chinese broadly; zh-Hans (Simplified) and zh-Hant (Traditional) use the ISO 15924 script code when distinguishing written forms

ISO 3166-1 Alpha-2 (region code): two-letter uppercase codes.

US (United States), GB (United Kingdom), AU (Australia), CA (Canada), DE (Germany)

The correct format: {language}-{REGION}

en-GB ✓
en-US ✓
fr-FR ✓
pt-BR ✓ (Portuguese as used in Brazil)
zh-TW ✓ (Chinese as used in Taiwan)

Common incorrect formats:

en_GB ✗ (underscore instead of hyphen — silently ignored)
en-gb ✗ (lowercase region code — technically tolerated by Google but not correct)
en_us ✗ (multiple errors)
EN-GB ✗ (uppercase language code)

When to use language-only vs language-region

Language-only tags (en, fr, de) target speakers of that language regardless of location. Appropriate when:

Content isn't region-specific (international English content not targeting a specific country)
You have only one version for all speakers of a language

Language-region tags (en-GB, en-US, en-AU) target speakers of that language in that specific country. Appropriate when:

Significant content differences exist for different regions (pricing in local currency, local spelling, local examples)
You want Google to preferentially show a specific version to users in a specific country

Mixing appropriately: a site might use en for international English while also having en-GB for UK-specific content — but both must point to actual distinct URLs with meaningfully different content for the annotation to serve its purpose.

The self-referential requirement

Every hreflang implementation must include a self-referential tag — the page's own URL must appear in the hreflang set pointing to itself:

<!-- On the English UK page: -->
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/page/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/us/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

The first tag is self-referential — the English UK page includes an hreflang annotation pointing to itself.

Why this is required: Google uses the hreflang cluster to understand which URLs are alternate versions of each other. Without the self-referential tag, the page isn't explicitly claiming membership in the cluster from its own perspective — Google may have lower confidence in the annotation.

Common error: including hreflang annotations on the destination pages but not the self-referential tag. The annotation is incomplete and may not fully function.

Hreflang via HTTP header: the non-HTML implementation

Three implementation methods exist for hreflang:

<link> in <head> (most common): standard HTML meta implementation — works for all pages.

HTTP Link header: for pages where modifying HTML is difficult (PDFs, dynamically-served content):

Link: <https://example.com/uk/page/>; rel="alternate"; hreflang="en-GB",
      <https://example.com/us/page/>; rel="alternate"; hreflang="en-US"

XML sitemap: hreflang annotations in the sitemap rather than on the page:

<url>
  <loc>https://example.com/uk/page/</loc>
  <xhtml:link rel="alternate" hreflang="en-GB" href="https://example.com/uk/page/"/>
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/us/page/"/>
</url>

The consistency requirement: you cannot mix implementation methods for the same set of pages. All pages in a hreflang cluster must implement via the same method. A page in a sitemap-based hreflang cluster that also has a conflicting HTML <link> annotation creates confusion that may cause the annotation to be ignored.

Return linking: the bidirectional requirement

Every hreflang cluster must have return links — for each page A that references page B in hreflang annotations, page B must also reference page A:

English UK page:

<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/page/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/us/page/" />

English US page must also include:

<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/page/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/us/page/" />

Why this matters: Google validates hreflang clusters by checking the bidirectional references. A one-directional annotation (A references B, but B doesn't reference A) is treated as an error and may be partially or completely ignored.

The practical challenge: maintaining bidirectional hreflang across large sites (hundreds of pages, multiple language versions) requires systematic CMS or template-level implementation — not manual maintenance of individual pages.

How to use the Hreflang Generator on sadiqbd.com

Generate correct syntax: use the tool to produce properly formatted hreflang tags with correct ISO code casing — eliminating the underscore vs hyphen and case errors that cause silent failures
Verify the complete cluster: generate tags for all language/region combinations at once — the tool produces the complete self-referential set that should appear on every page in the cluster
For sitemap implementation: the generator's output can be adapted to the sitemap <xhtml:link> format if implementing via sitemap rather than HTML <head>

Frequently Asked Questions

Does hreflang work for country-targeting without language differences — like targeting UK vs Australia where both use English? Yes — but Google prioritises language signals over country signals, and content quality for local users. en-GB and en-AU hreflang annotations signal country-specific targeting. Google will preferentially show UK users the en-GB version. However, if the content doesn't meaningfully differ between the two (no UK-specific pricing, no UK spelling, no locally relevant examples), Google may treat them as duplicate content and consolidate them to one URL anyway, regardless of hreflang. The annotations work best when the content actually differs in ways that are meaningful to users from each country — otherwise, a single en international version with geo-targeting via Google Search Console may be more appropriate.

Is the Hreflang Generator free? Yes — completely free, no sign-up required.

Try the Hreflang Generator free at sadiqbd.com — generate valid hreflang tags for any language and region combination instantly.