International SEO: selling into more than one country

A store expanding into a second country almost always starts the same way: duplicate the site, run the copy through a translation agency or a translation tool, swap the currency symbol on the price tag, and wait for that market's traffic to show up. Weeks later the new site is live, correctly translated, genuinely useful to a shopper standing in that country, and invisible in that country's search results. The reason is rarely the translation. It is that translation solves the language problem and leaves three technical decisions completely untouched: which URL structure tells search engines a page belongs to a specific market, how hreflang gets implemented across the whole catalogue rather than a handful of pages, and whether the new pages read as distinct enough from the original to avoid being treated as duplicates of it.

International SEO for ecommerce is the discipline of telling search engines, unambiguously, which version of a page is meant for which country and language combination, using hreflang (an HTML tag or sitemap entry, hreflang="en-gb" for English aimed at the UK, hreflang="fr-fr" for French aimed at France) and a consistent URL structure, so each market builds its own ranking history instead of competing with or diluting the others. Get the structure right early and a second market grows the way the first one did. The most common way to get it wrong is adding hreflang to only some of the site's pages, which leaves search engines either ignoring the tag or occasionally serving the wrong country's page to the wrong audience. This covers the domain structure decision and its real trade-offs, how hreflang works and the mistake that makes it silently do nothing, why currency, language and country are three separate decisions rather than one, the duplicate content risk inside near-identical locale pages, when translation is not enough, and how to sequence a market entry so you are not fighting the same battle on three fronts at once.

If you are deciding how to structure a second market, whether you are a founder about to clone a Shopify store into a new region or a marketing lead being asked why the French version of the site is not turning up in French search results six months after launch, this is the structural decision guide for that call, not a translation checklist. It assumes the translation itself is already good.

Domain structure: ccTLD, subdomain or subfolder

Three real options exist, and each buys you something different at a different cost.

A country-code top-level domain (a ccTLD, .fr, .de, .it) sends the strongest possible local signal: to a user and to a search engine, it reads as a genuinely local site. The cost is that it starts from zero. Domain authority does not transfer from your main site, so the new domain builds its own backlink profile, crawl history and trust signals from scratch, on top of separate hosting, a certificate and a registration to renew every year, per market.

A subdomain (fr.example.com) is quicker to stand up than a ccTLD, but the authority transfer from the root domain is only partial, and in my experience search engines still treat it more like a semi-separate property than a true section of the main site: often the worst of both options, not fully separate and not fully connected.

A subfolder (example.com/fr/) is what I default to unless there is a concrete reason not to. It inherits the root domain's authority immediately and is the structure Google's own documentation describes as the least resource-intensive way to run a multi-regional site (source: developers.google.com/search/docs/specialty/international/managing-multi-regional-sites). I have built all three. Periodico, the Italian fashion retailer whose headless Next.js storefront I built on Shopify, runs Italian and English through /it/ and /en/ on the same domain, with x-default pointing at /it/, the original market, rather than left unset. The point at which I would move a client off a subfolder and onto a ccTLD is not a traffic number. It is when the market has its own in-market payment processor, its own legal entity, and a local team running it day to day. Before that, splitting the domain buys very little you can defend.

Hreflang, and the mistake that makes it silently do nothing

Hreflang is not a ranking signal in itself. It is a routing instruction: it tells a search engine that a set of URLs are equivalent versions of the same page aimed at different language and country combinations, so the right one gets shown to the right searcher instead of the search engine guessing or, worse, indexing several versions as competing pages for the same query.

The requirement that trips almost everyone up is reciprocity. Every page in a hreflang cluster has to link back to every other page in that cluster, both directions, on every URL. What trips up almost every site I have looked at is the same thing, and it never throws an error to flag it: hreflang goes onto the homepage and the top-level category pages, because that is where the redesign budget went, and the rest of the catalogue never gets touched. From the outside nothing looks broken. Underneath, most of the site is sending no locale signal at all, and search engines fall back to their own judgement about which version to rank for which audience, which in practice usually means defaulting to whichever market already has the stronger existing signals, almost always the original one. The new market's product pages sit there, correctly translated, and effectively invisible in search.

Two smaller details break the same thing in less obvious ways: the hreflang value has to point at a URL that returns a 200 and is genuinely equivalent content, not a redirect; and x-default (the fallback value shown to searchers who match none of your specific locales) should point somewhere sensible, usually the original-market version, rather than be left off entirely.

Currency, language and country are three separate decisions

Treat these as one setting and you end up with pages that do not fully serve anyone. A French speaker in France and a French speaker in Canada share a language and almost nothing else: different currency, different tax treatment, different delivery promise, sometimes different sizing convention. An English speaker in the UK and one in the US share a language too, and still need their own currency, spelling and shipping thresholds handled correctly for each market.

