Mehrsprachiges WordPress ohne Rewrite-Magie: warum Übersetzungen normale Beiträge sein sollten

Die Frage „welches Mehrsprachigkeits-Plugin soll ich nehmen" wird fast immer über Funktionslisten entschieden. Das ist verständlich und trotzdem die falsche Reihenfolge. Denn die Funktionsliste ändert sich mit jedem Update, die Architektur nicht. Und die Architektur entscheidet, was in drei Jahren passiert, wenn du das Theme wechselst, einen Cache einbaust, die Seite umziehst oder das Plugin wieder loswerden willst.

Dieser Artikel sortiert die drei möglichen Architekturen, erklärt die hreflang-Regeln, an denen in der Praxis die meisten Setups scheitern, und ordnet die bekannten Werkzeuge sachlich ein.

Drei Architekturen, drei sehr unterschiedliche Konsequenzen

Variante A: Übersetzungen sind eigene Beiträge

Jede Sprachfassung ist ein vollwertiger Beitrag oder eine vollwertige Seite mit eigener ID, eigenem Permalink und eigenem Eintrag in der Beitragsliste. Die Verbindung zwischen den Fassungen liegt in einer separaten, kleinen Zuordnung, etwa in Post-Meta.

Konsequenz: WordPress behandelt jede Sprachfassung wie jeden anderen Inhalt auch. Suche, REST-API, Exporte, Cache-Plugins, Backup-Tools und der Editor kennen keinen Sonderfall. Entfernst du das Plugin, verlierst du die Zuordnung, aber keinen Text. Der Preis: Menüs, Kategorien und Theme-Texte sind damit nicht automatisch mitübersetzt, dafür braucht es weiterhin eine eigene Lösung.

Variante B: Übersetzungen hängen am selben Beitrag

Ein Beitrag trägt mehrere Sprachfassungen in Zusatzfeldern oder eigenen Tabellen. Beim Aufruf entscheidet das Plugin, welche Fassung ausgeliefert wird.

Konsequenz: Das ist bequem, weil eine Seite eine Seite bleibt, und es erlaubt, auch Theme-Strings und Menüs mitzunehmen. Der Preis ist die Verflechtung: Der Inhalt lebt in einer Struktur, die WordPress von sich aus nicht kennt. Deinstallierst du das Plugin, bleibt in der Regel die Quellsprache sichtbar und alles andere liegt in Feldern, die kein anderes Werkzeug lesen kann. Ein Wechsel ist dann kein Wechsel, sondern eine Migration.

Variante C: Ein Proxy vor der Seite

Die Übersetzung passiert nicht in WordPress, sondern in einem Dienst, der zwischen Besucher und deiner Seite sitzt. Er holt deine Seite, ersetzt Texte und liefert das Ergebnis aus, oft unter einer Subdomain oder einem Sprachpfad, den er selbst verwaltet.

Konsequenz: Das ist der schnellste Weg zu einer mehrsprachigen Seite, und für reine Informationsseiten funktioniert er gut. Zwei Dinge sollte man vorher wissen. Erstens: Der Auslieferungsweg der übersetzten Seiten hängt am Dienst, und die Abrechnung läuft in aller Regel nach Wortbestand, also laufend für Inhalt, den du selbst geschrieben hast. Zweitens: Markt-spezifische Abweichungen sind schwierig. Wenn die englische Fassung einer Seite einen anderen Absatz braucht, weil dort andere Regeln gelten, kämpft man gegen ein Modell, das auf „gleicher Text, andere Sprache" ausgelegt ist.

Warum wir Variante A für die richtige Voreinstellung halten

Nicht, weil sie mehr kann. Sie kann weniger. Sondern weil sie an drei Stellen billiger ist, an denen es später wehtut.

Erstens beim Wechsel. Inhalte, die als normale Beiträge existieren, sind nicht an ein Plugin gebunden. Das ist kein theoretischer Vorteil: Jedes Plugin kann eingestellt werden, jeder Anbieter kann Preise ändern. Eine Architektur, die den Ausstieg offen lässt, verhandelt für dich mit.

Zweitens bei allem, was WordPress sonst noch tut. Volltextsuche, geplante Veröffentlichung, Revisionen, REST-API, Redaktionsrollen, Import und Export, Statistik-Plugins: Das alles funktioniert bei normalen Beiträgen ohne Anpassung. Bei Sonderstrukturen funktioniert es genau so weit, wie das Plugin daran gedacht hat.

