hreflang: What It Does, and the Four Ways It Breaks

hreflang does not rank a page. It does not push a market, and it will not rescue a translation nobody wanted. It answers one question: given several versions of the same thing, which one should this person see. Most of the value is in avoiding a problem, and most implementations have one of four faults.

What it actually does

hreflang is an annotation. It tells a search engine that this page and that page are the same content for different audiences, and which audience each is for. When someone searches, the engine picks the version that matches them.

The benefit is not a higher position. It is that the position you already have gets shown to the right person, in their language, so they click and stay instead of bouncing off a page in a language they do not read.

The second benefit is quieter and often larger: it stops your own versions from being treated as duplicates of each other.

What it does not do

It does not make a page rank in a new country. If your Spanish page has no links, no relevance and no demand behind it, annotating it changes nothing.

It does not consolidate authority. Each version earns its own.

It is not a directive. Google’s documentation on localized versions describes it as a signal, and signals get overruled when other evidence is stronger.

The four ways it breaks

1. The return tag is missing

This is the one that accounts for most broken implementations. If page A says page B is its Spanish version, page B has to say page A is its English version. Without that, the pairing is ignored, silently, in both directions.

The rule extends further than people expect: every page in a set must list every page in the set, including itself. A three language set means three annotations on each of three pages, nine in total, and if one page lists only two, that page drops out.

2. The annotation points at a URL that redirects or 404s

This usually appears after a redesign, when URLs moved and the annotations did not. An annotation pointing at a redirect is discarded. So the set quietly shrinks to the pages that still resolve.

It is worth re-checking every annotation after any migration, for the same reason you re-check canonicals.

3. canonical and hreflang disagree

This is the expensive one, because both tags look correct on their own.

A page that annotates itself as the Hebrew version while its canonical points at the English page is saying two contradictory things: treat me as a distinct version for Hebrew speakers, and also, do not index me, index that other page instead. The canonical wins, the Hebrew page leaves the index, and nothing in either tag looks wrong when you inspect it.

The rule is short: every page in an hreflang set canonicalises to itself. If you cannot say that about a page, fix the canonical before you look at anything else.

4. The codes are wrong in ways that look right

The language code is ISO 639-1 and the optional region code is ISO 3166-1 Alpha 2, and the traps are specific:

• en-UK is invalid. The country code for the United Kingdom is GB.
• he-IL is valid, but iw is the old code for Hebrew and is not accepted.
• A region on its own, like x-default-US or a bare US, is not a thing. Region never appears without a language.
• Region is not language. es-US means Spanish for people in the United States, not Spanish and English.

x-default, which is not a language

x-default marks the page to show when no other version matches. Not a fallback language, a fallback page.

If your set is English and Hebrew, someone searching in French matches neither. x-default decides what they get. Point it at whichever version serves an unknown visitor best, which for most international businesses is the English one.

It is optional. Leaving it out means the engine guesses.

Where to put it

Three places are valid and you pick one. In the page head, in the XML sitemap, or in HTTP headers for files that have no head, like PDFs.

Head tags are the easiest to inspect and the easiest to keep correct, because they sit next to the canonical you have to keep in sync with them. Sitemap annotations scale better on very large sites and are much harder to eyeball.

Do not do two of them at once and let them drift.

How to check it in ten minutes

Pull the head of each version and compare. On a small site this is faster than any tool:

1. Every page lists every version in the set, including itself.
2. Every URL in every annotation returns 200 with no redirect.
3. Every canonical points at the page it sits on.
4. Exactly one x-default across the set, and it points at a real page.
5. Pages with no counterpart carry no annotations at all, rather than a half set.

That last one is worth saying plainly. A page that exists in one language only should have no hreflang, and a language switcher on it should say where it is sending you, because it is not sending you to an equivalent page.

When it is worth the effort

hreflang earns its keep when you have real demand in more than one market and content genuinely built for each. It is close to worthless when the second language is a machine translation of the first, because then the two versions are competing to be the answer to the same question and neither deserves to win.

That order matters more than the tags. Decide which markets deserve their own content, build it, then annotate it. Annotating first is how sites end up with a tidy hreflang set across four thin versions of one page.

This is the part of international SEO consulting that is least glamorous and most often the actual cause. If you are ranking in one market and invisible in another you were supposed to be in, tell me which markets and I will look at the set.

In the six-market engagement the same page existed in six versions. Without the hreflang set, Google treated them as six competitors. With it, they stopped competing and started helping each other rank.