Mehrsprachiges WordPress 2026: WPML, Polylang, MultilingualPress und Headless

#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.

#Was WordPress ohne Plugin für mehrere Sprachen mitbringt

Der WordPress-Kern übersetzt die Oberfläche, nicht den Inhalt. Eine frische Installation läuft in einer Website-Sprache, die in den allgemeinen Einstellungen festgelegt wird, und der Kern lädt die passenden Sprachpakete von translate.wordpress.org für sich selbst und für die Plugins und Themes aus dem Verzeichnis auf WordPress.org.

Seit WordPress 4.7 kann jeder Benutzer im Profil eine eigene Sprache für das Backend wählen. Der Kern speichert sie als Benutzer-Metadaten unter dem Schlüssel locale und nutzt die Website-Sprache, wenn das Feld leer ist (make.wordpress.org/core, 2016). Dasselbe Release brachte switch_to_locale() und restore_previous_locale(), mit denen Plugins eine E-Mail in der Sprache des Empfängers verschicken statt in der Sprache der Anfrage, die sie ausgelöst hat.

WordPress 6.5 hat den Lademechanismus für Übersetzungen ersetzt. Sprachpakete von WordPress.org enthalten jetzt .l10n.php-Dateien neben .mo und .po, und wenn beide vorhanden sind, lädt der Kern die PHP-Datei, die OPcache im Speicher halten kann. Websites mit reinen .mo-Dateien funktionieren weiter, und der Filter translation_file_format mit dem Rückgabewert 'mo' schaltet die PHP-Dateien ab (make.wordpress.org/core, 2024). Kommerzielle Plugins außerhalb von WordPress.org müssen die PHP-Dateien selbst erzeugen, zum Beispiel mit wp i18n make-php aus WP-CLI 2.10.

Was der Kern nicht hat, ist eine Verknüpfung zwischen zwei Beiträgen, die dasselbe in zwei Sprachen sagen. Die WordPress-Roadmap führt mehrsprachige Websites als Phase 4 des Gutenberg-Projekts, nach Bearbeitung, Anpassung und Zusammenarbeit, ohne Veröffentlichungsdatum (WordPress-Roadmap). Bis diese Phase im Kern ankommt, ergänzt jede der folgenden Strategien die Übersetzung von Inhalten über ein Plugin, ein Multisite-Netzwerk oder ein separates Frontend.

#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.

Was die kostenlose Version und Pro jeweils abdecken, laut dem Polylang-Eintrag auf WordPress.org: Die kostenlose Version übersetzt Beiträge, Seiten, Medien, Kategorien, Schlagwörter, eigene Inhaltstypen und Taxonomien und liest die Sprache aus einem Code in der URL, einer Subdomain oder einer eigenen Domain. Pro ergänzt das Duplizieren und Synchronisieren von Inhalten zwischen Übersetzungen, übersetzte URL-Slugs, maschinelle Übersetzung mit DeepL sowie Export und Import im XLIFF-Format für externe Übersetzer. WooCommerce braucht das separate Add-on Polylang for WooCommerce, das Shop, Warenkorb, Kasse und Kundenkonto übersetzt und WooCommerce-E-Mails in der Sprache des Kunden versendet.

#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

#Wie Polylang und WPML Übersetzungen in der Datenbank speichern

Das Speichermodell entscheidet, wie aufwendig eine spätere Migration, eine eigene Abfrage oder ein Headless-Export wird.

Polylang nutzt Taxonomien des WordPress-Kerns. Der Plugin-Code registriert vier davon: language und term_language halten die Sprache eines Beitrags oder Begriffs, post_translations und term_translations gruppieren die Elemente, die Übersetzungen voneinander sind. Ein deutscher Beitrag ist ein gewöhnlicher Beitrag mit einem zugeordneten language-Begriff, daher sehen WP_Query, Exporte und Backups normale WordPress-Daten.

WPML verwendet eigene Tabellen. Sprachen und Übersetzungsverknüpfungen liegen in icl_translations: element_id ist die Beitrags-ID oder term_taxonomy_id, element_type benennt die Art des Objekts, trid gruppiert die Elemente, die Übersetzungen voneinander sind, language_code ist die Sprache des Elements und source_language_code ist beim Original leer (WPML-Datenbanktabellen). Texte außerhalb von Beiträgen, etwa der Untertitel der Website, landen in icl_strings und icl_string_translations, Übersetzungsaufträge in icl_translate_job und verwandten Tabellen. Eine eigene Abfrage oder ein Migrationsskript muss diese Tabellen verbinden, weil die Beitragstabelle allein nicht verrät, in welcher Sprache ein Beitrag ist.

