When a site has versions in several languages or targeted at different countries, a question comes up that hreflang exists specifically to answer: of all the equivalent versions of the same page, which one should Google show a user searching in French from France, or in Spanish from Mexico versus Spain? Without this signal, Google decides on its own, based on indirect signals, and that decision doesn't always match what the site itself would have chosen.
What hreflang solves and what it doesn't
The hreflang tag tells Google which language or region version to show each user, but it's important not to confuse it with a canonicalization tool: it doesn't solve duplicate content between versions (see the canonicalization guide), because each language version is, by definition, a distinct document, with its own indexable URL, its own self-referential canonical, and its own ability to rank independently. hreflang only acts as an audience router between documents that are already legitimate and distinct from each other.
Basic syntax: language code, region code, and the special x-default value
Each hreflang relationship is declared with a language code in ISO 639-1 format (es, en, fr) and, optionally, a region code in ISO 3166-1 format (es-MX for Mexican Spanish, en-GB for British English), separated by a hyphen:
<link rel="alternate" hreflang="es" href="https://www.yourdomain.com/" />
<link rel="alternate" hreflang="es-MX" href="https://www.yourdomain.com/mx/" />
<link rel="alternate" hreflang="en" href="https://www.yourdomain.com/en/" />
<link rel="alternate" hreflang="x-default" href="https://www.yourdomain.com/" />The x-default value is special: it indicates which version to show a user whose language or region doesn't match any explicitly declared one (for example, a user browsing in German on a site that only has Spanish and English). It's not mandatory, but its absence means Google decides that situation by default with no guidance from the site.
The rule that causes the most violations: mandatory reciprocity
The single most important technical condition, and the one most often overlooked, is that hreflang relationships must always be bidirectional: if the Spanish version links to the English version as an alternative, the English version must link back to the Spanish one, and both must link to themselves too (self-reference). If Google finds a one-way relationship (A points to B, but B doesn't point back to A), it considers it invalid and ignores it entirely, with no visible error beyond a warning in Search Console that many teams never check.
ES page must include: hreflang="es" (to itself) + hreflang="en" (to the EN version)
EN page must include: hreflang="en" (to itself) + hreflang="es" (to the ES version)
If only one of the two directions exists, Google discards the entire relationship.Three ways to implement hreflang, and which fits which site
The most common implementation is in the HTML <head>, as shown above, suitable for small to medium sites. For very large sites, where adding these tags to every page considerably bloats the HTML's weight, there's the alternative of declaring hreflang directly in the XML sitemap, grouping all the relationships for a given set of pages in the sitemap file instead of in each individual HTML page. A third, less common option is declaring it in the HTTP header (Link:) for non-HTML resources, such as PDFs available in several languages.
Implementation mistakes that make Google ignore the whole signal
The most frequent is the already-mentioned lack of reciprocity. The second is a malformed language or region code (using es_ES with an underscore instead of es-ES with a hyphen, or reversing the order to ES-es), which the spec doesn't recognize as valid. The third is pointing hreflang at a URL that isn't that page's canonical, or that returns a redirect or a 404: hreflang should always point to each version's final, indexable, self-canonicalized URL. The fourth, more subtle, is declaring hreflang toward a version that has noindex: Google can't send traffic to a page it has explicitly excluded from the index, so that relationship has no effect either.
hreflang and subdomains, subfolders or separate domains: the structure doesn't matter
An important nuance: hreflang works exactly the same regardless of whether language versions live in subfolders (yourdomain.com/en/), subdomains (en.yourdomain.com) or completely separate domains (yourdomain.co.uk). Choosing between these three structures is an architecture and authority-management decision (a separate domain starts with none of the main domain's inherited authority), not a technical limitation of hreflang, which is declared the same way in any of the three cases.
How to actually verify hreflang is working
Search Console includes a specific hreflang report that shows detected reciprocity and format errors, but it only covers part of the possible problems; the most reliable check in real audits combines that report with a crawling tool that extracts every hreflang relationship declared on the site and automatically cross-references them to detect one-way relationships, invalid language codes, or destinations that don't return 200.
Frequently asked questions
Do I need hreflang if I only have a Spanish version and an English one?
Yes, if both live on the same domain and you want Google to show the right version to each user based on their language. Without hreflang, Google might show the wrong version to a user, or even treat both as near-duplicate content between each other if they're very similar in structure.
Does hreflang improve each version's ranking?
It isn't a ranking factor in itself: having it doesn't make a page rank better on its own. What it does is direct Google toward the correct version for each audience, which improves perceived relevance for the user and, with that, indirectly, behavioral metrics that do matter.
What happens if my site has 10 languages and I get just one wrong?
It depends on the type of error: a reciprocity error between two specific languages usually only invalidates that relationship between those two, without affecting the rest of the set, as long as the other relationships are correctly declared independently.
Should I use hreflang even if I only have regional variants of the same language?
Yes, it's a perfectly valid use case: for example, es-ES and es-MX with different pricing and terminology but the same language. hreflang works just as well for distinguishing regions as for distinguishing languages.
Can I use hreflang without actually having translated content?
Technically yes, but it doesn't make sense to: hreflang assumes each declared version is a real, relevant document for that audience. Declaring hreflang toward a page that isn't actually translated (or that redirects back to the original version) creates a bad user experience and contradicts the signal itself.