What is hreflang?
Hreflang is an HTML attribute that tells search engines which language and regional version of a page to show to which user. A site with English, Spanish and German versions of the same page uses hreflang to say *these three URLs are the same content in different languages* — so Google can serve the right one rather than picking arbitrarily or treating them as duplicates.
It is not a ranking factor. It does not make a page rank higher. It determines which of several near-identical pages gets shown, in which market. Get it wrong and your Spanish page shows to English readers, or your carefully localised German site sits behind the English original in German search results.
When do you actually need hreflang?
Fewer sites need it than implement it.
| Situation | Need hreflang? |
|---|---|
| One language, one country | No |
| One language, multiple countries with genuinely different content (pricing, shipping, legal) | Yes |
| One language, multiple countries with identical content | Usually no — use one page and let it rank everywhere |
| Multiple languages | Yes |
| Multiple languages *and* multiple regions per language | Yes, and this is where it gets difficult |
The middle row causes the most wasted effort. If your UK and Australian pages are word-for-word identical, hreflang is solving a problem you don't have. Splitting one strong page into two weak ones costs you more than the targeting gains.
The three ways to implement hreflang
You may use any one of these. Do not use more than one — conflicting signals across methods is a common and easily avoidable failure.
1. HTML <link> tags in the <head>
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/page/" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de-de/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />Simplest to implement and to inspect. Best for small to mid-size sites. The cost is page weight: every page must list every version, so a site with fifteen locales carries fifteen tags on every page.
2. XML sitemap annotations
Each URL in your sitemap carries <xhtml:link> entries for its alternates. No page-weight cost, and far easier to manage at scale — which is why large multi-market sites use it. The trade-off is that it's invisible when you inspect a page, so debugging requires pulling the sitemap.
3. HTTP headers
The only option for non-HTML files such as PDFs. Rarely the right choice otherwise.
The five errors that break hreflang
These account for the overwhelming majority of broken implementations.
1. Missing return tags. Hreflang must be reciprocal. If your English page points to the German page, the German page must point back to the English one. One-directional annotations are ignored entirely — this is the single most common failure, and it fails silently.
2. Wrong or invented codes. The language must be an ISO 639-1 code and the region an ISO 3166-1 Alpha-2 code, in that order. The traps:
en-ukis wrong. The country code for the United Kingdom isGB. Useen-gb.zh-cnandzh-tware region codes, not scripts. If you need Simplified versus Traditional Chinese, usezh-Hansandzh-Hant.- Region alone is invalid.
hreflang="de"is fine;hreflang="DE"meaning Germany is not — language always comes first. en-eudoes not exist. The EU is not a country.
3. Hreflang and canonical fighting each other. Each language version must self-canonicalise. If your German page carries rel="canonical" pointing at the English page, you have told Google the German page shouldn't be indexed at all — and hreflang cannot override that. This one causes total collapse of a locale and is often invisible until traffic disappears.
4. Pointing at redirecting or 404 URLs. Every hreflang target must return 200. After a site restructure, hreflang sets routinely point at URLs that now redirect. The annotation is dropped.
5. Missing x-default. Not mandatory, but you should have one. x-default tells Google which page to serve when no listed version matches the user — the fallback for everyone outside your target markets. Point it at your primary-language page or a language selector.
URL structure: which to choose
Hreflang works with any of these, but the choice has consequences well beyond hreflang.
| Structure | Example | Strengths | Weaknesses |
|---|---|---|---|
| ccTLD | example.de | Strongest local trust signal; clear geo-targeting | Each domain builds authority from zero; expensive to maintain |
| Subdirectory | example.com/de/ | Inherits domain authority; cheapest to run | Weaker local signal; one server location for all |
| Subdomain | de.example.com | Some separation, some inheritance | Ambiguous — tends to get the drawbacks of both |
For most businesses, subdirectories are the right answer. They consolidate authority on one domain, which matters enormously when you're entering a market with no local link profile. ccTLDs make sense when you have a genuine local entity, local operations, and the budget to build authority separately in each market.
Subdomains are chosen more often than they should be. If you're weighing it, the honest question is whether you have a specific technical reason — separate hosting, separate teams, separate platforms. Absent that, subdirectory.
How to validate your hreflang
Search Console's International Targeting report is the primary tool. It surfaces missing return tags and unknown language codes across your live site at scale — the two errors that matter most, in the one place that reflects what Google actually sees.
A crawler (Screaming Frog, Sitebulb or similar) will map your full hreflang graph and flag non-reciprocal pairs, non-200 targets and canonical conflicts before deployment. Run this on staging.
Manual spot-checks. View source on one page per locale and confirm the set is complete and reciprocal. It takes ten minutes and catches template-level errors that scale to every page on the site.
Validate after every restructure, migration or locale launch. Hreflang breaks quietly — there is no error message, no ranking penalty, and no notification. The pages simply stop being served to the right people.
Frequently asked questions
Is hreflang a ranking factor? No. It determines which language or regional version of a page is shown to which user. It does not improve rankings.
Do I need hreflang for the same language in different countries? Only when the content genuinely differs — different pricing, shipping, legal terms or product availability. If the pages are identical, one page serving both markets usually performs better.
What does x-default do? It specifies the fallback page for users whose language and region don't match any version you've listed. Point it at your primary-language page or a language selector.
Is en-uk a valid hreflang code? No. The ISO 3166-1 country code for the United Kingdom is GB, so the correct value is en-gb. en-uk is one of the most common hreflang errors.
Can I use hreflang in the head and the sitemap at the same time? You shouldn't. Pick one method. Using both creates conflicting signals when they inevitably drift out of sync, and they always do.
Why is my hreflang not working? The most common cause is missing return tags — the relationship must be reciprocal in both directions. The second most common is a canonical tag on a translated page pointing at the original, which prevents that version from being indexed at all.
Does hreflang fix duplicate content across languages? It clarifies the relationship so Google understands the versions are alternates rather than duplicates. It does not fix genuine duplication within a single language.
Get your international setup right the first time
Hreflang is the visible part of a much larger decision. URL structure, market prioritisation, and whether a market has enough search demand to justify translation all come first — and a hreflang implementation built on the wrong architecture has to be torn out and redone.
TapasSEO's International SEO Foundations covers the architecture decision, hreflang implementation across your locale set, canonical alignment, and validation before launch.
International SEO Foundations — $1,297 →
If you don't yet know whether a market is worth entering, the International Keyword Pack measures real demand in the target language before you commit to translation — because translated keywords and researched keywords are rarely the same list.