2021 betreute ich einen deutschen E-Commerce-Client bei Seahawk an. Sieben Sprachen, WooCommerce, Elementor, und ein Deadline, der bereits zu rutschen begann. Ich installierte WPML, wie man das eben tut, richtete den Language Switcher ein, führte die erste Übersetzungssynchronisierung durch, und beobachtete, wie die Time to First Byte auf einem 40 £/Monat-Managed-Host über 2,8 Sekunden kroch. Der Client war nicht begeistert. Ehrlich gesagt, ich auch nicht.
Das war der Moment, in dem ich tatsächlich anfing, andere Optionen zu testen, statt einfach anzunehmen, dass WPML die Antwort ist. Vier Jahre und ein paar hundert mehrsprachige Projekte später habe ich Meinungen. Starke.
---
Warum Menschen 2026 über WPML hinausschauen
WPML ist nicht schlecht. Lassen Sie mich das klar sagen. Für komplexe redaktionelle Websites mit einem Content-Team, das Übersetzungen in einem Workflow verwaltet, ist es immer noch echte fähig. Aber es gibt drei Dinge, die Clients (und mich) immer wieder zu Alternativen treiben.
Preisanstieg. Der Multilingual-CMS-Plan, derjenige, den man tatsächlich für WooCommerce oder Custom Post Types braucht, kostet jetzt 99 Dollar pro Jahr. Das ist pro Website. Agenturen, die White-Label-Arbeit für KMUs leisten, können das nicht immer weitergeben, ohne ein Gespräch zu führen, das sie lieber vermeiden würden. The Multilingual CMS plan, the one you actually need for WooCommerce or custom post types, sits at $99/year now. That's per site. Agencies doing white-label work for SMEs can't always pass that on without a conversation they'd rather not have.
Performance-Overhead. WPML fügt pro Seitenaufruf eine erhebliche Anzahl von Datenbankabfragen hinzu. Bei einer großen Website mit Tausenden von Beiträgen addiert sich das. Ich habe gesehen, dass es 400–600 ms zur TTFB hinzufügt auf Websites, die nicht speziell dafür optimiert waren. Googles Core Web Vitals Richtlinien machen diese Art von Verlangsamung zunehmend teuer, um sie zu ignorieren. WPML adds a non-trivial number of database queries per page load. On a large site with thousands of posts, that compounds. I've seen it add 400-600ms to TTFB on sites that weren't tuned specifically around it. Google's Core Web Vitals guidance makes that kind of drag increasingly expensive to ignore.
Komplexität für einfache Anforderungen. Wenn ein Kunde drei Sprachen und zwanzig Seiten braucht, ist WPMLs Konfigurationsoberfläche abschreckend. Man klickt sich durch String Translation, Translation Management, WooCommerce Multilingual Setup... es ist viel. Manchmal braucht man einfach nur etwas, das an einem Nachmittag funktioniert. If a client needs three languages and twenty pages, WPML's configuration surface is intimidating. You're clicking through String Translation, Translation Management, WooCommerce Multilingual setup... it's a lot. Sometimes you just need something that works in an afternoon.
---
Polylang: Das Arbeitstier, das die meisten Agenturen übersehen
Ich habe Polylang wahrscheinlich auf über 200 Websites eingesetzt. Die kostenlose Version kümmert sich um grundlegende Post/Page/Taxonomy-Übersetzungen ohne dich einen Cent zu kosten. Die Pro-Version (£99 pro Jahr für unbegrenzte Websites, soweit ich zuletzt geprüft habe) ist dort, wo es wirklich konkurrenzfähig wird, weil diese „unbegrenzte Websites"-Lizenzierung für Agenturen ein völlig anderes Angebot ist als WPMLs Pro-Website-Modell.
Das kann Polylang gut
Die Benutzeroberfläche ist sauber. Die Sprachzuweisung erfolgt direkt in der Post-Editor-Seitenleiste, sie übernimmt dein Dashboard nicht, und der Performance-Impact ist merklich leichter als bei WPML. Bei einem vergleichbaren Test, den ich im März 2025 auf einer Staging-Website mit 500 Beiträgen durchgeführt habe – WPML gegenüber Polylang Pro – reduzierte Polylang die TTFB um etwa 180 ms. Nicht riesig, aber real.
Es integriert sich gut mit Elementor, Bricks, ACF und WooCommerce (über das WooCommerce Add-on, das extra kostet). Das Letzte ist der Haken: WooCommerce-Support benötigt das Add-on, und wenn man das dazustapelt, wird der Kostenunterschied zu WPML enger.
Wo Polylang schwach wird, ist maschinelle Übersetzung. Es gibt im Kern keine integrierte DeepL- oder Google Translate-Integration. Man braucht eine Brücke von Drittanbietern wie WPMLs eigenes Ökosystem oder etwas wie Linguise, was mich zu...WPML's own ecosystem or something like Linguise, which brings me to...
---
TranslatePress: Die beste Option für Speed-First-Projekte
TranslatePress hat verändert, wie ich über mehrsprachiges WordPress denke. Statt des Post-Duplikations-Modells (bei dem man separate Posts pro Sprache hat), nutzt es einen visuellen Frontend-Editor, in dem man Text direkt auf der gerenderten Seite übersetzt. Du siehst deine Website, klickst auf einen String, tippst die Übersetzung ein. Fertig.
Das hat Auswirkungen auf die Performance. Es gibt keine sprachspezifische Post-Duplikation, die deine Datenbank aufbläht. Übersetzte Strings liegen in einer Custom-Tabelle, nicht als separate Posts. Bei einem Projekt, das Seahawk Ende 2024 für einen französisch-belgischen Einzelhandelskunden durchführte, wechselten wir mitten im Projekt von WPML zu TranslatePress (nicht ideal, ich weiß, aber der Kunde änderte den Umfang) und die Datenbankabfragen pro Seite sanken um etwa 40%.
Die DeepL-Integration
TranslatePress Pro hat eine DeepL-API-Integration integriert. Für Kunden, die maschinelle Übersetzung als Ausgangspunkt und menschliche Überprüfung danach wünschen, ist dieser Workflow unvergleichlich besser als alles, was ich manuell zusammengebastelt habe. Du stellst es so ein, dass es beim Veröffentlichen automatisch übersetzt, dein Editor überprüft und korrigiert, und du bist fertig. Die Bearbeitungszeit für eine 50-Seiten-Website sinkt von Tagen auf einen Nachmittag.DeepL API integration built in. For clients who want machine translation as a starting point and human review after, this workflow is miles better than anything I've patched together manually. You set it to auto-translate on publish, your editor reviews and corrects, and you're done. The turnaround on a 50-page site goes from days to an afternoon.
Die Preisgestaltung liegt bei etwa 89 $/Jahr für den Personal-Plan, 179 $ für Business (3 Websites), 299 $ für Developer (unbegrenzt). Für Agenturen ist der Developer-Plan der relevante.
Eine ehrliche Einschränkung: sehr komplexe WooCommerce-Stores mit viel dynamischem Inhalt können Lücken in der String-Erkennung offenbaren. TranslatePress fängt die meisten Dinge, aber wenn du stark angepasste Checkout-Flows oder von Plugins generierte Strings aus obskuren Add-ons hast, könnten dir einige entgehen. Kalkuliere ein paar Stunden für manuelle String-Bereinigung ein.
---
Weglot: Wenn der Kunde Budget hat und Zero Friction möchte
Ich mache es kurz: Weglot ist teuer. £99/Jahr bekommst du ein Sprachpaar und bis zu 10.000 Wörter. Eine echte Business-Website sprengt das fast sofort, und die Preise steigen von da an schnell an. Bei einer mittelgroßen Website mit drei Sprachen kannst du mit £300-400/Jahr rechnen.
Aber hier ist der Punkt. Das Setup dauert etwa 15 Minuten. Du installierst das Plugin, fügst einen API-Schlüssel ein, wählst deine Sprachen aus, und es funktioniert. Keine Konfigurationsfallen, keine Kompatibilitätsprobleme mit deinem Page Builder. Es verarbeitet JavaScript-gerenderte Inhalte besser als jede andere Option auf dieser Liste, was wichtig ist, wenn du ein React-lastige oder Elementor-mit-vielen-dynamischen-Widgets-Setup laufen hast.
Ich empfehle Weglot speziell, wenn: der Kunde ein Startup mit echtem Umsatz ist, sie schnell vorankommen müssen, und Mehrsprachigkeit ist wirklich nebensächlich für ihr Produkt (nicht das Hauptthema). Für eine SaaS-Landingpage, die von Englisch auf Deutsch und Französisch umgestellt wird, ist es ein No-Brainer, wenn Budget kein Problem ist.
---
MultilingualPress: Die Lösung für WordPress-Multisite-Setups
Wenn du WordPress Multisite betreibst, und 2026 erlebt Multisite gerade eine kleine Renaissance bei Enterprise- und Franchise-Kunden, dann ist MultilingualPress das Plugin, das du brauchst. Punkt.
Es erstellt eine separate Website pro Sprache in deinem Netzwerk. Das ist ein grundlegend anderer architektonischer Ansatz im Vergleich zu den anderen auf dieser Liste. Jede Sprachwebsite ist unabhängig: eigene Datenbankeinträge, eigene URL-Struktur (du kannst Subdomains oder separate Domains verwenden), eigenes Admin-Panel. Sie sind durch Beziehungen verbunden, mit denen du äquivalente Inhalte über Sites hinweg verlinken kannst.
Seahawk hatte 2023 einen Franchise-Kunden mit 14 regionalen Sites, 6 Sprachen und einer Zentrale, die zentrale Content-Kontrolle mit lokalen redaktionellen Änderungen wollte. MultilingualPress auf einem Multisite-Netzwerk war wirklich die richtige Antwort. Nichts anderes kam in Frage. Die eigene Dokumentation von MultilingualPress ist eigentlich anständig, wenn du sehen willst, wie die Content-Beziehungen funktionieren.MultilingualPress's own documentation is actually decent if you want to see how the content relationships work.
Der Nachteil ist operative Komplexität. Multisite ist schwieriger zu pflegen, schwieriger an einen nicht-technischen Kunden zu übergeben, und Plugins, die Multisite nicht unterstützen (es gibt noch immer einige), werden dein Problem. Geh mit offenen Augen rein.
---
Linguise: Das dunkle Pferd für Headless- und API-gesteuerte Projekte
Linguise ist kein WordPress-Plugin im klassischen Sinne. Es ist eine proxy-basierte Übersetzungsschicht, die sich vor deine Website setzt und die Übersetzung am Edge handhabt. Das macht es besonders interessant für Headless-WordPress-Setups, bei denen das Frontend in Next.js oder Nuxt gebaut ist.
Ich habe es Anfang 2025 in einem Headless-Projekt getestet, bei dem der Client ein Gutenberg-basiertes CMS hatte, das ein Next.js-Frontend speiste. WPML und TranslatePress passten beide schlecht, weil die Übersetzung im gerenderten Output stattfinden musste, nicht in WordPress-Content-Feldern. Linguise hat das sauber gelöst.
Es ist auch nicht billig – Pläne starten bei etwa 15 €/Monat – aber für die richtige Architektur löst sonst nichts das Problem auf die gleiche Weise.
---
Wie man tatsächlich wählt
Hier ist mein Entscheidungsrahmen nach dem Aufbau mehrsprachiger Sites über zwölftausend Projekte hinweg. Kein starrer Algorithmus, sondern ein Satz von Fragen, die es schnell eingrenzen.
- Was ist die URL-Strategie? Falls der Client separate Domains pro Sprache braucht (example.de, example.fr), handhabt MultilingualPress oder WPML das am saubersten. TranslatePress und Polylang können es, brauchen aber mehr Konfiguration. If the client needs separate domains per language (
example.de,example.fr), MultilingualPress or WPML handle this most cleanly. TranslatePress and Polylang can do it but need more config. - Ist WooCommerce involviert? Falls ja, liste WPML, Polylang Pro + WooCommerce-Add-on oder TranslatePress Business auf. Teste jeden mit deiner spezifischen Produktkataloggröße. If yes, shortlist WPML, Polylang Pro + WooCommerce add-on, or TranslatePress Business. Test each on your specific product catalogue size.
- Will der Client maschinelle Übersetzung? TranslatePress mit DeepL oder Weglot sind am saubersten. WPMLs Translation-Management funktioniert auch, wirkt aber unternehmensgerichteter. TranslatePress with DeepL or Weglot are the cleanest. WPML's translation management also works but feels more enterprise-y.
- Wie viele Websites muss Ihre Agentur abdecken? Polylang Pro's Lizenz für unbegrenzte Websites ist das beste Preis-Leistungs-Verhältnis für Agenturen mit großem Volumen. Polylang Pro's unlimited-sites licence is the standout value for agencies at volume.
- Ist das Frontend headless oder stark JavaScript-getrieben? Weglot oder Linguise. Kämpfen Sie nicht mit Post-Duplikations-Plugins auf einem Next.js Frontend. Weglot or Linguise. Don't fight with post-duplication plugins on a Next.js frontend.
- Ist dies ein Multisite-Netzwerk? MultilingualPress. Das war's. MultilingualPress. That's it.
---
Was ist mit den nativen mehrsprachigen Funktionen des Block Editors?
WordPress-Kern bewegt sich seit Jahren in Richtung nativer mehrsprachiger Unterstützung. Matt Mullenweg hat sich dazu öffentlich mehr als einmal geäußert, und es gab Gutenberg-GitHub-Diskussionen darüber seit 2020. Stand Anfang 2026 ist es immer noch nicht in irgendeiner bedeutsamen produktionsreifen Form vorhanden.Gutenberg GitHub discussions about it going back to 2020. As of early 2026, it still isn't here in any meaningful production-ready form.
Ich würde eine Plugin-Entscheidung nicht aufschieben und auf native Unterstützung warten. Entwickeln Sie mit dem, was heute existiert. Falls native Unterstützung kommt, ist eine Migration ein Problem, das Sie gerne haben würden.
---
FAQ
Lohnt sich WPML noch im Jahr 2026?
Bei großen redaktionellen Websites mit dedizierten Übersetzungsteams absolut ja. Das Translation Management Modul, der XLIFF Export, die Kompatibilität mit so gut wie allem im WordPress Ökosystem – es ist immer noch die vollständigste Option. Wo es schwach wird, sind der Preis bei Skalierung, die Performance auf großen Datenbanken und die Komplexität für einfache Projekte.
Kann ich während eines Projekts von WPML zu einem anderen Plugin wechseln?
Technisch ja, praktisch ist es schmerzhaft. WPML speichert Sprach-Metadaten in eigenen Tabellen und Post Meta. Die meisten anderen Plugins lesen das nicht nativ. Es gibt Migration Tools und Scripts auf GitHub, aber rechne mit Zeit dafür. Ich habe drei Migrationen von WPML gemacht und jede brauchte Custom SQL Arbeit. Plane für eine mittlere Website mindestens einen halben Tag ein.
Funktioniert TranslatePress mit Elementor und Bricks?
Elementor: ja, sehr gut. Der Front-End Translator von TranslatePress rendert den Elementor Output und erfasst Strings zuverlässig. Bricks ist neuer und die Kompatibilität hat sich 2024-2025 verbessert – ich würde einen gründlichen Test auf deinem spezifischen Template machen, bevor du auf einer Production Site commitest.
Welches Multilingual Plugin ist am besten für SEO?
Alle großen (WPML, Polylang, TranslatePress) implementieren hreflang Tags korrekt, wenn richtig konfiguriert. Die Lücke ist nicht in der hreflang Implementierung, sondern darin, wie schnell jedes die Seite rendert. SEO 2026 ist stark auf Core Web Vitals gewichtet, daher kann der Performance Unterschied zwischen einer aufgeblähten WPML Installation und einem schlanken TranslatePress Setup wichtiger sein als die hreflang Konfiguration.hreflang tags correctly when configured properly. The gap isn't in hreflang implementation, it's in how fast each renders the page. SEO in 2026 is heavily weighted toward Core Web Vitals, so the performance difference between a bloated WPML install and a lean TranslatePress setup can matter more than the hreflang configuration.
Was ist der billigste Weg für mehrsprachiges WordPress?
Polylang kostenlos plus manuelle Übersetzung für jeden Post. Null Kosten. Funktioniert gut für kleine Websites mit geduldigen Redakteuren. In dem Moment, wo du WooCommerce, maschinelle Übersetzung oder mehr als 50 Posts brauchst, wirst du für etwas bezahlen wollen.
---
Der mehrsprachige WordPress-Bereich ist wirklich erwachsen geworden. WPML hatte die Kategorie viel zu lange für sich allein, und der Wettbewerb hat alles besser gemacht. Wählen Sie basierend auf Ihrer Architektur, dem Budget Ihres Kunden und Ihrer eigenen Bereitschaft, Dinge zu konfigurieren – nicht basierend darauf, was 2018 die Standardantwort war.