Hreflang for Ecommerce Stores: Setup and Common Mistakes

Hreflang is an annotation that tells Google which language or country version of a page to show to which searchers. For an ecommerce store it links equivalent product and category pages across markets, so that a shopper in Germany is more likely to see the German page and a shopper in the UK the UK page. It is a hint, not a command, and it only works when every version points to every other version and back.

Hreflang is simple in principle and easy to get wrong at scale. A store with a few thousand products and four markets has thousands of page sets, and one template mistake repeats on all of them. This guide covers the code format, the three ways to add hreflang, what changes on product and category pages, and the mistakes I would check first.

It is part of a wider set of decisions about selling abroad. If you are still choosing between folders, subdomains and country domains, read the guide on country versus language URL structure first, because hreflang sits on top of that choice. For how I work on this, see international SEO for ecommerce stores.

What Hreflang Does and Does Not Do

Google’s localized versions documentation describes hreflang as a way to tell Google about localized versions of a page, so that it can serve the right language or regional URL in search results. It is a signal that Google combines with others, and Google may still show a different version in some cases.

Question	Answer	Why it matters
Does it choose which version is shown?	It helps Google choose, as a hint	Google can still pick another version if other signals point that way
Does it translate or localise pages?	No	The pages still need real localised content, prices and currency
Does it replace canonical tags?	No, they do different jobs	Each version should still canonicalise to itself
Does it merge the ranking strength of versions?	Not something Google documents	Treat each version as a page that has to stand on its own
Does it work across search engines?	Check each engine’s own documentation	Other search engines may handle language targeting differently

The practical point is that hreflang fixes one problem: showing the right regional version of a page you already have. It does not create demand in a new market and it does not rescue a thin page.

How the Language and Region Codes Work

A hreflang value is a language code, optionally followed by a region code. The language comes from the ISO 639-1 list and the region from the ISO 3166-1 alpha-2 list. A language on its own, such as de, is valid. A region on its own is not, because hreflang needs to know the language first. The special value x-default marks the version for searchers who do not match any listed language or region, and is often used for a language selector or a global page.

What you mean	Code	Watch out for
English, any country	`en`	Fine as a fallback for English, not specific to a market
English for the United Kingdom	`en-GB`	The code for the UK is GB. `en-UK` is a common mistake
Spanish for Mexico	`es-MX`	Do not use one Spanish page for Spain and Mexico if prices or terms differ
German for Austria	`de-AT`	Region only matters if you have a separate Austrian version
Fallback for everyone else	`x-default`	Point it at a real page, not at a redirect
A country with no language	`us`	Invalid on its own. Use `en-US`

Another code to watch is eu. People use it for Europe, but it is the language code for Basque. Hreflang has no way to target a continent, so a pan-European English page is usually listed as plain en or handled through x-default.

Three Ways to Add Hreflang

Google supports hreflang in the HTML head, in HTTP headers and in an XML sitemap. You only need one method per page set. Using several is allowed, but if they disagree it creates a conflict you then have to debug.

Method	Suits	Watch out for
HTML link elements in the head	Smaller stores and templates that already know every version	Adds markup to every page, and long sets add page weight
XML sitemap with alternates	Large catalogues where a database can generate the sets	Every URL entry must list all its alternates, and the sitemap must stay current
HTTP headers	Non-HTML files such as PDFs	Rarely relevant for product and category pages

This is what the HTML version looks like for one product that exists in three markets, with a fallback. The example uses placeholder URLs.

product page head

<link rel="alternate" hreflang="en-us" href="https://example.com/us/blue-mug/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/blue-mug/" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de/blaue-tasse/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/blue-mug/" />

Three rules apply to every method. Each page lists all versions, including itself. Each alternate links back, so that if page A names page B, page B names page A. And every URL is fully qualified, with the protocol and domain. When return links are missing, Google may ignore the annotations for that set.

Hreflang on Product and Category Pages

Hreflang works page to page, so the first job is deciding which pages are real equivalents. On a store, most of the effort goes into product and category templates, because that is where the volume is.

Page type	What to annotate	Watch out for
Product page	The same product in each market where it is sold	Do not point at a different product, a category or the home page when a market does not stock it
Product variants	The canonical product URL, not each variant parameter	Variant URLs that canonicalise elsewhere should not carry their own sets
Category page	The matching category in each market	Assortments differ by market, so a category may have no equivalent in one of them
Paginated category pages	Match page to page where each page is indexable	Mismatched page counts between markets
Filtered and sorted URLs	Usually none, if you keep them out of the index	Annotating URLs that canonicalise to the parent category
Blog and guides	Only where a translated or localised equivalent exists	Machine-translated copies nobody reviewed
Home and language selector	Each market home, plus `x-default`	A selector that redirects by location

When a product is discontinued or removed in one market, take it out of the set and make sure the other versions stop pointing at it. The guide to out-of-stock and discontinued product pages covers what to do with the page itself, and the duplicate product URLs guide covers why the canonical URL of each product matters before you annotate it.

Hreflang and Canonical Tags Must Agree

Each language or country version should have a canonical tag that points to itself. A canonical that points at a different market’s version tells Google that the other page is the main one, and the annotated page may then be left out. Hreflang says “these pages are alternatives of each other”. Canonical says “this URL is the main copy of this content”. They do different jobs and they need to agree.

Near-identical pages in the same language, such as US and UK English product pages with the same copy, are a separate case. Google may group near-duplicates and choose one as the main page even when hreflang is present. If the pages are genuinely different, with their own price, currency, spelling and shipping details, that grouping is less likely. If they are not, ask whether you need both versions.

