Claude for translating and localising ecommerce content

This blog runs in three languages, and the mistake that took me longest to spot wasn’t a translation mistake. It was a search mistake. One of my English pages was impeccably written and pulled in zero impressions, because I’d translated the Spanish keyword instead of researching what somebody in the UK actually types. The sentence was correct. The term didn’t exist.

In an ecommerce catalogue that same failure gets multiplied by your SKU count, and it doesn’t travel alone: sizes that don’t match, prices with the wrong punctuation, returns windows copied from another jurisdiction. This post is about how I use Claude to translate and localise ecommerce content at scale without producing the flat copy you can spot on the first read. It isn’t the content ops guide, and it isn’t the Shopify markets setup. It’s the quality part.

In 30 seconds:

• Translating changes the words. Localising changes what sits inside them: units, sizing, currency, legal windows and the season.
• Google only treats localised versions of a page as duplicates if the main content remains untranslated.
• A translated keyword isn’t a researched keyword, and that gap decides whether the translated page gets traffic.
• The locked-term glossary is the single piece that prevents most errors once you go from twenty products to two thousand.
• The Batches API takes up to 100,000 requests at half price, so the bottleneck stops being generation and becomes review.

What’s the difference between translating and localising a catalogue?

Translating changes the language of the text. Localising changes the data sitting inside that text so it stays true in the destination market. It’s a boring distinction right up until you watch it fail in production.

An example from a fashion retailer I audited, selling into France and the UK: the English pages said “size 38” because the Spanish original said “talla 38”. Grammatically perfect. Commercially, a guaranteed return, since British sizing doesn’t line up. Nobody checked that field because the text read fine.

Before I touch anything I split the content in two: what gets translated and what gets converted. The first is prose and allows freedom. The second is data, and it needs an explicit rule per market. Mix them in the same prompt and the model will get it right most of the time, which in a large catalogue is exactly the problem.

What breaks when you translate word for word?

Everything that isn’t prose. The long description survives. What doesn’t survive are the fields carrying a data point inside them: a size, a measurement, a deadline, a price, because the text translates just as smoothly while the fact underneath stops being true in the destination market.

The seasonality row looks anecdotal. It’s the one I’ve seen sabotage launches most often: if you sell to the UK and Australia from one catalogue, your summer sale lands in a country that’s in the middle of winter. The model translates “summer” as “summer” because that’s what you asked for. Flipping the editorial calendar is your call.

Returns carry a different, more expensive risk. A cooling-off period isn’t copy, it’s an obligation shaped like a sentence. I pull that out of the automated flow entirely.

How do you build the workflow for a whole catalogue?

Four pieces: a frozen glossary, a prompt with real examples, batch processing, and a diff somebody can actually review. In that order, because each one depends on the last.

1. Freeze the glossary before you translate the first product. Product names, proprietary materials, collection names, regulated claims, and any term the brand keeps identical in every language. This file goes into every request.
2. Write the conversion rules per market. Sizing, units, price format and seasonality, with the rule written down rather than assumed.
3. Build the prompt from examples, not adjectives. Anthropic’s documentation is direct about it: examples are one of the most reliable ways to steer output format, tone and structure, and it recommends including three to five for best results. Three already-approved translated products beat a paragraph describing your tone of voice.
4. Structure the input with XML tags. The same guide explains they help the model parse complex prompts unambiguously when you’re mixing instructions, context, examples and variable inputs. One <glossary>, one <market_rules> and one <product> per request.
5. Process in batches. The Message Batches API is capped at 100,000 requests or 256 MB per batch, most batches finish in under an hour, and they cost half.
6. Ship a reviewable diff, not a fresh CSV. Source and translation side by side, with converted fields flagged. If it can’t be skimmed, nobody will review it.

One cost detail: if you repeat the same glossary and instruction block in every request, prompt caching reuses that prefix and cuts both processing time and cost. Its default lifetime is five minutes, so it only pays off when you fire the requests back to back. The rest of the production machinery lives in my guide to Claude for ecommerce content ops.

Why is the glossary the piece that pays off most?

Because it’s the only thing stopping the same concept from being translated three different ways across three consecutive products. A model has no memory between independent requests, and in a batch of two thousand parallel calls each one decides on its own.

In a homeware catalogue I found the same finish appearing as “brushed brass”, “burnished brass” and “antique brass” inside one product family. All three were defensible. The problem wasn’t quality: the collection page filter broke, because the attribute stopped having a single value.

My glossary has three blocks and no more:

• Locked. Terms that never get translated. Brand, collection, proprietary material.
• Pinned. Terms that do get translated, but with one approved translation per language. Finishes, fabrics, categories and anything that feeds a navigation filter.
• Banned. Words I don’t want to see in the output, usually calques and false friends the team has already flagged.

