Zum Inhalt springen

Mehrsprachiger WooCommerce-Shop: WPML oder Polylang? Ein praktischer Leitfaden

· · 22 Min. Lesezeit
Mehrsprachiger WooCommerce-Shop: WPML oder Polylang? Ein praktischer Leitfaden

Einen Umschalter „PL / EN / DE" hinzuzufügen reicht nicht, um einen Shop mehrsprachig zu machen. Sie müssen noch Produkte, Variationen, Kategorien, Filter, den Warenkorb, E-Mails, AGB und die von Plugins erzeugten Meldungen übersetzen.

Hinzu kommen Preise, Währungen, Steuern, Versand und Zahlungen. Die deutsche Version des Shops kann korrekt übersetzt sein und trotzdem nicht verkaufen, wenn sie Preise in Złoty, polnische Versandmethoden und marktfremde AGB anzeigt.

Meist läuft die Wahl auf zwei Lösungen hinaus: WPML und Polylang. Beide erlauben es, mehrere Sprachversionen von WooCommerce zu betreiben, unterscheiden sich aber im Umgang mit Übersetzungen, in der Automatisierung, bei Währungen und im Umfang fertiger Integrationen.

In diesem Leitfaden vergleichen wir sie, ohne einen einzigen Sieger für alle Shops zu benennen. Wir zeigen, wann WPML besser passt, wann Polylang und was Sie vorbereiten müssen, damit ein mehrsprachiges WooCommerce keine Probleme mit SEO, Produkten und Bestellungen verursacht.

Kurz gesagt: WPML oder Polylang?

Wählen Sie WPML häufiger, wenn der Shop groß ist und mehrere Währungen, Automatisierung und einen geordneten Übersetzungsprozess braucht. Polylang ist sinnvoll, wenn Sie ein einfacheres Arbeitsmodell und direkte Kontrolle über die Inhaltsversionen bevorzugen. Das heißt nicht, dass WPML für einen großen Shop immer besser ist, Polylang immer günstiger oder dass eines der Plugins jede Integration ohne Tests bewältigt — die Entscheidung muss auf Ihrer konkreten WooCommerce-Konfiguration beruhen.

Kurz gefasst (TL;DR)

  • WPML bewährt sich häufiger in größeren Shops, die ein zentrales Übersetzungspanel, Automatisierung, mehrere Währungen und umfangreiche Integrationen benötigen.
  • Polylang bietet eine direktere Art, Sprachversionen zu verwalten, und kann eine gute Wahl für einen einfacheren Übersetzungsprozess sein.
  • Das kostenlose Polylang bietet keine vollständige WooCommerce-Unterstützung. Das Add-on Polylang for WooCommerce wird benötigt.
  • Polylang Pro unterstützt die automatische Übersetzung über DeepL, übersetzt aber nicht den ganzen Shop mit einem Klick.
  • WPML hat ein eigenes Multicurrency-Modul. Bei Polylang müssen Sie eine separate Multicurrency-Lösung wählen.
  • Beide Plugins können SEO-technisch einwandfrei funktionieren. Das Ergebnis hängt von URLs, hreflang, Canonicals, Übersetzungsqualität und Verlinkung ab.
  • Prüfen Sie vor der Wahl die Kompatibilität mit Zahlungen, Versand, Rechnungen, ERP, Produktfeed und Theme.
  • Testen Sie zuerst eine Sprache und eine kleine Produktgruppe. Erst danach erweitern Sie die Umsetzung.

Was bedeutet ein mehrsprachiger WooCommerce-Shop wirklich?

Mehrsprachiges WooCommerce sind mehrere verbundene Versionen der Produkte und des gesamten Kaufwegs — nicht nur eine übersetzte Beschreibung.

Der Kunde sollte in der gewählten Sprache eine Kategorie öffnen, Filter nutzen, ein Produkt öffnen, eine Variation wählen, das Produkt in den Warenkorb legen, den Versand auswählen, zur Zahlung übergehen, eine Bestellbestätigung erhalten, die Rückgaberegeln lesen und den Support kontaktieren können. Wenn die Produktseite auf Deutsch ist, die Fehlermeldung an der Kasse aber auf Polnisch erscheint, ist die Umsetzung noch nicht abgeschlossen.

Zu übersetzen sein können: Produktnamen und -beschreibungen, Kurzbeschreibungen, Kategorien und Unterkategorien, Tags, Attribute, Variationsnamen, das Menü, Schaltflächen, WooCommerce-Meldungen, Warenkorb und Checkout, transaktionale E-Mails, Versandmethoden, Zahlungsnamen, Formulare, AGB, Datenschutzerklärungen, Banner, die Fußzeile, Meta-Title und Meta-Description sowie URLs. Außerdem müssen Sie entscheiden, welche Daten gemeinsam bleiben und welche sich zwischen Märkten unterscheiden dürfen:

DatenMeist gemeinsamKönnen sich zwischen Märkten unterscheiden
LagerbestandJaSelten
SKUJaSelten
BilderJaJa
Name und BeschreibungNeinJa
BasispreisOftJa
WährungNeinJa
SteuerNicht immerJa
VersandNeinJa
ProduktverfügbarkeitOftJa
AGBNeinJa
SEO-MetadatenNeinJa

Sprache, Land und Währung sind drei verschiedene Dinge

Eine Sprachversion muss nicht einem Land entsprechen, und die Währung sollte nicht allein anhand der Sprache gewählt werden.

Erst die Marktmatrix, dann das Plugin

