Localising content without duplicating your catalogue

Ask a team how they plan to launch in Germany and you will usually get one of two answers, both of which involve making a copy. Either a second Shopify store on a .de domain, or the same store carrying a second set of products — SKU-1234-DE sitting next to SKU-1234 — so that the German copy has somewhere to live.

Both work on launch day. The cost arrives afterwards, and it is a multiple rather than an addition. A price change is now two edits. A stock correction is two edits, and between them you have a window where the two disagree. A product photographed again is two uploads. A bug in the size guide is fixed in one place and quietly survives in the other. Add a third market and the multiple is three.

The more expensive version of this is the reporting. One product with two records is two rows in every sales report, two entries in every inventory export, and a permanent argument about which number is the real one. Teams solve that with a spreadsheet that maps the duplicates back together, and the spreadsheet becomes the thing everybody actually trusts — which is a fair description of a system that has stopped working.

None of this is necessary, because the three things people clone a product to vary — whether it is for sale, what it costs, and what language it is written in — are all things Shopify varies without a copy.

Translations work the same way: they attach to the product you already have. The German version of a product page is not a German product, it is your product with a German rendering of its title and description. That is the whole point, and it is why the catalogue does not grow when the language count does.

Two constraints in Shopify's documentation decide how far this gets you, and both are worth knowing before you scope anything.

The first is that a resource's `tags` field cannot be translated — the documentation says so plainly, giving product tags as the example. If your collection filters, your search facets or your merchandising rules are built on tags, they stay in your primary language no matter what else you translate. That is not usually fatal, because tags are often invisible to the shopper, but it is fatal to a theme that renders tag names as filter labels. Move those to metafield definitions with proper values before you localise, not after.

The second is that metafields can only be translated if they are publicly accessible. On a modern Shopify store a large share of the page — specification tables, care instructions, ingredient lists, the content blocks a merchandiser assembles — lives in metafields and metaobjects rather than in the description. Whether that content can carry a second language is decided by how the definitions were set up. Discovering this halfway through a translation project is a common and entirely avoidable way to lose a fortnight.

Metaobjects. Define a content type once — a delivery promise, a size guide, a compliance block — and create one entry per market, then have the theme resolve the right entry for the current market with a documented fallback to a default. That gives you market-specific content without market-specific products, and it gives a merchandiser somewhere obvious to edit it.

The fallback matters more than it sounds. A market with no entry should render the default rather than rendering nothing, because the alternative is a launch checklist where somebody has to remember to author eleven blocks before a market can go live. Systems that fail to empty get shipped broken; systems that fail to a sensible default get shipped and then improved.

The same reasoning applies to the navigation and the homepage. A market that needs a different hero does not need a different store — it needs a homepage assembled from metaobjects that vary by market, which is the same content model you already built for the product page.

The fear behind a lot of duplication is duplicate content: if /products/shirt and /de/products/shirt are nearly the same page, will search engines punish you? This is the one area where Shopify does most of the work, and doing it yourself usually makes it worse.

Shopify generates hreflang tags automatically from your market and language configuration. That is the signal that tells a search engine these pages are alternates for different audiences rather than copies competing with each other, and it is derived from configuration you have already done rather than markup somebody has to maintain. Published languages are included in the store's sitemaps, which is how the alternates get discovered in the first place.

The thing to be disciplined about is not markup, it is machine translation. A market page that is the same page run through a translation engine, with no localised delivery promise, no local payment methods and no local returns address, is a thin page in a second language — and that is a content problem no hreflang tag fixes. Human-translate the twenty pages that carry your traffic and let the long tail be machine-translated; spending a full human translation budget on four thousand product descriptions is the most reliable way to spend a localisation budget badly.

There are cases where a second store is the correct answer, and they are worth naming so the decision gets made on the real criteria rather than on language.

A separate legal entity with its own accounts, its own tax registration and its own finance team. A market operated by a distributor you do not control. A catalogue that genuinely does not overlap — a business selling different products under the same brand in different regions, rather than the same products in different currencies. A market with regulatory requirements that would otherwise contaminate the main store's checkout.

Notice what is absent from that list: language, currency, price, delivery terms and market-specific content. None of those justify a second store, and all of them are the reasons most commonly given for one.

• International Shopify and Shopify Markets
• Shopify Markets or a store per country?
• Translation and localisation beyond currency