Die schnellste und sicherste Lösung für die meisten Shops ist ein indexierbares Unterverzeichnis‑Setup mit einem etablierten Mehrsprach‑Plugin wie WPML, Polylang oder TranslatePress, ergänzt durch saubere hreflang‑Auszeichnung und übersetzte Slugs. Wer WooCommerce mehrsprachig aufsetzt, muss zusätzlich Checkout‑E‑Mails, Zahlungsmethoden und Währungslogik pro Sprache prüfen. Der nächste Schritt ist immer derselbe: ein Staging‑Test der kompletten Bestellstrecke, bevor die Sprache live geht.
Kurz gesagt:
- Für komplexe WooCommerce-Shops mit vielen Varianten und mehreren Währungen ist WPML die zuverlässigste Wahl, obwohl es höhere Serveranforderungen mit sich bringt.
- Bei überschaubaren Katalogen empfiehlt sich Polylang mit einem kostenpflichtigen Add-on, während TranslatePress vor allem für weniger technikaffine Teams geeignet ist.
- Das Unterverzeichnis‑Setup ist die sinnvollste Architektur, weil es Domain‑ausscheidungen vermeidet und direkt mit den drei gängigen Plugins umgesetzt werden kann.
- Jeder Sprachversion muss eine eigene, indexierbare URL samt hreflang- und Canonical-Tags zugewiesen werden, um Probleme bei Google zu vermeiden.
- Der technische Start erfolgt idealerweise in einer getrennten Staging-Umgebung, wobei Inhalte, Zahlungsmethoden und rechtliche Texte vor dem Livegang sorgfältig geprüft werden sollten.
Inhaltsverzeichnis
- Plugins & Architekturen für WooCommerce mehrsprachig: WPML, Polylang, TranslatePress
- Technische Checkliste: Was bei WooCommerce mehrsprachig übersetzt werden muss
- Mehrsprachiges SEO: URL, hreflang und Canonical richtig setzen
- Checkout, Zahlungsmethoden und Währungen pro Sprache absichern
- Übersetzungs‑Workflows: Manuell, Agentur oder KI‑gestützt
- Performance und Hosting für mehrsprachige WooCommerce‑Shops
- Agentur‑Praxis: Staging‑Tests und Launch‑Checkliste
- Kosten und Budget für WooCommerce mehrsprachig einplanen
- Angebot: WooCommerce mehrsprachig mit Werbeeinfach umsetzen
- Offizielle Dokumentation und weiterführende Tools
- Quellen
- FAQ
Plugins & Architekturen für WooCommerce mehrsprachig: WPML, Polylang, TranslatePress
Die Wahl des Plugins entscheidet über Monate an Mehraufwand, nicht nur über die Optik im Sprachumschalter. Bei komplexen Shops mit vielen Varianten, individuellen Attributen und internationalem Zahlungsverkehr ist WPML meist die robustere Wahl. Es bietet eine tiefe WooCommerce‑Integration mit Multicurrency‑Funktionen und lässt sich mit maschinellen Übersetzungsdiensten koppeln. Der Preis dafür: eine steilere Lernkurve und höhere Performance‑Anforderungen an den Server, gerade bei großen Produktkatalogen.
TranslatePress punktet an einer anderen Stelle. Der visuelle Frontend‑Editor zeigt die Seite genau so, wie sie später aussieht, während man übersetzt. Für Teams ohne tiefes technisches Wissen ist das oft die praktikablere Wahl, weil niemand zwischen Backend‑Tabellen und Frontend‑Vorschau hin und her springen muss.
Polylang bleibt die schlanke Variante für kleinere Kataloge. Das Datenmodell ist aufgeräumt, die Grundversion kostenlos. Für den produktiven Einsatz mit WooCommerce braucht es aber in der Regel ein kostenpflichtiges Add‑on, sobald Produktvarianten und Attribute mehrsprachig gepflegt werden sollen.
Welcher Plugin‑Typ passt wohin:
- Komplexe Shops mit vielen Varianten, B2B‑Preislogik oder mehreren Währungen: ein WPML‑artiges System mit vollständiger WooCommerce‑Integration
- Nicht‑technische Teams, die selbst übersetzen wollen: TranslatePress wegen der visuellen Bearbeitung
- Schlanke Setups mit wenigen Produkten und knappem Budget: Polylang als Einstieg, mit Blick auf das nötige Add‑on
Bei der Architektur gibt es drei gängige Muster: Unterverzeichnis (shop.de/en/), Subdomain (en.shop.de) oder separate Domain (shop.com). Für die meisten deutschen Onlinehändler ist das Unterverzeichnis die sinnvollste Lösung. Es bündelt die Domain‑Autorität an einer Stelle, erfordert kein zusätzliches DNS‑Setup und lässt sich mit den drei genannten Plugins direkt umsetzen. Subdomains ergeben nur Sinn, wenn unterschiedliche Server oder Teams pro Region betrieben werden sollen, was für einen einzelnen mehrsprachigen WooCommerce‑Shop selten der Fall ist.
Ein Punkt wird häufig übersehen: Mehrsprachigkeit und Mehrwährungsfähigkeit sind zwei getrennte Baustellen. Ein Shop kann perfekt übersetzt sein und trotzdem nur eine Währung anzeigen. Wer international verkaufen will, braucht zusätzlich einen Currency‑Switcher oder eine Zahlungsintegration, die automatisch in Landeswährung abrechnet, unabhängig von der gewählten Sprache.
Technische Checkliste: Was bei WooCommerce mehrsprachig übersetzt werden muss
Die eigentliche Arbeit beginnt nicht beim Plugin‑Kauf, sondern bei der vollständigen Inventur aller übersetzungspflichtigen Elemente. Wer hier eine Kategorie vergisst, merkt es meist erst, wenn ein Kunde aus Frankreich eine englische Bestellbestätigung erhält.
Was konkret übersetzt werden muss:
- Produkttitel, Kurzbeschreibungen und Langbeschreibungen
- Produktvarianten und Attribute (Größe, Farbe, Material) inklusive der Attributwerte selbst
- Taxonomien wie Kategorien und Tags, nicht nur die Produktseite
- Menüs, Widgets und alle statischen Theme‑Strings (Buttons, Formularlabels, Fehlermeldungen)
- Transaktions‑E‑Mails: Bestellbestätigung, Versandbenachrichtigung, Rechnungsmail
- Slugs der URLs, damit
/produkt/rote-taschein der englischen Version zu/en/product/red-bagwird statt zur unübersetzten Kopie - Metadaten und Open‑Graph‑Tags für jede Sprachversion, sonst zeigt eine geteilte Produktseite in Social Media weiterhin den deutschen Titel
- ALT‑Texte der Produktbilder, die sonst dauerhaft auf Deutsch verharren, selbst wenn der Rest der Seite übersetzt ist
Die Reihenfolge, in der ein Projekt abläuft, entscheidet über die Fehlerquote. Zuerst wird eine Staging‑Umgebung aufgesetzt, komplett getrennt vom Live‑Shop. Dort legt man die Zielsprachen im Plugin an, bevor auch nur ein Produkt übersetzt wird, weil sich Sprachstruktur und URL‑Schema später nur mit Aufwand ändern lassen. Erst danach folgt die eigentliche Übersetzung der Inhalte, gefolgt von der Konfiguration von Zahlungsmethoden und Versandoptionen pro Sprache oder Land. Diese Reihenfolge verhindert, dass halb übersetzte Produkte live gehen, während im Hintergrund noch am Zahlungs‑Setup gebastelt wird.
Profi-Tipp: Legen Sie schon vor der ersten Übersetzung ein Glossar mit festen Begriffen an, etwa Produktnamen oder Markenbegriffe, die niemals übersetzt werden dürfen. Das spart in größeren Katalogen Dutzende Korrekturrunden, weil Übersetzer und KI‑Tools sonst jedes Vorkommen eigenständig interpretieren.
Ein Detail, das gerne unterschätzt wird: Produkte, die nur in bestimmten Sprachen verfügbar sein sollen, etwa weil ein Artikel nur regional lieferbar ist, brauchen eine bewusste Entscheidung im Plugin. WPML erlaubt es, Produkte gezielt aus einzelnen Sprachversionen auszuschließen, statt eine leere oder unvollständige Übersetzung anzuzeigen. Ohne diese Einstellung landen Kunden auf Produktseiten, die zwar sprachlich passen, aber gar nicht bestellbar sind, was zu Support‑Anfragen und Kaufabbrüchen führt.
Mehrsprachiges SEO: URL, hreflang und Canonical richtig setzen
Jede Sprachversion braucht eine eigene, indexierbare URL. Das klingt banal, wird aber regelmäßig falsch gemacht, etwa wenn Inhalte per JavaScript nachgeladen oder per Cookie umgeschaltet werden, ohne dass Google je eine zweite URL zu sehen bekommt. Das Unterverzeichnis‑Muster (/de/, /en/, /fr/) ist hier die Standardempfehlung, weil es jeder gängige Mehrsprach‑Plugin von Haus aus unterstützt.
Fehlerhafte hreflang‑Sets und falsche Canonical‑Tags gehören zu den häufigsten Ursachen für Indexierungsprobleme bei internationalen Shops. Drei Regeln verhindern die meisten davon:
- Jede Sprachversion verweist wechselseitig per hreflang auf alle anderen Sprachversionen derselben Seite, nicht nur auf eine
- Ein
x-default-Tag definiert, welche Version gezeigt wird, wenn keine der hinterlegten Sprachen zur Browsersprache passt - Jede Seite trägt ein selbstreferenzielles Canonical auf sich selbst, niemals auf die deutsche Ausgangsversion, sonst signalisiert man Google, dass die übersetzte Seite nur eine Kopie ist
Slugs sollten tatsächlich übersetzt werden, nicht nur der sichtbare Inhalt der Seite. Eine englische Produktseite mit deutschem Slug wirkt auf Suchmaschinen inkonsistent und verschenkt Rankingpotenzial in der Zielsprache. Wer bestehende Slugs im Rahmen der Mehrsprachigkeit ändert, muss außerdem 301‑Weiterleitungen von alten URLs einplanen, sonst drohen tote Links aus bereits indexierten Suchergebnissen oder aus externen Backlinks.
Zur Sitemap‑Strategie gehört, dass jede Sprache entweder eine eigene Sitemap oder einen eigenen Sitemap-Abschnitt bekommt, damit Google die Struktur klar erkennt. Nach dem Launch gehört die Prüfung in der Google Search Console zum Pflichtprogramm: dort lässt sich pro URL nachvollziehen, ob eine Sprachversion tatsächlich indexiert wurde oder als Duplikat der Hauptsprache eingestuft ist. Bei welcher Sprache man mit der Priorisierung beginnt, lässt sich auch datenbasiert entscheiden. Die Statista‑Auswertung zur Sprachverbreitung im Internet zeigt, welche Sprachen die größte Reichweite versprechen, was bei begrenztem Budget eine sinnvolle erste Sortierung liefert.
Checkout, Zahlungsmethoden und Währungen pro Sprache absichern
Mehrsprachigkeit betrifft nicht nur Texte auf der Seite, sondern den gesamten Bezahlvorgang. Ein Shop kann in fünf Sprachen übersetzt sein und trotzdem an der Kasse scheitern, wenn Zahlungsmethode, Währung oder Steuerlogik nicht zur gewählten Sprache passen.
Zunächst die Grundunterscheidung: Mehrsprachig bedeutet übersetzte Inhalte. Mehrwährungsfähig bedeutet, dass der Preis in der jeweiligen Landeswährung angezeigt und auch tatsächlich abgerechnet wird. Beides läuft technisch getrennt, wird aber vom Kunden als eine einzige Erfahrung wahrgenommen. WPML etwa bietet dafür eine eigene Multicurrency‑Funktion, die Preise automatisch an die gewählte Sprache oder Region koppeln kann.
Diese Testfälle gehören vor jedem Sprach‑Launch auf die Liste:
- Warenkorb füllen und über den kompletten Checkout in jeder Zielsprache durchklicken
- Jede aktivierte Zahlungsmethode einmal pro Sprache tatsächlich auslösen, nicht nur visuell prüfen
- Bestellbestätigung und Rechnungsmail in der jeweiligen Sprache öffnen und auf korrekte Beträge, Währungssymbole und Steuersätze prüfen
- Versandkosten und Versandländer pro Sprachversion gegen die tatsächlich gültigen Regeln abgleichen
- Rechtliche Pflichttexte wie Datenschutzerklärung, AGB und Widerrufsrecht in jeder Sprache auf Vollständigkeit prüfen, nicht nur auf Vorhandensein einer Übersetzung
Steuer‑ und Versandregeln unterscheiden sich oft pro Land, nicht pro Sprache, was gerne verwechselt wird. Ein französischsprachiger Kunde in Belgien braucht andere Steuersätze als ein französischsprachiger Kunde in Frankreich, obwohl beide dieselbe Sprachversion sehen. Diese Logik muss in WooCommerce über Länder‑ und nicht über Sprach‑Einstellungen abgebildet werden. Die technische Einrichtung zeigt unser Leitfaden zu Steuern in WooCommerce für Deutschland.
Profi-Tipp: Prüfen Sie bei jeder neuen Sprache auch die rechtlichen Pflichttexte gesondert, nicht nur die Produktseiten. Eine übersetzte AGB ohne Anpassung an lokales Verbraucherrecht kann später teurer werden als die gesamte technische Umsetzung.
Übersetzungs‑Workflows: Manuell, Agentur oder KI‑gestützt
Die Wahl des Übersetzungswegs entscheidet über Tempo, Kosten und Qualität, meist in dieser Reihenfolge der Kompromisse. Inhouse‑Übersetzung durch eigene Mitarbeiter ist günstig, wenn die Sprachkenntnis ohnehin im Team vorhanden ist, skaliert aber schlecht bei großen Katalogen. Eine Agentur liefert konstante Qualität und übernimmt oft auch branchenspezifische Terminologie, kostet aber pro Wort deutlich mehr und braucht Vorlaufzeit.
KI‑gestützte Übersetzung mit anschließendem menschlichem Lektorat, dem sogenannten Post‑Editing, hat sich als praktikabler Mittelweg etabliert. WPML lässt sich beispielsweise direkt mit Diensten wie Microsoft Translator koppeln, wodurch Produktbeschreibungen automatisch vorübersetzt werden und ein Mensch nur noch gegenliest, statt komplett neu zu schreiben.
Worauf es bei der Wahl des Workflows ankommt:
- Ein zentrales Glossar mit Markennamen, Fachbegriffen und Produktbezeichnungen verhindert Inkonsistenzen, egal welcher Übersetzungsweg gewählt wird
- String‑Übersetzung (einzelne Textbausteine wie Buttons) unterscheidet sich technisch von Page‑Level‑Übersetzung (ganze Seiteninhalte); beides muss im Plugin getrennt geprüft werden
- KI‑Übersetzung eignet sich gut für große Produktkataloge mit ähnlichem Satzbau, aber schlecht für rechtlich sensible Texte wie AGB
- Jede Übersetzung, egal woher sie stammt, sollte einmal auf Staging im tatsächlichen Layout angesehen werden, bevor sie live geht, weil längere Übersetzungen Layouts sprengen können
Die Entscheidung zwischen diesen Wegen muss nicht endgültig sein. Viele Shops starten mit KI‑gestützter Vorübersetzung für den Produktkatalog und beauftragen eine Agentur gezielt für rechtliche Texte und die Startseite, wo Nuancen stärker zählen.
Performance und Hosting für mehrsprachige WooCommerce‑Shops
Mehrsprachigkeit vergrößert die Datenbank, oft deutlich stärker, als Shopbetreiber erwarten. Jede zusätzliche Sprache verdoppelt im Extremfall die Anzahl der Produktdatensätze, weil Plugins wie WPML für jede Übersetzung eigene Einträge in zusätzlichen Datenbanktabellen anlegen. Das wirkt sich direkt auf Ladezeiten und Backup‑Größe aus.
Was Hosting und Caching bei WooCommerce mehrsprachig leisten müssen:
- Eine aktuelle PHP‑Version und ein Objekt‑Cache (etwa Redis) fangen die zusätzliche Datenbanklast durch mehrsprachige Abfragen ab
- Caching‑Regeln müssen pro Sprachversion greifen, sonst liefert der Cache versehentlich die falsche Sprache an einen Nutzer aus
- Ein CDN mit sprachspezifischer Auslieferung beschleunigt vor allem Bilder und statische Assets in internationalen Zielmärkten
- Backups sollten vor jedem größeren Übersetzungs‑Batch erstellt werden, damit ein Rollback möglich ist, ohne bereits übersetzte Sprachen zu verlieren
- Performance‑Tests gehören in jede Sprachversion einzeln, nicht nur in die deutsche Hauptversion, weil zusätzliche Plugins die Ladezeit pro Sprachordner unterschiedlich beeinflussen können
Spezialisierte Hoster mit WooCommerce‑Erfahrung kennen diese Fallstricke meist schon und bieten entsprechend dimensionierte Serverpakete an. Wer hier zu knapp plant, merkt die Folgen erst beim zweiten oder dritten Sprach‑Rollout, wenn die Datenbank bereits deutlich gewachsen ist.
Agentur‑Praxis: Staging‑Tests und Launch‑Checkliste
In der Projektpraxis von Werbeeinfach zeigt sich immer wieder derselbe Musterfehler: Teams testen die Übersetzung, aber nicht die Bestellstrecke. Eine Produktseite kann perfekt übersetzt sein und der Checkout trotzdem in der falschen Sprache landen, etwa weil eine Zahlungsanbieter‑Integration eigene, nicht übersetzte Fehlermeldungen ausliefert.
Ein belastbares Testprotokoll läuft in dieser Reihenfolge ab:
- Eine vollständige Testbestellung pro Sprache durchführen, vom ersten Klick auf das Produkt bis zur Bestellbestätigung
- Jeden aktivierten Zahlungsanbieter in jeder Sprache einmal echt auslösen, inklusive Fehlerfällen wie einer abgelehnten Zahlung
- Die Steuer‑ und Versandmatrix pro Land gegen die tatsächlich angezeigten Beträge in jeder Sprachversion abgleichen
- Alle Transaktions‑E‑Mails öffnen und auf korrekte Sprache, Währung und Firmendaten prüfen
- Die hreflang‑ und Canonical‑Tags jeder neuen Seite in der Google Search Console kontrollieren, sobald sie live ist
Ein Punkt aus der Praxis, der oft für Diskussionen sorgt: automatische IP‑basierte Sprachumschaltung wirkt zunächst komfortabel, sperrt Nutzer aber faktisch in eine Sprache, die sie vielleicht gar nicht wollten. Ein Deutscher im Urlaub in Spanien würde plötzlich eine spanische Version sehen, ohne das gewählt zu haben. Ein sichtbarer, jederzeit erreichbarer Sprachumschalter respektiert die tatsächliche Wahl der Nutzer und bleibt deshalb die verlässlichere Lösung.
Profi-Tipp: Führen Sie den Sprach‑Rollout nie für alle Sprachen gleichzeitig durch. Ein Soft‑Launch mit einer einzigen neuen Sprache, begleitet von zwei Wochen Monitoring über Search Console und Server‑Logs, deckt Probleme auf, bevor sie sich über den gesamten Katalog vervielfachen.
Der Rollout selbst folgt am zuverlässigsten diesem Ablauf: Staging‑Umgebung aufsetzen, eine Sprache vollständig fertigstellen und testen, dann als Soft‑Launch veröffentlichen, zwei bis drei Wochen beobachten und erst danach die nächste Sprache angehen. Wer hier alles auf einmal live schaltet, verliert bei einem Fehler den Überblick, welche Änderung ihn ausgelöst hat.
Kosten und Budget für WooCommerce mehrsprachig einplanen
Die Lizenzkosten für ein Mehrsprach‑Plugin sind meist der kleinste Posten im Budget, auch wenn sie zuerst sichtbar sind. Deutlich schwerer wiegen die laufenden Kosten für Übersetzung und die einmaligen Agenturstunden für die technische Einrichtung.
Diese Posten gehören in eine realistische Budgetplanung:
- Jährliche Lizenzgebühren für das Mehrsprach‑Plugin und benötigte WooCommerce‑Erweiterungen, da die meisten Anbieter jährlich statt einmalig abrechnen
- KI‑gestützte Übersetzung ist pro Wort meist deutlich günstiger als menschliche Übersetzung, verursacht dafür Lektoratsaufwand, der separat kalkuliert werden muss
- Agenturstunden für Einrichtung, Konfiguration von Zahlungs‑ und Versandlogik sowie für die Staging‑Tests, oft der größte Einzelposten bei einem professionellen Launch
- Ein fester Budgetposten für SEO‑Nachbesserungen und 301‑Weiterleitungen nach dem Launch, weil sich hreflang‑ und Slug‑Probleme selten beim ersten Versuch vollständig lösen lassen
Wer diese vier Posten von Anfang an getrennt budgetiert, statt sie in einer pauschalen Projektsumme zu verstecken, erkennt frühzeitig, wo tatsächlich verhandelt werden kann, etwa bei der Wahl zwischen KI‑Vorübersetzung und vollständiger Agenturübersetzung.
Angebot: WooCommerce mehrsprachig mit Werbeeinfach umsetzen
Die technische Umsetzung eines mehrsprachigen WooCommerce‑Shops umfasst alles von der Plugin‑Auswahl bis zum Staging‑Test der kompletten Bestellstrecke, statt nur ein Plugin zu empfehlen und den Rest dem Zufall zu überlassen.
Mit Erfahrung in der WordPress‑ und WooCommerce‑Entwicklung sind typische Stolperstellen bei mehrsprachigen Projekten bekannt: falsch konfigurierte hreflang‑Tags, vergessene Checkout‑E‑Mails, Steuerlogik, die an der falschen Stelle greift. Genau diese Details entscheiden, ob ein zusätzlicher Sprach‑Rollout tatsächlich neue Umsätze bringt oder nur zusätzliche Supportanfragen erzeugt.
Das Leistungsspektrum umfasst die Architekturentscheidung, die Integration des passenden Plugins und die Betreuung nach dem Launch. Wer bereits einen WooCommerce‑Shop betreibt und eine zweite Sprache ergänzen will, bekommt eine technische Bestandsaufnahme, einen konkreten Umsetzungsplan und im Anschluss einen Wartungsvertrag, der auch mehrsprachige Updates und Sicherheitschecks abdeckt. Für Händler, die noch ganz am Anfang stehen, lohnt sich zusätzlich ein Blick auf die verschiedenen Shop‑Architekturen, bevor die Mehrsprachigkeit obendrauf geplant wird.
Der nächste Schritt ist unkompliziert: Ein kurzes Erstgespräch gibt eine Einschätzung, welche Plugin‑Architektur und welcher Zeitrahmen für das konkrete Projekt realistisch sind.
Offizielle Dokumentation und weiterführende Tools
Für die technische Vertiefung lohnt sich der direkte Blick in die Primärquellen, statt sich auf Zusammenfassungen Dritter zu verlassen.
- Die WPML‑Dokumentation zu WooCommerce Multilingual erklärt Multicurrency‑Einstellungen und Checkout‑Übersetzung im Detail
- Die Plugin‑Seite auf WordPress.org listet aktuelle Kompatibilitäten und Mindestanforderungen
- Die Google Search Console bleibt das wichtigste Werkzeug, um hreflang‑ und Indexierungsfehler nach dem Launch zu erkennen
- Übersetzungsdienste wie Microsoft Translator lassen sich für die maschinelle Vorübersetzung großer Produktkataloge direkt anbinden
Quellen
- WPML Multilingual & Multicurrency for WooCommerce – WPML Dokumentation
- WPML Multilingual & Multicurrency for WooCommerce auf WordPress.org
- Statista — Verbreitung der Sprachen im Internet
FAQ
Wie kann ich WordPress mehrsprachig machen?
WordPress selbst bietet keine native Mehrsprachigkeit, deshalb braucht es ein Plugin wie WPML, Polylang oder TranslatePress. Diese Plugins verwalten separate Inhalte pro Sprache und erzeugen automatisch die passenden URLs und hreflang‑Tags.
Wie stelle ich WooCommerce auf Deutsch ein?
WooCommerce erkennt die in WordPress unter „Einstellungen“ hinterlegte Sprache automatisch und übernimmt sie für Systemtexte wie Buttons und Checkout‑Labels. Für vollständig mehrsprachige Shops mit Deutsch als einer von mehreren Sprachen braucht es zusätzlich eines der genannten Mehrsprach‑Plugins.
Wie erstelle ich eine mehrsprachige Website?
Der technische Weg führt über ein Mehrsprach‑Plugin, eine klare URL‑Struktur pro Sprache, meist per Unterverzeichnis, sowie die vollständige Übersetzung aller Inhalte inklusive Menüs, Formulare und E‑Mails. Ein Agentur‑Setup wie bei Werbeeinfach ergänzt das um Staging‑Tests der kompletten Nutzerreise vor dem Launch.
Ist Polylang kostenlos?
Die Grundversion von Polylang ist kostenlos und deckt einfache mehrsprachige Websites gut ab. Für den produktiven Einsatz mit WooCommerce ist in der Regel ein kostenpflichtiges Add‑on nötig, um Produkte, Varianten und Attribute vollständig zu übersetzen.
Was kostet die Umsetzung eines mehrsprachigen WooCommerce‑Shops bei Werbeeinfach?
Die konkreten Kosten hängen vom Umfang des Katalogs und der Anzahl der Zielsprachen ab und werden individuell kalkuliert. Aktuelle Preise und Leistungsdetails erfahren Sie direkt über die WooCommerce‑Serviceseite von Werbeeinfach.
