Hreflang Tags: How They Work and the Mistakes That Break Them

Hreflang tags tell Google that several URLs are the same page in different languages or for different regions, so it can show each searcher the version that fits them. They do not push a page higher in the results; they swap the right URL into the spot a page has already earned.

That distinction explains most of the confusion around them. Google's documentation describes hreflang as a way to point users to the most appropriate version of a page by language or region, and it never calls it a ranking signal. It also clears up a common worry about duplicate content: localized pages are only treated as duplicates if the main content stays untranslated. A properly translated Vietnamese page and its English original are two different pages that happen to share a topic, and hreflang simply tells Google how they relate.

There are three equivalent ways to declare the relationship, and Google says it treats them the same. The first is a link element in the head of each page, with rel="alternate", an hreflang value such as "vi" or "en-GB", and an href pointing to the alternate URL. The second is an HTTP Link header, which is the only option for files that have no HTML head, such as PDFs. The third is a sitemap, where each url entry lists every variant as an xhtml:link child, including the entry itself. You can combine methods, but Google notes there is no benefit in doing so and it makes the setup harder to keep consistent. Pick one and apply it everywhere.

Whichever method you choose, four rules decide whether the annotations work. First, every version must list itself and every other version, so an English page, a Vietnamese page and a French page each carry the same set of three entries. Second, the links must be reciprocal. Google is explicit that if two pages do not point to each other, the tags are ignored, a safeguard that stops a stranger's site from declaring itself your French version. Third, URLs must be fully qualified, including https; relative paths and protocol-relative addresses are not accepted. Fourth, the codes must follow the standards: a language code from ISO 639-1, optionally followed by a dash and a region code from ISO 3166-1 Alpha 2.

The code rule trips up more people than it should. A region cannot stand alone, so "be" means Belarusian rather than Belgium. Underscores such as en_us are invalid; the separator is a dash. Google also says that values outside the standards, including es-419 for Latin American Spanish and reserved codes like EU or UN, have no effect. The United Kingdom is the familiar trap: the ISO code is GB, not UK, and Ahrefs has observed that Google tolerates UK even though it is not the correct code.

Then there is x-default, a reserved value for the page to use when no other language or region matches the searcher's browser settings. Google says it was designed for language selector pages and works best with them, though many sites point it at their main language instead. It is optional, but without it you leave the fallback choice to Google.

How often does all this go wrong? When Ahrefs analysed 374,756 domains that use hreflang in 2023, 67% had at least one problem. The most common was a missing x-default on 56.3% of domains, followed by missing self-references on 18%, annotations pointing to redirected or broken pages on 16.9%, missing return tags on 15.3%, and links to non-canonical URLs on 8%. Only 4.6% used invalid codes, which suggests the syntax is the easy part and consistency across a whole site is the hard part.

The canonical conflict deserves its own warning. Hreflang should point to canonical URLs, and each language version should carry a self-referencing canonical. If your Vietnamese and French pages both declare the English page as canonical, you are telling Google the translations are copies of the original, and the English version can end up shown to readers in every market. The same logic applies to alternates that are noindexed, blocked in robots.txt or returning 404: Google cannot read a return link on a page it cannot fetch, so the whole set can be discarded.

In practice, the safest approach is to generate hreflang from the same data that generates your URLs rather than typing it by hand. In the Next.js App Router, for example, the alternates.languages field in the metadata object produces the link elements from one map of language codes to absolute URLs, and the same map can feed your sitemap. After deployment, check the page source of two language versions side by side and confirm they list an identical set. If they match, include themselves and point only to live, canonical, indexable URLs, you have avoided every error on the list above.