<b>Validate rendered hreflang, not just source — JS injection traps</b>

<b>Validate rendered hreflang, not just source — JS injection traps</b>

A modern failure mode that bypasses traditional audits: hreflang annotations injected by client-side JavaScript rather than present in the initial HTML response.

The risk: if your tag manager or framework writes <code>&lt;link rel="alternate" hreflang&gt;</code> into the head after page load, the annotations exist in the rendered DOM but not in the raw HTML Googlebot first receives. Google does render JavaScript — but on a deferred, resource-budgeted second pass, not guaranteed and not immediate.

What the evidence suggests:

— For hreflang specifically, Google has indicated a preference for annotations available without rendering. JS-injected hreflang may be picked up, but you've made a load-bearing international signal depend on the render queue, which is slower and less reliable than the raw response.

— The practical symptom is intermittent: "view-source" shows nothing, the browser DevTools (post-render) shows correct tags, and the auditor disagrees with the validator because one reads source and the other reads rendered DOM.

The audit discipline: check both. Fetch the raw HTML (curl, no JS) and confirm hreflang is present there. If it only appears in the rendered DOM, treat that as a defect even if it sometimes works.

The robust fix: emit hreflang server-side in the initial response, or use the sitemap method (which sidesteps rendering entirely). Tag-manager injection of hreflang is convenient and fragile.

Caveat: Google's rendering has improved, and JS-injected hreflang sometimes works fine. But "sometimes, eventually, if the render pass happens" is the wrong reliability target for an international serving signal. Prefer the deterministic path.