Emitting hreflang on parameterized and paginated URLs that shouldn't carry it

Emitting hreflang on parameterized and paginated URLs that shouldn't carry it

A scaling failure we see on large catalogs: hreflang tags generated on URL variants that were never meant to be cluster members.

The template emits hreflang on every rendered page. That sweeps in URLs that aren't canonical entry points:

— Faceted/filtered URLs with tracking or sort parameters (?sort=price, ?utm=…) that canonicalize to the clean URL
— Paginated pages (page 2+) cross-referencing other locales' page 2, an arrangement that's fragile and rarely correct
— Session or currency parameters producing thousands of near-duplicate annotated URLs

The damage: hreflang on a non-canonical URL contradicts its own canonical (which points to the parameter-free version), so the cluster member doesn't self-canonicalize — and we're back to the canonical-vs-hreflang conflict, now multiplied across the parameter space. Crawl budget gets spent confirming reciprocity on URLs that shouldn't exist in the index.

The fix:

— Emit hreflang only on canonical URLs. If a URL's canonical points elsewhere, it should not carry hreflang at all
— Strip tracking/sort/session parameters before generating the alternate set
— For pagination, the mainstream-safe choice is to keep hreflang on the canonical paginated structure only where each locale's pagination genuinely corresponds — and when in doubt, restrict hreflang to the first canonical page of a series

Limitation: pagination handling is genuinely contested and Google's own guidance has shifted over the years. We can't offer a one-size answer for paginated clusters. The non-negotiable part is narrower and certain: never put hreflang on a URL that canonicalizes to a different one.