AI Summary
Hreflang tells search engines which language and regional version of a page to show to which user, and it can be declared in exactly three places: HTML head link tags, an HTTP Link header, or an XML sitemap. The method matters far less than the rules, because almost every failed implementation fails on reciprocity, self reference, or a page in the cluster that is not indexable.
- Pick one delivery method per site. Declaring the same cluster twice creates conflicts nobody catches.
- Every annotation must be reciprocal and every page must reference itself, or Google discards the set.
- Use ISO 639-1 for language and optional ISO 3166-1 alpha 2 for region. A region code alone is invalid.
- A noindex or canonicalized page inside a cluster breaks the whole cluster, not just that one entry.
Hreflang has a reputation for being difficult, and it is, but not for the reason people assume. The syntax is trivial. What makes it hard is that hreflang is one of the few SEO annotations that is only valid as a complete, mutually consistent set. A title tag that is wrong on one page is wrong on one page. An hreflang cluster where one page forgets to point back is not partially valid, it is discarded. That all or nothing behaviour is why hreflang rewards generation from a single source of truth and punishes hand editing.
This page covers the three delivery methods, the rules that apply to all of them, and how to test an implementation before it ships. For the specific edge cases, such as the same language across many countries or a shared checkout, the hreflang scenarios guide works through them in turn.
The three delivery methods
All three carry identical information. Choose on the basis of site size, file types and how you intend to audit the result.
HTML head link tags. One tag per cluster member, in the <head> of every page in the cluster.
<link rel="alternate" hreflang="en-us" href="https://example.com/us/" /> <link rel="alternate" hreflang="en-gb" href="https://example.com/gb/" /> <link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
Simple to reason about, visible in view source, and it scales badly. A cluster of forty locales puts forty tags in the head of forty pages, which is 1,600 tags to keep synchronized.
HTTP Link header. The same data in the response header, which is the only option for files that have no HTML head.
Link: <https://example.com/gb/>; rel="alternate"; hreflang="en-gb",
<https://example.com/fr/>; rel="alternate"; hreflang="fr-fr"Use it for PDFs and other non HTML assets. Its drawback is that it is invisible to anyone inspecting the page source, so implementations rot quietly.
XML sitemap. The cluster is declared once per URL inside the sitemap using the xhtml namespace.
<url> <loc>https://example.com/gb/</loc> <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/gb/"/> <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/us/"/> </url>
This is the method to prefer at scale. It keeps page weight down, it centralizes the annotations in one auditable file, and a diff of two sitemap builds shows you exactly what changed. The catch is that the generator becomes a critical dependency: if it silently drops a locale, every cluster it touched breaks at once. A fuller comparison lives in where to declare hreflang.
| Method | Best for | Page weight cost | Auditability | Works on non HTML files |
|---|---|---|---|---|
| HTML head link tags | Small and mid size HTML sites | High on large clusters | Easy, visible in view source | No |
| HTTP Link header | PDFs and other non HTML assets | None on the HTML payload | Poor, invisible without header inspection | Yes |
| XML sitemap | Large sites and frequent locale changes | None | Best, one file to diff and validate | Yes, by URL entry |
Crawlability Essentials
Hreflang is a set of instructions about URLs, so every URL in the set has to be reachable on its own terms. Three crawl level failures account for most broken clusters.
- A cluster member is blocked in robots.txt. The crawler never fetches it, never sees its return annotation, and therefore treats the pairing as unconfirmed. Blocking a locale folder while still listing it in hreflang is self defeating.
- A cluster member redirects. Annotations must point at the final URL. Pointing at a URL that 301s means the return tag will be on a different address than the one you declared, and reciprocity fails.
- Relative URLs. Hreflang requires absolute URLs including the protocol. A relative href is not a minor style issue here, it is invalid.
Geo redirects deserve their own warning. Automatically bouncing users to a locale based on IP address will also bounce the crawler, which typically crawls from one country. The result is that only one version is ever seen. If you must detect location, offer a suggestion banner rather than a forced redirect.
Indexation Optimization
The rule practitioners underestimate: hreflang only works between pages that are eligible to be indexed. Two settings quietly disqualify a page.
The first is noindex. A noindexed page cannot be returned as an alternate, so including it in the cluster is at best inert and at worst confusing to your own auditing. The second is a cross canonical. Each page in a cluster needs a canonical pointing at itself. If the German page canonicalizes to the English page, you have told Google that the German page should not exist as a separate result, and no amount of hreflang will override that. Canonical and hreflang are frequently implemented by different teams, which is exactly how this conflict survives review. The canonical tags reference covers the interaction in detail.
Language and region codes are the other reliable source of invalidation:
- Language uses ISO 639-1, two letters, and it is mandatory.
- Region uses ISO 3166-1 alpha 2, two letters, and it is optional.
- A region code cannot appear alone. Write
hreflang="en-us", neverhreflang="us". - Watch the codes that do not match intuition: the United Kingdom is
gb, notuk. Traditional Chinese for Taiwan iszh-tw. Latin America is not a region code at all.
Performance and Experience
On large multilingual sites the delivery method has measurable delivery cost. A forty locale cluster rendered as head tags adds real bytes to every document and pushes meaningful content further down the HTML, which is the practical argument for moving to the sitemap method rather than a purely theoretical one.
The experience side matters as much as the crawl side. Hreflang influences which version appears in results, but a user who lands on the wrong version still needs an obvious, crawlable way to switch. Build the language selector as real anchor tags with href values, not as a JavaScript dropdown that changes location on change. The second version gives crawlers no links to follow and gives users nothing to open in a new tab.
Two smaller points that come up in review: do not use a country flag to represent a language, because languages are not countries and Spanish speakers outside Spain notice. And keep the selector in the same place on every template, because users who need it are already slightly lost.
Testing before and after deployment
Hreflang is generated, so test the generator rather than spot checking pages.
- Validate the set, not the page. Crawl the site and extract every annotation, then check programmatically that for each pair A points to B and B points to A. Any crawler that exports hreflang can feed this, and it takes a few lines of script to verify.
- Confirm self reference on every member. A missing self reference is easy to miss by eye and invalidates nothing else, so it survives manual review indefinitely.
- Check status codes of every target. Every annotated URL should return 200. Filter for anything that does not.
- Check indexability of every target. Pull the robots directive and the canonical for each URL in the cluster and flag any that are noindexed or canonicalized elsewhere.
- Diff each deploy. Compare the annotation set before and after release. Silent removals during a template change are the usual cause of an implementation that worked last quarter.
For a catalogue of the specific mistakes worth searching your own crawl for, see hreflang implementation errors.
| Symptom | Likely cause | How to confirm |
|---|---|---|
| Annotations present but nothing changes in results | Non reciprocal return tags | Extract all pairs from a crawl and test both directions programmatically |
| One locale never appears in its market | That page is noindexed or canonicalized to another locale | Pull the robots directive and canonical for every cluster member |
| Wrong country version shown to users | Region code invalid or missing, or language code used alone | Validate every code against ISO 639-1 and ISO 3166-1 alpha 2 |
| Search Console reports no return tags | Annotation points at a URL that redirects | Check that every annotated URL returns 200 with no redirect hop |
| Only one version ever gets crawled | Automatic IP based redirect is bouncing the crawler | Request the page with a non local IP and inspect the response status |
| Implementation worked, then stopped after a release | Generator dropped locales during a template change | Diff the annotation set between the last two deploys |
FAQ
Yes. If page A declares page B as an alternate, page B must declare page A. Google treats non reciprocal annotations as unconfirmed and ignores them, which is the single most common reason a correct looking implementation has no effect.
Yes. Every page in a cluster must list every member of the cluster including itself. A self referencing entry is what makes the annotation set identical on all pages, which in turn makes it cacheable, testable and much easier to generate correctly.
It nominates the URL to serve when no other language or region entry matches the user. It is not a fallback for missing translations and it is not required. Use it for a genuine language selector or a global default page, and leave it out if you do not have one.
Yes, and you must be careful. Each page in an hreflang cluster needs a self referencing canonical. If a localized page canonicalizes to the original language version, you have told Google to drop it, and the hreflang cluster collapses along with it.
Pick one and only one. HTML head link tags suit small and mid size sites, the HTTP Link header is the only option for non HTML files such as PDFs, and the XML sitemap method scales best and is by far the easiest to audit. Declaring the same cluster in two places invites conflicts.
Bing reads hreflang but leans more heavily on the content language meta tag and on server location signals. Yandex supports it. Baidu does not use it. If those markets matter, do not rely on hreflang alone to route users to the right version.
Yes. DeepCrawl rebranded to Lumar in 2022, which is why the source link on this page resolves to a lumar.io address. The hreflang guidance itself is unaffected by the name change.
Source: https://www.lumar.io/ebooks/international-seo-guide/hreflang-best-practice
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