Eine englische Version kann sich an Großbritannien, Irland, die USA oder internationale Kunden in der EU richten — und in jedem Fall können andere Preise, Währungen, Steuern, Versandarten, Zahlungen, Lieferzeiten und rechtliche Hinweise gelten. Bereiten Sie vor der Installation eines Plugins eine einfache Marktmatrix vor (Markt → Sprache → Währung → Lager → Versand → Zahlungen). Eine solche Tabelle zeigt oft, dass das Projekt nicht nur eine Übersetzung der Seite ist — es ist eine Verkaufseinführung in einen neuen Markt.

MarktSpracheWährungLagerVersandZahlungen
PolenPolnischPLNPLPaketautomaten, KurierBLIK, Karte, Überweisung
DeutschlandDeutschEURPL oder DEinternationaler KurierKarte, PayPal
GroßbritannienEnglischGBPPL oder UKinternationaler KurierKarte, PayPal
TschechienTschechischCZK oder EURPLAbholpunkte, Kurierlokale Methoden

WPML oder Polylang — ein schneller Vergleich

Die Entscheidung muss auf Ihrer konkreten WooCommerce-Konfiguration beruhen, nicht allein auf der Anzahl der Funktionen.

KriteriumWPMLPolylang
WooCommerce-UnterstützungWPML + WooCommerce Multilingual & MulticurrencyPolylang oder Pro + Polylang for WooCommerce
Produkte und VariationenJaJa
Kategorien und AttributeJaJa
Warenkorb und CheckoutJaJa
WooCommerce-E-MailsJaJa
Automatische ÜbersetzungZentrales System und CreditsDeepL in Polylang Pro
Übersetzung der gesamten WebsiteUmfangreicher WorkflowKeine einzelne Schaltfläche für die ganze Seite
Mehrere WährungenIntegrierte Unterstützung in WCMLSeparate Lösung
Slug-ÜbersetzungJaPolylang Pro
hreflangJaJa
ÜbersetzerteamUmfangreicher WorkflowEinfacheres Modell, Pro-Funktionen
VerwaltungsmodellZentrales ÜbersetzungspanelVerknüpfte WordPress-Inhalte
Typische WahlGroßer und komplexer ShopEinfacherer Shop und direkte Bearbeitung

Multicurrency bedeutet die Unterstützung mehrerer Währungen in einem Shop (z. B. PLN, EUR, GBP) samt ihren Preisen, Wechselkursen, Zahlungen und Rückerstattungen.

Was kosten WPML und Polylang?

Kosten sollten nicht allein anhand einer einzigen Lizenz verglichen werden, weil WooCommerce unterschiedliche Komponenten-Sets erfordern kann.

Laut den im Juni 2026 verfügbaren Preislisten: WPML Multilingual CMS kostet 99 Euro pro Jahr; Polylang Pro ab 99 Euro pro Jahr für eine Website; Polylang for WooCommerce ab 99 Euro pro Jahr für eine Website; es gibt auch ein Bundle, das Polylang Pro mit dem WooCommerce-Add-on kombiniert. Preise und Aktionen können sich ändern — prüfen Sie vor dem Kauf die aktuelle Preisliste des Anbieters.

WPML-Kosten. Für einen großen Shop wählt man meist WPML Multilingual CMS — das Paket umfasst das Haupt-Plugin, ein Übersetzungsmanagement-Panel, die Übersetzung von Theme- und Plugin-Texten, die WooCommerce-Integration, automatische Übersetzungen, Updates und Support. Automatische Übersetzungen funktionieren im Credit-System: Die Lizenz enthält ein bestimmtes Kontingent, aber ein großer Katalog kann zusätzliche Gebühren erfordern.

Polylang-Kosten. Polylang for WooCommerce kann mit dem kostenlosen Polylang oder mit Polylang Pro arbeiten. Das WooCommerce-Add-on selbst deckt die wichtigsten Shop-Elemente ab; Polylang Pro wird benötigt, wenn es Ihnen u. a. auf die Slug-Übersetzung, die DeepL-Integration, den XLIFF-Export und -Import, das erweiterte Kopieren von Inhalten, Sprachberechtigungen und einen umfangreichen Redaktionsprozess ankommt. XLIFF ist ein Format zum Austausch von Inhalten zwischen WordPress und den Werkzeugen professioneller Übersetzer.

Welche Lösung ist günstiger? Das lässt sich ohne Kenntnis des Umfangs nicht beantworten. Polylang mit kostenlosem Kern und WooCommerce-Add-on kann niedrigere Einstiegskosten haben; wenn Sie aber auch Polylang Pro, DeepL und ein separates Währungs-Plugin benötigen, können die Kosten an WPML heranreichen oder es übersteigen. Lizenzen sind nur ein Teil des Budgets — mehr können Übersetzungen, SEO-Konfiguration, Integrationstests, Theme-Anpassungen, Feed-Vorbereitung, Datenmigration und die spätere Wartung kosten.

Wie funktioniert WPML in einem WooCommerce-Shop?

WPML erstellt ein zentrales System zur Verwaltung der Sprachversionen und verbindet es über das Modul WooCommerce Multilingual & Multicurrency mit WooCommerce.

Ein Produkt in der Hauptsprache kann die Inhaltsquelle sein, und seine Übersetzungen sind verknüpfte Versionen. WPML synchronisiert die Daten, die Sie üblicherweise nicht trennen möchten (SKU, Lagerbestand, einen Teil der Produkteinstellungen, Variationen, Bilder, Versandklassen), während Namen, Beschreibungen, URLs und Metadaten für jede Sprache getrennt bleiben.

