What Is Hreflang and How Does It Work for International SEO
Hreflang is an annotation that tells Google which language and, optionally, which region each version of a page is for. If a site has an English page for the United States, an English page for the United Kingdom, and a French page for France, hreflang connects them as versions of the same content so that Google can show searchers the one that matches their language and location. It works best when every version in the set points to every other version, including itself. Google ignores any pair of annotations that is not returned from the other side, but it still processes the pairs that are.
How Hreflang Values Are Built
An hreflang value is a language code, optionally followed by a region code. Google’s documentation on localized versions specifies the formats: the language “in ISO 639-1 format,” followed by an optional region “in ISO 3166-1 Alpha 2 format.”
| Value | Meaning |
|---|---|
| <!–INLINECODE0–> | German content, for any region |
| <!–INLINECODE1–> | English content for users in the United Kingdom |
| <!–INLINECODE2–> | German content for users in Spain |
| <!–INLINECODE3–> | Chinese in Traditional script |
| <!–INLINECODE4–> | The fallback for users whose language matches no listed version |
Google’s documentation sets three rules for valid values:
- Only standard codes work. “Only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported; other codes that aren’t listed in those standards, such as es-419, aren’t supported.”
- A region code cannot stand alone. “You can’t specify the country code by itself,” because “Google doesn’t automatically derive the language from a country code.” Google’s example:
beis the code for Belarusian, not Belgium. - Case does not matter to Google, but uppercase regions such as
en-GBfollow the ISO convention.
Three Ways to Implement It
Google’s documentation lists HTML, HTTP headers, and sitemaps, and states: “The three methods are equivalent from Google’s perspective.”
| Method | Where the annotations live | Where it fits |
|---|---|---|
| HTML | <!–INLINECODE7–> elements in each page's <!–INLINECODE8–> | Sites that can edit page templates |
| HTTP headers | The <!–INLINECODE9–> header in the server response | Non-HTML files such as PDFs |
| Sitemap | <!–INLINECODE10–> entries under each URL in the XML sitemap | Large sites that generate annotations centrally |
In HTML, each version carries the full set:
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/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" />The Rules Every Method Shares
- Self-reference. “Each language version must list itself as well as all other language versions.”
- Return links. “If two pages don’t both point to each other, the tags will be ignored.” Google explains why: so that “someone on another site can’t arbitrarily create a tag naming itself as an alternative version of one of your pages.”
- Full URLs. Alternate URLs “must be fully-qualified, including the transport method (http/https),” and they “do not need to be in the same domain.”
- A fallback for a shared language. With separate pages for Ireland, Canada, and Australia, Google suggests a generic
enpage for English speakers everywhere else.
When a complete set is hard to maintain, Google allows a partial one: “you can omit some languages on some pages; Google will still process the ones that point to each other.” It adds that newly added language pages should still be linked both ways with the site’s original or dominant language versions.
x-default
The reserved x-default value “is used when no other language/region matches the user’s browser setting.” Google notes that “it was designed for language selector pages and so it will work best with those,” and that no language code is needed for it. In a May 8, 2023 post, Google wrote that the value “is potentially underused by sites that already use hreflang.”
Errors to Check
- Missing return links, which make the affected pair of annotations void.
- Invalid codes: a region without a language, an unsupported code, or an underscore instead of a hyphen.
- Missing self-reference in a template.
- Relative URLs.
- Targets that redirect, return errors, carry
noindex, or point their canonical elsewhere. Translated versions should each be canonical to themselves; Google’s canonical documentation asks for a canonical page in the same language. Same-language regional pages are a different case: where they carry essentially the same content, Google’s multi-regional guidance says to pick a preferred version and userel="canonical"together withhreflangso that “the correct language or regional URL is served to searchers.”
Validating an Implementation
Search Console no longer reports hreflang errors in a dedicated report. Google’s documentation updates for August 24, 2022 note: “Removed references to the deprecated International Targeting report in Search Console.” Guides that send readers to that report are out of date.
Today the checks are:
- Crawl the site with a tool that reads hreflang and reports missing return links, invalid codes, and non-indexable targets.
- Use the URL Inspection tool on key pages in each market to see how Google processes them.
- Confirm in the Page indexing report that each version you expect to be indexed is indexed; a regional copy you pointed at a preferred version will show as an alternate instead.
- Repeat after template changes, new locales, and URL migrations, when hreflang sets break without any visible symptom on the page.