Hreflang is the piece of technical SEO that most often gets implemented once, incorrectly, and then left alone for years. The concept is straightforward — tell Google which language or regional version of a page to show which users — but the implementation has several requirements that are easy to miss and produce silent failures. There is no error message when hreflang is wrong; it simply stops working, and your German visitors keep landing on the English page.
What Hreflang Does
Hreflang annotations tell search engines that several URLs are the same content in different languages or for different regions, and which one to serve to whom.
Critically, hreflang is not a ranking factor. It does not make any version rank higher. It influences which version is shown once a page qualifies to rank. The benefit is fewer visitors bouncing off a page in the wrong language, and less risk of your versions competing with each other.
You need it when you have genuinely equivalent content at different URLs for different audiences — English and Spanish versions, or UK and US variants of the same page. You do not need it for a single-language site, and you should not use it to connect pages that are different content rather than translations.
The Syntax
Three implementation methods exist. HTML <head> tags are the most common:
<link rel="alternate" hreflang="en-us" href="https://example.com/us/page" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/seite" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />The value format is language, optionally followed by region:
en— English, any regionen-gb— English, United Kingdomde-at— German, Austria
Language codes are ISO 639-1. Region codes are ISO 3166-1 Alpha 2. Two mistakes recur constantly:
en-ukis invalid. The ISO country code for the United Kingdom is GB. Useen-gb.- Region alone is invalid.
hreflang="us"does not work. Language is mandatory; region is optional.
You can also deliver hreflang via XML sitemap — better for large sites, since you manage it centrally rather than in every page’s head — or via HTTP headers, which is the only option for non-HTML files like PDFs.
Pick one method. Mixing them across the same URL set causes conflicts.
The Rule Everyone Breaks: Self-Referencing
Every page in an hreflang set must list itself, alongside every other version.
If you have three language versions, each of the three pages must contain all three annotations — including its own. A German page that lists only the English and French versions is invalid, and Google will ignore the entire set.
The reason is that hreflang must be reciprocal. Google verifies that if page A claims page B is its German version, page B claims A back. Self-references are part of how that confirmation works. Without them, the relationship is unverified and discarded.
This means the annotation block is identical on every page in the set, which is actually convenient: generate it once and output it everywhere. Missing self-references — reported in some tools as “no self-referencing hreflang” — are the single most common cause of hreflang silently doing nothing.
x-default
<link rel="alternate" hreflang="x-default" href="https://example.com/" />x-default specifies the fallback for users whose language and region do not match any version you have declared. A Japanese speaker visiting a site with English, German and French versions gets whatever x-default points at.
It is optional but recommended. Point it at a language selector page if you have one, or at your most broadly useful version — usually English. Do not point it at a page that redirects based on IP, because that reintroduces the ambiguity you are trying to remove.
Hreflang and Canonical Tags
This is where most implementations break, and the rule is short:
Each page’s canonical must point to itself. Never to another language version.
Hreflang and canonical are answering different questions. Hreflang says “these are alternate versions for different audiences.” Canonical says “this is the authoritative version of this content.”
If your German page canonicalises to the English page, you have told Google the German page should not be indexed at all — and hreflang cannot connect a set that includes a non-indexed page. The two directives contradict each other, and the canonical wins. Your German page disappears.
Correct configuration on the German page:
<link rel="canonical" href="https://example.com/de/seite" />
<link rel="alternate" hreflang="de" href="https://example.com/de/seite" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page" />Self-referencing canonical, full hreflang set including itself. If you are seeing language versions dropping out of the index, check this first — and our guide to “alternate page with proper canonical tag” covers how that failure surfaces in Search Console.
Other Ways It Fails Silently
Non-reciprocal annotations. A links to B, B does not link back. The relationship is discarded. Both directions must be present.
Relative URLs. Hreflang requires absolute URLs with protocol and domain. /de/seite does not work; https://example.com/de/seite does.
Pointing at redirects or 404s. Every hreflang target must return 200 OK. A URL that 301s elsewhere breaks the set.
Pointing at noindexed pages. A page excluded from the index cannot participate.
Mixing protocols or hostnames. http:// in one annotation and https:// in another, or www in some and not others, are treated as different URLs and break reciprocity.
Blocking versions in robots.txt. If Google cannot fetch a page, it cannot read its annotations — the same constraint that affects canonicals and noindex, covered in “indexed, though blocked by robots.txt”.
Using it for near-duplicate content that is not translated. Hreflang is for equivalent content in different languages or regions. It is not a fix for having accidentally published the same page twice — that is what canonicals are for.
Testing Your Implementation
- View source on a page in each language and confirm the full annotation set is present, including the self-reference.
- Crawl the site with a tool that reports hreflang — Screaming Frog and Sitebulb both surface missing self-references, non-reciprocal pairs, and broken targets. This is the fastest way to find problems at scale.
- Check every target returns 200 and is not canonicalised elsewhere.
- Validate your codes. Confirm you are using
en-gbnoten-uk, and that region codes are valid ISO 3166-1 Alpha 2. - Confirm canonicals are self-referencing on every version.
- Watch the Page Indexing report for language versions disappearing.
Note that Google removed the dedicated International Targeting report from Search Console some time ago, so third-party crawlers are now the practical way to validate hreflang at scale.
Do You Actually Need It?
Worth asking before you build it. Hreflang adds real maintenance overhead — every new page needs annotations on every version, and every URL change ripples through the set.
You need it if you have equivalent content at separate URLs for separate language or regional audiences.
You do not need it if you have one language and one market, or if your “regional versions” are actually the same page with a currency switcher. And if you are considering launching regional variants purely for SEO — separate /us/ and /uk/ versions of identical English content — think carefully. That creates near-duplicate pages, doubles your maintenance, and delivers little unless the content genuinely differs in pricing, availability, or regulation.
Get the Basics Right and Leave It Alone
Hreflang rewards precision and punishes approximation, but the requirements are finite. Self-reference on every page. Absolute URLs. Reciprocal annotations. Self-referencing canonicals. Valid language codes. Every target returning 200.
Get those six right and it works. Miss any one and it silently does nothing — which is why an annual crawl to verify it is still intact is worth the hour it takes, particularly after any site migration or URL change.
If you are launching in new markets and want the international setup done correctly from the start, or you have an existing implementation that has quietly stopped working, our SEO services cover international technical SEO. Reach out to the team at blogthememachine.com, and subscribe to our newsletter below for more guides like this one.
