When we launched Taocarts as a multi-language storefront for reverse-Taobao resellers, traffic was the bottleneck. Sellers had great Chinese products, but overseas buyers couldn't find them through Google or their local search engines. The catalog existed; it just wasn't discoverable.

Here is the retrospective on how we approached SEO for a marketplace that ships content in five languages from day one.

The core problem: one product, five languages, one URL mess

A single SKU sourced from Taobao or 1688 needed pages in English, Korean, Japanese, Spanish, and more. The naive approach — translate the title and ship it — produced thin, duplicate-looking pages that search engines ignored.

We had to solve three things at once:

  1. Each language version must be a real page with unique, human-readable copy, not machine spam.
  2. Search engines must understand these pages are the same product in different languages.
  3. Local buyers must land on the version their locale expects, without a redirect maze.

Step 1: Treat localization as rewriting, not translation

We built the content layer so each locale has its own editable fields: title, description, meta description, and category labels. A Korean listing for a gaming laptop isn't a translated Chinese listing — the spec emphasis, the search phrases real Korean buyers use, and the category path are authored per market.

This is where our multi-language architecture (React frontend + Laravel backend, with locale-aware content tables) paid off. Copy lives in locale-scoped rows keyed by sku + locale, so a seller can tune the Korean page without touching the English one.

Step 2: hreflang so Google stops guessing

Every localized page emits a full hreflang set pointing to all sibling locales plus a x-default. We generate these server-side from the same sku + locale key set, so they never drift out of sync.

The gotcha we hit: when a locale was missing for a SKU, we previously dropped that entry from the hreflang block. That taught Google the set was inconsistent. Now we always include x-default even if a specific locale isn't authored yet, and we backfill missing locales in a nightly job.

Step 3: Sitemaps per locale, not one giant file

A single sitemap with mixed locales confused crawl budget allocation. We switched to one sitemap per locale, each submitted separately in Search Console. Crawl rates per market became observable, and we could see which regions were under-indexed.

We also added lastmod based on the content row's updated timestamp, so edits to a Korean description actually triggered a recrawl instead of waiting for the next full sweep.

Step 4: Structured data that survives translation

Product schema was the same across locales, but our initial JSON-LD hardcoded Chinese category names. We moved category and brand identifiers into locale-scoped reference tables, so the structured data reads naturally in each market. This noticeably improved rich-result eligibility abroad.

What changed

After rolling this out, organic discovery from local search became a meaningful acquisition channel — not just paid and social. The lesson wasn't "do SEO," it was: multi-language isn't a checkbox, it's a content architecture decision. If your localized pages are thin or disconnected, search engines treat them as noise.

If you're building for overseas buyers, design the locale model before you write the first translation. Retrofitting hreflang and sitemaps onto a flat catalog is painful; getting it right early is almost free.

Tags: ecommerce, webdev, i18n, automation