Zentrales Übersetzungspanel. Inhalte können zur automatischen Übersetzung, an Benutzer in der Rolle von Übersetzern, an externe Dienste oder zur manuellen Bearbeitung übergeben werden. Bei einem großen Katalog können Sie steuern, was übersetzt wurde, was auf Bearbeitung wartet, welche Quelle geändert wurde und welche Übersetzungen aktualisiert werden müssen.

Automatische Übersetzung in WPML. Sie erlaubt es, die Übersetzung größerer Inhaltsmengen zu automatisieren, und nutzt ein Übersetzungsspeicher (Wiederverwendung zuvor übersetzter Fragmente). Veröffentlichen Sie das automatische Ergebnis nicht ohne Kontrolle — prüfen Sie besonders Kategorienamen, Fachbegriffe, Einheiten, Variationsnamen, Verkaufsbotschaften, Versandinformationen, Rechtstexte und SEO-Phrasen.

Mehrere Währungen in WPML. WooCommerce Multilingual & Multicurrency erlaubt es, mehrere Währungen hinzuzufügen, automatische oder manuelle Wechselkurse einzustellen, separate Preise pro Währung einzugeben, einer Sprache eine Standardwährung zuzuweisen, Zahlungen nach Währung/Standort einzuschränken und einen Währungsumschalter hinzuzufügen. Jede Konfiguration muss mit echten Zahlungsanbietern getestet werden — nicht jedes Gateway unterstützt alle Währungen, wiederkehrende Zahlungen, Teilrückerstattungen, eine Abrechnung ohne Umrechnung oder Rückerstattungen in der Originalwährung der Transaktion.

Wie funktioniert Polylang in einem WooCommerce-Shop?

Polylang beruht auf separaten, verknüpften Produktversionen und nutzt die Standard-Bearbeitungsoberfläche von WordPress.

Für die vollständige Shop-Unterstützung benötigen Sie Polylang for WooCommerce. Jedem Produkt wird eine Sprache zugewiesen, und es wird mit seinen Gegenstücken verknüpft. Dieses Modell ist übersichtlich für jemanden, der das WordPress-Panel kennt, jede Version manuell kontrollieren möchte, keine umfangreiche Übersetzungs-Warteschlange braucht und mit einem kleinen Team arbeitet.

Produktsynchronisation. Polylang for WooCommerce kann zwischen den Übersetzungen u. a. Bestände, Preise, Kategorien, Tags, Attribute, Versandklassen sowie Bilder und Galerien synchronisieren. Vor dem Start müssen Sie entscheiden, welche Daten gemeinsam bleiben sollen. Beispiel: Ein Produktbild kann für alle Versionen gemeinsam sein, aber wenn es polnischen Text enthält, wird für die deutsche Version eine eigene Grafik benötigt.

Übersetzung über DeepL. DeepL ist ein externer Dienst für automatische Übersetzungen. Polylang Pro ermöglicht die Nutzung von DeepL für ausgewählte Inhalte — der Prozess besteht nicht darin, den ganzen Shop mit einem Klick zu übersetzen. Die Integration erfordert einen eigenen DeepL-API-Schlüssel, funktioniert für Seiten/Produkte/Inhaltstypen, erlaubt die Nutzung eines Glossars in Polylang Pro 3.8, wird für ausgewählte Elemente gestartet und verarbeitet nicht direkt Inhalte, die von Elementor, Divi und einigen anderen Buildern gespeichert wurden. Page Builder speichern Inhalte oft in einer anderen Struktur als der Standard-Editor, was die automatische Übersetzung erschwert. Ein Glossar ist eine Liste freigegebener Namen, Marken und Begriffe — es hilft, dieselben Übersetzungen im gesamten Katalog beizubehalten.

Währungen in Polylang. Polylang for WooCommerce ist für die Sprachen zuständig, bietet aber kein vollständiges eigenes Multicurrency-System. Wenn Sie mehrere Währungen benötigen, müssen Sie eine separate Lösung wählen und ihre Kompatibilität mit Polylang, dem Zahlungsanbieter, Steuern, Gutscheinen, Rückerstattungen, Rechnungen, dem Produktfeed und dem ERP prüfen.

Wann sollten Sie WPML wählen?

WPML ist in der Regel die sinnvollere Wahl, wenn die Mehrsprachigkeit einen großen Katalog, mehrere Währungen, ein Übersetzerteam und umfangreiche Integrationen umfasst.

Ziehen Sie WPML in Betracht, wenn der Shop Hunderte oder Tausende Produkte hat, Sie mehrere Sprachen planen, Sie ein zentrales Übersetzungspanel benötigen, viele Inhalte automatisch übersetzt werden, mehrere Personen an den Übersetzungen arbeiten, Sie mehrere Währungen brauchen, Zahlungen von Währung/Markt abhängen sollen, Produktaktualisierungen häufig sind, Sie den Arbeitsstatus verfolgen möchten oder Sie viele WooCommerce-Erweiterungen nutzen. Beispiel: ein Möbelshop mit 8.000 Produkten, Farbvariationen, PL/DE/CZ-Versionen, den Währungen PLN/EUR/CZK, Produktimport, Google Merchant Center, Lagerintegration und mehreren Übersetzern — hier ist ein geordneter Aktualisierungsprozess wichtiger als ein Unterschied von einigen Dutzend Euro im Lizenzpreis.

