Hreflang Implementation for International Ecommerce: The 9 Mistakes That Kill Your Rankings

Hreflang is one of the most commonly misimplemented technical SEO features in ecommerce. The mechanic itself is simple: tell Google which language and country version of a page should be shown to which audience. The implementation reality is full of subtle traps that produce non-obvious failures. A misconfigured hreflang setup can suppress every international version of a store from search results — the pages exist, Google has indexed them, but they don't appear because the hreflang signals are contradictory or broken.

Below are the nine mistakes that recur most often in StoreVitals audits across Shopify Markets, WooCommerce multisite, BigCommerce multi-storefront, and custom international setups.

1. Missing Self-Reference

Every page that has hreflang annotations must include a self-referencing hreflang tag. If your US English page lists hreflang entries for UK, CA, and AU but doesn't list itself as en-us, Google treats the entire annotation set as invalid and ignores it.

<!-- On the US page (https://example.com/us/) -->
<link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/gb/" />
<link rel="alternate" hreflang="en-ca" href="https://example.com/ca/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/us/" />

The self-reference (en-us pointing to itself) is non-negotiable. Most implementation tools handle this correctly, but custom code and theme-level implementations often omit it.

2. Missing Return Tags

Hreflang must be reciprocal. If the US page lists the UK page as an alternate, the UK page must list the US page as an alternate. Asymmetric hreflang sets are ignored by Google.

This is the most common failure mode. A store launches a UK version, adds hreflang from the US page → UK page, but forgets to add the corresponding annotation from the UK page → US page. Google sees the one-way link and treats the whole annotation set as broken.

The fix: every page in an hreflang cluster must list every other page in the cluster, including itself. For a 4-region store (US, UK, CA, AU), every page has 4 hreflang entries — one for each region.

3. Incorrect Language-Region Codes

Hreflang values follow ISO 639-1 (language) and ISO 3166-1 Alpha 2 (country) — never the other way around, never with underscores instead of hyphens, never with three-letter codes.

• Correct: en-us, en-gb, fr-ca, de-at, es-mx
• Incorrect: en_us (underscore), en-uk (UK is not a valid ISO code; use GB), eng-usa (three-letter codes), en-EU (EU is not a country)

Common mistakes: using "en-uk" instead of "en-gb" — UK is not a country code in ISO 3166. Use "en-eu" for European Union — same issue, EU is not a country. The valid form is to set up country-by-country entries within the EU or use a region-neutral en tag.

4. Using Language-Only When You Mean Language-Region

An hreflang value can be language-only (en) or language-region (en-us). They mean different things:

• en = "show this to English speakers anywhere in the world"
• en-us = "show this to English speakers in the United States"
• en-gb = "show this to English speakers in the United Kingdom"

If you have a US-specific store with US-specific pricing, use en-us — not just en. Otherwise Google may show the US store to UK visitors, who will see USD prices and be confused.

Use language-only (en) when you have only one English version and want it to serve all English-speaking countries. Use language-region when you have country-specific content.

5. Missing x-default

The x-default hreflang specifies which page to show when no other language/region match applies. Without it, visitors from unhandled countries (say, a German visitor when you have en-us, en-gb, en-ca but no de) get inconsistent treatment from Google's matching logic.

<link rel="alternate" hreflang="x-default" href="https://example.com/us/" />

Best practice: set x-default to either your primary market's URL or a country-selector landing page that lets visitors choose their region.

6. Hreflang on Non-Equivalent Pages

Pages in an hreflang cluster must be substantively equivalent. A US product page can hreflang to its UK equivalent (same product, different price/currency). A US product page should NOT hreflang to a generic UK homepage.

Common failure: stores that have UK versions of only some pages (homepage, top categories) but use hreflang from all US pages to the UK homepage. Google treats this as misleading — the user expects the equivalent page, gets a homepage, has a poor experience.

The fix: only annotate hreflang on page pairs that are truly equivalent. Leave out pages without an international equivalent.

7. Conflicting Canonical Tags

Canonical tags and hreflang interact. If the UK page has a canonical pointing to the US page, you're telling Google "the UK page doesn't really exist independently; index the US one instead." Then the hreflang annotation pointing to the UK page is meaningless — Google won't serve the UK page anyway.

Rule: each page in an hreflang cluster must self-canonicalize. Never canonicalize across hreflang variants.

8. HTTP vs HTTPS Inconsistency

Hreflang URLs must match the exact URL Google has indexed. If your store is on HTTPS but the hreflang URLs are listed as HTTP (or vice versa), Google sees a mismatch and treats the annotation as invalid.

Common cause: a developer wrote hreflang tags during initial setup when the staging site was on HTTP. When the site moved to HTTPS, the hreflang URLs weren't updated.

Verify by viewing source on representative pages and confirming every hreflang URL uses HTTPS.

9. Hreflang on Pages Blocked by robots.txt or noindex

If a page is blocked from indexing (robots.txt disallow or robots meta noindex), the hreflang annotations on that page are ignored — Google can't process annotations on a page it can't or won't index.

Common case: a developer adds noindex to specific country pages during a launch phase but leaves the hreflang annotations in place. Removing noindex restores the hreflang.

The Hreflang Implementation Audit

1. Every hreflang-annotated page has a self-referencing tag
2. All cluster relationships are reciprocal (return tags present)
3. Language-region codes follow ISO 639-1 + ISO 3166-1 Alpha 2 (lowercase, hyphenated)
4. Language-region (en-us) used when content differs by country; language-only (en) used when one version serves all
5. x-default specified for the fallback page
6. Annotated pages are substantively equivalent — no homepage substitutes for product pages
7. Each page self-canonicalizes (never cross-canonicalizes between hreflang variants)
8. All URLs in hreflang annotations use HTTPS
9. No hreflang annotations on pages blocked by robots.txt or noindex
10. Google Search Console → Legacy tools → International Targeting (or use a third-party hreflang validator) shows no errors

Hreflang done right is invisible — the US visitor sees the US store, the UK visitor sees the UK store, and Google shows the right URL in the right country's search results. Hreflang done wrong has no obvious symptom in the dashboard — it just quietly suppresses international rankings until someone notices that the UK store gets 80% less organic traffic than it should. StoreVitals scans validate hreflang annotation completeness, reciprocity, format compliance, and canonical/noindex conflicts across multi-region stores. Run it after any international launch or migration to catch implementation drift before it costs you a quarter of international SEO.