A multilingual online store, and what actually blocks a sale

The question a small seller usually asks is whether machine translation is good enough. It is the wrong question, and answering it carefully has kept a lot of shops monolingual for years while the actual barriers went unaddressed.

Here is the finding that reframes it. CSA Research surveyed 8,709 consumers across 29 countries and found that 76% prefer to buy where product information is in their own language, that 40% will never buy from websites in other languages, and, most usefully, that 65% prefer content in their language even if it is poorly translated. Two thirds of them already use machine translation themselves.

Your competition is not a perfect human translation. It is a shopper pasting your page into a translator, or leaving. Against that baseline, a decent automatic translation you control and can correct is a clear improvement, and the reason to do it is not quality. It is that you get to choose the words for the things that matter.

What actually stops someone buying in another language?

Almost never the adjectives. It is the practical unknowns: what this costs in money they understand, whether you ship to them, how long it takes, what happens at customs, and what it costs to send back.

A shopper can tolerate a clumsy product description. Nobody completes a checkout when they cannot work out the total. If your price shows in one currency, your delivery page lists domestic options only, and your returns policy quotes a postal service that does not exist in their country, translating the prose changes nothing about any of that.

Work in that order and each step is useful before the next one exists. A shop with English descriptions that clearly states prices in euros, ships to Germany within five days, and pays for returns is more sellable in Germany than a shop with beautiful German copy and no shipping information. The survey supports this indirectly: 67% of respondents said they tolerate mixed languages on websites, which is exactly what a partially localised shop looks like.

Which countries repay the effort most?

The ones where language preference is strongest, and the spread is wider than most sellers expect. CSA Research reported Germany with 57% of consumers buying exclusively at local language sites, and the strongest demand for native language content in five Asia Pacific markets: Taiwan at 94%, Korea 92%, China 92%, Japan 90% and Indonesia 88%.

Set those figures against where your traffic already comes from rather than against where you would like to sell. A shop with steady unconverted traffic from Germany has a clear first locale. A shop with scattered visits from twelve countries has no locale problem yet, and adding six languages to chase it produces maintenance work rather than sales.

Is translated content a spam risk?

Not when you are translating your own catalogue. The confusion is real and it comes from one word in Google's spam policy, so it is worth reading that sentence in full rather than in fragments.

The scaled content abuse policy targets pages generated for the primary purpose of manipulating search rankings and not helping users. Its examples include scraping feeds, search results or other content to generate many pages, including through automated transformations such as synonymizing, translating or other obfuscation techniques. The subject of that sentence is scraped content. Translating somebody else's pages to spin up volume is the abuse. Translating your own product catalogue so your own customers can read it is the opposite activity.

Where a real risk exists is in scale without purpose: generating forty language versions of a catalogue you cannot support, cannot answer questions about, and do not ship to. That is many pages that do not help users, and it fails on its own terms regardless of how they were produced. Two locales you can serve properly beat twelve you cannot.

How should the technical side be set up?

One URL per language version, annotated so search engines know they are the same page in different languages. Not a cookie, not a browser setting, not one URL that changes what it serves.

Google's guidance is to use different URLs for each language version and to connect them with hreflang annotations. The rules that trip people up are mechanical. Each version must list itself as well as every other version. All URLs must be fully qualified including the protocol. And if two pages do not both point to each other, the tags will be ignored, which is the single most common reason a correctly built set of translations does nothing.

One detail that decides whether the whole set works: hreflang can be declared in the page head, in your sitemap, or in HTTP headers, and Google treats the three as equivalent. Pick one and use it consistently. Mixing methods across a site is where contradictions creep in, and a contradiction is resolved by ignoring the annotation rather than by guessing which version you meant.

Script variants have their own notation where it matters, such as zh-Hant for Traditional Chinese. If you sell into a market where the script distinction is real, getting this wrong is more visible to customers than any translation error.

Should you redirect visitors to their local version?

No, and there are two independent reasons which is unusual enough to be worth noticing. Google advises against automatically redirecting users between language versions and against using IP analysis to adapt content, on the grounds that IP location is unreliable.

The second reason is not advice. Under the EU geo-blocking regulation, a trader is prohibited from re-routing a customer to another website without prior consent where the reason relates to their nationality, residence or establishment. Rerouting needs advance permission and cannot happen automatically based on location. The regulation has applied across the EU since 3 December 2018.

So the same design satisfies both: detect, suggest, let them choose. A visible banner saying this shop is available in German, with a link and no automatic jump, is compliant and is also what the search guidance asks for. An IP based redirect is a guess about a person, imposed on them, and it is the pattern both rules exist to prevent.

What does the geo-blocking regulation require beyond redirects?

Two more things that catch small sellers by surprise, and both are about treating an EU customer from another member state the same as a local one.

Traders cannot apply different general conditions of access based on a customer's nationality, residence or establishment, with defined exceptions covering situations where delivery is not physical or where a service is supplied in the trader's own member state. There is also a non discrimination rule on payment: you choose which payment methods you offer, but you cannot discriminate between customers through those choices.

