Ecommerce SEO
International SEO for stores: hreflang and markets
Serving a second country from one store without versions competing: URL structure, hreflang done correctly, real localization and the feed per country.
By CartKernel · Published
Selling into a second country creates a second version of every page. Without structure, Google sees two near-identical pages, picks one, and often shows a Canadian searcher the US page with the wrong currency and shipping. The job has three parts: a URL structure that gives each market its own place, hreflang that tells Google which version is for whom, and localization that makes the version worth showing. Skipping any one of the three is how stores end up with the wrong page ranking in the right country.
Choose the URL structure before anything else
| Structure | Example | Best for | Cost |
|---|---|---|---|
| Subfolder | example.com/en-ca/ | Most stores: one domain, authority consolidated, simple hosting | Per-market signals are weaker than a country domain |
| Country domain | example.ca | Brands with a local presence and the budget to build authority per domain | Each domain starts from zero and needs its own links |
| Subdomain | ca.example.com | Stores whose platform forces it | Treated closer to a separate site than a folder |
| Parameter | example.com/?country=ca | Nothing | Not recommended by Google for localized versions |
Our default is subfolders on one domain, with a language and region code in the path, unless there is a strong local brand that justifies a country domain. Whether a store should use subdomains has a longer answer, and it rarely ends in yes for international markets. Each version is a language plus region pair: en-ca and fr-ca are two versions, not one Canadian version.
What hreflang does and what it does not
Hreflang is an annotation that maps the versions of one page to each other and says which language and region each serves. It does not make a page rank; it helps Google choose the right version among pages that already do. The rules that make it work:
- Every version lists every other version and itself. If the Canadian page points at the US page, the US page must point back, or the annotation is ignored.
- Language codes follow ISO 639-1 and region codes follow ISO 3166-1 alpha-2, joined as en-ca. A region on its own is invalid.
- An x-default entry names the version to show when no other matches, usually the global or English page with a country selector.
- Each URL in the set is the canonical, indexable version of itself. Annotations pointing at redirected, noindexed or non-canonical URLs are dropped.
- The canonical tag on each version points at itself, never at another language version.
Three ways to deliver it: link elements in the head, HTTP headers, or an XML sitemap. For a catalog with thousands of products and several markets, the sitemap method keeps the page head small and is easier to generate from data. On a handful of markets, head tags are fine and easier to verify by eye.
Localize, do not just translate the header
Google’s guidance is that same-language pages for different regions are valid versions as long as they genuinely differ for the region. The differences that matter to a buyer are the ones that matter to Google:
- Currency and prices, shown in the local currency without conversion notices.
- Shipping options, costs and delivery estimates for that country.
- Tax display conventions for the market.
- Spelling, units and size systems.
- Payment methods buyers in that country expect to see.
- Contact details, returns address and support hours that apply there.
A version that is the US page with a currency toggle is a duplicate with an annotation. A version that answers a Canadian buyer’s questions about delivery, returns and duties is a page worth ranking.
Never redirect by IP
Automatic redirects based on the visitor’s location hide every version except one from crawlers, most of which request from the United States. Google’s documentation on locale-adaptive pages describes some crawling from other locations, and also says not to rely on it. Serve the version the URL asks for, show a banner suggesting the right market, and let the buyer choose. Remember the choice in a cookie so they are not asked twice.
Shopify Markets specifics
Markets is Shopify’s model for the whole problem. A market groups countries and gets its own pricing, currency, languages and either a subfolder on the primary domain or its own domain. Shopify adds hreflang tags for the market and language URLs it generates, which removes the most error-prone part of the setup. Translations come through the translation app or an integration, with metafields and theme content translated alongside product content.
What to check on a Markets build:
- Every market that should be indexed has a subfolder or domain, not only a currency switch on the primary.
- Translated content is rendered server-side, so the translated page is what crawlers see. Apps that inject content in the browser stay in the original language.
- Product availability per market is set deliberately, so a product not sold in a market does not produce a page there.
- Canonicals on market pages are self-referencing, which the platform handles unless a theme or app overrides them.
- The x-default resolves to the primary market’s page.
Whether Markets is the right route for a given store depends on how different the markets need to be, and separate stores per country remain the answer for some. The Shopify development side of an international launch is mostly making sure the theme respects all of the above.
WooCommerce, BigCommerce and headless
On WooCommerce, a multilingual plugin generates the language subfolders and the hreflang set, a multi-currency plugin handles pricing, and the SEO plugin manages canonicals per language; the three have to agree, and testing the head of a product page in each language is how you confirm they do. BigCommerce supports multi-storefront setups where each storefront can serve a market, with hreflang handled at the theme level. On a headless build, the framework’s internationalized routing produces the URL structure and the hreflang set is emitted from the same locale data, which is the most controllable version of all, and the ecommerce development work is in getting the sitemap per locale and the fallbacks right.
Merchant Center per country
Each target country needs product data in its currency, shipping settings for that country, and landing pages in a supported language for it. One feed can target several countries where currency and language match; otherwise a feed per country, or a feed with per-country overrides, is the clean answer. The landing page for a Canadian listing has to be the Canadian version, so market URLs and feed URLs must line up. Whether one Merchant Center account can serve several stores covers the account structure, and Merchant Center setup for a multi-country store is where we sort the feeds, shipping and tax settings per market.
Verifying and monitoring
Search Console no longer offers a dedicated report for international targeting, so validation is on you. Crawl the site with a tool that checks hreflang reciprocity and reports missing return links, invalid codes and annotations pointing at non-canonical URLs. Add a Search Console property per market subfolder, so clicks and impressions can be read per market. Track rankings for a set of core queries from each target country, and watch for the wrong version appearing, which is the symptom that sends you back to the annotations.
Launch checklist
| Area | Confirm |
|---|---|
| URLs | One subfolder or domain per language and region pair; no parameter versions |
| Hreflang | Every version lists all versions and itself; x-default set; codes valid |
| Canonicals | Self-referencing on every version |
| Content | Currency, shipping, tax, spelling and payment methods localized; rendered server-side |
| Redirects | No IP-based redirects; suggestion banner instead |
| Sitemaps | One per market, or one with hreflang entries, submitted in Search Console |
| Feeds | Product data, shipping and landing pages per target country in Merchant Center |
| Monitoring | Property per market, crawler validation of annotations, rankings per country |
Most of the problems we see on international stores are not exotic. A missing return link, a canonical pointing at the English page, or a redirect that hides the French version from the crawler. The checklist exists because the failures are ordinary, and ordinary failures are the ones a launch can prevent.