The third block grows fastest, and it’s the cheapest way I know of turning reviewer feedback into a permanent rule. Any correction that comes up twice becomes a line in the file. The third time, it never reaches the reviewer.

Do you still need a native reviewer?

Yes, and not out of distrust for the model. The error that costs you money isn’t the grammatical one, which is visible, but the one that reads perfectly and isn’t what your category calls that thing in that market.

So what does a native speaker catch that a well-briefed model doesn’t? Register, mostly. If your brand is on first-name terms in English and the French translation reaches for the vous of a private bank, not one sentence is wrong and the tone is off. They also catch category convention: what the trade calls something versus what it technically is. And the claim that’s normal marketing here and borderline regulated there.

What I do is stratified sampling. A hundred per cent of templates and legal copy, a hundred per cent of category pages because there are few of them and they concentrate traffic, and one sample per product family on the detail pages. If a family throws up three corrections, it gets reviewed in full and the glossary gets updated.

That depends a lot on how similar your products are. In fashion, with templated descriptions, sampling works. In technical product you’ll need to review considerably more.

What about SEO on the translated pages?

They need two things translation doesn’t give you: their own keyword research and their hreflang annotations done properly.

Start with the good news. Google is explicit that localized versions of a page are only considered duplicates if the main content of the page remains untranslated. Genuinely translating the body doesn’t create a duplicate problem. What does create one is translating the template and leaving the content in the source language, which is exactly what happens when somebody “internationalises” a shop by swapping the menu and the footer.

The same documentation notes there are three ways to declare those versions, HTML, HTTP headers and sitemap, and that each language version must list itself as well as all the others. That self-reference is the failure I run into most. The Shopify-specific setup is covered in Shopify international: hreflang, markets and translations, so I won’t repeat it here. Google also recommends avoiding automatic redirects that push users from one language version to another.

Now the awkward part. Your translated page’s keyword shouldn’t come out of the translator. I treat every market as a new site: its own research, and the translation is written around that term. It’s more work, and it’s the difference between a translated page and a page that ranks. Same logic applies when generating meta descriptions at scale: the snippet competes against local results, not against a translation of the Spanish snippet.

There’s one more reason not to fully automate this. Google’s spam policies list, under scaled content abuse, generating many pages through automated transformations like synonymising or translating where little value is provided to users. The practical reading isn’t “don’t use AI to translate”: it’s that the value has to be there. For the rest of the page-level work, I’ve got Shopify product page SEO and, at collection level, collection page SEO.

Frequently asked questions

Does Google penalise AI-translated content?

Not for using AI. Its spam policies target generating many pages through automated transformations, translation included, where little value reaches the user. The difference is whether the page genuinely answers the query in that market or just restates the original in other words. Reviewed and localised translation: no problem. Mass unreviewed output: real risk.

Can I reuse the same translated keyword in every language?

It rarely works. The most-searched term in the destination market usually differs from the literal translation, and sometimes it isn’t even the word you’d pick yourself. Do your own research per market and write the translation around that term. Invert the order and you’ll end up with a correct page nobody searches for.

How much does translating a large catalogue with Claude cost?

It depends on how long your product copy is and which model you run, so any figure quoted without seeing your catalogue is invented. What is fixed: the Batches API costs half and takes up to 100,000 requests per batch. In my experience the dominant cost stops being the model and becomes your native reviewer’s time.

Is translating the title and meta description enough?

No. Google states that localised versions only count as duplicates when the main content isn’t translated, and that’s precisely what happens if you translate metadata and template only. A page with a French title and an English body converts terribly. Translate the main content or don’t publish that version yet.

What do I review first if I can’t review everything?

In this order: legal and returns copy, shared templates, category pages, then one sample per product family. Templates and categories repeat across thousands of URLs, so an error there multiplies. A badly translated product page costs one sale; a badly translated template costs the market.

Translating is the cheap part

Translating a catalogue stopped being the bottleneck a while ago. A well-built batch hands you two thousand products in an afternoon. What still costs is everything else: the rules per market, keeping the glossary alive, reviewing what actually needs reviewing, and doing search research from scratch in each language.

That’s why I’m sceptical of anyone selling “we’ll translate your shop with AI in a week”. The translation takes an afternoon. Localisation is a project, and hreflang, per-market research and native review are most of it. When somebody skips those steps you spot the result fast: pages that read well, rank for nothing, and generate size-related returns. For a general read of the site before you expand, the Shopify SEO audit with Claude is the starting point.

On my own site the rule hasn’t changed across three languages: nothing publishes without a keyword researched in that language and a full read by somebody who speaks it that way. If you’d like me to look at your multilingual catalogue, your hreflang and the workflow you’re translating with, book 30 minutes of consulting and we’ll go through it together.