Read practically, that means a shop selling into the EU cannot show a French visitor a higher price than a Belgian one for the same product on the same terms, and cannot refuse a card because of where it was issued while accepting the same brand of card locally. The prohibitions apply to business to consumer sales and to business to business sales made on standard terms, and they reach electronically supplied services such as software and e-books.

What the regulation does not do is force you to ship everywhere. You decide your delivery area. What you cannot do is quietly present different terms to different nationalities within the area you already serve, which is a distinction worth holding onto if you are also considering the pricing questions in our piece on what a small shop is allowed to change about a price.

How much does each extra language actually cost to run?

The translation is the cheap part now and it is not where the cost sits. The recurring expense is everything that has to stay true in more than one place.

Count it honestly before adding a locale. Every product added needs a description in each language. Every policy change needs propagating. Every support conversation may arrive in a language you do not read. Every seasonal campaign needs its copy twice. Every one of those is small, and the total is a standing obligation that grows with your catalogue rather than with your traffic.

Against that, the case for a second language is strong when it is a market you already have unconverted traffic from, where you can already deliver at a sensible price and time, and where you can handle a support request. When all three are true the locale mostly pays for itself. When only the traffic is true, you have built a shop that attracts people and then disappoints them in their own language, which is worse than the monolingual version because it raised an expectation first.

There is one shortcut worth taking seriously for testing a market. Translate the pages that answer the practical questions, delivery, returns, contact, plus your five best selling products, and leave the rest. That is a fraction of the maintenance surface and it tests the market honestly, because the pages you translated are the ones a buyer needs. If those convert, extend. If they do not, you have learned it cheaply and you have four pages to maintain rather than four hundred.

What about translating customer reviews?

Wanted by shoppers and delicate for a reason nobody mentions. The same survey found 73% want product reviews in their language at minimum, which makes reviews one of the highest value things to translate and one of the few you should not translate silently.

A review is somebody's own words attributed to them by name. Running it through a translator and publishing the result under that person's name changes what they said, and the failure modes for sentiment are exactly the ones that make reviews hard to read automatically in the first place. Sarcasm inverts, negation scope shifts, and a mixed review can come out sounding uniformly positive or uniformly damning.

The workable pattern is to show the translation labelled as one, with the original available. That satisfies the reader and keeps the reviewer's actual words on the page, which matters given how specific the rules around review authenticity have become. We went through those in the piece on what your reviews tell you and what you may not do with them, and the same principle applies here: you may present a customer's words, you may not author them.

Where does translation quality genuinely matter?

Anywhere a mistranslation creates an obligation or a safety issue. That is a much shorter list than the whole catalogue, and it is where any budget for human review should go.

Returns and cancellation terms come first, because a mistranslated window or condition is a promise you have made. Anything with a legal shape, warranty language, age restrictions, ingredient or allergen information, follows. Sizing and fit come next, since that is the single largest driver of returns in clothing and the vocabulary does not transfer cleanly between markets. Product names last, but they matter more than people think: a name that reads as unintentionally comic in the target language will be quoted back at you.

Everything else can be machine translated and improved on evidence. Watch which pages get traffic and no conversion, and fix those. This is measurable rather than a matter of taste, and if you want the formal version of how translation quality gets scored, our piece on measuring machine translation quality covers the metrics and what they miss.

Does support have to be in their language too?

It has more effect on repeat buying than the storefront copy does. CSA Research found 75% of respondents more likely to buy again from brands offering customer care in their language, which is a larger number than most localisation projects are justified on.

This is also the part that got cheap recently. Answering a support email in a language you do not speak was, until fairly recently, a reason not to sell into a market at all. It is now a translation step in a workflow you already run, with the caveat that anything committing you to something should be checked before it goes. The ticket triage logic is the same as it is in one language, and we set that out in the piece on which support tickets to automate first: facts you hold can be answered automatically, judgements cannot, and adding a second language does not change which is which.

The maintenance problem nobody plans for

Every locale you add multiplies every future change. Change a returns policy and you have changed it in one place and forgotten it in three. That drift is what turns a multilingual shop from an asset into a liability, and it happens quietly.

Two habits prevent most of it. Keep the operational facts, prices, delivery windows, return windows, in one structured place and render them into each locale rather than writing them into translated prose. And when you change something, treat the change as incomplete until every locale reflects it, in the same way a code change is incomplete until it builds. A shop that cannot do that reliably should run fewer locales rather than more.

Which is ultimately a question about how the shop is built. Locale routing, hreflang generation, a currency and delivery table rendered per market, a language banner that suggests rather than redirects: these are structural properties of the storefront rather than features you can bolt on. On a platform they are whatever the plugin offers. When the code is yours, they are a routing decision made once and reused, which is the practical reason to prefer a shop whose structure you control before you add the second language rather than after.