Ein mittelständischer Onlineshop entscheidet sich, in einer zweiten Sprache zu verkaufen. Die Entscheidung fällt dann oft dort, wo zuerst jemand antwortet: Kann unsere Plattform das? Das ist eine Werkzeugfrage – und wer die Internationalisierung so beginnt, greift zu dem Plugin, der App oder dem Plattform-Feature, das ohnehin schon installiert ist. Die Architekturfrage kommt, wenn überhaupt, ein Jahr später auf den Tisch: dann, wenn der Katalog über drei Storefronts dupliziert ist und niemand mehr genau weiß, warum.
BigCommerce hat am 21. August 2026 ein Beispiel dafür geliefert: nativer Mehrsprachen-Support, allgemein verfügbar, der Sprachvarianten innerhalb der Plattform verwaltet, statt den Shop je Sprache aufzuteilen. Das ist eine echte Funktion. Eine Entscheidung ist es nicht. Die Entscheidung lautet, wo die Übersetzung liegt – in der Plattform, in einer Schicht davor oder in der Quelle. Und sie wirkt lange nach dem Go-live nach.
Blackbit ist Commerce Engineering Partner für mittelständische E-Commerce-Unternehmen im DACH-Raum, die neue Märkte erschließen wollen, ohne ihre Produktdatenpflege zu verdoppeln.
Welche drei Wege gibt es, einen Onlineshop mehrsprachig zu machen?
Technisch gibt es drei Geometrien, und sie unterscheiden sich darin, wo die Übersetzung liegt. Erstens im Shopsystem selbst: die Plattform verwaltet Sprachvarianten nativ und legt Sprach-Subfolder an, ohne den Katalog zu duplizieren. Zweitens in einer Übersetzungs-Schicht, die zwischen Plattform und Nutzer:in geschaltet wird und Inhalte zur Laufzeit übersetzt. Drittens in der Quelle: Produktdaten werden im PIM übersetzt und dem Shop wie nativ gepflegte Inhalte übergeben. Alle drei führen zu einem mehrsprachigen Shop – aber zu unterschiedlichen Betriebskosten, unterschiedlicher SEO-Tiefe und unterschiedlicher Abhängigkeit von einem Anbieter.
Die drei Wege im Detail
Meine Erfahrung mit mehrsprachigen BigCommerce-Shops stammt aus Multi-Storefront-Implementierungen und aus Weglot, nicht aus dem neuen nativen Feature. Die Unterscheidung ist wichtig: Wie viele Storefronts ein Markt braucht, ist eine andere Entscheidung als die, wo Übersetzungen gepflegt werden. Vier Kriterien entscheiden bei jedem der drei Wege – SEO-Tiefe, Datensouveränität, Pflege und Skalierung, Kostenmodell.
Nativ in der Plattform. Die Plattform verwaltet Sprachvarianten selbst und legt sprachspezifische URL-Subfolder an, ohne den Katalog zu duplizieren. BigCommerce pflegt seinen nativen Mehrsprachen-Support über einen Translations Manager oder die GraphQL-API und deckt laut Dokumentation Produkte, Checkout, Zahlungen, Versand und Post-Purchase-Kommunikation ab. Shopware und Shopify lösen dieselbe Aufgabe anders, jeweils laut eigener Dokumentation: In Shopware sind Sprachen eigene Entitäten, die Verkaufskanälen zugeordnet werden, und jeder Verkaufskanal kann eine eigene Domain oder ein eigenes Unterverzeichnis erhalten. Shopify bildet Sprachen über Markets ab, pflegt die Inhalte in Translate & Adapt und vergibt je Sprache eigene URLs. SEO-Tiefe: Alle drei erzeugen eigenständige, indexierbare Sprach-URLs; marktspezifische Inhalte und Metadaten brauchen weiterhin redaktionelle Prüfung. Datensouveränität: Die übersetzten Texte liegen in der Datenbank der Plattform. Für Produkttexte ist das selten eine Datenschutzfrage, personenbezogene Daten stecken dort in der Regel nicht. Es ist eine Frage der Abhängigkeit und der Nachvollziehbarkeit: Führendes System bleibt die Plattform, der Export läuft über deren Schnittstellen, und Versionierung und Prüfspur reichen so weit, wie die Plattform sie anbietet. Wo Hosting-Ort und Rechtsordnung selbst zum Kriterium werden, gehört das in die Plattformentscheidung. Pflege und Skalierung: Jede Plattform hat Obergrenzen – bei BigCommerce etwa fünf Locales je Storefront. Kostenmodell: Verfügbarkeit und Kosten im gewählten Tarif bestätigen lassen; Implementierung, Übersetzung und Lektorat separat budgetieren.
Übersetzungs-Layer, Beispiel Weglot. Eine Cloud-Schicht zwischen Plattform und Kundschaft, eingebunden über ein JavaScript-Snippet oder ein Plug-in. Neue Inhalte werden automatisch maschinell übersetzt und im Seitenaufbau ausgeliefert, manuelle Korrekturen sind nachträglich möglich. SEO-Tiefe: Hier entscheidet nicht das Produkt, sondern die Integrationsart. Weglot weist in der eigenen Dokumentation darauf hin, dass die clientseitige JavaScript-Integration nicht SEO-tauglich ist; die Subdomain- und die Unterverzeichnis-Variante übersetzen serverseitig, vergeben eigene URLs und setzen hreflang automatisch. Prüfen Sie also zuerst, welche Variante bei Ihnen läuft – daran hängt, ob die übersetzten Seiten im Zielmarkt überhaupt indexiert werden. Und es betrifft nicht nur Google: In der bislang umfangreichsten Messung dazu (Vercel und MERJ, Dezember 2024) führte keiner der großen KI-Crawler JavaScript aus. Was erst im Browser entsteht, existiert für sie nicht – und damit auch nicht in ihren Antworten. Datensouveränität: Die Übersetzungen werden beim Anbieter verwaltet; Export-Zugriff und Migrationsbedingungen für den gewählten Tarif prüfen. Pflege und Skalierung: Nicht nur neue Inhalte, auch Änderungen an bestehenden werden automatisch erfasst und neu übersetzt. Manuelle Korrekturen gehen dabei nicht verloren, sie bleiben in der Übersetzungsliste erhalten – ausgespielt wird aber die neue maschinelle Fassung. Geprüfte Metadaten müssen nach einer Quelländerung also erneut kontrolliert werden. Kostenmodell: gestaffeltes Abonnement nach Wortvolumen und Sprachanzahl, veröffentlicht auf Weglots Preisseite.
Übersetzung in der Quelle, Beispiel Pimcore mit Data Director und DeepL. Inhalte werden in der Quelle übersetzt und dort gespeichert. Der Blackbit Data Director verbindet Pimcore mit einem Anbieter wie DeepL und kann die Übersetzung automatisch auslösen, sobald sich Quellinhalte ändern; daneben stehen Workflows auf Abruf. Die Ergebnisse liegen als Sprachvarianten im PIM und werden an den Shop übergeben. Das Muster ist plattformunabhängig: Ob die Zielplattform Shopware, Shopify oder BigCommerce heißt, ändert nichts daran, dass die Sprachhoheit im PIM bleibt – in Shopware-Projekten arbeiten wir nach demselben Schema. SEO-Tiefe: Inhalte lassen sich je Markt redaktionell anpassen statt eins zu eins übersetzen. Datensouveränität: Die übersetzten Felder werden im PIM gepflegt; die Verarbeitung über DeepL ist davon getrennt zu betrachten – Verarbeitungsorte und Vertragsbedingungen des Anbieters prüfen. Pflege und Skalierung: Das Datenmodell muss mehrsprachfähig sein und die Trigger müssen vorab konfiguriert werden; danach läuft die Erkennung automatisch. Kostenmodell: PIM und Integration budgetieren, dazu die Übersetzungsnutzung. Der DeepL-Tarif Growth API kombiniert laut DeepL eine feste Grundgebühr, ein enthaltenes Zeichenkontingent und nutzungsabhängige Kosten für die Überschreitung.
Woran die Entscheidung wirklich hängt
Fünf Fragen leisten die meiste Arbeit, und keine davon ist eine Plattformfrage.
Wie viele Zielsprachen? Der native Weg und der Layer bewältigen eine Handvoll problemlos; je höher die Zahl steigt, desto wichtiger wird die automatische Erfassung. Dazu kommt: Plattformen haben Obergrenzen für Sprachen je Storefront – bei BigCommerce etwa fünf. Diese Grenze sollte man kennen, bevor man den Weg wählt, nicht danach.
Wie SEO-relevant sind die Zielmärkte? Prüfen Sie für kritische Märkte, wie editierbar Inhalte und Metadaten sind, wie die Sprach-URLs aufgebaut sind und wie der Freigabeprozess läuft – entscheiden Sie anhand der konkreten Umsetzung, nicht anhand der Kategorie. Weglot dokumentiert das Bearbeiten von Übersetzungen, Meta-Titeln und Descriptions; redaktionelle Kontrolle ist also kein Alleinstellungsmerkmal des PIM-Wegs.
Wie schnell ändern sich die Inhalte? Schnell drehende Inhalte passen zur automatischen Erfassung des Layers; ein stabiler Katalog profitiert stärker von redaktioneller Qualität in der Quelle.
Was verlangen Datensouveränität und Auditierbarkeit? B2B-Unternehmen und regulierte Branchen sollten diese Frage vor der Wahl des Wegs beantworten, nicht danach.
Wie viel redaktionelle Kapazität ist vorhanden? Der Quellweg setzt voraus, dass jemand die Übersetzungs-Trigger konfiguriert und die Ergebnisse prüft. Ohne diese Kapazität läuft die Automatisierung nicht von allein richtig.
Ein hybrides Setup kann Produkt- und Kategorieübersetzungen dem PIM zuordnen und redaktionelle Seiten einem Layer, mit klar definierten Zuständigkeits- und Aktualisierungsregeln je Content-Typ. Wo diese Aufteilung Teil einer breiteren Bewegung zu modularer Architektur ist, ordnet unser Beitrag zu Composable Commerce ein, wann sich dieser Schritt lohnt – ein hybrides Übersetzungs-Setup allein ist noch kein Composable Commerce.
Was in Projekten schiefgeht
Vier Risiken lohnen die Prüfung vor dem Launch.
Automatisierte Lokalisierung ohne menschliche Kontrolle. Maschinelle Übersetzung trifft den Wortschatz; kulturelle Nuancen, Tonfall und die technisch korrekte, im Kontext aber schiefe Formulierung trifft sie nicht zuverlässig. Jemand muss das Ergebnis lesen.
Sprach-URLs und hreflang zusammen planen. Google empfiehlt eigene URLs für Sprachversionen und Auszeichnungen, die auf die Alternativen verweisen; beides gehört vor den Launch geprüft und ist in Googles Dokumentation zu multiregionalen Websites beschrieben. Und verlassen Sie sich nicht darauf, dass Ihr System alles hergibt: Der hreflang-Wert x-default lässt sich in gängigen CMS nicht immer setzen – eine Lücke, die uns in der Praxis schon begegnet ist.
Ein neuer Markt ohne gepflegtes PIM. Die Storefront geht in der neuen Sprache live, die Produktdaten dahinter bekommen aber nicht dieselbe redaktionelle Aufmerksamkeit wie im Heimatmarkt. Die Listing-Qualität leidet.
Die Sichtbarkeit im Zielmarkt wird nicht gemessen. Am wenigsten in KI-generierten Antworten. Ohne Ausgangswert lässt sich nicht sagen, ob die Marke dort überhaupt vorkommt – geschweige denn, ob der gewählte Weg wirkt.
Mehrsprachigkeit im Onlineshop – die Kurzfassung
Einen Onlineshop mehrsprachig zu machen ist keine Übersetzungsaufgabe, sondern eine Architekturentscheidung mit drei Wegen. Erstens das native Sprach-Feature der Plattform: Sprachvarianten und Sprach-Subfolder entstehen im Shopsystem selbst, ohne den Katalog zu duplizieren – BigCommerce hat einen solchen nativen Mehrsprachen-Support im August 2026 allgemein verfügbar gemacht, Shopware und Shopify bieten vergleichbare Mechaniken. Zweitens ein Übersetzungs-Layer wie Weglot, der zwischen Plattform und Nutzer:in geschaltet wird: neue Sprachen sind in Stunden live, die Übersetzungen werden aber beim Anbieter verwaltet. Drittens die Übersetzung in der Quelle: Produktdaten werden im PIM übersetzt und wie nativ gepflegte Inhalte ausgeliefert – im Blackbit-Stack über den Blackbit Data Director mit DeepL-Anbindung. Welcher Weg passt, hängt an der Anzahl der Zielsprachen, der SEO-Relevanz der Zielmärkte, der Änderungsfrequenz der Inhalte und dem Anspruch an Datensouveränität; Hybrid-Setups sind dabei eine valide Option, wenn unterschiedliche Content-Typen unterschiedliche Workflows brauchen. Blackbit digital Commerce aus Göttingen begleitet mittelständische E-Commerce-Unternehmen im DACH-Raum bei dieser Entscheidung und setzt sie in Pimcore, Shopware, BigCommerce und Shopify um.
Vor der Sprachentscheidung, nicht danach
Wenn Sie Internationalisierung in den nächsten zwei Quartalen planen: Schildern Sie uns Ihr Setup – Datenmodell, SEO-Situation in den Zielmärkten, Redaktionskapazität – und wir ordnen die drei Wege für Ihren Fall ein. Ohne Plattform-Präferenz.
