A French store that wants to sell in Germany, Spain, and the Netherlands can triple its potential market. The price to pay: translating 5,000 product pages into 7 languages, or 35,000 translations. At €20 per page with a freelance translator, that means €700,000 and 18 months of lead time — unrealistic for 99% of stores.
In 2026, AI-targeted machine translation makes this project possible in 2–3 weeks for under €1,000. But between "doing it" and "doing it well," there are 4 pitfalls to avoid.
Generic machine translation engines (DeepL, Google, Microsoft) are excellent for standard prose. They fail in e-commerce for three reasons:
Product vocabulary is market-specific. In British English, pants are called "trousers," while in American English they are "pants" — and "pants" in the UK means underwear. An uncalibrated machine translator does not know that.
Local units and formats. FR size 44 = US 10 = UK 10 = CN 280. A 75 cm high chair in France becomes 29.5" in the US. A 5000 mAh battery stays 5000 mAh everywhere — but "2 days of battery life" may become "2 days" or "48 hours" depending on the market's commercial tone.
Cultural references. "Ideal for pre-dinner drinks with friends" does not translate word for word into German. In Spain, "tapas" may replace "appetizers." These adaptations break a generic translator.
The solution: a translation pipeline with an e-commerce-specific brief, plus post-processing that detects and corrects local errors.
When you translate a blog post or a product page, the URL question comes up.
Product slug: should it be translated?
✅ For local SEO, yes. An EN slug like leather-derby-shoes ranks better in the US than an FR slug like chaussure-derby-cuir.
❌ For maintenance, it is costly — 5,000 products × 7 languages = 35,000 slugs to manage, with redirects when changes happen.
The right approach: use hreflang infrastructure to tell Google which language/market matches which URL, and use localized slugs by language (not by country):
One slug per language, not one per country. Regional variants (fr-CA vs fr-FR, en-US vs en-GB) should be handled through hreflang and server-side geographic targeting, not through separate URLs.
A real-world problem: an FR store expanding into German sees its "ß" become "?" in product titles. Its meta description "für Damen" shows up as "fr Damen." Its URLs contain unreadable URL-encoded characters.
Cause: the translation pipeline or database is not configured in UTF-8. In 2026, this is rare — but not nonexistent, especially on older WooCommerce setups (MySQL in latin1 by default).
Checklist:
Database in utf8mb4 (not plain utf8 — utf8 does not handle all emojis and some Asian characters)
Product table collation in utf8mb4_unicode_ci or utf8mb4_0900_ai_ci
The ideal plan: AI translates → human reviews → publish. In reality, across 35,000 translations, nobody reviews all 35,000. Here is the realistic approach:
Tiered strategy by ROI
Top 20% of the catalog by revenue → systematic human review (native speaker from the target market). Typically 200–1000 pages.
Middle 60% → sample-based review (10% of pages). This catches systemic errors without scaling costs.
Bottom 20% → AI only + automatic anomaly detection (abnormal length, unreadable characters, too many source-language words).
This strategy reduces the human review workload to ~15% of the catalog while covering 85% of revenue. It is the trade-off that makes multilingual e-commerce realistic.
Here is the pipeline we use to translate catalogs of 5,000 to 50,000 pages:
Step 1 — Create the market brief
For each target language, define:
The tone (formal vs informal)
The specific vocabulary (lists of terms not to translate, required translations for certain words)
Units and formats (sizes, weight, currency)
Cultural references to adapt (yes/no)
This brief is created once per language, in 1–2 hours. It is reused for all future translations.
Step 2 — Targeted AI translation
GPT-5.4 (or Claude Opus) receives the source FR page + the target market brief. It produces:
The translated title calibrated for local SEO
The full description (benefits rewritten, not just translated)
The meta description (re-optimized for CTR in the target market, not a direct translation)
The translated tags
A candidate slug (or 3 candidates to validate)
Step 3 — Automatic validation
A script checks:
No source-language words left over ("le," "de," "the," "the" in the EN version...)
Length within limits (title < 60, meta < 160)
Correct special characters for the language
Valid slug (no forbidden characters)
Pages that fail are sent to a manual review queue.
Step 4 — Batch publishing
Validated pages are published in bulk through the admin API (via POST /admin-cms/blog/articles with locale=xx, or the product equivalent). Rollback is possible if something goes wrong.
To cover 80% of the EU market: FR, EN, ES, DE, IT. These 5 languages represent ~350 million consumers. Adding PT and NL brings coverage to ~90%. Beyond that, ROI drops quickly — prioritize depth (quality in the first 5) over expansion (adding Polish, Czech, etc.).
No. Reviews in the source language signal authenticity. Google does not penalize a mix of languages in reviews — it can even be a trust factor. Exception: if 90% of your reviews are in one language and you are expanding internationally, add subtitles or translations for the main reviews at the bottom of the page.
By IP, no (VPNs break detection and create traps for Google crawlers). By the browser's Accept-Language header, yes, but carefully. The right 2026 approach: explicit localized URLs (/fr/..., /de/...) + a persistent language selector visible in the header.
Through hreflang in the sitemap and in <link rel="alternate"> tags. Content can be identical for 90% of pages, with local variants (price, currency, expressions) for the top 10% of the catalog. Search engines serve the right version based on the visitor's IP geolocation.
Yes, under one condition. EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) measures the overall reliability of your site, not each description in isolation. A catalog with AI translations + accurate product information + clear policies + authentic reviews is fine. A catalog with AI translations + thin content + missing legal information will be penalized — but the problem is not AI, it is overall quality.
With the AI pipeline: 3–5 days total, including brief creation, translation, validation, and publishing. With human post-editing on 20% of the catalog: add 2–3 weeks for review. The first language takes the most time (pipeline setup); the next ones can be deployed in 2–3 days each.