Shopify Markets: country domain, subdomain or subfolder

What does Shopify give a market to live on?

In Shopify a market is a group of buyers with its own buying experience, and its web presence is the address that experience is served from. The Shopify Markets overview lists three shapes. A store selling in the United States on example.com can serve a Canadian market from a subfolder at example.com/en-ca, from a subdomain at ca.example.com, or from a country-code domain at example.ca.

Languages add a second layer. The same page says each additional language needs its own subfolder, and that this happens automatically on Liquid storefronts. Add French to the United States and Canadian markets and the French United States pages sit at example.com/fr, while the French Canadian pages sit at example.com/fr-ca, ca.example.com/fr or example.ca/fr, depending on how the Canadian market is set up. A market that has no web presence at all is reachable only through the country selector, on the primary domain's own URLs.

So the question is never "domain or subfolder" for the whole store. It is asked once per market, and the answer for Switzerland can differ from the answer for the United Arab Emirates.

What does Google do with each structure?

Google's guide to multi-regional and multilingual sites has a table of the options. We have kept its wording close, because the trade-offs are Google's, not ours.

The same page explains how Google decides which country a page is for. It uses country-code domains, hreflang statements in tags, headers or sitemaps, server location, and what it calls other signals: local addresses and phone numbers, local language and currency, links from other local sites and a Business Profile. Server location is not definitive, because many sites sit behind a CDN.

Two details matter for Shopify stores. First, Google treats some country-code domains as generic. The list on that page includes .co, .io, .me and .tv, so a store on one of them gets no country signal from the domain and has to send it another way. Second, .eu and .asia are treated like .com: they are regional, not country-specific, and do not geotarget a single country.

Which one should a Shopify store pick?

The table points to a rule we apply. Choose by how many countries the store will sell in and how independent each market has to be.

• One country is the whole business: a country-code domain is fine. The signal is the clearest one Google has and nothing needs configuring. The cost is that the domain can only ever target that country.
• Several countries on one brand: subfolders on a generic domain. One host, easy to set up and low maintenance, in Google's words. You add a market without buying a domain. The cost is that the URL alone does not say whether /de/ is the German language or Germany the country, so a language-and-market folder such as /de-ch says more than a bare language folder.
• Markets that must be run separately: country domains or subdomains. Different legal entities, different catalogues and different teams argue for separation. Google lists easy separation of sites as a pro for both. Each domain then has to earn its own links, so budget for that before choosing it.

The hardest part of the decision is that it is expensive to reverse. Moving from example.ch/fr to example.com/fr-ch changes every URL. It is a migration with redirects and a Search Console change of address, and it is far cheaper before the translated catalogue exists than after. Our guide for Shopify developers in Switzerland shows how that plays out on a French and German store, and the Arabic storefront guide covers the extra language decision for stores selling into the Gulf.

What does Shopify write for you, and what does it leave to you?

Shopify adds the hreflang tags itself. The multiple currencies and languages guide says they come through the content_for_header object, so there is no theme setting to edit. What the tags contain is decided by the languages you publish and the markets you give a web presence to. The mechanics are in our hreflang guide; here we stay with the structure decision.

Google's localised versions guide sets the rules every set of tags has to satisfy. Each version must list itself and every other version. If page X links to page Y, page Y must link back, or the annotations may be ignored. And Google suggests an x-default entry as a fallback for languages that match none of your pages. Shopify generates the tags; what it cannot do is make the pages different from each other.

Here is the part that stays with you. Google's multi-regional guide says that if you serve similar or duplicate content in the same language on different URLs, for instance example.de/ and example.com/de/ showing the same German text, you should pick a preferred version and use rel="canonical" together with hreflang. A store with a Germany market and an Austria market both in German, sharing one catalogue, has exactly that problem. The structure does not solve it. Translated product copy, local contact details and local currency are what separate the pages, and these are the "other signals" in Google's own list.

Theme code is the second place structure causes damage. The multiple currencies guide warns that a hard-coded link such as /cart forces visitors back to the domain default, so they may see the wrong language or currency. In Liquid, build the link from the routes object. In JavaScript, build it from window.Shopify.routes.root, which always ends in a slash and returns something like /en-ca/ inside that market's subfolder. The same guide says structured data should set priceCurrency from the cart currency, not the shop currency:

priceCurrency: {{ cart.currency.iso_code }},

How do you check what each market serves?

Do this for every market URL, not only the primary one. It takes about five minutes per market, and it needs only a terminal.

1. List the web presences. In the Shopify admin, open Settings, then Markets, and note the domain or subfolder of each market. Write down the exact URL of one product page per market.

2. Read the head of each page. Run the following, with $URL set to the market's product page:

   curl -s "$URL" | grep -o '<link rel="alternate"[^>]*>\|<link rel="canonical"[^>]*>'
   

   Every market page should list the same set of alternates, including itself, and a canonical that points to that page's own address.

3. Check the return links. Take one alternate from the output and run the same command against it. The first page must appear in its list. A missing return link is the commonest reason hreflang is ignored.

4. Test the language header. Run curl -sI -H 'Accept-Language: fr' "$URL" and confirm the response is not a redirect. Googlebot does not send that header, so a page that only shows its content after a language redirect may not be crawled in full.

The language header test matters because of a line in Google's multi-regional guide. Google says that if you reroute users on their language settings, it may not find and crawl all your variations, because Googlebot usually originates from the USA and sends requests without Accept-Language. The same page says not to adapt content by IP analysis, which it calls difficult and generally unreliable. The practical rule is to let the visitor choose: a visible country and language selector, and a banner at most, never an automatic redirect.

What should you fix first, and how long does it take?

1. Run the head check on every market page (five minutes per market). Anything where the canonical points elsewhere or a return link is missing goes to the top of the list.
2. Replace any hard-coded /cart, /search or /collections/... link with routes in Liquid and window.Shopify.routes.root in JavaScript (an hour on a typical theme, longer if apps inject their own links).
3. Remove automatic location redirects and replace them with a country selector (an hour, plus testing in each market).
4. Decide whether any market should have no web presence. A market nobody stocks for only adds URLs and tags (a short conversation, not a code change).
5. If the current structure is wrong for the markets you plan to enter, decide before you translate the catalogue. Moving later is a migration.

If you would rather have the market structure, the head output and the redirects read on your own store, that is part of what our Store Teardown looks at, and our services cover the migration if one is needed.