Translate Ecommerce Product Pages: A Practical Guide
Translate every customer-facing field on a product page, not only the title and description: attributes, variant options, size guides, reviews, image alt text, shipping and returns text, the page title and meta description, and the structured data. Then localise what translation alone cannot fix, such as currency, units, sizes and delivery promises. Give each language version its own crawlable URL and connect the versions with hreflang.
What should you translate on a product page?
Use this as a checklist. The first column is content; the second is what usually gets missed.
| Element | Translate? | Common miss |
|---|---|---|
| Product title and description | Yes | Re-using the source title with a translated description |
| Attributes and specifications (material, colour, fit) | Yes | Values stored as codes or free text in the catalogue |
| Variant option names (Size, Colour) and values | Yes | Option labels left in the source language in the selector |
| Size guide, care instructions, ingredients | Yes | Images of tables that cannot be translated |
| Reviews and ratings | Decide per policy | See below |
| Image alt text and captions | Yes | Alt text auto-generated from the filename |
| Breadcrumbs, filters, buttons, error messages | Yes | Theme strings, "Add to cart" states, validation messages |
<title>, meta description, headings |
Yes | Meta data left untranslated while the body is translated |
| URL slug | Optional, recommended for reach | Discussed in translating URLs and slugs |
| Structured data | Yes | JSON-LD generated from source-language fields |
| Policies (shipping, returns, terms) | Yes, with legal review | Machine translation of legal text |
Untranslated boilerplate can hurt discoverability, too. Google notes that when you translate only a template and leave the main content in one language, the pages can appear multiple times in search results with different boilerplate languages; localized versions are only considered duplicates if the main content stays untranslated.
How should reviews and user-generated content be handled?
Reviews are written in a single language, so you have three reasonable options: show them in the original language with a label, offer a translate-on-demand control, or show reviews written in the visitor's language first. Keep these constraints in mind:
- If you mark up reviews, Google's review snippet guidelines say marked-up review content must be visible to users on the page, ratings should be tied to a specific item, and you must not include fake or undisclosed incentivised reviews.
- Do not aggregate reviews or ratings from other websites into your markup.
- Translated reviews are a machine-generated representation of someone's words. Label them as translated so readers can judge them.
- Be careful with privacy when you send review text to a translation service; our GDPR and privacy article covers what to check.
What does localisation add beyond translation?
Translation changes words. Localisation changes what the page promises. For each target market, review:
- Currency and price display. Show prices in the local currency with the local format (decimal separators and symbol placement vary). If you show different currencies, Google's merchant listing documentation says to use a distinct URL per currency.
- Units and sizes. Metric or imperial, and regional clothing and shoe size systems. Show a conversion table or sizes in the local system, and test the size-guide images.
- Dates and times. Format delivery dates, sale end dates and opening hours using locale-aware formatting rather than concatenated strings.
- Shipping. Which countries you ship to, costs, delivery times, customs and duties responsibilities, and cut-off times.
- Returns and warranty. Windows, who pays, and statutory consumer rights, which differ by country. Have these reviewed by someone qualified rather than relying on literal translation.
- Tax. Whether prices include VAT or sales tax, and how this is shown. Requirements vary; confirm with your tax adviser.
- Payment methods and trust signals. Locally expected payment methods, local contact details and local support hours.
- Cultural fit. Colour names, imagery, sizing language ("petite") and product names that mean something unintended in the target language.
How should URLs and hreflang work for product pages?
Use separate, crawlable URLs for each language version, and annotate them with reciprocal hreflang. Google states that each language version must list itself and all other versions, and that if two pages do not point to each other, the tags are ignored. For stores with many products, sitemaps are often easier to maintain than head tags; see hreflang implementation methods.
<link rel="alternate" hreflang="en" href="https://example.com/en/products/wool-coat/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkte/wollmantel/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/wool-coat/" />
Variants complicate this. Google's product variant documentation says each variant must be directly preselectable with a distinct URL, and on multi-page sites each page needs full, self-contained markup for the entities it defines. Apply the same hreflang logic to each variant URL that is indexable. The hreflang guide explains the rules, and Shopify multilingual SEO shows how one platform handles them.
How do you write product structured data for several languages?
Google distinguishes product snippets (pages where people cannot buy directly) from merchant listings (pages where they can). For merchant listings the documentation lists name, image and offers as required, with a price greater than zero and a currency. availability is listed as recommended rather than required, alongside hasMerchantReturnPolicy, shippingDetails, brand, description, sku, gtin and aggregateRating. Check the current documentation before relying on this, because properties change.
Per language page, a minimal example:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Wollmantel",
"description": "Mantel aus recycelter Wolle, mit Futter.",
"image": "https://example.com/img/wollmantel.jpg",
"sku": "COAT-001",
"offers": {
"@type": "Offer",
"url": "https://example.com/de/produkte/wollmantel/",
"price": "249.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}
}
</script>
Guidance, partly documented and partly our inference:
- Documented: one distinct URL per currency; shipping and return policies are best provided site-wide under
Organizationmarkup, with offer-level policies only to override; variants useProductGroup,variesBy, and unique IDs per variant. - Inference: write
name,descriptionand policy text in the language of that page and keep the price and currency identical to what the visitor sees. Mismatches between visible content and markup are a common cause of problems. Do not mark up text that is not on the page. - The Product type itself has no per-language switch in the Google docs we read; the language of the markup follows the page. Schema.org's
inLanguageproperty applies to content types such as CreativeWork, not Product, so do not add it to Product.
What about checkout, emails and customer accounts?
Visitors who read a translated product page and then land in an English checkout often abandon it. Review these surfaces for every language you sell in:
- Cart, checkout, address forms and error messages, including field formats such as postal codes and phone numbers.
- Order confirmation, shipping notification and refund emails; invoices and packing slips where legally required.
- Account pages, wishlists and back-in-stock notices.
- Customer support: contact forms, help articles and auto-replies.
On Shopify, the documentation says that once you publish a language, checkout and email notifications are displayed in the customer's language, and you can edit the notification translations; confirm the details for your plan and theme in the platform documentation. See how to set up a multilingual Shopify store.
Key takeaways
- Translate all customer-facing product fields, including attributes, variant options, alt text, meta data and policies, not only the description.
- Give each language and currency its own crawlable URL, connected by reciprocal hreflang annotations.
- Localise currency, units, sizes, shipping, returns and tax statements for each market; translation alone does not do this.
- Keep structured data in step with the visible page, in the page's language and currency, and review required properties in Google's current documentation.
- Treat reviews carefully: keep marked-up reviews visible and genuine, and label machine translations.
- Check checkout and emails, where untranslated text commonly costs sales.
Sources
- Google Search Central: Product structured data – product snippets vs merchant listings, policies, Merchant Center
- Google Search Central: Merchant listing structured data – required and recommended properties, distinct URL per currency, shipping and returns
- Google Search Central: Product variants – ProductGroup, variesBy, unique IDs and URLs per variant
- Google Search Central: Localized versions of your pages – hreflang rules, translated template vs content
- Google Search Central: Review snippet guidelines – visible review content, fake reviews, aggregation limits
- Shopify Help Center: Languages – translation methods, checkout and email notifications
Frequently asked questions
What should I translate on an ecommerce product page?
Translate everything a buyer reads or relies on: title, description, attributes and variant options, size guides, shipping and returns text, buttons, error messages, image alt text, and the page title and meta description. Then localise price, currency, units and sizes, and keep structured data consistent with the visible page.
Should each language have its own product URL?
Yes, this is the safest approach for search. Google's product documentation requires a distinct URL per currency for merchant listings and recommends separate localized URLs with hreflang for language versions. Translated slugs are optional; the key point is that each version is crawlable and cross-referenced.
Do I need to translate product reviews?
Not necessarily. You can show reviews in their original language and label them, or offer translation on request. If you mark reviews up with structured data, Google's guidelines say the marked-up review content must be visible on the page, and reviews must not be fake or aggregated from other sites.
Should structured data be translated too?
Yes, as a practical rule. Product markup on each language page should describe the same product as that page shows, with the name, description and price in that page's language and currency. Google's merchant documentation also advises a distinct URL for each currency.