<b>Three places to put hreflang — and when each one wins</b>

<b>Three places to put hreflang — and when each one wins</b>

Hreflang can live in the HTML head, in HTTP headers, or in the XML sitemap. They're functionally equivalent to Google, but the operational tradeoffs differ sharply, and mixing them causes problems.

What we've found across implementations:

— HTML <code>&lt;link&gt;</code> tags: most common, easiest to inspect, but they bloat every page. A 50-language cluster adds 50 link tags to all 50 pages — that's 2,500 annotations to keep synchronized, and page weight grows linearly. Fine for small clusters.

— HTTP headers: the only option for non-HTML files (PDFs, etc.). Operationally fiddly; hard to audit because you can't see them in page source without inspecting response headers.

— XML sitemap: scales best for large clusters. The annotations live in one centralized, machine-generated file rather than scattered across thousands of pages. Easiest to regenerate atomically when a locale is added or removed.

The critical rule: pick one method per cluster. Don't put partial hreflang in HTML and the rest in the sitemap — Google reads all sources, and inconsistencies between them create contradictions that can invalidate the cluster.

The scaling argument: past roughly 10 languages, the sitemap method's centralization usually pays for itself in maintainability and reduced reciprocity errors.

Caveat: sitemap hreflang is the least visible to third-party tools and the hardest for new team members to discover, so document it. The right choice trades inspectability against maintainability.