Webflow SKU variant translation: the missing manual

"Yes, we support SKU variants" is the most overloaded phrase in Webflow translation marketing. Every tool says it. What they each mean by it ranges wildly, and the gap between them is where customer carts break in production.

This is the post we wished existed when we were building StoreLingo's variant translation path. We hit every footgun. Some of them silently. Some of them loudly — the "Unable to open this product because a variant is missing" Designer error is one we shipped, fixed, and turned into a postmortem.

Webflow's Ecommerce data model in 90 seconds

Before we can talk about translating variants, you need to know the actual shape of the data. A Webflow Ecommerce product has three connected entities:

1. The product. A row in the product CMS collection. Has fields like name, description, slug, a reference to its default-sku, and a sku-properties array describing the variant schema.
2. The SKUs. Each variant combination (Red+S, Red+M, Blue+L) is a separate row in the SKU collection. Each SKU has its own name, slug, price, inventory, and a back-reference to the product.
3. The SKU properties. The variant schema itself ("Color", "Size") is on the product, while each SKU row references the specific property values it represents.

How most translation tools handle variants (the visible-text approach)

Runtime-overlay tools (Weglot, Linguana) live in the rendered DOM. When a German customer lands on the page, the overlay walks the DOM, finds "Color: Red" and "Size: Large," swaps them to "Farbe: Rot" and "Größe: Groß," and you see translated UI.

This works for the cosmetic case. It breaks down at five real-world points:

For low-stakes catalogs the overlay approach is fine. For a serious ecommerce catalog with regional inventory, regional pricing, and order fulfillment that reads structured SKU data, visible-text translation is a footgun pretending to be a feature.

The "right" way: duplicate SKU rows with structured fields

The mechanics

1. For each source product, you've already duplicated the parent product row with a de- slug prefix.
2. For each source SKU, you create a duplicate SKU row in the same SKU collection. The duplicate inherits the source SKU's price, inventory, sku-id, and gets a translated name and locale-prefixed slug.
3. The German parent product's default-sku field is updated to point at the DUPLICATE'S OWN SKU id — not the source's. This is the variant-link fix we shipped in v2.
4. The sku-properties schema gets translated and written to the duplicate. Property value labels ("Red" → "Rot") get translated. Internal property IDs stay scoped to each product.

Done correctly: the German product page loads with German property labels, German SKU names, real German-row inventory counters, and a click-through to checkout that POSTs structured German-SKU-row data.

The variant-link bug we shipped (and what it taught us)

Worth describing in detail because we suspect other Webflow Ecommerce localization tools have similar bugs sitting undiscovered.

Our v1 publish flow looked like this: fetch the source product including its full fieldData, spread it into a new object, overlay our translated field values, PATCH or POST to Webflow. Simple. Works for a normal product PATCH.

Two things happened:

• Storefront silently mostly worked. Webflow's render falls back to the first SKU when default-sku resolves to nothing, so customers could browse and order. Possibly the wrong thing.
• Webflow Designer refused to open the product. Designer strictly resolves default-sku and throws "Unable to open this product because a variant is missing."

If you're using a translation tool that emits Webflow Ecommerce duplicates and you ever see "variant is missing" in Designer on a translated product, this is almost certainly the bug.

Pricing translation: a separate problem

Even with perfect variant labels, you may want different prices per locale. Webflow's SKU price is a structured object: { value: 1900, unit: "USD" }. Localizing this is not a translation problem; it's a regional-pricing decision.

Three approaches:

1. Same nominal value, different currency unit. Set the duplicate's SKU price to { value: 1900, unit: "EUR" }. Customer in Germany sees "€19.00."
2. FX-converted values. Set the duplicate's SKU price to { value: 1750, unit: "EUR" } if EUR/USD is 0.92. Manual but accurate.
3. Webflow's multi-currency feature. Supported on Advanced plans. Hand the regional pricing problem off to Webflow's currency layer.

StoreLingo preserves the source SKU's price object verbatim on first duplicate creation, so you can edit prices per-locale in Webflow Designer after publish.

How to know if your current tool handles SKU variants properly

Five tests. Try them on a real translated product in your store.

1. Open the translated product in Webflow Designer. Does it open cleanly? If you see "Unable to open this product because a variant is missing," your tool has the variant-link bug.
2. Inspect the translated product's SKU rows in Designer. Separate rows per variant, or just one row with the source name?
3. Place a test order through the translated product page. Webflow order confirmation: translated SKU name or source name?
4. Change inventory of the translated XL SKU in Designer. Does it stick? Affect storefront separately from source XL SKU?
5. View source on the translated product page. Form's underlying value attributes: structured SKU id or translated string label?

Pass tests 1–4 and your tool is doing structured variant translation. Only visible-text on the page but tests 2–5 fail? That's runtime overlay; know its limits.

Full publish-pipeline detail: StoreLingo publishing docs. The variant-link fix history: resubmission changelog.

The short version

"Supports SKU variants" without context is marketing-speak. Ask whichever tool you're evaluating these five questions:

1. Do you create real per-locale SKU rows in my Webflow CMS, or translate at the visible-text layer?
2. Can I edit a translated SKU's name and inventory in Webflow Designer independently of the source?
3. Does the duplicate product open cleanly in Designer, with the SKU dropdown populated?
4. When I place a test order, does the order data carry the structured SKU id, or just a translated string label?
5. How do you handle currency on the translated SKU's price object?

If the answers are vague, the tool isn't doing structured variant translation. That might be fine for your catalog. It's worth knowing.