Polylang vs WPML vs TranslatePress: Vergleich 2026

Sie sind dabei, eine mehrsprachige WordPress-Website zu erstellen. Sie öffnen Google, geben „bestes WordPress-Übersetzungs-Plugin“ ein, und innerhalb von zehn Minuten ertrinken Sie in Affiliate-Bewertungen, Vergleichstabellen, die wie kopiert aussehen, und widersprüchlichen Ratschlägen zu Polylang, WPML und TranslatePress. Jede Rezension kommt bequemerweise zu dem Schluss „Plugin X ist der Gewinner“, und Sie haben keine Möglichkeit zu erkennen, welches wirklich für Ihr Projekt funktionieren wird.
Hier ist die ehrliche Antwort: Diese drei Plugins lösen das gleiche oberflächliche Problem – die Anzeige Ihrer Website in mehreren Sprachen –, verfolgen jedoch grundlegend unterschiedliche Ansätze. WPML speichert Übersetzungen in duplizierten Beiträgen. Polylang macht dasselbe, hält seinen Kern aber kostenlos. TranslatePress übersetzt gerendertes HTML in Echtzeit. Jede Architektur hat echte Kompromisse in Bezug auf Leistung, SEO, Content-Workflow und langfristige Wartung.
Dieser Vergleich durchbricht das Affiliate-Rauschen mit Details, die Ihre Website im Jahr 2026 tatsächlich beeinflussen: Preise ab diesem Jahr, wie jedes Plugin Ihre Core Web Vitals beeinflusst, was kaputt geht, wenn Sie Plugins wechseln, und warum eine wachsende Zahl von Teams alle drei überspringt und .po-Dateien direkt übersetzt.
Was diese Plugins tatsächlich tun (Sie sind nicht dasselbe)
Bevor Sie Funktionen vergleichen, müssen Sie verstehen, dass diese Plugins drei verschiedene Architekturen verwenden. Wählen Sie die falsche Architektur, und keine Menge an Plugin-Konfiguration wird Sie retten.
WPML: Duplikat-Beitrags-Modell
WPML erstellt für jede Sprache eine separate Kopie jedes Beitrags, jeder Seite, jedes Taxonomie-Begriffs und jedes Menüelements. Ihre posts-Tabelle wächst linear mit der Anzahl der Sprachen. Eine Website mit 500 Beiträgen und 5 Sprachen endet mit 2.500 Zeilen in wp_posts, plus passenden Postmeta, Term-Beziehungen und Revisionen.
Dies bietet Ihnen saubere URL-Strukturen (/es/producto/, /fr/produit/), volle Kompatibilität mit den meisten Plugins und unabhängige Bearbeitung pro Sprache. Die Kosten sind Datenbankgröße und Abfragekomplexität – jede Archivabfrage muss nach Sprache filtern, und komplexe Websites verlangsamen sich ab etwa 10.000+ übersetzten Beiträgen.
Polylang: Auch Duplikat-Beitrag (Mit kostenlosem Kern)
Polylang verwendet den gleichen Duplikat-Beitrags-Ansatz wie WPML, wird aber mit einem kostenlosen Kern-Plugin und einem kostenpflichtigen Pro-Add-on für erweiterte Funktionen wie String-Übersetzung für Plugins und WooCommerce-Unterstützung ausgeliefert. Unter der Haube ist die Architektur nahezu identisch mit WPML – gleiche Leistungsmerkmale, gleiches Skalierungsverhalten.
TranslatePress: Front-End HTML-Umschreibung
TranslatePress verfolgt einen völlig anderen Ansatz. Anstatt Beiträge zu duplizieren, übersetzt es das gerenderte HTML im laufenden Betrieb. Sie besuchen Ihre Website auf Französisch, und TranslatePress fängt die Ausgabe ab, sucht Übersetzungen in seiner eigenen Tabelle und ersetzt Zeichenfolgen, bevor die Antwort an den Browser gesendet wird.
Das bedeutet, Sie duplizieren keine Beiträge. Es bedeutet aber auch, dass jeder einzelne Seitenaufbau zusätzliche Abfragen ausführt, um übersetzte Zeichenfolgen nachzuschlagen. Für stark frequentierte Websites schafft dies eine Leistungsgrenze, die die anderen Plugins nicht haben.
Preise und Lizenzübersicht (2026)
Die Preisgestaltung ist am einfachsten zu überprüfen und der schwierigste Bereich für Affiliate-Bewertungen, um ehrlich zu bleiben. Hier sind die Zahlen für 2026, wie auf der Website jedes Anbieters veröffentlicht.
| Plugin | Kostenlose Stufe | Einstiegs-Abo | Pro-Stufe | Websites | Verlängerung |
|---|---|---|---|---|---|
| WPML | Nein | $39/yr (Multilingual Blog) | $99/yr (Multilingual CMS) | 1-unbegrenzt | Ja, ~50% erstes Jahr |
| Polylang | Ja (core) | $99/yr (Pro) | $139/yr (Business) | 1-5 | Ja, 50% Rabatt |
| TranslatePress | Ja (limited) | $7.99/mo (Personal) | $14.99/mo (Business) | 1-5 | Automatische Verlängerung |
Einige Dinge, die die Vergleichstabellen normalerweise verbergen:
- Automatische Übersetzung kostet extra. WPMLs Advanced Translation Editor verwendet DeepL oder Google, abgerechnet pro Wort. Polylang integriert mit Lingotek oder DeepL, ebenfalls abgerechnet. TranslatePress berechnet „Guthaben für automatische Übersetzung“ zusätzlich zur Lizenz.
- WooCommerce-Unterstützung ist gestaffelt. Polylang erfordert die Business-Stufe für WooCommerce. WPML erfordert die Multilingual CMS-Stufe. TranslatePress Personal beinhaltet keine WooCommerce-String-Übersetzung.
- Verlängerungspreise steigen. Einige Rezensionen zitieren den Rabatt für das erste Jahr. Die Kosten über mehrere Jahre sind das, was zählt.
Eine vollständige Aufschlüsselung, wie sich diese Kosten gegenüber Freelancer-Tarifen und Cloud-Übersetzung zusammensetzen, finden Sie in unserem WordPress-Übersetzungskosten-Vergleich.
Leistung und Auswirkungen auf die Website-Geschwindigkeit
Hier sind die architektonischen Unterschiede am wichtigsten. Core Web Vitals beeinflussen Ihr SEO direkt, und Übersetzungs-Plugins sind eine der häufigsten versteckten Ursachen für schlechte LCP- und INP-Werte.
WPML und Polylang: Datenbankgewicht
Beide Plugins fügen den meisten Front-End-Abfragen Joins hinzu. WP_Query muss nach Sprache filtern, was zusätzliche term_taxonomy- und term_relationships-Joins auf jeder Archivseite bedeutet. Auf einer kleinen Website werden Sie das nicht bemerken. Auf einer Website mit über 5.000 Beiträgen in 5 Sprachen werden Sie eine TTFB-Erhöhung von 200-500 ms ohne aggressives Caching feststellen.
TranslatePress: Umschreibung pro Anfrage
TranslatePress führt auf jeder gerenderten Seite eine Zeichenfolgensuche durch. Selbst mit Objekt-Caching setzt das Plugin eine Untergrenze für die Reaktionsgeschwindigkeit Ihrer Website, da es HTML abfangen, parsen, umschreiben und erneut ausgeben muss. Wir haben dies ausführlich in unserem Benchmark von statischen .mo-Dateien vs. Übersetzungs-Plugins gemessen – die Front-End-Umschreibung wurde in allen Testszenarien durchweg als der langsamste Ansatz eingestuft.
Das sich verstärkende Problem: Plugin-Stacks
Sie betreiben selten ein Übersetzungs-Plugin isoliert. Fügen Sie WooCommerce, einen Page Builder, ein SEO-Plugin und eine Caching-Schicht hinzu, und jedes Übersetzungs-Plugin hat seine eigenen Kompatibilitäts-Shims. WPML liefert Adapter für Dutzende von Plugins. Polylang ist etwas leichter. TranslatePress hat den kleinsten Kompatibilitäts-Fußabdruck, schreibt aber HTML um, nachdem jedes andere Plugin fertig ist, was Caching-Optimierungen aus dem Rest Ihres Stacks rückgängig machen kann.
Übersetzungsqualität und Workflow
Die Qualität der automatischen Übersetzung hängt davon ab, welche Engine jedes Plugin aufruft, nicht vom Plugin selbst. WPML verwendet DeepL, Google oder Microsoft. Polylang verwendet DeepL, Google oder Lingotek. TranslatePress verwendet DeepL oder Google.
Wichtiger ist, wie die Übersetzung geliefert und gespeichert wird:
- WPML und Polylang speichern Übersetzungen in ihren eigenen Tabellen und stellen sie über PHP bereit. Die Bearbeitung erfordert das Anmelden, Öffnen des erweiterten Editors und Speichern pro Zeichenfolge.
- TranslatePress verwendet einen visuellen Front-End-Editor. Sie klicken auf eine Zeichenfolge auf der Seite und bearbeiten sie direkt. Nicht-technische Benutzer mögen dies, aber es skaliert nicht auf Hunderte von Seiten.
Keines dieser drei Plugins schützt Platzhalter oder Code-Token standardmäßig. Wenn Sie eine automatische Übersetzung über Ihre Zeichenfolgen laufen lassen, erhalten Sie immer noch die gleiche %s-Beschädigung, HTML-Tag-Brüche und Pluralformfehler, die die rohe KI-Übersetzung plagen. Unser Leitfaden zu manueller vs. KI-Übersetzung für WordPress geht ausführlich auf die Sicherheitskompromisse ein.
Die versteckte Alternative: Statische .mo-Dateien (Kein Plugin)
Jedes WordPress-Theme und -Plugin wird mit .pot-Vorlagendateien ausgeliefert. Eine ordnungsgemäß übersetzte .po-Datei, die zu .mo kompiliert und in wp-content/languages/ abgelegt wird, wird einmal pro Seitenaufruf vom WordPress-Core gelesen – mit null zusätzlichen Datenbankabfragen, null Plugin-Overhead und voller CDN-Kompatibilität.
So hat die WordPress-Core-Community WordPress selbst seit 20 Jahren in über 70 Sprachen lokalisiert. Es ist schnell, stabil und bindet Sie nicht an das Ökosystem eines Anbieters.
Der einzige Grund, warum die meisten Website-Betreiber stattdessen Plugins verwenden, ist, dass das manuelle Übersetzen von .po-Dateien mühsam ist – Sie öffnen Poedit, übersetzen 2.000 Zeichenfolgen von Hand und hoffen, keinen Platzhalter beschädigt zu haben. Cloud-Übersetzungstools beseitigen diese Barriere vollständig. Laden Sie .po hoch, laden Sie übersetztes .po + .mo herunter, legen Sie es in wp-content/languages/themes/your-theme-es_ES.mo ab, fertig.
Keine Plugin-Lizenz. Keine Leistungseinbußen. Keine Anbieterbindung. Wenn das Theme aktualisiert wird und neue Zeichenfolgen hinzufügt, übersetzen Sie die neue .pot und stellen Sie die aktualisierte .mo-Datei erneut bereit.
Dieser Ansatz funktioniert hervorragend für Inhalte, die im Code leben (Theme-UI, Plugin-Strings, Fehlermeldungen, Schaltflächenbeschriftungen). Für Inhalte, die in der Datenbank leben (Beiträge, Seiten, Produktbeschreibungen), benötigen Sie immer noch ein Plugin oder einen manuellen Duplikat-Beitrags-Workflow. Viele Teams kombinieren beides: statische .mo-Dateien für die UI, WPML oder Polylang für Inhalte. Das Ergebnis ist schneller, kostengünstiger und besser wartbar, als sich allein auf ein Plugin zu verlassen.
Wann welcher Ansatz zu wählen ist
Schnelle Entscheidungshilfe basierend auf dem Projekttyp:
- Kleiner Blog, 2-3 Sprachen, hauptsächlich UI-Inhalt: Statische
.mo-Dateien. Das Plugin überspringen. - Inhaltsintensive Website, Redaktionsteam, viele Beiträge: Polylang oder WPML. Wählen Sie Polylang, wenn Sie einen kostenlosen Startpunkt und später Business-Funktionen benötigen; wählen Sie WPML, wenn Sie mehrsprachige benutzerdefinierte Beitragstypen und Taxonomien im großen Maßstab benötigen.
- Visueller Bearbeitungs-Workflow für nicht-technische Benutzer: TranslatePress, aber akzeptieren Sie den Leistungskompromiss und vermeiden Sie es bei stark frequentierten WooCommerce-Shops.
- WooCommerce-Shop mit großem Katalog: WPML Multilingual CMS plus
.mo-Dateien für die Theme-UI. Polylang Business funktioniert auch. - Agentur, die über 20 Kunden-Websites verwaltet: Verlagern Sie so viele Übersetzungen wie möglich in
.mo-Dateien. Eine vollständige Architektur finden Sie in unserem idealen Lokalisierungsworkflow für Agenturen.
Alles zusammenfassen
Polylang, WPML und TranslatePress sind alles legitime Tools. Jedes hat echte Benutzer, die erfolgreich echte mehrsprachige Websites betreiben. Der Fehler besteht darin, sie als austauschbare Alternativen zu behandeln und eines basierend auf einer Vergleichstabelle auszuwählen. Es handelt sich um grundlegend unterschiedliche Architekturen mit unterschiedlichen Leistungsobergrenzen und Content-Workflows.
Die tiefere Frage, die sich die meisten Website-Besitzer nie stellen, ist, ob sie überhaupt ein Übersetzungs-Plugin benötigen. Ein großer Teil dessen, was diese Plugins übersetzen – Schaltflächenbeschriftungen, Fehlermeldungen, Theme-UI, Checkout-Strings – lebt in .po-Dateien, die der WordPress-Core nativ lesen kann. Diese Dateien einmal zu übersetzen und die kompilierte .mo in wp-content/languages/ abzulegen, eliminiert eine ganze Klasse von Plugin-Overhead, Lizenzverlängerungen und Leistungsproblemen.
Bereit, Ihre WordPress
.po-Dateien zu übersetzen, ohne ein weiteres Plugin zu Ihrem Stack hinzuzufügen? Probieren Sie SimplePoTranslate kostenlos aus – keine Kreditkarte erforderlich. Laden Sie.pohoch, laden Sie übersetztes.po+.moherunter, stellen Sie es bereit.