<b>Relative URLs and protocol mismatches break clusters quietly</b>
A mechanical failure mode that produces no obvious error but severs the cluster: hreflang hrefs that aren't fully-qualified, canonical, absolute URLs.
The requirements, stated exactly:
— Absolute, not relative. <code>href="/de/"</code> is invalid in this context; it must be <code>https://example.com/de/</code>. Some parsers tolerate relative, but the spec and Google expect absolute, and tolerance is not something to depend on.
— Protocol must match reality. If the site is on HTTPS but the hreflang href says <code>http://</code>, that's a different URL. Google follows it, may get redirected, and the redirect breaks the clean reciprocity match.
— Trailing-slash consistency. <code>/de</code> and <code>/de/</code> are different URLs. If the annotation says one and the canonical is the other, the return-tag handshake fails on a character.
— www vs non-www, and tracking parameters, same story — any divergence from the exact canonical URL is a different node.
Why it's hard to catch: each individual URL still resolves (via redirect), the page still loads, nothing 404s. The damage is purely in cluster reconciliation — Google sees the declared alternate and the actual canonical as two different things and declines to confirm reciprocity.
The audit: extract every hreflang href, and confirm each is byte-for-byte the canonical URL of its target, including protocol, host, path, and slash. Caveat: a few redirects in a large cluster won't necessarily collapse it — Google is somewhat resilient — but they accumulate into the "no return tags" warning.
Hreflang Lab
@HreflangLab
<b>Relative URLs and protocol mismatches break clusters quietly</b>
Этот пост опубликован в Telegram-канале Hreflang Lab. Подписаться можно по ссылке: @HreflangLab.