International e-commerce SEO: hreflang and choosing your next market

Expanding an online shop into a new country is usually decided on logistics, margin and instinct, then handed to the SEO team to make the new store rank. By then the expensive decisions have been made: which market, which domain, which language and which currency. Hreflang, the markup that tells Google which version of a page suits which language or country, is often the last thing set up and the first thing to break.

Search data can inform every one of those decisions earlier. This article covers how we use it to choose the next market, how we decide between country domains, subdomains and subfolders, how we set up hreflang so Google uses it, and how we measure each market once it is live.

Why the market and structure decisions matter commercially

A market chosen on ambition alone carries fixed costs (translation, local customer service, returns handling, a new section of the site to build authority for) against search demand that may turn out to be small or held by local retailers. A structure chosen for internal convenience can split your authority across sites, or leave Google showing the wrong country's page, in the wrong currency, to a shopper who then leaves.

Getting it right means each new market starts with an estimate of the demand you can win, the cost of winning it and a site setup that will not need rebuilding in year two. That is a far easier case to make to a board than a launch followed by a year of explaining why the new store has no organic traffic.

Choosing your next market with search demand

We treat market selection as a short feasibility study before anything is built:

1. Build the demand set for each market. We localise your core category and product terms rather than translating them word for word, because shoppers in each country use their own terms, then pull search volume for each country so demand is compared on the same basis.
2. Check who owns the results. For each market we look at who ranks for the priority terms. A market where local specialists and marketplaces fill the first page is a different investment from one where international retailers already rank with translated pages.
3. Estimate what you could win. Search volume, a realistic share of clicks, and your conversion rate and order value in comparable markets give a range, not a promise. We show a low and a high case and the assumptions behind each.
4. Weigh the operational cost. Delivery times, duties, returns, local payment methods and customer service languages decide whether demand converts. A market that looks attractive on search volume and fails on returns cost is not attractive.
5. Rank the markets and pick one. We would rather see one market entered properly than five launched thinly, because each needs its own content, links and attention.

Our article on why we start with a market feasibility report rather than an agency proposal explains the format we use.

Choosing a URL structure: country domain, subdomain or subfolder

Google's guidance on managing multi-regional and multilingual sites sets out the options. Country-code domains such as example.de give a strong signal of which country you target, but each can only target one country and they cost more to run. Subdomains such as de.example.com are easy to set up, though users may not be able to tell whether "de" means a language or a country. Subfolders such as example.com/de/ are easy to set up and low maintenance. URL parameters are not recommended.

For most mid-market retailers we recommend subfolders on the existing domain, because each market starts with the authority the main site has already built and there is one platform to maintain. Country domains make sense when you already own and use them, when shoppers in a market trust a local domain more, or when legal or operational separation is needed. Changing structure later is a migration, with the risks our guide to SEO during an e-commerce replatform describes.

Two points from the same guidance catch out many international sites. Google works out a page's language from its visible content, not from the HTML lang attribute or the URL. And it advises against redirecting visitors automatically by language or IP address, because redirects can stop users and search engines seeing all versions of a site; it notes that most of its crawling originates from the US. A banner suggesting the local store does the same job without the risk.

How we set up hreflang so Google uses it

Hreflang annotations tell Google which URLs are equivalent versions of the same page for different languages or regions. Google's documentation on localised versions of a page (last updated September 2026) accepts three methods, HTML link elements, HTTP headers or the XML sitemap, and says they are equivalent from Google's perspective. On large catalogues we usually use the sitemap, because it keeps the annotations out of page templates and can be generated from the same data as the catalogue.

1. Map equivalent pages first. Hreflang only works between true equivalents: the same product or category in each market. We build the mapping from product and category IDs rather than URLs, because slugs are often translated and will not match.
2. Use the right codes. Google supports only ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes, and a country code cannot be used on its own. A common error is en-UK: the code for the United Kingdom is GB, so the value is en-GB.
3. Include return links and self-references. Each version must list itself and every other version, and if two pages do not point to each other Google ignores the tags. This is why hreflang so often breaks when one market's pages are updated and another's are not.
4. Add x-default. The x-default value is used when no other language or region matches the user's browser setting. We point it at a country selector, or at the version we want unmatched visitors to see.
5. Point only at canonical, indexable URLs. Alternate URLs must be fully qualified, including https. Each URL in a set should also be the canonical version of itself and return a 200 status. A canonical tag from the UK page to the US page asks Google to index the US page instead, which defeats the point of having both.
6. Generate and monitor it. On an e-commerce site the hreflang set changes whenever a product is added, discontinued or moved. We generate the annotations from the catalogue and crawl the full set every month for missing return links, wrong codes and targets that redirect or are not indexable.

Localisation beyond translation: currency, stock and delivery

Hreflang gets the right page in front of the right shopper. Whether they buy depends on what the page says. Translated copy that keeps UK sizing, UK delivery promises and sterling prices loses the sale even when it ranks.

