Mehrsprachiges WordPress 2026: WPML, Polylang, MultilingualPress und Headless
Mehrsprachiges WordPress gehört zu den Fragen, bei denen “kommt darauf an” eine ehrliche und nützliche Antwort ist. 2026 existieren vier funktionierende Strategien nebeneinander, jede mit einer anderen Abwägung zwischen Redaktionsalltag, SEO, Performance und Betriebskosten. Dieser Leitfaden ordnet den häufigsten Auftraggeberprofilen die passende Strategie zu und zeigt, was bei der falschen Wahl schiefgeht.
Der Artikel verweist auf die Leistungsseite Headless WordPress, wenn SEO und Core Web Vitals die Entscheidung bestimmen.
Mehrsprachiges WordPress 2026 auf einen Blick
- Polylang Pro: sichere Standardwahl für redaktionelles WordPress auf einer Website mit kleinen bis mittelgroßen Teams.
- WPML: Standard für WooCommerce-Shops mit komplexen Übersetzungsabläufen.
- MultilingualPress: passt zu Multisite-Netzwerken, in denen jede Sprache eine eigene Website ist.
- Headless mit Astro 5+ oder Next.js 15: am besten, wenn SEO-Kontrolle und Performance wichtiger sind als redaktioneller Komfort.
- Alle vier brauchen korrektes Hreflang, Sitemaps pro Sprache und eine saubere URL-Struktur.
Welche vier Strategien gibt es für mehrsprachiges WordPress
1. Polylang (Pro) auf einer einzelnen WordPress-Website
So funktioniert es: Jeder Beitrag, jede Seite, Taxonomie und jeder Menüeintrag existiert einmal pro Sprache innerhalb einer WordPress-Installation. Das Plugin verknüpft zusammengehörige Einträge. Der Block-Editor zeigt einen Sprachumschalter, und die Redaktion übersetzt im selben Dashboard.
Wann es passt:
- Das Team ist klein bis mittelgroß, die redaktionellen Abläufe sind überschaubar.
- Die Website hat bis zu einem Dutzend Sprachen mit gemeinsamer Struktur.
- Das Hosting-Budget ist begrenzt; eine einzelne WordPress-Installation ist spürbar günstiger als Multisite.
- WooCommerce fehlt oder spielt nur eine kleine Rolle.
Abwägungen: WPML hat eine etwas ausgefeiltere Oberfläche für Redakteure, die häufig zwischen Sprachen wechseln. Polylang Pro hat außerhalb des WooCommerce-Ökosystems weniger Kompatibilitätsprobleme mit Themes und Plugins.
2. WPML auf einer einzelnen WordPress-Website
So funktioniert es: ähnliches Architekturmodell wie Polylang (eine Website, viele Spracheinträge), aber mit einer aufwendigeren Schicht für das Übersetzungsmanagement, einschließlich Translation Memory, Anbindung professioneller Übersetzer und einer tieferen WooCommerce-Integration.
Wann es passt:
- Die Website ist ein WooCommerce-Shop mit übersetzten Produkten, Kategorien, Attributen und Checkout-Texten.
- Das Team arbeitet über ein Translation-Management-System mit externen Übersetzungsdienstleistern.
- Die Plugins, von denen die Website abhängt, führen WPML als offiziell unterstützten Partner.
Abwägungen: Die WPML-Lizenz ist kostenpflichtig, die Stufen richten sich nach der Anzahl der Websites. Einige WordPress- und WooCommerce-Releases haben in der Vergangenheit Reibung verursacht; der Kompatibilitätsrückstand von WPML ist real, aber meist kurz.
3. MultilingualPress auf WordPress Multisite
So funktioniert es: Jede Sprache ist eine eigene Website in einem Multisite-Netzwerk. MultilingualPress verknüpft Beiträge zwischen den Websites und gibt der Redaktion einen Umschalter. Die Architektur lautet “ein Netzwerk, viele Websites” statt “eine Website, viele Sprachen”.
Wann es passt:
- Die Sprachversionen arbeiten operativ getrennt: eigene Redaktionsteams, eigene Veröffentlichungspläne, eigene Plugin-Sets.
- Marken- oder Rechtsgründe verlangen eine sichtbare Trennung der Sprach-Websites (verschiedene Domains, verschiedenes Branding).
- Die Performance pro Sprache zählt, und es hilft, die Plugins einer Sprache von den anderen zu isolieren.
Abwägungen: Multisite ist ein schwereres Betriebsmodell. Die Auswahl kompatibler Plugins wird kleiner. Websiteübergreifende Suche und Auswertung brauchen Zusatzarbeit.
4. Headless WordPress mit Astro 5+ oder Next.js 15
So funktioniert es: WordPress (mit Polylang oder WPML für die Inhaltserstellung) wird zum Backend. Die öffentliche Website rendert Astro oder Next.js und lädt die Inhalte pro Sprache über die WordPress REST API oder WPGraphQL. Hreflang, Sitemap, strukturierte Daten und Edge-Caching liegen in der Verantwortung des Frontends.
Wann es passt:
- SEO und Core Web Vitals bestimmen direkt den Umsatz (E-Commerce, Lead-Generierung, regulierte Branchen).
- Die Inhalte gehen über das Web hinaus (Mobile App, Oberflächen für KI-Agenten, Syndikation).
- Der Auftraggeber will explizite Kontrolle über die URL-Struktur pro Sprache, das Edge-Caching und die Genauigkeit von Hreflang.
- EU-Rechtsraum ist nicht verhandelbar; Cloudflare Workers plus ein in der EU gehosteter WordPress-Origin ist das Standardmuster.
Abwägungen: Die Redaktion arbeitet mit einer leichten Umleitung (die Vorschau läuft über eine separate Domain). Zwei Stacks müssen gepflegt werden. Die architektonischen Vorteile wachsen über die nächsten fünf Jahre, die Kosten zeigen sich in den ersten sechs Monaten.
Diesen Weg beschreibt die Leistungsseite Headless WordPress im Detail.
Wie Sie eine Strategie für mehrsprachiges WordPress wählen
| Kriterium | Polylang | WPML | MultilingualPress | Headless |
|---|---|---|---|---|
| Redaktionsalltag | Stark, ein Dashboard | Stark, ein Dashboard, tieferes TMS | Wechsel der Website nötig | Indirekt über REST oder GraphQL |
| Eignung für WooCommerce | Gut mit Pro | Am besten | Möglich, mehr Einrichtung | Eigene Integration nötig |
| SEO-Kontrolle | Plugin erzeugt Hreflang | Plugin erzeugt Hreflang | Plugin erzeugt Hreflang | Frontend verantwortet Hreflang vollständig |
| Performance-Obergrenze | An WordPress gebunden | An WordPress gebunden | An WordPress gebunden | An die Edge gebunden, deutlich höher |
| Betriebskosten | Niedrig | Niedrig bis mittel (Lizenz) | Mittel (Multisite) | Mittel bis hoch |
| Am besten für | Redaktionelle Websites | Online-Shops | Netzwerke mit mehreren Marken | Performance-kritisch oder reguliert |
Hreflang, Sitemaps, URLs und Metadaten bei mehrsprachigem WordPress
Fünf Punkte, die jede Strategie für mehrsprachiges WordPress korrekt ausliefern muss:
Hreflang-Tags. Jede Seite muss ihre Alternativen pro Sprache deklarieren, dazu einen Verweis auf sich selbst und ein x-default. Testen Sie mit echten Werkzeugen (Sitebulb, Screaming Frog oder einem selbst gebauten Crawler).
Sitemap pro Sprache. Yoast, Rank Math und die Headless-Frontends unterstützen Sitemaps pro Sprache. Prüfen Sie die Ausgabe manuell, bevor Sie sie in der Google Search Console einreichen.
Saubere URL-Struktur. Verwenden Sie konsequent Unterverzeichnisse (/en/, /de/) oder Subdomains (en.example.com). Query-Parameter (?lang=en) sind 2026 ein Antipattern und verursachen Indexierungsprobleme.
Übersetzte strukturierte Daten. JSON-LD-Blöcke nach Schema.org brauchen pro Seite übersetzte Werte für name, description und inLanguage. Die automatische Übersetzung strukturierter Daten ist ein häufiger, unbemerkter Fehler.
Übersetzte Metadaten. SEO-Titel, Meta-Beschreibung, Open-Graph-Titel und Twitter Cards werden unabhängig vom Fließtext übersetzt. Polylang und WPML decken das ab; Headless-Frontends brauchen explizite Templates pro Sprache.
Häufige Fehler bei mehrsprachigem WordPress
Drei Muster, die mehrsprachiges WordPress im Produktivbetrieb kaputt machen:
Strategiewechsel mitten im Projekt. Wer mit Polylang startet und zu WPML wechselt (oder umgekehrt), muss meist Links, Weiterleitungen und Plugin-Integrationen neu schreiben. Entscheiden Sie einmal und gründlich, bevor Sie skalieren.
Maschinelle Übersetzung als einziger Übersetzungsprozess. Maschinell erzeugte Redaktionstexte lesen sich wie maschinell erzeugte Texte. Nutzen Sie maschinelle Übersetzung nur für erste Entwürfe; die öffentliche Fassung prüft ein Muttersprachler.
Den Suchmaschinenindex ignorieren. Mehrsprachige Websites haben N-mal so viele URLs. Indexierungsprobleme summieren sich. Prüfen Sie die Search Console in den ersten drei Monaten nach dem Launch wöchentlich und erneut nach jedem größeren Plugin- oder Theme-Update.
Welche Strategie für mehrsprachiges WordPress zu welcher Website passt
Für redaktionelles WordPress auf einer einzelnen Website 2026: Polylang Pro ist der richtige Ausgangspunkt, sofern WooCommerce oder Compliance-Anforderungen Sie nicht woanders hinführen.
Für einen WooCommerce-Shop: WPML ist der richtige Ausgangspunkt.
Für ein Netzwerk mit mehreren Marken oder Regionen: MultilingualPress auf Multisite.
Für eine performance-kritische oder regulierte Website: Headless mit Astro oder Next.js, mit WordPress als redaktionellem Backend. Die architektonischen Details behandeln die Leistungsseite Headless WordPress und der Leitfaden zu Cloudflare Workers und WordPress an der Edge.
