Why a hreflang cluster only works when every version links back

What the error means

Hreflang declarations form a group: every alternate must list the others, and each listed page must link back. When a language version does not return the link — or points at a URL that 404s, redirects, or is blocked — Google treats the cluster as unreliable and may ignore it entirely, serving the wrong version to the wrong country.

Why Google rejects it

Reciprocity is how Google validates that the set of alternates was written deliberately rather than scraped or mistyped. A one-way hreflang — the home page lists six languages, but the German page lists none — fails that test, and the annotation that was supposed to route users stops routing anything.

How to fix it

1. Make the set self-referential and complete: every URL in the cluster lists every member, including itself, plus the x-default where used.
2. Use absolute URLs with the correct scheme, and make sure each target returns 200 to an outside request — a 403 from bot protection silently kills the cluster.
3. Do not point alternates at URLs that redirect. List the final URL, or the annotation points at a move rather than a page.
4. Combine hreflang with self-canonicals: an hreflang target that canonicalises elsewhere contradicts itself and is dropped.

Common causes

Only the source page lists the alternate

A language switcher or manually added head tags may be present on the main-language page but missing from translated templates. Google expects the alternate pages to confirm the relationship too. Inspect the source of both pages and compare their complete hreflang sets, including each page's self-reference.

The return link uses a different URL variant

One page may reference the HTTPS URL while its partner points to HTTP, www instead of apex, a trailing-slash variant, or a redirecting old path. The URLs look related in a browser, but the literal alternate values do not identify the same final pages. Compare each href with the canonical live URL.

A localized URL does not return a usable page

An alternate can return 404, 403, a redirect chain, or a page that requires a locale cookie. In that case the annotation does not reliably identify an accessible equivalent. Request the exact URL externally and confirm it loads the intended language or regional version directly.

A plugin or theme generates different sets by locale

Multilingual plugins can build alternate lists from translation relationships, while custom theme code may add another partial set. If a translation is unpublished or detached, one page can keep a stale reference that the other version no longer emits. Compare actual rendered tags across the full cluster.

Page tags and sitemap annotations conflict

Some sites publish hreflang in both HTML and XML sitemaps, then update only one source. One method may list a language version that the other omits or spells differently. Choose a source of truth or keep both generated from the same translation data, then check the relevant sitemap entry and page head.

Fix it on your platform

On Shopify

1. List the actual language or market URLs Shopify publishes and confirm each translated page is active and accessible before treating it as an alternate.
2. If an internationalization app generates hreflang, check its language assignment and URL mapping for each product or page; do not add a second hard-coded set to the theme without comparing the output.
3. For custom theme output, inspect the published theme's <head> and ensure each localized URL emits its full alternate set plus itself.
4. Use final HTTPS URLs in the annotations. If a market domain redirects to the primary domain, correct the mapping or use the intended final destination.

On WooCommerce

1. Check the multilingual plugin's translation relationship for each affected page; the plugin can only emit reciprocal links when the translations are connected as equivalents.
2. Inspect the active theme's rendered head and the plugin's sitemap output to find duplicate or conflicting hreflang sources.
3. Publish the translation before expecting it in the alternate set, and confirm its permalink returns the localized page to a logged-out visitor.
4. If you manage hreflang in custom code, generate all alternates from one mapping instead of maintaining separate language-specific snippets.

On other platforms

1. Wix: check that each page is assigned to the correct language in the multilingual setup and that translated pages are published; inspect the published page tags.
2. BigCommerce or Squarespace: inspect the active theme or multilingual integration that emits alternate tags and compare one page from each locale.
3. For custom sites, store the language-to-URL mapping once and render the same complete, self-referencing set on every equivalent page.
4. If both HTML and sitemap methods are in use, generate them from the same translation inventory and check that each URL uses its final canonical destination.

How to confirm it is fixed

1. Choose two or more affected locale pages and compare their exact hreflang codes and absolute href URLs, including a self-reference on each page.
2. Request every target URL directly from outside your logged-in session; confirm it returns the expected localized page without an error or redirect to another market.
3. Run Shipwork's hreflang check to inspect page alternates and sampled return links, then use hreflang sitemap check if you also publish sitemap annotations.
4. Use Search Console URL Inspection on representative URLs after publishing and allow time for Google to recrawl the localized pages.

Other errors like this