Hreflang is the protocol that decides whether your translation work produces visibility or not. A correctly-implemented hreflang on a multilingual site routes each user to the right page in the right language for their region. A broken hreflang setup undermines the same translation work — the pages exist but the wrong ones surface, the alternates compete with each other in the index, and the international SEO investment never pays back. This chapter covers the implementation, the audit, and the failure modes that quietly cap most multilingual sites.

“Hreflang is the cheapest piece of the international SEO stack and the most consequential when broken. A two-hour audit catches what a year of translation can't fix on its own — the protocol that tells search engines which version is for whom.”

How hreflang signals work

Hreflang declares, on every page, the full set of language-and-region alternates and which one this page is. The signal lives in three valid places:

• HTML head, link rel="alternate". The most common implementation. Each page lists every alternate in <link rel="alternate" hreflang="..." href="..." /> tags.
• HTTP headers. For non-HTML resources (PDFs, images), hreflang lives in the Link: response header.
• XML sitemap. A separate xhtml:link entry per alternate inside each URL block. Useful for very large sites where head-injection becomes maintenance-heavy.

All three are read by Google. Pick one and stick to it; mixing them invites inconsistencies. For most sites the HTML head is the right call — the same engine that renders the page renders the hreflang.

The format

Hreflang values use ISO 639-1 (language) plus optional ISO 3166-1 alpha-2 (region):

• hreflang="en" — English (any region).
• hreflang="en-US" — English, United States.
• hreflang="en-GB" — English, United Kingdom.
• hreflang="es-MX" — Spanish, Mexico.
• hreflang="es-ES" — Spanish, Spain.
• hreflang="x-default" — the page to serve when no other alternate matches the user's locale. Critical for global sites; covered below.

The region code is uppercase by convention but case-insensitive to Google. The language code must be lowercase per the spec; some implementations capitalize it and Google still accepts.

The symmetry requirement

Every page in the alternate set must reference every other alternate — including itself. If page A says "the Spanish version is at B" but page B doesn't say "the English version is at A," the relationship is broken from B's side. Google's verification fails and the hreflang is dropped from the affected pages.

The minimum complete hreflang set on a 3-locale site (EN, es-MX, en-AU):

• Self-reference: <link rel="alternate" hreflang="en" href="https://example.com/page" />
• Sibling 1: <link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/page" />
• Sibling 2: <link rel="alternate" hreflang="en-AU" href="https://example.com/en-au/page" />
• Default: <link rel="alternate" hreflang="x-default" href="https://example.com/page" />

All three locale pages must include all four entries. Self-reference is mandatory; missing it doesn't always break Google's rendering but it consistently creates parsing ambiguity.

Hreflang and canonical — the interaction

Hreflang declares alternates; canonical declares the preferred version when duplicates exist. The two interact:

• Each language version self-canonicalizes. The es-MX page's canonical points to the es-MX URL, not to the EN URL. The hreflang declares the EN/AU/etc alternates exist; the canonical confirms the page is the canonical for its locale.
• Common mistake: setting canonical to the EN version on every locale. This collapses all the alternates into a single canonical and undoes the hreflang. Don't do it.
• Trailing slash consistency. Canonical, hreflang, and the actual URL must agree on trailing-slash. Mismatch is a silent suppression.
• Protocol consistency. Canonical and hreflang URLs must use https://, the same domain, and the same casing as the actual URL.

Implementation patterns

• Subdirectory pattern. example.com (en), example.com/es-mx (Spanish Mexico), example.com/en-au (Australia). Hreflang is straightforward — same domain, different subdirectories. The chapter on international URL architecture compares this against subdomains and ccTLDs.
• Subdomain pattern. us.example.com, mx.example.com, au.example.com. Hreflang works the same; treat each subdomain as a distinct origin in the alternate set.
• ccTLD pattern. example.com, example.mx, example.com.au. Each domain is treated as separately by Google; hreflang strings the alternates together across the three domains.

The audit playbook

Most multilingual sites have broken hreflang on at least some pages. The audit catches the patterns that don't show up obviously in Search Console:

• Coverage check. For every page, does the hreflang block exist? Many CMS migrations drop hreflang on subset pages.
• Symmetry check. For every alternate referenced, does that alternate page also reference back? Use a crawler (Sitebulb, Screaming Frog) to validate the bidirectional link.
• Self-reference check. Does each page include itself in its hreflang set?
• Canonical compatibility. Is the canonical pointing to the same locale as the page it's on, not to the EN version?
• x-default validity. Does the x-default URL exist, return 200, and not redirect?
• Code validity. Are the language-region codes valid ISO codes? (en-uk is wrong; en-GB is right. es-LA isn't valid; es-MX or es-ES is.)
• HTTP status check. Do all alternate URLs return 200, not 301/302/404?
• HTTPS consistency. All hreflang URLs on the same protocol as the page itself.

What hreflang doesn't do

• It's not a ranking signal. Hreflang doesn't make a page rank higher — it just routes the right page to the right user. The page still has to be optimized to rank against local competitors.
• It doesn't translate content. Translation is a separate discipline; hreflang just declares which version exists for which audience. The chapter on translation vs localization covers content strategy.
• It doesn't override geotargeting. Hreflang plus Search Console international targeting plus on-page localization plus link profile all stack — hreflang alone is necessary but not sufficient.
• It doesn't help with regional pricing. Currency, payment methods, region-specific products are handled at the application layer, not via hreflang.

The failure modes

• Translated content with no hreflang. Google treats the alternates as duplicate content and may pick one to canonicalize, dropping the others.
• Asymmetric hreflang. A claims B is its Spanish alternate; B doesn't reciprocate. Google drops the relationship from B.
• x-default missing or broken. Users from unmatched locales see the wrong page or a broken one.
• Canonical pointing to EN on every locale. Collapses all alternates into one canonical; hreflang is ignored.
• Trailing-slash mismatch. The hreflang URL doesn't exactly match the served URL; Google can't match the alternate.
• Stale hreflang after URL changes. A page moves; the hreflang on its alternates still points to the old URL. Common after rebrands or CMS migrations.

Hreflang is the foundation. The next chapter, international URL architecture, covers the structural decision — subdirectories, subdomains, or ccTLDs — that hreflang strings together.