Definition:

Hreflang is an attribute that tells Google which alternative versions of a page are intended for different languages or regions. It connects URLs with equivalent content so the search engine can show the variant it considers most appropriate for a user’s language and, when specified, location.

Hreflang does not translate a page, change its content, or automatically redirect a visitor. Its purpose is to describe the relationship between localized versions in search, not to choose which version a browser must open or to guarantee a particular ranking.

Índice de contenidos

1 How hreflang works
2 Language, region, and x-default codes
3 Implementation methods
4 Relationship with canonical and localized content
5 Common errors and verification

How hreflang works

The implementation creates a set of alternative URLs. Each page must declare its own URL and the other variants that belong to the set. References must be reciprocal: if the Spanish version points to the English version, the English version must also point to the Spanish version.

The specified URLs must be absolute, including the protocol and domain. Versions can be located in directories, subdomains, country-code domains, or even different domains. The URL structure does not determine the language or region by itself, so the attribute makes that correspondence explicit.

Google can discover alternative versions without hreflang, but a correct declaration helps it interpret their relationship. If return links are missing, codes are invalid, or a URL cannot be crawled, the affected annotations may be ignored without necessarily causing an indexing problem for the entire site.

Language, region, and x-default codes

An hreflang value contains a language code and can include a regional code. The language is required and the region is optional, so using a country alone is not valid.

Language: Usually uses an ISO 639-1 code, such as es, en, fr, or de.
Language and region: Combines the language with an ISO 3166-1 Alpha 2 code, such as es-MX, en-GB, or fr-CA.
Script variation: Can use an ISO 15924 code when writing systems need to be distinguished, such as zh-Hans and zh-Hant.
Capitalization: Values are case-insensitive, although the usual convention writes the region in uppercase.
x-default: Identifies a fallback URL for users whose language or region does not match a specific variant.

A generic version can coexist with regional variants. For example, es can target Spanish speakers without a specific region, while es-MX identifies a version prepared for Mexico. Regional differences should actually exist on the page, such as currency, availability, terms, or vocabulary, rather than being limited to a different code.

Implementation methods

Google supports three methods for communicating localized versions. All three are equivalent from a search perspective, so it is usually best to choose the one that is easiest to maintain.

HTML: Add link elements with rel="alternate", the hreflang value, and the alternative URL inside the head of each page.
HTTP header: Send the alternatives through the Link header, an option that is especially useful for non-HTML files such as PDF documents.
XML sitemap: Include xhtml:link elements with every variant for each URL in the sitemap.

A basic pair of pages could declare hreflang="es" for the Spanish URL and hreflang="en" for the English URL. Both must include the same set as well as a reference to themselves. Combining all three methods provides no additional search benefit and can increase inconsistencies if their values do not match.

Relationship with canonical and localized content

Hreflang and rel canonical serve different purposes. Canonical identifies the preferred URL among duplicate or very similar pages, while hreflang connects alternatives intended for language or regional audiences. A localized page should normally use a self-referencing canonical, rather than pointing its canonical to another language version that is intended to remain in search results.

Alternatives should represent essentially the same page or need, although they can adapt prices, currency, availability, examples, or regional terms. Hreflang should not connect a product page in one language with a category or a different article in another. Equivalence is assessed through purpose and main content, not only through the URLs’ positions within the site.

Google determines language from visible content, not from hreflang or only from the HTML lang attribute. If only the navigation is translated and the main content remains the same, the pages may still be treated as duplicates. Hreflang does not replace genuine content localization.

Common errors and verification

Errors usually appear when the page set is no longer consistent. A review must check every URL and every relationship, not just the presence of a tag on one version.

Missing self-reference: A page lists other variants but does not include itself.
No return link: One version points to another that does not return the reference.
Incorrect codes: A region is used without a language, an unsupported code is entered, or language and country are confused.
Relative or defective URLs: The protocol or domain is missing, the URL contains a typo, or it redirects to a different destination.
Different sets: Equivalent pages list incompatible groups of alternatives.
Conflicting canonical: The URL declares another version as canonical even though it should remain an independent alternative.
Unavailable pages: Alternatives return errors, are blocked, contain noindex, or cannot be crawled.
Incorrect matching: Pages that do not satisfy the same intent or are not equivalent versions are connected.

Verification can examine rendered HTML, HTTP headers, or the sitemap, as well as crawl a complete sample of sets and their responses. Google’s documentation on localized versions describes the supported formats and codes. A valid implementation supports selection of the appropriate version, but it does not guarantee traffic, conversions, or automatic ranking improvements.