What Is Hreflang? (And Do You Need It?)

Hreflang is an HTML attribute that tells search engines a page has versions in other languages or for other countries, and which version to show to which searcher. It doesn't improve rankings — it swaps the right URL into a result that already ranks. You only need it if you genuinely publish the same content for more than one market.

What hreflang actually does

Hreflang solves one specific problem: you have two or more pages that say essentially the same thing in different languages or for different markets, and you want a searcher in Berlin to land on the German page rather than the American one.

It works by declaring the relationship between those pages. Each version lists every version — including itself — so search engines can treat them as a set rather than as competing duplicates. Google then picks a member of the set based on the searcher's language settings and location.

Three things it does not do, all of which get assumed:

It doesn't rank pages. Google's documentation on localized versions describes hreflang as a signal for selecting which URL to show, not a ranking factor. If none of your versions rank for a query, hreflang changes nothing.
It doesn't merge authority. Each language version accumulates its own links and its own ranking strength. Hreflang groups them for display; it does not pool their equity the way a canonical tag or a 301 redirect consolidates signals onto one URL.
It isn't a general duplicate-content fix. It only applies to translated or market-localized versions of the same content. Two near-identical English pages on your own site are a cannibalization problem, not an hreflang problem.

Do you need it?

Your situation	Need hreflang?
One site, one language, one country	No
Same language, different countries (en-us / en-gb / en-au)	Yes — this is where it earns its keep
Genuinely translated content (English + Spanish + French)	Yes
Machine-translated pages nobody proofread	No — fix the content first
One page with a language switcher that swaps text client-side	No — there's only one URL to point at
Separate ccTLDs per market (example.de, example.fr)	Yes, and it works across domains

The biggest real-world need is the same-language case. Google is good at working out that a French page serves French speakers, and much worse at guessing whether a British reader should get /uk/pricing or /us/pricing when both are in English. That's where the tag does most of its work — and also where getting it wrong is most visible, because the wrong currency turns up in the wrong country's search results.

The three ways to implement it

Pick one. Mixing methods is where inconsistencies creep in.

1. Link tags in the <head> — the most common approach, and the easiest to inspect:

<link rel="alternate" hreflang="en-us" href="https://example.com/us/pricing" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/pricing" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Every one of those pages must carry the same full block, including a line pointing at itself.

2. XML sitemap annotations — better for large sites, because you edit one file instead of every template, and it keeps page weight down. It's also the only practical option when you can't touch the <head> of thousands of URLs.

3. HTTP Link headers — the only option for non-HTML files like PDFs.

The four mistakes that break it

Missing return links. If the German page points at the English page but the English page doesn't point back, Google ignores the pairing. Hreflang is bidirectional by design — an unreciprocated declaration is treated as unverified. This is the single most common failure.

Wrong or invented codes. The language uses ISO 639-1 and the optional region uses ISO 3166-1 Alpha 2, in that order. en-gb is valid; gb alone is not, because there is no bare region form. en-uk is invalid too — the country code for the United Kingdom is GB. And hreflang="es" targets Spanish speakers everywhere, not Spain, which is es-es.

Pointing at non-canonical URLs. Every hreflang target should be the canonical, indexable, 200-status version of that page. Point at a URL that redirects, 404s, is blocked in robots.txt, or canonicalizes elsewhere, and the whole cluster gets discarded.

Fighting your own canonical tags. Each page should canonicalize to itself, then use hreflang to reference its siblings. Canonicalizing the German page to the English one tells Google to drop the German page from the index entirely — at which point there's nothing left for hreflang to swap in.

There's no longer a report in Search Console for this; Google retired the International Targeting report in 2022. Verify with a crawler that cross-checks the reciprocal pairs, or by fetching a handful of URLs by hand and reading the blocks side by side.

What `x-default` is for

x-default names the fallback page for anyone whose language and location don't match any version you've declared. Usually that's your global or English page, or a language-selector landing page. It's optional, and it matters most when you serve a handful of markets but get traffic from everywhere else.

The part that catches people out: links don't pool

Because hreflang doesn't consolidate authority, each market version has to earn its own links. A German subfolder with zero German referring domains will struggle in German results no matter how well your English pages perform, and no amount of correct markup changes that.

Practically, that means international SEO multiplies your link-building work rather than reusing it. Links from sites in the target language and country carry the most weight for that market, which is also why local relevance matters more than a headline domain authority score when you're choosing partners. If you're building links deliberately per market, a peer exchange makes the geography easy to filter for: on Backlinkster, site owners trade one in-content link for one, each placement verified live by code, so you can target partners in the market you're actually trying to rank in.

Frequently asked questions

Does hreflang help my rankings? No. It changes which of your existing pages appears for a given searcher. Rankings still come from content, links, and relevance — hreflang just stops the wrong version from showing.

Do I need hreflang for a single-language site? No. If every page exists in one language with one URL, there is nothing to declare.

Does hreflang work across different domains? Yes. You can point example.de and example.fr at each other, provided both sides carry reciprocal annotations and you control both.

Do Bing and other engines use hreflang? Bing supports it but has said it also leans on the content-language meta tag and on ccTLD signals. Yandex uses hreflang. Implementing it correctly for Google covers most of what the others look at.

Can hreflang fix duplicate content between my US and UK pages? It's the right tool for exactly that case — telling Google these are market variants rather than duplicates. It won't help with two duplicate pages in the same language and market; that needs a canonical or a merge. See does duplicate content hurt SEO.

How many hreflang tags can one page have? There's no hard limit, but every version must be listed on every page, so a 30-market site carries 31 lines in each head. That's the point at which sitemap annotations become the sane option.

The bottom line

Hreflang is narrow, unglamorous plumbing: it makes sure the version of a page you already rank with is the version the right searcher sees. If you publish in one language for one country, skip it. If you publish across markets, implement it once with self-references and reciprocal pairs, keep every target canonical and indexable, and then spend your actual effort on earning links in each market — because that's the part hreflang can't do for you.