Three places to put hreflang: which signal actually survives
Google accepts hreflang via HTML head tags, HTTP Link headers, or XML sitemaps. They are equivalent in theory. In practice we found they fail differently.
The data suggests a pattern across audits we ran on roughly 40 multilingual properties:
— HTML tags break most often, because they live in templates editors touch daily. A single missing return tag from a CMS migration silently invalidates a cluster.
— HTTP headers are the only viable method for non-HTML files (PDFs, feeds). They are also invisible to most CMSs, so they drift least once set — but hardest to audit without log access.
— Sitemap hreflang scales best for large clusters (20+ locales) because reciprocity is declared in one file, not multiplied across every page's head.
A caveat worth flagging: sitemap-based hreflang only works if Google trusts and recrawls the sitemap promptly. On low-authority sites we have seen sitemap annotations ignored for weeks while HTML tags were honored immediately.
Our tentative heuristic: small clusters under ten locales, use HTML tags for crawl speed. Large clusters or sites with frequent template edits, move to sitemaps to centralize reciprocity. PDFs and non-HTML, headers are your only option.
Limitation: we could not isolate whether sitemap lag is authority-driven or sampling noise. Treat it as a hypothesis, not a rule.
Hreflang Lab
@HreflangLab
Three places to put hreflang: which signal actually survives
Этот пост опубликован в Telegram-канале Hreflang Lab. Подписаться можно по ссылке: @HreflangLab.