Drittens bei der Redaktion je Markt. Wenn die englische Fassung ein zusätzliches Kapitel bekommt, weil der Markt es braucht, ist das in Variante A einfach eine Änderung an einem Beitrag. Der eigentliche Punkt: Weil der Zielbeitrag ein echter Beitrag ist, ist er bereits die Marktvariante. Es braucht keine Zusatzstruktur, damit sich zwei Sprachfassungen inhaltlich unterscheiden dürfen.

Die URL-Frage: /en/ ist kein Rankingfaktor

Eine hartnäckige Annahme lautet, mehrsprachige Seiten bräuchten zwingend ein Sprachpräfix wie /en/ oder eine eigene Subdomain, sonst verstehe Google die Zuordnung nicht. Das stimmt so nicht. Google nennt Unterverzeichnisse, Subdomains und länderspezifische Domains als gleichwertige Möglichkeiten und macht keine davon zur Pflicht. Was zählt, ist die eindeutige Zuordnung über hreflang, und die funktioniert unabhängig davon, wie deine Adressen aussehen.

Praktisch heißt das: Du kannst /en/about-us/ als ganz normale Seitenhierarchie bauen, wenn dir die Struktur gefällt. Du musst es aber nicht, und kein Plugin muss dafür in deine Permalinks eingreifen. Rewrite-Regeln sind eine Design-Entscheidung, kein SEO-Zwang.

Fünf hreflang-Regeln, an denen es in der Praxis scheitert

1. Bidirektionalität. Wenn Seite A auf Seite B als Übersetzung verweist, muss B auch auf A verweisen. Fehlt die Rückrichtung, ignoriert Google die Angabe. Das ist der mit Abstand häufigste Fehler, und er entsteht fast immer dadurch, dass die Verweise pro Seite gepflegt statt aus einer gemeinsamen Gruppe erzeugt werden.
2. Selbst-Referenz. Jede Seite muss sich in ihrer eigenen hreflang-Liste selbst nennen. Klingt überflüssig, ist aber Teil der Spezifikation.
3. x-default. Der Wert sagt, welche Fassung ausgeliefert werden soll, wenn keine Sprache passt. Ohne x-default rät die Suchmaschine.
4. Absolute URLs. hreflang-Verweise brauchen die vollständige Adresse inklusive Protokoll und Domain. Relative Pfade werden ignoriert.
5. Keine Verweise auf Unveröffentlichtes. Entwürfe, private oder per noindex ausgeschlossene Seiten dürfen nicht in der Liste stehen. Genauso sinnlos ist eine hreflang-Ausgabe für eine Seite, die überhaupt nur in einer Sprache existiert.

Der bemerkenswerte Punkt an dieser Liste: Vier der fünf Regeln erledigen sich von selbst, wenn die Verweise aus einer gemeinsamen Gruppe erzeugt werden statt pro Seite gepflegt. Bidirektionalität ist dann keine Fleißaufgabe, sondern eine Eigenschaft der Konstruktion. Wer strukturierte Daten sauber halten will, kennt das Muster schon aus unserem Beitrag zum Schema Markup in WordPress: Es ist immer robuster, Angaben aus dem Inhalt abzuleiten, als sie parallel zu pflegen.

Die bekannten Werkzeuge, sachlich eingeordnet

Keines dieser Werkzeuge ist schlecht, und für viele Projekte ist der große Funktionsumfang von WPML genau richtig. Die Frage ist nicht „welches ist das beste", sondern „welche Konsequenz kann ich in drei Jahren tragen".

Eine Checkliste vor der Entscheidung

• Brauche ich wirklich übersetzte Menüs und Theme-Texte, oder betrifft mein Bedarf vor allem Beiträge und Seiten?
• Was passiert mit meinen Inhalten, wenn ich das Werkzeug in zwei Jahren entferne? Bleiben sie lesbar in der WordPress-Oberfläche stehen?
• Rechne ich einmal ab oder laufend nach Wortbestand, und wächst die Rechnung mit meinem eigenen Content?
• Werden die Sprachfassungen inhaltlich identisch bleiben, oder brauche ich je Markt Unterschiede?
• Erzeugt das Werkzeug hreflang aus einer gemeinsamen Gruppe, oder muss ich Verweise pro Seite pflegen?

Wer die letzte Frage ernst nimmt, hat die Hälfte der typischen SEO-Probleme in mehrsprachigen Setups bereits ausgeschlossen. Die andere Hälfte ist inhaltlich, und darum geht es im Beitrag Eine Sprache ist ein Markt.

Häufige Fragen