Hreflang lets you express all three axes together, en-gb, en-us, fr-fr, fr-ca, using ISO 639 for the language and ISO 3166 for the country, or a language-only value like fr where one version genuinely serves every French speaker regardless of country. The mistake I see is a language selector that swaps the text but leaves currency and shipping logic tied to a geo-IP guess at the visitor's location rather than the country the hreflang value claims to target. A Canadian visitor lands on the correctly targeted fr-ca page and still sees UK shipping costs and a GBP price, because the checkout logic was never told the two settings had to move together.

The duplicate content problem hiding inside near-identical locale pages

Two markets sharing a language, UK and Ireland, US and Canada in English, often end up as genuinely near-duplicate pages: the same product description, word for word, with only the currency symbol and a shipping line changed. Correct hreflang mostly resolves the technical duplicate risk, because it tells the search engine these are intentional locale equivalents rather than accidental copies. What it does not fix is the page underneath. A shopper in that country still gets no local delivery timeframe and no answer to the import duty question they actually have, and the page does not become more useful just because the canonical signalling around it is correct.

This is the failure I would flag first on a fast, low-budget market expansion: best-selling product pages duplicated into a new locale to test demand, hreflang wired up correctly, nothing else changed. Technically clean, and still underperforming, because correct tagging and genuine relevance are two different jobs, and only the first one got done.

When translation is not enough

Literal translation and localisation solve different problems. Sizing charts differ between UK, EU and US conventions in ways a translator will render accurately without flagging that the underlying numbers mean something different to the shopper reading them. Payment methods that are default expectations in one market barely register in another. And a keyword built around English search terms rarely maps cleanly onto how people actually search for the same product in another language, because search behaviour, not just vocabulary, differs by market.

In the accounts we run, the single most common cause of a well-translated page underperforming is not the translation itself. It is that the target keyword was translated from the English keyword list rather than researched natively in-market, and the two rarely match closely enough for the page to be built around the term people are actually typing. The gap widens with linguistic distance: I spent years running expansion into markets including Japan, China and Korea, and the stores that struggled were reliably the ones that translated the site as-is instead of transcreating it, rebuilding what the words are for in the target language rather than swapping vocabulary. Word-for-word translation fails politely in French. It fails completely in Japanese.

Sequencing a market entry

The instinct on a first international push is to launch several markets at once, because the technical setup, once built for one, is nearly the same for the next. Resist it until the first market has proven the model: hreflang implemented across the full catalogue, keyword research done natively rather than translated, local payment and delivery expectations met, and real content behind the pages rather than a currency swap. Only then is it worth replicating the structure into a second and third market, because by then you know the structure actually works.

When I was leading international expansion at Dentsu, the costliest version of this mistake was never about rankings. The launch that taught me the lesson was a major fashion brand entering Japan, a market I worked in for years: the website was ready, the digital presence was ready, and the logistics and local payment methods were not. I flagged it repeatedly before launch, the launch went ahead anyway, and it worked, technically, with results far below what anyone had modelled, until the operational side finally got fixed months later. The SEO version of the same mistake is smaller in scale but identical in shape: correct hreflang pointed at a market that is not actually ready to serve a customer once they land.

Local signals that reinforce hreflang beyond the tag itself

A correctly implemented hreflang cluster is the foundation, not the whole picture. A few signals reinforce it, roughly in order of priority. Local backlinks, a mention or listing from a site genuinely relevant to that country, do more for a new market's credibility than almost anything else, because they are one of the few signals a competitor cannot fake by copying your site structure. In-market business details, a local phone number, a local returns address printed on the page, matter as much for a shopper's trust and conversion decision as for any ranking effect, worth building before SEO even enters the conversation. Server or CDN edge location I would put last: a much weaker signal than it used to be, not worth budget before the above are fixed.

When international SEO is not the problem you actually have yet

Two situations where I would tell a client to hold off on building full locale infrastructure. The first is unproven demand: if you have not sold into a market yet and do not know whether there is real appetite there, building hreflang, native content and a dedicated URL structure for it is expensive guesswork. Test demand first, through paid traffic or a marketplace listing, and invest in organic infrastructure once there is a real signal to build against. The second is poor translation quality itself: hreflang will faithfully route native speakers to a badly translated page exactly as intended, so fixing the tagging before the translation just gets the wrong page in front of people faster.

If you are weighing up domain structure or hreflang for a market you have not launched yet, our SEO team can review the plan before you build it, a far cheaper conversation than restructuring six months in. The category and platform work in building an ecommerce SEO strategy applies again, per market, once the structure underneath it is sound.