Direct answer

Build one hreflang cluster for each set of equivalent localized pages. Every included URL should return successfully, identify itself and the other variants with fully qualified URLs, use supported language or language-region codes, and reciprocate the relationships.

What to remember
  • Hreflang maps equivalent localized URLs; it does not translate content, detect language, or replace canonicalization.
  • Every page in a cluster should list itself and every other included variant.
  • Reciprocal relationships matter because Google may ignore one-way annotations.
  • HTML, HTTP headers, and XML sitemaps are equivalent implementation methods for Google Search; choose one maintainable source of truth.

01

Preconditions

Hreflang work starts with a URL inventory, not a tag generator. Identify every localized version of each page and decide which URLs are genuinely equivalent alternatives.

A valid cluster might contain:

English, no region: https://example.com/en/shipping
English for Canada: https://example.com/en-ca/shipping
French for Canada: https://example.com/fr-ca/expedition
German: https://example.com/de/versand

The pages do not need identical wording, design, prices, or legal text. They should serve the same underlying user task for different languages or regions. A German shipping-policy page is an alternate for the English shipping-policy page. It is not an alternate for an English returns page merely because both belong to customer support.

Google supports hreflang annotations in HTML, HTTP response headers, and XML sitemaps. The methods are equivalent for Google Search. Using all three provides no search advantage and creates three places for humans to manufacture disagreement. Choose the method your publishing system can update reliably. [1]

Before implementation, confirm:

  • Each locale URL is public and crawlable.
  • Each page returns a stable successful response.
  • Canonical URLs are deliberate.
  • The main content is actually localized where translation is claimed.
  • Language and region codes are valid.
  • The application can generate the same cluster on every member page.
  • Redirects, mobile variants, and parameters do not create accidental alternates.

02

Ordered process

  1. Group pages by equivalent intent.

Create one record per content concept, then attach locale variants to that record.

Concept: Shipping policy
Variants: en, en-CA, fr-CA, de

Do not generate hreflang by mechanically replacing /en/ with /fr/ unless the target page exists and serves the same purpose. Broken localization systems often produce convincing-looking annotations to nonexistent, redirected, or semantically unrelated URLs.

  1. Choose supported locale codes.

Google supports a language code and an optional region code separated by a hyphen.

Examples:

en
en-US
en-GB
fr-CA
de-CH
zh-Hant
zh-Hans-US

The language comes first. A country code alone is invalid because Google does not infer a language from the country. Use fr-BE, nl-BE, or de-BE for language audiences in Belgium rather than BE. Google documents ISO 639-1 language codes, ISO 3166-1 Alpha 2 region codes, and supported script codes for cases such as simplified and traditional Chinese. [1]

  1. Use fully qualified destination URLs.

Every alternate should include the complete scheme and host.

Use:

https://example.com/fr-ca/expedition

Do not use:

/fr-ca/expedition
//example.com/fr-ca/expedition

Variants may live on different domains or subdomains. The cluster can connect a .com, a country-code domain, and a subdomain when those URLs are the intended localized alternatives. [1]

  1. Include a self-reference.

Each page must list itself in addition to every other included variant.

For a four-page cluster, every page should expose the same four relationships:

en → English URL
en-CA → Canadian English URL
fr-CA → Canadian French URL
de → German URL

The self-reference establishes that the current page participates in the cluster. Omitting it creates incomplete sets that are harder to validate and can be ignored.

  1. Make the relationships reciprocal.

If the English page names the French page as an alternate, the French page should name the English page. Google says nonreciprocal annotations may be ignored. This protects a site from being declared an alternate by an unrelated third party. [1]

In large systems, complete pairwise maintenance can become expensive. Google notes that it can process the reciprocal relationships that do exist, but newly added locale pages should at least link back to the originating or dominant language pages. The better engineering solution is still a centralized locale map that emits identical clusters deterministically.

  1. Select one delivery method.

HTML is appropriate when every page template can emit the cluster in the document head.

HTTP headers are useful for non-HTML resources such as localized PDFs.

Sitemaps are useful when locale relationships are managed centrally or page templates cannot be trusted. Each sitemap URL entry still lists every alternate, including itself. The additional alternate entries do not count toward the normal sitemap URL limit. [1]

  1. Align canonical signals.

Each genuinely distinct localized page should normally identify a canonical URL in the same language. Google recommends choosing the same-language canonical, or the closest available substitute when no same-language canonical exists. Do not canonicalize every translated page to the English page and then expect hreflang to preserve the translations as independent search results. [2]

Regional duplicates in the same language require more judgment. If en-US and en-CA contain meaningfully different prices, availability, legal terms, or inventory, self-canonicals can be appropriate. If several URLs are nearly identical duplicates, select the preferred canonical while keeping hreflang relationships coherent.

  1. Validate the rendered output.

Check representative clusters for:

  • Successful status codes
  • No redirect targets
  • Fully qualified URLs
  • Correct protocol and hostname
  • Valid language and region codes
  • Self-reference
  • Reciprocal reference
  • Consistent cluster membership
  • Same-language canonicals
  • Crawlable pages
  • No accidental staging URLs
  • No mixed production and preview hosts

Do not validate only the source template. Inspect actual rendered pages, response headers, or generated sitemaps.

  1. Monitor changes as a graph.

When one locale launches, moves, or disappears, update the whole affected cluster. A localization deployment is not complete merely because the new page exists. Every surviving variant must receive the updated relationship set.

Store cluster tests in the build pipeline. A reasonable validator should fail when a destination is missing, redirected, duplicated, malformed, nonreciprocal, or assigned conflicting locale codes.

03

Failure cases

One-way annotations. The English page references German, but the German page does not reference English. The relationship may be ignored.

Country codes used as languages. US, CA, or BE is supplied without a language.

Generic English omitted. A site publishes only en-US, en-CA, and en-AU, leaving other English speakers without a catchall. Google recommends a generic en option when several regional English pages exist. [1]

Canonical and hreflang conflict. Every localized page canonicalizes to one global English page. The alternate cluster and canonical cluster describe incompatible architectures.

Redirecting alternates. The annotation points to an old locale URL that redirects to another path. Update the alternate to the final canonical URL.

Automatic path replacement. The system creates alternate URLs by string substitution even when the corresponding translation was never published.

Three conflicting implementations. HTML, headers, and sitemaps disagree. The site gained no search advantage from triplication, only three bureaucracies with separate opportunities to be wrong.

04

Completion criteria

The implementation is complete when every intended locale page belongs to one semantically correct cluster, lists itself and the other variants, receives reciprocal references, uses supported codes and fully qualified URLs, returns successfully, and aligns with the page’s canonical signals.

The same cluster should be generated from one controlled dataset across HTML, headers, or sitemaps. Build tests should detect missing destinations and inconsistent membership before release. Manual checks should confirm that the visible content language and regional purpose match the assigned code.

Continue with Hreflang x-default for unmatched-language fallback behavior, Locale-Adaptive Pages SEO when content changes by IP or request headers, and Multilingual Canonical Tags when representative URL selection conflicts with localization.

References

Sources behind this record

  1. Tell Google about localized versions of your page — Google Search Central (accessed August 2, 2026)
  2. How to specify a canonical URL with rel="canonical" and other methods — Google Search Central (accessed August 2, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.

Claim limit

Valid hreflang annotations help Google understand localized alternatives but do not guarantee that a particular regional URL will rank, be indexed, or replace another result for every user.