Three ways to implement hreflang
Google accepts three equivalent methods: link elements in each page's HTML head, HTTP headers (handy for PDFs) or entries in your XML sitemap. Pick whichever your CMS maintains most reliably. Using all three brings no extra benefit in search and only multiplies the chances of inconsistencies.
The syntax
Values start with an ISO 639-1 language code (en, es, fr), optionally followed by an ISO 3166-1 alpha-2 region code: en-US for English aimed at the United States, es-MX for Spanish aimed at Mexico. A region code on its own is invalid. The x-default value names the fallback page for users whose language matches no version, typically a language selector.
Every page must list all versions, including itself, and every version must link back to the others. Without return links, Google ignores the annotation.
What hreflang does not do
Google states that it does not use hreflang or the HTML lang attribute to detect a page's language; its own systems do that. Hreflang does not redirect visitors and does not boost rankings either. It only helps Google serve the right variant among pages it has already indexed.
To check an implementation, run the site through a crawler that reads hreflang, such as Screaming Frog or Sitebulb: it flags missing return links and invalid codes. Then filter Search Console clicks by country to spot a version being served to the wrong market, for example your Spanish page ranking for English queries in Texas.
Common mistakes
- Missing return links between versions.
- Wrong codes: en-UK instead of en-GB, or es-LA, which is not a valid region.
- Annotations pointing to redirected, broken or noindexed URLs.
- A canonical on one language version pointing to another language.
- Automatic IP-based redirects that keep crawlers from seeing every version.