Wann sollten Sie Polylang wählen?

Polylang kann die bessere Wahl sein, wenn der Shop eine einfachere Struktur hat und das Team separate Produktversionen direkt bearbeiten möchte.

Ziehen Sie Polylang in Betracht, wenn der Katalog relativ klein ist, Sie eine oder zwei Sprachen hinzufügen, Übersetzungen manuell erstellt werden, Ihnen das Standard-WordPress-Panel wichtig ist, Sie kein integriertes Multicurrency-System benötigen, das technische Team WordPress kennt, die genutzten Erweiterungen mit Polylang geprüft wurden oder Sie kein zentrales System für viele Übersetzer benötigen. Beispiel: ein Herstellershop mit 120 Produkten, einer polnischen und deutschen Version, einer Währung, gemeinsamem Lager, manuell erstellten Übersetzungen und einer geringen Anzahl an Plugins — Polylang kann alles bieten, was der Shop wirklich braucht.

Ist Polylang schneller als WPML?

Ohne einen Test des konkreten Shops lässt sich kein universeller Performance-Sieger seriös benennen.

Polylang nutzt ein einfacheres Modell der Inhaltsverwaltung; WPML hat ein umfangreicheres Übersetzungssystem und eigene Mechanismen zur Speicherung der Verknüpfungen. Das bedeutet nicht, dass jeder WPML-Shop langsam und jeder Polylang-Shop schnell ist. Das Ergebnis hängt auch von der Anzahl der Produkte, der Anzahl der Sprachen, von Variationen, Filtern, dem Theme, dem Builder, dem Hosting, der Datenbank, dem Cache, den Integrationen, den Importen und den Abfragen an externe Systeme ab — in einem Shop mit 10.000 Produkten kann ein schlecht funktionierender Filter größere Probleme verursachen als das Sprach-Plugin. Vergleichen Sie vor und nach der Umsetzung die Server-Antwortzeit, die Kategorieseite, die Produktseite, die Filter, die Variationsauswahl, den Warenkorb, den Checkout, das Admin-Panel, den Produktimport und die Cron-Jobs. Cron ist der Mechanismus, der geplante Aufgaben ausführt (Produktimport, Kursaktualisierung, Versand von Nachrichten). Wenn der Shop nach dem Hinzufügen von Sprachen langsamer wird, prüfen Sie auch das WooCommerce-Hosting sowie die Datenbank und die Plugins.

Wie plant man die URLs der Sprachversionen?

Für die meisten Shops, die auf einer Domain entwickelt werden, sind Sprach-Unterverzeichnisse am einfachsten.

Beispiel: shop.de/ (Polnisch), shop.de/en/ (Englisch), shop.de/de/ (Deutsch), shop.de/cs/ (Tschechisch). Möglich sind auch Subdomains (z. B. de.shop.de), separate Domains (z. B. shop.de) und verschiedene regionale Domains.

Unterverzeichnisse sind in der Regel einfacher in Wartung, Analytics, Verlinkung, WordPress-Aktualisierung und beim Aufbau der Autorität einer einzigen Domain. Separate Domains können sinnvoll sein, wenn jeder Markt eine eigene Marke, ein separates Lager, ein anderes Angebot, lokalen Support, ein eigenes SEO-Budget und deutlich andere Verkaufsregeln hat — in der Praxis bedeutet das jedoch, mehrere Projekte statt eines zu führen.

Sollte man Slugs übersetzen? Ein Slug ist der letzte Teil der Adresse (z. B. buerostuhl in shop.de/moebel/buerostuhl/). Wenn Ihnen lesbare Adressen wichtig sind, lohnt es sich, auch Slugs zu übersetzen — statt shop.de/de/krzesla/krzeslo-drewniane/ besser shop.de/de/stuehle/holzstuhl/. In Polylang erfordert die Slug-Übersetzung die Pro-Version; WPML behandelt sie in seinem Übersetzungssystem.

Eine Änderung der URL-Struktur ist eine Migration. Wenn die aktuellen Versionen bereits in Google sichtbar sind, erfordert die Änderung von de.shop.de/produkt/ in shop.de/de/produkt/ u. a. eine Adresskarte, 301-Weiterleitungen, die Aktualisierung von hreflang und Canonicals, Sitemap-Änderungen, die Korrektur interner Links, Änderungen in Feeds und Anzeigen sowie die Überwachung von 404-Fehlern. Das vollständige Vorgehen beschreiben wir im Leitfaden Shop-Migration ohne Rankingverlust.

Hreflang — wie verbindet man die Sprachversionen?

Hreflang teilt Google mit, welche Adressen Gegenstücke desselben Inhalts sind, die für verschiedene Sprachen oder Regionen vorbereitet wurden.

Ein Beispiel-Set kann auf pl (Polnisch), de (Deutsch), en (allgemeine englische Version) und en-gb (Englisch für Großbritannien) verweisen. WPML und Polylang können die Auszeichnungen automatisch erzeugen — Sie müssen ihre Richtigkeit dennoch prüfen.

Die häufigsten hreflang-Fehler: die PL-Version verweist auf DE, aber DE verweist nicht auf PL; die Adresse führt über eine Weiterleitung; der Verweis führt zu einem 404-Fehler; verschiedene Produkte wurden verbunden; ein falscher Sprach-/Ländercode wurde verwendet; der Selbstverweis fehlt; die Adressen sind keine vollständigen HTTPS-Adressen; ein nicht übersetztes Produkt verweist auf eine zufällige Seite; der Canonical führt zu einer anderen Sprachversion.

