Hreflang is an attribute of the link element that tells search engines which language or regional version of a page to show to a given user.
The useful thing to know before touching the code: it does not push anything up the rankings. At the same ranking position, it swaps the URL shown in the SERP for the one that suits the searcher's language and country. If the problem is "my site doesn't rank in Germany", hreflang will not solve it. If it is "German users land on the English page", then it will.
When you need it, and how many businesses really do
Google Search Central's documentation lists three cases: content fully translated into several languages; the same language with minor regional variations, such as prices, currency and shipping terms; a translated template with the main content in a single language, which is the situation of forums and pages with user-generated content.
Outside these three cases the attribute adds nothing. On a single-language site aimed at one market it just adds lines to keep up to date. The scope of duplicate content also needs clarifying: Google only treats localised versions as duplicates when the main content remains untranslated, which is the typical case of an English site for the United States, the United Kingdom and Australia where only the currency and commercial details change.
How many UK sites fall within that scope? In the ONS E-commerce and ICT activity bulletin for 2019, the latest in the series, 25.2% of UK businesses with 10 or more employees received website orders from UK customers, 9.9% from customers in other EU countries and 7.3% from customers in the rest of the world. The subset selling across borders is a fraction of the whole. That is where hreflang makes sense: in genuine international SEO projects, or in SEO for manufacturing when the same catalogue has to serve buyers in different countries.
The syntax: two codes, nothing made up
The basic annotation sits in the head section and looks like this:
<link rel="alternate" hreflang="it" href="https://www.example.com/it/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />The value is made up of a mandatory language code in ISO 639-1 format and an optional region code in ISO 3166-1 Alpha 2 format. Google only accepts codes that appear in those two lists. The pair does not have to reflect the country's official language: de-BE, German for Belgium, is valid.
| Value | Valid | Why |
|---|---|---|
it | Yes | ISO 639-1 language code, Italian regardless of region |
it-CH | Yes | Italian for users in Switzerland |
de-BE | Yes | German for Belgium: the language does not have to be the country's official one |
zh-Hant | Yes | Script in ISO 15924 format (Traditional Chinese) |
x-default | Yes | Reserved value for unmatched languages |
IT | No | A region on its own is never a valid value; the language code is required |
en-UK | No | UK is not an assigned code in ISO 3166-1 Alpha 2; the United Kingdom is GB |
en-EU | No | EU and UN are reserved and have no effect on Google Search |
es-419 | No | Not an ISO 3166-1 Alpha 2 code; Latin America cannot be targeted |
One clarification clears up half the doubts: Google does not use hreflang, nor the HTML lang attribute, to work out what language a page is written in. It determines the language from the content with its own algorithms. Declaring hreflang="de" on a page written in English will not make it appear in German searches; it will only make it inconsistent.
The three conditions that make a cluster valid
A set of pages linked by hreflang only works if it is closed and consistent. There are three conditions, and they all apply together.
- Return links. If page A declares B, B must declare A. The mechanism exists to stop any domain from naming itself as an alternate version of a site it does not control. Without a return confirmation, the annotations are ignored or misread.
- Self-reference. Every page also lists itself. The block of annotations is identical on every version in the cluster, and that sameness is what makes it verifiable.
- Absolute, indexable URLs.
https://example.com/it/is fine,/it/is not. And the declared URL must return 200, be canonical and not carry noindex.
The variants do not have to sit on the same domain. A cluster linking example.co.uk, example.de and example.fr is as valid as one built on subfolders, so the choice of domain architecture stays independent of hreflang.
Three implementation methods, and it pays to pick one
Google supports three and treats them as equivalent: link tags in the head, HTTP headers and the XML sitemap.
- Tags in the head are the most common method and the easiest to inspect. On a site with ten languages they become dozens of lines on every page, and every new language means updating all the existing versions.
- HTTP headers are for non-HTML files, PDFs first of all, where there is no
head. - The XML sitemap centralises the annotations in one place and lends itself to automatic generation. The trade-off is that errors cannot be seen by inspecting the page.
Using them together brings no benefit. The documentation spells it out: maintaining three implementations instead of one is simply harder.
x-default also does something nobody talks about
The reserved value x-default indicates the page to show when no variant matches the user's settings. It usually points to a language selector page or to the international version, and needs no language code.
On 8 May 2023 Gary Illyes added a detail you rarely see mentioned on the Google Search Central blog: the URLs declared in hreflang annotations, x-default included, may be used by Google to discover new URLs and so be scheduled for crawling. On a large international site, where it is hard to guarantee every localised page is well linked internally, the cluster also becomes a discovery channel.
Where it really breaks, in numbers
Patrick Stox of Ahrefs analysed 374,756 domains using hreflang: 67% have at least one problem. It is a global sample, but the distribution of errors is instructive because it does not match the advice doing the rounds.
| Problem found | Domains affected |
|---|---|
| Pages without x-default | 56.3% |
| Missing self-referencing tag | 18% |
| Annotations pointing to redirected or unreachable URLs | 16.9% |
| Missing return link | 15.3% |
| Annotations pointing to non-canonical URLs | 8% |
| Incorrect hreflang values | 4.6% |
| lang attribute inconsistent with the annotation | 3.2% |
The least intuitive figure is the first. x-default is missing on more than half of domains and is formally optional; after Illyes's clarification on URL discovery, though, leaving it out costs more than a missing safety net.
The others are almost all maintenance errors rather than first-implementation ones: annotations pointing to URLs that have been moved or deleted, return links left behind after a language was added. A cluster breaks when someone sets up a 301 redirect or changes a slug, and it breaks silently.
The conflict with canonical
Hreflang and rel="canonical" work at different levels and should be used together, with a single working rule: every page in the cluster must have a canonical pointing to itself.
The mistake that wrecks the whole implementation is setting a canonical on every language version pointing to the main version, usually the English one. That asks Google to deindex the local versions while hreflang tells it they should all stay in the index. The two signals contradict each other, and hreflang usually loses. They also belong in two separate tags: rel="canonical, alternate" on a single line is not valid syntax.
A historical detail explains why so many old set-ups are wrong. In the post of 5 December 2011 in which Christopher Semturs announced rel="alternate" hreflang, Google suggested adding a canonical between near-identical pages aimed at different countries. That line now carries an update at the bottom: to simplify implementation, Google no longer recommends using rel="canonical" that way. Anyone who has inherited an international site built a few years ago should check exactly that point.
How to check it, now that Search Console no longer reports it
Search Console's International Targeting report, which listed the hreflang errors found on the site, has been retired. Google's help page says two things at once: the report no longer exists, and hreflang tags are still supported and used. Monitoring has therefore moved entirely to external tools.
For a single published page, Google's documentation mentions two third-party tools: Merkle's testing tool and Aleyda Solis's tag generator. For site-wide checks you need a crawler: Screaming Frog has a dedicated hreflang report that catches missing return links, URLs not returning 200 and invalid codes, and similar checks are in the site audits of Ahrefs and Semrush.
On WordPress, generation is almost always handled by the multilingual plugin, WPML or Polylang, which builds the annotations from the translation relationships set in the CMS. That shifts what you are checking: you are not reviewing hand-written code, you are checking that every translation is linked to its original in the back office. A page that is translated but not associated drops out of the cluster, and nobody notices by looking at the site.
This is why hreflang deserves a recurring check rather than a one-off set-up. It is one of the few technical SEO elements that degrade without leaving a trace: it raises no error in Search Console, produces no 404 error, lowers no score. One day French users start landing on the English version again and nobody connects it to the release three weeks earlier. If you are launching a site across several markets, the time to look is before that happens: our SEO work often starts with a crawl like this.
Hreflang FAQs
No. It does not make a page rank better: at the same ranking position it replaces the URL shown in the SERP with the right one for the user's language and country. In the post announcing it in December 2011, however, Google wrote that one of its aims was to consolidate signals across pages declared as variants of the same content.
Not if it serves a single market. It only makes sense when there are several language versions of the same content, or several versions in the same language aimed at different countries, for example the UK and the US. On a single-language site aimed at one market it adds maintenance with no benefit.
Yes, on one condition: the canonical of every page in the cluster must point to itself. A canonical pointing from the French version to the English one contradicts hreflang and usually makes it ineffective. The two attributes also go in two separate link tags, never combined on the same line.
No, but Google recommends it as a fallback page for users whose language does not match any declared version. It is missing on 56.3% of the domains analysed by Ahrefs, and it is also an annotation Google can use to discover new URLs to crawl.
Because UK is not an assigned code in the ISO 3166-1 Alpha 2 standard: the United Kingdom's code is GB, so the correct value is en-GB. Google lists EU, UN and UK as values reserved for other purposes, which have no effect on Search.
