You own your translations. Forever.
This is the single most important thing to understand about StoreLingo. Every other choice in this product flows from it.
The two architectures
Localization apps for Webflow come in two flavors:
Runtime overlay. The translation app keeps your translated text on its own servers. When a visitor lands on your German page, the app injects a JavaScript layer that swaps the visible text from English to German at render time. Weglot, Linguana, and most browser-based translation tools work this way. The translated "page" is not a real page; it's an English page with a German costume painted on it by a script.
Real CMS rows (Strategy A). The translation app writes actual Webflow CMS items into your own site, one per locale. Each translated product is a new row in your Products collection with a German slug, German fields, and a Webflow-native page that Google indexes like any other. StoreLingo is the only Webflow Marketplace app for Ecommerce that uses this architecture.
The architectures look similar from the outside on day one. The difference is everything that happens after day one.
What "you own them" actually means
Open Webflow Designer right now and look at your Products collection. After you publish a German locale with StoreLingo:
- Five new product rows appear with
de-slug prefixes. - You can click any one of them in Designer and edit the price, the description, the images, the variants - the normal Webflow Ecommerce editor, working exactly the way you already know it.
- You can export them via CSV.
- You can deep-link to them from a custom German landing page you build in Webflow Designer.
- You can write Webflow filters that show only
locale=deitems in a list, and Webflow's CMS handles it natively. - They appear in your
sitemap.xml, with their own meta tags, their own canonicals, and their own URLs that Google crawls and ranks.
None of that is true of runtime-overlay tools. With those, your "translated products" don't exist in Webflow's CMS at all. They are JavaScript transformations applied to your English pages on the fly, served from someone else's CDN, indexable only as much as Google can render JavaScript (less than people think).
Things that change after day one
| Event | StoreLingo (Strategy A) | Runtime overlay (Weglot/Linguana) |
|---|---|---|
| You cancel your subscription | All translated CMS rows stay in your Webflow site. Pages keep rendering. You can keep selling. | The translated layer stops loading. Locale URLs serve English again or 404. |
| The translation app goes offline | No change. Your pages are served by Webflow, not the app. | Locales go dark until the app comes back up. |
| You migrate to a different translation tool | You export the existing translations via CSV. The new tool imports them, no re-translating. | The old tool's database is locked. You re-translate from scratch. |
| You add a custom locale-aware landing page in Webflow Designer | Trivial. The translated CMS items are first-class Webflow data; you use them in a Collection List with a filter. | Impossible without the overlay app's UI, because the translated rows don't exist in Webflow. |
| You need to edit a translated product without opening StoreLingo | Open Webflow Designer, click the row, edit, publish. Standard Webflow flow. | You must open the overlay app's panel. There is no Webflow row to edit. |
| You want to A/B test a German headline | Use Webflow's normal split testing on the German CMS row. | Hope the overlay app has split testing. Most don't. |
| Webflow ships native Ecommerce localization (someday) | One-click migration: your CMS rows are already the format Webflow expects. | Painful: re-import everything via Webflow CSV, lose your translation history. |
The pattern is the same in every row: your translated content stays usable and editable inside Webflow no matter what happens to the app.
Why we chose this trade-off
Strategy A is harder for us to build. We have to manage duplicate-product creation in Webflow, handle slug collisions, track per-locale CMS row IDs, support an Orphan Recovery flow for the disconnect/reconnect case, and deal with Webflow's Ecommerce SKU model rather than just intercepting strings. A runtime overlay would have been about a tenth of the engineering work.
We chose Strategy A because every customer who has ever switched localization tools has the same complaint: "I'm locked in. If I leave, I lose everything." We refuse to be the next vendor in that pattern. Your translations belong to your Webflow site, not to StoreLingo.
The honest cost of Strategy A: hreflang is a tiny bit slower to index than server-rendered tags (we inject it via the Webflow Custom Code API, see SEO and hreflang), and a few SEO-purist setups will prefer the manual mode where you paste hreflang into Designer yourself. For the 99% of customers who just want translated pages that work and survive, Strategy A wins by a wide margin.
What this means for you in practice
Three checkpoints to make Strategy A's promise real:
- You can audit it. Open Webflow Designer right now. Go to the Products collection. After StoreLingo publishes a locale, the duplicate rows are visible with their locale-prefixed slugs. They're yours.
- You can leave anytime. Cancel StoreLingo from the Billing portal. Your translated pages keep working. We don't delete anything from your Webflow site on cancel.
- You can take it elsewhere. Export every translated CMS row via the in-app CSV export, or via Webflow's native CSV export. The data is portable from day one.
That's the whole pitch. Everything else in these docs is mechanics: how to set it up, how to publish, how to handle edge cases. The mechanics are interesting only because they protect this promise.