Ist x-default verpflichtend? Nein. Sie können es für eine neutrale Sprachauswahlseite oder eine Standardversion für Personen nutzen, für die keine genaue Variante vorbereitet wurde. Das Fehlen von x-default ist nicht automatisch ein Fehler.

Canonical: jede Sprachversion verweist auf sich selbst

Jede gültige, indexierbare Version sollte ihren Canonical in der Regel auf sich selbst verweisen lassen: PL-Produkt → Canonical PL, DE-Produkt → Canonical DE, EN-Produkt → Canonical EN. Setzen Sie den Canonical nicht aller Übersetzungen auf die polnische Version — Google könnte die ausländischen Adressen dann als Duplikate behandeln, die nicht indexiert werden sollten, und die gesamte Sprachversion fällt aus den Ergebnissen. Hreflang prüfen Sie in Screaming Frog, Sitebulb, einem anderen Crawler, im Quellcode oder durch die URL-Inspektion in der Search Console (der separate Bericht „Internationale Ausrichtung" existiert nicht mehr).

Sind WPML und Polylang gleich gut für SEO?

Beide Lösungen können eine korrekte technische Struktur erstellen, aber kein Plugin ersetzt eine SEO-Strategie für einen konkreten Markt.

Beide Systeme können separate Adressen, hreflang, SEO-Titel, Meta-Descriptions, übersetzte Inhalte, Kategorien, Sitemaps und die Verlinkung zwischen Versionen abbilden. Die Ergebnisse werden vor allem von der Übersetzungsqualität, der Wahl lokaler Phrasen, der Kategoriearchitektur, der Indexierung, der Verlinkung, dem Angebot, lokalen Vertrauenssignalen und dem Wettbewerb bestimmt.

Übersetzen Sie Phrasen nicht Wort für Wort. Eine polnische Phrase hat nicht immer ein direktes Gegenstück mit ähnlicher Popularität — in Polen suchen Kunden vielleicht nach „szafka RTV", während in Deutschland je nach Möbeltyp und -stil andere Begriffe verbreitet sind. Führen Sie vor der Übersetzung einer Kategorie eine separate Keyword-Recherche für jeden Markt durch.

Bereiten Sie separate Metadaten vor. Jede Version sollte ihren eigenen Meta-Title, ihre Meta-Description, H1, Kategoriebeschreibung und interne Verlinkung haben — das automatische Ersetzen einzelner Wörter reicht nicht.

Prüfen Sie die Sitemap. Sie sollte indexierbare Produkte, wichtige Kategorien, korrekte kanonische Adressen und aktive Sprachversionen enthalten; sie sollte keine leeren Übersetzungen, noindex-Adressen, Weiterleitungen, inaktive Produkte oder technische Parameter enthalten.

Wie übersetzt man Produkte und Variationen?

Übersetzen Sie zuerst Kategorien und Attribute, und erst danach variable Produkte.

Ein Beispielprodukt „Baumwoll-T-Shirt — schwarz — Größe M" besteht aus dem Produkt, dem Attribut „Farbe", dem Wert „schwarz", dem Attribut „Größe", dem Wert „M", der Variation, dem Preis, dem Bestand und dem Bild. Wenn Sie nur das Produkt übersetzen, kann der Filter weiterhin polnische Attributnamen anzeigen. Empfohlene Reihenfolge: (1) Sprachen hinzufügen, (2) Kategorien übersetzen, (3) globale Attribute, (4) Attributwerte, (5) Slugs prüfen, (6) Produkt übersetzen, (7) Variationen verifizieren, (8) Bestand und SKU prüfen, (9) Filter testen, (10) Produkt in den Warenkorb legen.

Erstellen Sie keine unabhängigen Produktkopien. Fügen Sie ein deutsches Produkt nicht als völlig separaten Eintrag hinzu, wenn es einen gemeinsamen Bestand nutzen soll — das kann doppelte Bestände, unterschiedliche SKUs, Variationsfehler, Feed-Duplikate, den doppelten Verkauf des letzten Stücks und ein fehlendes korrektes hreflang verursachen. Die Versionen sollten durch den Mechanismus des Plugins verknüpft sein.

Was ist mit Preisen, Währungen und Zahlungen?

Die Sprache lässt sich unabhängig von der Währung ändern, deshalb erfordert die Preiskonfiguration eine separate geschäftliche Entscheidung.

Mögliche Modelle: eine Sprache und mehrere Währungen (eine englische Version mit Auswahl EUR/GBP/USD); eine einer Sprache zugeordnete Währung (Polnisch → PLN, Deutsch → EUR, Englisch → GBP); ein manuell für den Markt festgelegter Preis (129 Euro in Deutschland, 119 Pfund in UK, 499 Złoty in Polen). Ein ausländischer Preis muss nicht das einfache Ergebnis des Wechselkurses sein — er kann Versandkosten, Retourenabwicklung, Gebühren, lokalen Wettbewerb, Marge und die Kosten der Marktbetreuung berücksichtigen. Testen Sie den Währungswechsel, die Variationspreise, Aktionen, Gutscheine, Steuern, Rundungen, die Zahlung, vollständige und teilweise Rückerstattung, die Rechnung, den Bestellexport und den Umsatzbericht.

Was ist mit Steuern, Versand und AGB?

Die Übersetzung des Shops passt die Verkaufsregeln nicht automatisch an das neue Land an.

Prüfen Sie, ob Sie B2C/B2B/beides verkaufen, von wo Sie versenden, in welche Länder Sie liefern, welche Steuersätze gelten, ob Sie VAT OSS nutzen, wie Sie Retouren abwickeln, wer die Rücksendung bezahlt, welche Informationen auf dem Produkt stehen müssen und welche Zahlungen lokal verbreitet sind. VAT OSS ist ein EU-Verfahren, das es erlaubt, die Umsatzsteuer auf einen Teil der B2C-Verkäufe in andere EU-Länder über ein einziges Portal abzurechnen, statt sich in jedem Verbrauchsland separat zu registrieren. Veröffentlichen Sie keine automatisch übersetzten AGB ohne Prüfung — Recht, Steuern und Verbraucherpflichten klären Sie mit jemandem, der den jeweiligen Markt kennt.

Automatische oder manuelle Übersetzung?

Die Automatik liefert einen guten Entwurf, sollte aber nicht eigenständig über Verkaufssprache, SEO und Rechtsdokumente entscheiden.

Automatisch lassen sich vorab lange Beschreibungen, einfache technische Informationen, unterstützende Inhalte, Blogbeiträge und sich wiederholende Parameter übersetzen. Manuell prüfen Sie Kategorienamen, Produktnamen, Überschriften, Schaltflächen, Metadaten, die wichtigsten Vorteile, Anzeigen, AGB, Lieferbedingungen, Formularfehler und den Checkout. Bereiten Sie ein Glossar vor, das hilft, dieselben Namen im gesamten Katalog beizubehalten:

Polnischer BegriffDeutsche EntsprechungAnmerkungen
Szafka RTVTV-LowboardNicht wörtlich übersetzen
Dąb artisanArtisan-EicheDekorname
Cichy domykSoft-CloseFachbegriff
PaczkomatPaketautomatAn den Versand anpassen
MeblościankaWohnwandLokaler Begriff

Sollte man den ganzen Katalog auf einmal übersetzen?

Sicherer ist es, mit einer begrenzten Produktgruppe zu beginnen und die Umsetzung erst nach Tests zu erweitern.

In einem Shop mit 10.000 Produkten wählen Sie zu Beginn eine Kategorie, einige Dutzend Produkte, ein einfaches Produkt, ein variables, ein Aktionsprodukt und ein Produkt mit benutzerdefinierten Feldern. Prüfen Sie die Übersetzungen, die Bestandssynchronisation, den Import, die Filter, den Feed, die Zahlungen, den Versand, die E-Mails und SEO. Ein bei 30 Produkten entdeckter Fehler ist leicht zu beheben — derselbe Fehler, repliziert auf 10.000 Einträge, kann eine separate Datenmigration erfordern.

Integrationen, ERP und Importe

Das externe System muss wissen, welche Daten gemeinsam sind und welche zu einer bestimmten Sprachversion gehören.

Ein ERP verwaltet u. a. Lager, Rechnungen, Preise und Bestellungen. Legen Sie in der Integration fest: ob das ERP mehrere Sprachen speichert, welches System die Quelle der Beschreibungen ist, ob die Bestände gemeinsam sind, woher die Preise bezogen werden, wie Übersetzungen identifiziert werden, ob Variationen eine gemeinsame SKU haben, in welcher Sprache die Bestellung eintrifft, wie die Währung gespeichert wird und in welcher Sprache die Rechnung ausgestellt wird.

Der Import kann Übersetzungen überschreiben — legen Sie die Quelle der Wahrheit fest

Ein typisches Szenario: Ein Übersetzer korrigiert die deutsche Beschreibung in WooCommerce, und nachts importiert das ERP die polnische Beschreibung in alle Versionen und löscht die deutsche Übersetzung. Das Problem ist dann nicht WPML oder Polylang — das Problem ist das Fehlen einer festgelegten Quelle der Wahrheit und von Importregeln. Prüfen Sie beim CSV-/XML-Import die Produktkennung, die Sprache, die Verknüpfung der Übersetzungen, die Variations-SKUs, die Kategorien, die Attribute, die Bilder, den Veröffentlichungsstatus und die Art der Datensatzaktualisierung. Führen Sie zuerst einen Test auf dem Staging durch.

Google Merchant Center und Produktfeeds

Jede Marktversion sollte konsistente Daten an Google übergeben: Sprache, Währung, Preis, Versand und die richtige Zielseite.

Ein Produktfeed ist eine Datei oder ein Datenstrom, der Google Informationen über das Angebot übergibt. Für den deutschen Markt sollten Titel, Beschreibung und Landingpage auf Deutsch sein, der Preis muss mit der Seite übereinstimmen, die Währung muss unterstützt werden, und der Versand sollte dem Land entsprechen — senden Sie keinen deutschen Titel an eine polnische Produktseite. Verifizieren Sie die Feed-Sprache, das Verkaufsland, die Währung, die Kennungen, die Verfügbarkeit, die Produktadresse, den Versand, die Rückgaberichtlinie und die Preiskonsistenz. Wenn Sie Produktanzeigen planen, bereiten Sie den Shop und die Google-Shopping-Kampagnen als einen Prozess vor.

Wie testet man den Kauf in jeder Sprache?

Der Test muss die gesamte Transaktion umfassen, weil ein Teil der Fehler erst im Checkout oder in der Nachricht nach der Bestellung auftritt.

Für jede Sprache: öffnen Sie eine Kategorie und nutzen Sie einen Filter → wählen Sie ein variables Produkt → in den Warenkorb legen → einen Gutschein anwenden → Versand wählen → Zahlungsmethode ändern → einen Formularfehler auslösen → eine Testbestellung aufgeben → die Danke-Seite prüfen → die Kunden-E-Mail prüfen → Status und Lagerbestand prüfen → eine Retoure durchführen. Achten Sie vor allem auf Sprachmischung: eine polnische Schaltfläche in der deutschen Version, eine englische Fehlermeldung, einen nicht übersetzten Versand, einen polnischen E-Mail-Betreff, ein Zahlungsgateway in einer anderen Sprache, einen nicht übersetzten Status.

Wie setzt man mehrsprachiges WooCommerce Schritt für Schritt um?

Führen Sie die Umsetzung von der Marktauswahl und der Auflistung der Integrationen über das Staging und eine Testsprache bis zum stufenweisen Start.

Schritt 1. Märkte wählen — Länder, Sprachen, Währungen, Steuern, Versand, Zahlungen und die Art der Kundenbetreuung. Schritt 2. Integrationen auflisten — Theme, Builder, Zahlungen, Kuriere, Rechnungen, ERP, Lager, Buchhaltung, Feeds, Filter, Abonnements, Buchungen, Konfiguratoren, benutzerdefinierte Felder. Schritt 3. Kompatibilität prüfen — Unterstützung für Variationen, dynamische Daten, E-Mails, Checkout-Blöcke, Import, HPOS und den verwendeten Builder. HPOS ist die Art, wie WooCommerce-Bestellungen in separaten Datenbanktabellen gespeichert werden. Schritt 4. URL-Struktur wählen — Unterverzeichnisse, Subdomains, Domains, Präfix der Primärsprache, Slug-Übersetzung. Schritt 5. Staging vorbereiten (eine Kopie des Shops für sichere Tests). Schritt 6. Backup erstellen (Dateien, Datenbank, Integrationskonfiguration).

Schritt 7. Eine Testsprache hinzufügen — beginnen Sie nicht mit allen geplanten. Schritt 8. Taxonomien übersetzen — Kategorien, Attribute, Attributwerte, Tags, Versandklassen. Schritt 9. Eine Produktstichprobe übersetzen — einfach, variabel, Aktion und mit Zusatzfeldern. Schritt 10. Preise und Währungen konfigurieren — Wechselkurse, manuelle Preise, Steuern, Rundungen, Zahlungen. Schritt 11. Technische Elemente übersetzen — Checkout, Konto, Formulare, E-Mails, Plugin-Meldungen. Schritt 12. SEO konfigurieren — Slugs, Metadaten, Canonicals, hreflang, Sitemap, Verlinkung. Schritt 13. Integrationen testen. Schritt 14. Testbestellungen aufgeben — jede Sprache, jedes Land, die wichtigste Versandmethode, Zahlung und Währung. Schritt 15. Stufenweise starten — veröffentlichen Sie zuerst einen Teil des Angebots, weitere Produkte und Sprachen fügen Sie hinzu, nachdem Sie bestätigt haben, dass der Prozess funktioniert.

Die häufigsten Fehler bei mehrsprachigem WooCommerce

Die meisten Probleme verursachen: die Wahl des Plugins vor der Beschreibung des Prozesses, Automatik ohne Korrektur, fehlende Attributübersetzungen und das Überschreiben durch den Import.

Wahl des Plugins vor der Beschreibung des Prozesses — ein Unternehmen kauft WPML oder Polylang, bevor es Märkte, Währungen und Integrationen festlegt. Automatische Übersetzung ohne Korrektur — der Text ist formal übersetzt, aber Produkt- und Kategorienamen klingen unnatürlich. Fehlende Attributübersetzungen — die Beschreibung ist auf Deutsch, aber der Filter zeigt weiterhin „kolor", „szerokość", „materiał". Ein polnischer Slug in einer Fremdsprache — die Adresse der deutschen Seite bleibt teilweise auf Polnisch.

Erzwingen Sie keine IP-Weiterleitung — geben Sie einen Umschalter

Ein häufiger Fehler: Der Kunde wird anhand der IP oder der Browsersprache umgeleitet und kann die Version nicht leicht ändern. Eine bessere Lösung sind ein Vorschlag und ein sichtbarer Sprachumschalter. Vermeiden Sie außerdem: den Canonical aller Übersetzungen auf die polnische Version zu setzen (ein Signal, dass die Übersetzung keine eigenständige, zu indexierende Seite ist), die automatische Verbindung von Sprache und Währung (ein englischsprachiger Kunde aus Deutschland erhält GBP statt EUR), nicht übersetzte E-Mails (eine deutsche Bestellung, eine polnische Bestätigung) und den Start des gesamten Katalogs ohne Probelauf (ein auf Tausende Produkte replizierter Fehler).

Was können Sie selbst prüfen?

Am meisten erfahren Sie, indem Sie dasselbe Produkt in jeder Sprache öffnen und den gesamten Kaufweg durchgehen.

  1. Öffnen Sie dasselbe Produkt in jeder Sprache.
  2. Wechseln Sie die Sprache auf der Produktseite und prüfen Sie, ob Sie auf das Gegenstück gelangen.
  3. Verifizieren Sie Kategorien, Attribute und Filter.
  4. Prüfen Sie Slugs, Canonicals und hreflang.
  5. Öffnen Sie die Sitemap.
  6. Legen Sie ein variables Produkt in den Warenkorb.
  7. Wechseln Sie die Sprache im Warenkorb.
  8. Prüfen Sie Versand und Zahlung.
  9. Geben Sie eine Testbestellung auf.
  10. Prüfen Sie die Sprache der E-Mail.
  11. Vergleichen Sie Währung und Beträge in der Bestellung.
  12. Verifizieren Sie den gemeinsamen Lagerbestand.
  13. Prüfen Sie das Produkt im Merchant Center.
  14. Testen Sie den Shop auf dem Smartphone.
  15. Prüfen Sie, ob der Import die Übersetzungen nicht überschreibt.

Wann lohnt es sich, einen Spezialisten zu beauftragen?

Die Hilfe eines Spezialisten wird benötigt, wenn der Shop einen großen Katalog, mehrere Integrationen oder bestehende Google-Rankings hat, die beim Umbau nicht verloren gehen dürfen.

Es lohnt sich, die Umsetzung auszulagern, wenn der Shop Hunderte oder Tausende Produkte hat, Produkte viele Variationen haben, ein Import aus einem ERP oder Großhandel läuft, Sie mehrere Währungen benötigen, Sie mehrere Zahlungsgateways nutzen, Sie lokale Versandmethoden umsetzen, der Shop einen Konfigurator nutzt, Sie Abonnements oder Buchungen verkaufen, Sie aktive Google-Shopping-Kampagnen haben, die Adressen bereits indexiert sind, Sie WPML auf Polylang umstellen oder umgekehrt, mehrere Personen die Übersetzungen verwalten oder Sie keine Testumgebung haben. Bei einem solchen Projekt müssen WooCommerce, Übersetzungen, SEO, Zahlungen, Versand, Feeds, Integrationen und die spätere Wartung zusammengeführt werden. Hilfreich sind außerdem Onlineshop-SEO, technisches SEO und ein SEO-Audit.

Häufig gestellte Fragen

Was ist besser für WooCommerce: WPML oder Polylang?

WPML bewährt sich häufiger in größeren Shops mit mehreren Währungen und einem zentralen Übersetzungsprozess. Polylang passt zu einem einfacheren Shop, in dem die Versionen direkt in WordPress verwaltet werden.

Reicht das kostenlose Polylang für WooCommerce?

Nein. Für die Verwaltung von Produkten, Variationen, Bestellungen und E-Mails wird das kostenpflichtige Add-on Polylang for WooCommerce benötigt.

Unterstützt WPML mehrere Währungen?

Ja. WooCommerce Multilingual & Multicurrency ermöglicht die Konfiguration von Währungen, Wechselkursen, manuellen Preisen, einem Umschalter und ausgewählten Zahlungen abhängig von Währung oder Standort.

Unterstützt Polylang mehrere Währungen?

Polylang for WooCommerce bietet kein eigenes vollständiges Multicurrency-Modul. Sie müssen ein separates Plugin verwenden und dessen Kompatibilität mit Zahlungen, Steuern und Rückerstattungen prüfen.

Hat Polylang eine automatische Übersetzung?

Ja. Polylang Pro kann DeepL nutzen. Die Übersetzung wird für ausgewählte Inhalte gestartet, nicht für die ganze Website mit einem Klick. Die Integration hat Einschränkungen bei Elementor und einigen Buildern.

Verlangsamt WPML oder Polylang den Shop?

Jede zusätzliche Schicht kann die Menge an Daten und Operationen erhöhen. Es gibt jedoch keine Regel, dass eines dieser Plugins immer schneller arbeitet. Das Ergebnis hängt auch vom Katalog, Theme, der Datenbank, dem Hosting und den Integrationen ab.

Welches Plugin ist besser für SEO?

Beide können separate Adressen und hreflang korrekt abbilden. Über die Sichtbarkeit entscheiden auch Übersetzungen, Keyword-Recherche, Canonicals, die Kategoriestruktur und die Verlinkung.

Kann man WPML auf Polylang umstellen?

Ja, aber es ist eine Datenmigration. Sie müssen die Übersetzungsverknüpfungen, Adressen, Metadaten, hreflang, Kategorien, Attribute und Weiterleitungen erhalten. Führen Sie die Migration zuerst auf dem Staging durch.


WPML oder Polylang — was wählen?

WPML und Polylang erlauben beide den Aufbau eines korrekten mehrsprachigen WooCommerce-Shops, sind aber keine identischen Lösungen.

WPML passt in der Regel besser zu einem Projekt, das einen zentralen Übersetzungsprozess, viel Automatisierung, mehrere Währungen, die Arbeit mehrerer Übersetzer und umfangreiche Integrationen erfordert. Polylang ist eine Überlegung wert, wenn Sie ein einfacheres Bearbeitungsmodell, manuelle Versionskontrolle, eine oder zwei zusätzliche Sprachen, einen kleineren Katalog und eine flexible, von einem technischen Team geführte Umsetzung benötigen.

Die wichtigste Frage lautet nicht „welches Plugin hat mehr Funktionen?". Legen Sie zuerst fest, wie viele Produkte Sie haben, wer sie übersetzt, woher die Daten stammen, wie Preise und Währungen funktionieren, welche Integrationen funktionsfähig bleiben müssen und wie weitere Märkte entwickelt werden. Wenn Sie einen mehrsprachigen Shop planen, können wir den Katalog, die Integrationen, die URL-Struktur und die Marktanforderungen prüfen und anschließend WPML oder Polylang an den realen Prozess anpassen: