Hreflang mistakes: how multilingual stores send Google to the wrong country page

A shopper in Munich searches for your product in German, clicks through, and lands on your US dollar page in English. Nothing is broken, exactly. The store loads fine, the product exists, the price is just in the wrong currency and the copy is in the wrong language for a page Google decided was the best match. That decision was yours to make and you made it correctly in your site structure. Google just never got the memo, because the hreflang tags that were supposed to deliver it were wrong.

What hreflang is actually for

Hreflang is an annotation, not a redirect. It tells Google (and Bing) which URL to serve for which language and region combination, so that a French-speaking visitor in Belgium gets /fr-be/ instead of /fr-fr/ or /en-us/. It does nothing to a browser directly; it only shapes what shows up in search results and, less reliably, what Google considers canonical among near-duplicate locale pages.

This is a different problem from translation quality or currency display. A store can have beautifully translated French copy and still rank the English page for French queries, because the signal that tells Google the French page exists and matches is the thing that's broken. For the content side of multilingual stores, the translation quality post covers the trust problem. This post is about the plumbing underneath it.

The reciprocity requirement nobody reads twice

Google's documentation is explicit about this and it's the single most skipped requirement: every hreflang annotation must be reciprocated. If your /en-us/ page lists /de-de/ as its German alternate, the /de-de/ page must list /en-us/ right back, with matching hreflang values on both sides. If the return tag is missing, outdated, or points to a different URL than the one that actually exists, Google disregards the whole set for that pair.

This breaks constantly on ecommerce sites because locale pages get added, renamed, or merged independently. Someone launches a new /fr-ca/ store section, updates the hreflang block on the main sitemap template, but the individual product pages were hardcoded with an older set of alternates and never got touched. Now you have a product with a US page, a Canadian French page, and a hreflang block on the US side that references a French page that no longer references back. Google quietly drops the annotation and falls back to its own judgment about which page best matches the query, which is often not the one you'd pick.

Self-referencing tags and the x-default trap

Each page's hreflang set must also include a self-referencing tag. The /en-us/ page needs to list itself as an alternate for en-us, not just list the other locales. Skipping this is a smaller error than broken reciprocity but it still weakens the signal, and it's an easy one to miss when hreflang is generated from a template that assumes "alternates" means "other pages."

The x-default tag is a separate, optional annotation meant to catch searchers whose language or region doesn't match any of your defined locales. It should point to whichever page you want to serve as a fallback, usually the country or language selector or your primary market page. A common mistake is pointing x-default at a redirect URL instead of a final destination, which brings us to the next problem, or using x-default as a substitute for a proper country redirect strategy, which it is not. If your store relies on redirects to route visitors by geography, the geo-redirect failure modes are worth checking alongside your hreflang audit, because redirect loops and hreflang errors often compound each other.

Hreflang pointing at redirects or canonicalized URLs

Hreflang annotations should point directly at the final, indexable URL for each locale, not at a URL that 301s somewhere else and not at a URL that carries a canonical tag pointing elsewhere. Both situations tell Google two contradictory things at once: the hreflang says "this is the right page for this locale" while the redirect or canonical says "actually, index that other one instead." Google has to pick a winner, and it's not obligated to pick the one you intended.

This happens often after a migration or a platform change. A store moves from subdirectories to subdomains, or merges two locale variants into one, and the old URLs start 301ing to the new ones. If the hreflang block wasn't regenerated to match, it's still referencing the old, now-redirected paths. The result looks identical to a reciprocity failure from Google's side: the annotation gets ignored. Canonical tag mistakes covers the canonical half of this in more detail, and it's worth reading both because the two tags are evaluated together, not independently.

Language-region codes are the other quiet failure point. Hreflang uses ISO 639-1 language codes and ISO 3166-1 Alpha 2 country codes, joined with a hyphen, lowercase language and uppercase country by convention (en-US, not en-us or en_US, although Google is somewhat tolerant of case). A surprising number of hreflang implementations use invalid or non-standard codes, like using a country code where a language code is expected, or inventing codes for regions that don't have standard ISO entries. Google's documentation lists the valid formats and is the fastest way to check a code you're unsure of.

How Shopify, WooCommerce, and BigCommerce generate these tags differently

On Shopify, multi-market and multi-language setups generate hreflang automatically for markets configured through the admin, but stores that layer in third-party translation or localization apps sometimes end up with two competing hreflang implementations, one from Shopify Markets and one injected by the app, which can conflict rather than merge. Check the rendered page source, not just the app's settings panel, to see what's actually being output. BigCommerce's multi-storefront and channel setup has a similar seam: hreflang needs to be configured per storefront, and it's easy to launch a new regional storefront without wiring up its alternates correctly from day one, a gap covered in the BigCommerce monitoring checks guide.

WooCommerce has no native hreflang support at all. It depends entirely on whichever multilingual plugin is installed (commonly WPML or Polylang), and plugin updates, theme changes, or conflicting SEO plugins are a frequent source of silently broken or duplicated hreflang output. Because WooCommerce hreflang is plugin-generated, it's worth re-checking after every plugin or theme update rather than assuming it survived unchanged, the same discipline covered in the WooCommerce migration risks post.

How to actually check your hreflang setup

Start with Google Search Console. If you have a dedicated International Targeting report available for your property, it flags missing return tags and some malformed codes directly. Not every property surfaces this report consistently, so a manual check is worth doing too: view source on a handful of representative locale pages (not just the homepage) and confirm each hreflang link element has a matching reciprocal tag on the target page, a correct code, a self-reference, and a destination URL that isn't a redirect.

For larger catalogs, a crawler that can simulate Googlebot and export hreflang pairs in bulk is more practical than manual spot checks, since errors are rarely uniform across a whole site. They tend to cluster around specific templates, specific locales added after the initial launch, or specific product types that were migrated separately. This is the kind of drift that's easy to miss because it accumulates slowly rather than breaking all at once; continuous monitoring of SEO health signals, including hreflang and canonical consistency, catches the drift before a quarter's worth of international traffic has quietly shifted to the wrong page. Cassian's™ SEO health checks are built around exactly this kind of slow, structural decay rather than one-time audits.

The fix is maintenance, not a one-time setup

Hreflang earns its keep quietly and fails the same way. There's rarely a dramatic error message, just a slow redistribution of which country sees which page, noticed only when someone checks analytics by region and wonders why German traffic has been flat for two quarters. Treat hreflang the way you'd treat a sitemap or a redirect map: something that needs to be re-verified after every new market launch, every migration, and every app or plugin update that touches your locale structure, not something you configure once and trust forever.