• Language and terms: use the words local shoppers search for, which the demand research has already found, and have native speakers review anything machine translated.
• Currency and price: Google Merchant Center asks for prices in the official currency of the target country, both in your product data and on your site including checkout, using ISO 4217 codes. It offers automatic currency conversion if you cannot price locally, but warns that shoppers may then assume you are not a local advertiser.
• Landing pages: Merchant Center does not allow landing pages that switch content such as language or currency based on the user's location, which is another reason to give each market its own fixed URLs.
• Product data: Merchant Center recommends a separate data source for each language, and the currency of your shipping costs should match the currency of the offer.
• Stock and delivery: show availability and delivery times for the market the page serves. A product in stock in a UK warehouse but a week away from Germany needs to say so on the German page.
• Sizing, payment and returns: local size conversions, the payment methods shoppers in that country expect and a clear returns process for that market.

Google's currency consistency guidance allows more than one currency on a landing page, as long as the currency in your product data is the default and shown prominently.

How to measure each market

We set each market up so it can be reported on separately from day one:

• A Search Console property for each market's subfolder or domain, so impressions, clicks and indexing can be read country by country.
• Indexing coverage: what share of the category and product pages launched for the market are indexed.
• Wrong-market traffic: clicks from one country landing on another country's pages, read from the Search Console country filter. A rising share points to hreflang or targeting problems.
• Organic revenue and conversion rate per market in analytics, by landing page.
• Non-branded visibility for the priority terms from the feasibility study, tracked against the low and high cases.

Report to leadership against the case that justified entering the market. In the first months, indexed pages and impressions are the leading indicators and revenue follows; explaining that gap before launch is better than explaining it afterwards.

When it does not fit, and the mistakes we see

• Selling in one country in one language: hreflang adds nothing, and the effort belongs elsewhere.
• Separate English pages for the UK, Ireland, Australia and the US with nothing different but the flag. If currency, delivery and returns differ, say so on each page; if nothing differs, ask whether four versions are needed.
• Machine translation published without review, which reads poorly to shoppers and misses the terms they search for.
• Hreflang added to one market's templates but not another's, leaving return links missing across the whole set.
• Automatic redirects by IP address that stop shoppers, and Google, reaching other versions of the site.
• Launching every market at once, so none gets the content, links and attention it needs to compete with local retailers.

Questions to ask your team or agency

• What is the search demand and competition in the markets we are considering, and what revenue range could we win in each?
• Why this URL structure, and what would it cost to change it later?
• How are our hreflang annotations generated, and how do we know they are still complete after this month's catalogue changes?
• Are prices, currency, stock and delivery on each market's pages right for that market, and do they match Merchant Center?
• How much of our organic traffic in each country lands on another country's pages?

Where to start

Our e-commerce visibility playbook covers the wider programme, and the playbooks for travel and hospitality and fashion e-commerce cover two sectors where international demand is often the main route to growth. If you are weighing up a new market, our international SEO team can run the feasibility study and the technical setup.

Frequently asked questions

What is hreflang?

Hreflang is an annotation that tells Google which URLs are equivalent versions of the same page for different languages or regions, so it can show each searcher the most suitable version. It can be added as link elements in the HTML head, as HTTP headers or in an XML sitemap, which Google treats as equivalent. Each version must list itself and every other version.

Does hreflang improve rankings?

Google describes hreflang as a way to tell it about the language and regional versions of your content, not as a way to rank higher. Its value is in helping Google show the right version to the right searcher, so a shopper in Germany sees your German page with euro prices rather than your UK page. That improves the visit, which is where the commercial benefit comes from.

Should an international e-commerce site use subfolders, subdomains or country domains?

Google lists the trade-offs: country-code domains give a strong country signal but target only one country and cost more to run; subdomains are easy to set up but less clear to users; subfolders are easy to set up and maintain. For most mid-market retailers we recommend subfolders on the main domain, unless you already own and use country domains or need separation.

What does x-default mean in hreflang?

x-default is a reserved hreflang value that Google uses when no other language or region in your set matches the user's browser setting. Retailers usually point it at a country or language selector page, or at the version they want unmatched visitors to see, such as an international English store priced in a widely used currency.

Should I redirect visitors to their local store automatically?

Google advises against automatic redirects based on a visitor's language or IP address, because they can stop users and search engines seeing all versions of your site, and most of Google's crawling originates from the US. A banner suggesting the local store keeps every version reachable while still guiding shoppers to the right one.

Sources

• Google Search Central: Managing multi-regional and multilingual sites (last updated 10 December 2025)
• Google Search Central: Tell Google about localized versions of your page (last updated 21 September 2026)
• Google Merchant Center Help: Set up Shopping ads and free listings in multiple countries
• Google Merchant Center Help: How to fix: Inconsistent currency between your product data and your website