#Wie Sie von WPML zu Polylang wechseln

Für diese Richtung gibt es ein eigenes Werkzeug. WPML to Polylang, gepflegt von den Polylang-Entwicklern, importiert Sprachen, Sprachen und Übersetzungen von Beiträgen und Begriffen (einschließlich eigener Inhaltstypen und Taxonomien), mehrsprachige Menüs, String-Übersetzungen und die Übersetzungseinstellungen von ACF-Feldern. WPML-Daten löscht es nicht. Die dokumentierte Reihenfolge: Datenbank sichern, WPML deaktivieren, Polylang und den Importer aktivieren, ohne in Polylang eine Sprache anzulegen, den Import über die Importer-Seite im Werkzeuge-Menü starten und danach einen Sprachumschalter einrichten. Der Importer hat keine eigene Fehlerbehandlung, und seine Autoren berichten von einem erfolgreichen Test mit einer Website mit rund 9.000 Beiträgen und Mediendateien. Links, Weiterleitungen und Plugin-Integrationen brauchen danach trotzdem eine manuelle Prüfung, deshalb gehört der Wechsel vor den Launch und nicht danach.

#Wie Sie WordPress Multisite für ein Netzwerk von Sprach-Websites einrichten

MultilingualPress läuft auf einem Multisite-Netzwerk, also fallen die Netzwerkentscheidungen zuerst. Multisite wird mit define( 'WP_ALLOW_MULTISITE', true ); in der wp-config.php aktiviert, was die Seite zur Netzwerkeinrichtung freischaltet. Dort wählen Sie zwischen Subdomains und Unterverzeichnissen. Laut WordPress-Dokumentation lässt sich das Netzwerk nach der Installation auf die andere Variante umstellen, das kann aber schwierig sein (Netzwerk erstellen). Wählen Sie die Struktur passend zum URL-Plan der Sprachen, bevor die erste Unterseite existiert.

Eigene Domains pro Sprache brauchen kein Plugin. Domain-Mapping ist seit WordPress 4.5 eingebaut: Der Netzwerk-Administrator bearbeitet die Unterseite und trägt die vollständige Domain samt Schema als deren Adresse ein. Jede zusätzliche Domain muss im DNS auf das Netzwerk zeigen, jede Domain braucht ein SSL-Zertifikat (SNI liefert mehrere Domains von einem Server aus), und ein Login, der auf einer gemappten Unterseite stillschweigend scheitert, lässt sich meist mit define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); in der wp-config.php beheben (Domain-Mapping in Multisite).

#Wie Sie übersetzte Inhalte in Headless WordPress abfragen

Ein Headless-Frontend muss WordPress nach Inhalten in einer Sprache und nach den IDs ihrer Übersetzungen fragen, weil es das Hreflang-Set und den Sprachumschalter selbst baut.

Mit Polylang geht das über die REST API, aber nur in Polylang Pro. GET /wp/v2/posts?lang=fr liefert Beiträge auf Französisch, und Beiträge und Begriffe erhalten zwei zusätzliche Felder: lang mit dem Sprachcode und translations, ein Objekt, das Sprachcodes den IDs der übersetzten Elemente zuordnet (Polylang REST API).

Mit WPML ist GraphQL der dokumentierte Weg. Das Add-on WPML GraphQL setzt WPGraphQL, WPML und WPML String Translation voraus. Es ergänzt Listenabfragen um das Argument language (where: { language: "de" } oder "all" für alle Sprachen) und Beiträge und Begriffe um das Feld translations, sodass eine einzige Anfrage eine Seite samt ihren Sprachversionen liefert (WPML GraphQL). Menüs und ACF-Optionsseiten akzeptieren dasselbe Argument.

In beiden Fällen übernimmt das Frontend, was vorher das Plugin ausgegeben hat: Hreflang aus dem Feld translations, einen Sitemap-Eintrag pro Sprache und übersetzte Metadaten. URL-Strukturen, die Hreflang-Regeln von Google und Übersetzungsmanagementsysteme behandelt der Leitfaden zur globalen Content-Strategie, daher wiederholt dieser Artikel sie nicht.

#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.

#Weiterführende Leitfäden zu mehrsprachigem WordPress

• Leistungsseite Headless WordPress
• Cloudflare Workers und WordPress an der Edge
• Tech Radar Q4 2026: Urteile zum Stack