Common Hreflang Mistakes on Ecommerce Sites

Mistake	What goes wrong	Fix
Missing return links	Page A names page B but B does not name A, so the pair may be ignored	Generate sets from one source so every member lists all the others
No self-reference	A page does not list itself in its own set	Include the page’s own URL and code in every set
Invalid codes	Values such as `en-UK` or a country on its own are not recognised	Use the ISO 639-1 language and ISO 3166-1 region lists
Pointing at redirects	The annotated URL redirects somewhere else	Point at the final, canonical URL
Pointing at noindex or non-canonical URLs	Signals conflict, and Google may drop the annotation	Annotate only indexable canonical pages
Non-equivalent targets	A product points at a category or the home page	Leave the market out of the set instead
Relative URLs	Annotations without the full protocol and domain are not valid	Use fully qualified URLs
Conflicting methods	HTML and sitemap sets disagree	Keep one method as the source of truth
Automatic redirects by location	Crawlers and shoppers cannot reach the other versions	Offer a market selector instead of forcing a redirect

The last item deserves a note. Google’s documentation advises against automatically redirecting or changing content based on a visitor’s location or language, because search engines usually crawl from a limited set of locations and may never see the other versions. A visible selector, and a banner that suggests another market without forcing it, is safer.

Hreflang on Shopify, WooCommerce, Magento and BigCommerce

Platforms and plugins handle hreflang differently, and they change over time, so I treat the behaviour below as things to check rather than things to assume. Open the page source of a product, a category and the home page in each market and look at what is actually output.

Platform	What to check	Typical gap
Shopify	Whether the markets and translation setup you use outputs hreflang for each language and market URL	Apps that add their own tags on top of the built-in ones, or tags that stop after a market change
WooCommerce	Whether your multilingual plugin outputs hreflang and which URL pattern it uses	WooCommerce has no multilingual feature of its own, so results depend on the plugin and its settings
Magento	Whether store views output hreflang by default or through an extension or template change	Store views that are not linked as alternates, or linked with wrong codes
BigCommerce	Whether the theme or multi-storefront setup outputs hreflang for each storefront	Storefronts that carry no cross-storefront annotations

If you are replatforming or adding markets, include hreflang in the parity checks from the replatforming SEO checklist. It is one of the things that often disappears quietly when templates are rebuilt.

How to Check Your Hreflang

Do not trust a single page check. Hreflang problems are usually template-level, so check one example of each template in each market, then check at scale.

View the source of one product, one category and the home page in every market and read the alternates.
Confirm that each page lists itself and every alternate, and that each alternate lists it back.
Crawl the site with a tool that reports hreflang and look for missing return links, invalid codes and annotations that point at redirects, errors or noindexed pages.
Compare the declared canonical with the one Google selected for a sample of pages, using the URL Inspection tool in Search Console.
Check the page indexing report in Search Console for versions that Google has chosen not to index.
Re-run the crawl after every template, platform or plugin change, and after adding a market.

Frequently Asked Questions

Does hreflang improve rankings?

Not directly. Hreflang helps Google choose which version of a page to show to which searcher. It does not add ranking strength to a page and it does not translate anything. Its job is to put the right version in front of the right audience.

Do I need hreflang if I only have one language?

If you sell in several countries with pages in the same language, such as English pages for the US, the UK and Australia, hreflang can still help, because it tells Google that those pages are regional alternatives. If you have one version of each page for everyone, there is nothing to annotate.

Which method should I use: HTML, sitemap or HTTP header?

Google treats them as equivalent, so pick the one your platform and team can keep correct. On a large catalogue I lean towards the XML sitemap because it keeps the page HTML lean and is easy to generate from the product database. That is a preference, not a rule, and using one method consistently matters more than which one.

Should hreflang point to the canonical URL?

Yes. Hreflang annotations should use the canonical, indexable URL of each version. Pointing at a redirected, noindexed or non-canonical URL gives Google conflicting signals, and it may ignore the annotation.

What if a product is not sold in one market?

Leave that market out of the product’s set rather than pointing at a different product or the home page. Hreflang is meant to connect equivalent pages. If the equivalent does not exist, there is nothing to connect.

Hreflang Checklist for Ecommerce Stores

Each market has a clear purpose: a language, a country, or both.
Every hreflang value is a valid language code, optionally with a valid region code.
Each page lists itself and all its alternates, and each alternate links back.
All annotated URLs are fully qualified, canonical, indexable and return a 200 status.
Each version has a canonical tag pointing to itself.
Product and category sets only connect equivalent pages. Markets without an equivalent are left out.
One method is the source of truth, and the sets are generated from one place.
There is an x-default pointing at a real page, such as a market selector.
No forced redirects by location stop crawlers or shoppers reaching other versions.
The set is re-checked after template changes, platform updates and new markets.

For the structure decision that comes before hreflang, read country versus language URL structure. For help applying this to your own store, see international SEO for ecommerce stores and the ecommerce SEO consultant page.

Want your hreflang checked?

Book a call and we will look at your market setup, the way hreflang is output on your product and category templates, and what to fix first.

Book a Call

Written by

Abdullah Mahmud

I work on online stores that sell into more than one country or language. This guide explains how hreflang works and where it usually breaks, and it does not promise how rankings will change.

HreflangInternational SEOEcommerce SEOTechnical SEOMarkets

International SEO for ecommerce Ecommerce SEO consultant Technical SEO consulting