KI-Übersetzung in WordPress: warum sie das mehrsprachige SEO bricht

#KI-Übersetzung in WordPress: warum sie das mehrsprachige SEO bricht

Die Schlagzeile stimmt. Das fehlende eine Prozent ist genau die Stelle, an der die Kosten landen. Leonardo Losoviz im WP Tavern Jukebox, gefragt, wo KI-Übersetzung heute im Vergleich zur menschlichen Arbeit steht, sagte:

“Es ist so einfach, alle werden es tun. Und wenn alle es tun, kommen Sie nicht voran, Sie rennen nur, um auf der Stelle zu bleiben.”

Auf Satzebene hat er recht. Er beschreibt damit aber auch einen Markt, auf dem die eigentliche Übersetzungsqualität keine Seite mehr von einer anderen unterscheidet. Was sie unterscheidet, geschieht in den Feldern, die der KI-Übersetzer eigentlich nicht anfassen sollte, in der Praxis aber regelmäßig anfasst.

Dieser Beitrag ist eine Polemik gegen die Lesart “99 Prozent genau” als Erfolgsmeldung. Die Zahl stimmt und ist trotzdem weitgehend irrelevant. Der Aufwand für eine mehrsprachige WordPress-Site hat sich 2026 von der Frage “ist der Text gut” hin zur Frage “übersteht die Struktur die Übersetzung” verschoben.

#KI-Übersetzung im mehrsprachigen WordPress 2026: TL;DR in 4 Punkten

• Im WP Tavern Jukebox sagt Losoviz: KI wickelt 99 Prozent der WordPress-Übersetzung korrekt ab, zu einem Bruchteil der menschlichen Kosten. Die Zahl ist real, aber sie gilt für die Prosa.
• Das fehlende eine Prozent, das KI-Übersetzungstools routinemäßig kaputt machen, steht nicht in den Sätzen, sondern in den Feldern, die entscheiden, unter welcher URL ein Artikel lebt und wie Google ihn indexiert.
• Genau dieses eine Prozent indexiert Google. Die 99 Prozent Prosa liest erst, wer auf einer korrekt indexierten Seite gelandet ist. Reißt die Indexierungsschicht, liest niemand mehr die Prosa.
• Die Lösung ist kein klügerer Satz-Übersetzer. Sie besteht darin, die technischen Felder von den Feldern zu trennen, an die der KI-Übersetzer ran darf, plus eine kurze Diakritika-Prüfung nach jedem Übersetzungslauf.

#Glossar: Frontmatter, Slug, Hreflang und Canonical in WordPress

Der Rest des Artikels stützt sich auf sieben Begriffe. Wenn einer davon unbekannt klingt, ist das genau das Feld, an dem der KI-Übersetzer am häufigsten etwas verbiegt. Für jeden, der noch nie eine Inhaltsdatei geöffnet hat:

• Frontmatter - der Metadatenblock ganz oben in einer Artikeldatei, eingerahmt von ---. Dort stehen Titel, Beschreibung, Kategorien, kanonischer URL, Links zu anderen Sprachversionen, der Slug und Dutzende weiterer Felder. Der KI-Übersetzer bekommt die ganze Datei zu sehen, also Frontmatter und Body zusammen.
• Slug - das Ende der Artikel-URL, zum Beispiel nis2-dora-wordpress-compliance-2026. Es ist eine Routing-Kennung (die Adresse, unter der die Seite tatsächlich erscheint), keine Überschrift zum Lesen.
• force_slug: true - ein Frontmatter-Schalter, der dem System sagt: “Nimm genau diesen Slug als URL, auch wenn der Dateiname anders aussieht.”
• Kanonische URL (canonicalUrl) - ein Frontmatter-Feld, das Google mitteilt, welche URL die maßgebliche Version zum Indexieren ist, wenn mehrere Varianten existieren.
• Hreflang - die Verknüpfungen zwischen den Sprachversionen desselben Artikels, damit Google versteht: “Das hier ist die deutsche Übersetzung der englischen Quelle.”
• Taxonomie-Begriffe - die Werte in categories und tags. Jeder erzeugt eine eigene URL, zum Beispiel /de/tag/compliance/.
• Weiterleitungstabelle - die Liste der Paare (alter URL, neuer URL), die verhindert, dass früher indexierte Links nach einer Slug-Änderung mit 404 zurückkommen.

Diese Felder sind für die Leserin unsichtbar. Für Google und das interne Linknetz sind sie entscheidend. Im Kontext von DSGVO- oder NIS2-Compliance-Inhalten kommt dazu, dass jede 404-Pfusch-URL im deutschen Markt nicht nur ein SEO-Problem ist, sondern in der Außenwirkung gegenüber Behördenseiten und BSI-Querverweisen zählt.

#Wie KI-Übersetzung einen deutschen WordPress-Slug zerlegt: ein konkreter Fall

Ein Muster, das sich mit jedem KI-Übersetzungstool reproduzieren lässt, das eine ganze Datei verarbeitet, gegen einen typischen Astro- oder WordPress-Inhaltsbaum:

• Die deutsche Version eines Compliance-Artikels liegt in der Datei irgendwas-compliance-2026.de.md und bringt im Frontmatter den Eintrag slug: nis2-dora-wordpress-Konformität-2026 mit. Der Übersetzer hat das deutsche Lehnwort gewählt, weil das Feld nach einem Satzanfang aussah und die Zielsprache des Textes Deutsch ist. Aus “compliance” wurde “Konformität”.
• Der Rest des Clusters verlinkt weiter auf die ASCII-Variante, so wie es die englische, polnische, norwegische, spanische und portugiesische Schwesterdatei tun. Jeder dieser Links liefert 404 zurück, denn der Router liefert die Seite unter der Umlaut-Adresse aus, die der Übersetzer eingetragen hat und der force_slug: true Vorrang vor dem Dateinamen einräumt.
• Zwei deutsche Pillar-Seiten leben jetzt unter einer URL mit ä, auf die keine andere Sprachversion verweist. Das cluster-interne Linknetz reißt auf der Indexierungsschicht so lange auseinander, bis jemand ein strukturelles Audit fährt, was auf den meisten Produktiv-Sites schlicht nie passiert.

Hätte der Übersetzer einen leicht ungelenken Satz in den Body geschrieben, wäre der Preis ein Seufzer der Leserin gewesen. Dieselbe Fehlerklasse im slug-Feld kostet Monate cluster-internen Link-Signals, verteilt auf ein Dutzend Seiten.

Das ist der Abstand zwischen “99 Prozent genau” und “0 Prozent kaputt auf der Schicht, die zählt”.

#Was “99 Prozent genaue” KI-Übersetzung nicht misst

Wenn Losoviz von 99 Prozent spricht, meint er Treue auf Satzebene. Bedeutet der deutsche Absatz, was der englische Absatz bedeutete. Bleibt die Terminologie über den ganzen Beitrag hinweg konsistent. Passt der Ton zur Zielgruppe. Moderne KI-Übersetzer, an einen veröffentlichten Style-Guide gehalten, treffen bei Muttersprachler-Reviews tatsächlich 95 bis 99 Prozent. Die Zahl ist real.

Was die Zahl nicht misst:

1. Ob der Slug im Frontmatter zum Dateinamen und zur etablierten URL-Konvention passt.
2. Ob der force_slug-Schalter durch eine bewusste Autorenentscheidung oder durch eine Übersetzerhalluzination gesetzt wurde.
3. Ob die canonicalUrl nach einer Slug-Änderung noch zum Slug passt.
4. Ob die Werte in categories und tags mit den Kategorie- und Tag-URLs übereinstimmen, die der Rest der Site benutzt. Ein deutscher Blog kann auf /de/tag/Konformität/ abdriften, während jede andere Sprachversion auf die ASCII-Term-URL leitet, womit eine Tag-Seite entsteht, auf die keine andere Sprachversion verlinkt.
5. Ob die Hreflang-Geschwister-URLs im Layout sich tatsächlich auflösen lassen.
6. Ob die Weiterleitungstabelle nach einer Slug-Änderung einen 301-Eintrag von der alten URL enthält.
7. Ob 301-Weiterleitungen von einer zuvor veröffentlichten und indexierten URL existieren, wenn der Übersetzer in einem frischen Lauf das Slug-Muster verändert.

Keiner dieser sieben Punkte ist Satzebene. Alle sind strukturell. Der KI-Übersetzer kann jeden davon beeinflussen, weil jeder im Frontmatter offen liegt, das der Übersetzer neben dem Body liest und umschreibt.

#Warum ein KI-Slug-Fehler teurer ist als ein Satzfehler

Ein schlechter Satz in einem übersetzten Absatz wird von einer Nutzerin gelesen, möglicherweise von der Qualitätsbewertung einer AI Overview niedrig eingestuft, und trägt im schlimmsten Fall zu einer schleichenden Vertrauenserosion bei. Ein schlechtes Slug-Feld ist eine Routing-Änderung, die so lange anhält, bis jemand ein Link-Audit fährt. Die Kosten zahlen sich über Monate in der Google Search Console aus, nicht in einer einzelnen Lesesitzung.

Für ein Cluster verlinkter Pillar-Seiten in nicht-englischen Sprachversionen skalieren die Folgen mit der Dichte der internen Verlinkungen. Ein einziger falsch übersetzter Pillar-Slug bedeutet, dass jeder weitere Artikel im Cluster, der auf die kanonische URL zeigte, jetzt 404 liefert. Google sieht einen gerissenen Graphen: eine Pillar-Seite, indexiert unter einer URL, Dutzende eingehender interner Links auf eine Schwester-URL, die niemand ausliefert. PageRank zersplittert. Die thematische Autorität verdünnt sich zwischen der echten und der phantomhaften Adresse. Die nutzersichtbare Prosa bleibt gut, was genau das Problem ist: das Symptom ist von der gerenderten Seite aus unsichtbar.

Das ist der Abstand zwischen “99 Prozent genau” und “0 Prozent kaputt auf der Schicht, die zählt”.

#Wie die KI-Übersetzungspipeline in WordPress funktioniert und wo sie scheitert

Der Mechanismus ist banal und allen bekannt, die schon einmal einen Übersetzungs-Prompt geschrieben haben, der Frontmatter berührt:

1. Der Übersetzer bekommt die ganze Datei zu sehen: Frontmatter plus Body.
2. Der System-Prompt sagt: “Übersetze jede nutzersichtbare Zeichenkette in die Zielsprache.”
3. Dem Übersetzer wird (korrekt) gesagt, dass er title, description, seo.title, FAQ-Fragen und -Antworten und den Body übersetzen soll.
4. Dem Übersetzer wird (korrekt) gesagt, dass er wpId, pubDate, heroImage nicht übersetzen soll.
5. Das slug-Feld fällt in eine Grauzone. Der Übersetzer sieht: Der Slug sieht deutsch aus, weil die Datei sentence-case-Slugs verwendet, die wie Satzanfänge wirken. Er entscheidet, “compliance” in einem deutschen Slug sei ein englisches Lehnwort und gehöre zu “Konformität” - die Zielsprache der Prosa ist schließlich Deutsch. Er tut das scheinbar Richtige. Niemand hat ihm gesagt, dass das slug-Feld eine Routing-Kennung ist, kein Text für die Leserin.

Ein klügerer Satz-Übersetzer kann das nicht beheben. Die Lösung besteht darin, das Feld aus dem Input des Übersetzers zu nehmen. Im Werkzeug sollte das Frontmatter in Felder, in die der KI-Übersetzer schreiben darf, und Felder, die nur lesbar sind, aufgespalten werden. slug, force_slug, canonicalUrl, redirect_from und Taxonomie-Begriffe gehören in die nur-lesbare Gruppe.

In einem System mit ordentlichem Schema ist das eine einmalige Engineering-Investition. In einem typischen Werkzeug, das die ganze Datei in den Prompt klebt - und das sind die meisten heutigen Produktiv-Tools für KI-Übersetzung - ist es strukturell unmöglich.

#Wie Sie mehrsprachiges WordPress vor KI-Slug-Drift schützen

Sind die strukturellen Felder einmal geschützt, bleibt das Restrisiko, dass Diakritika anderswo einsickern: in Body-Links, in Strukturdaten-Quellen, in Hreflang-Verweise. Die Verteidigung ist ein einseitiges Pre-Publish-Audit-Skript, pro Sprachversion ausgeführt. Die Regel ist klar: ein Latin-Extended-Diakritikum, das nach einem Übersetzungslauf in einem URL-Feld auftaucht, ist fast immer eine Regression. Jede Sprachversion bekommt ihr eigenes Regelset - die norwegische Variante (ø, æ, å) akzeptiert mehr Diakritik-Oberfläche als die deutsche, die spanische (á, é, í, ó, ú, ñ) ist anders gestaltet, die portugiesische ç/ã/õ-Klasse wieder anders.

Das ist kein Engineering-Glanzstück. Es ist ein Regex pro Sprachversion und ein Build-Gate, das den Deploy fallenlässt, wenn die Anzahl der Diakritika in URL-Feldern über eine bekannte Baseline steigt. Der Grund, warum die meisten produktiven mehrsprachigen WordPress-Sites dieses Gate nicht haben, ist prosaisch: das Symptom ist vom redaktionellen Dashboard aus unsichtbar. Bei NIS2-Kritikalitätspflichten und DSGVO-Auditpfaden ist genau das problematisch, weil unsaubere URLs in den Datenschutz- und Cookie-Bannern sich im Audit-Trail wiederfinden.

#WPML AI, TranslatePress AI, Weglot, Gato AI Translations: dasselbe strukturelle Problem

Die Produktseite von Gato AI Translations beschreibt den Wert als “übersetze jeden Post-Type, jede Taxonomie, jedes Custom-Field und jeden String mit KI”. Korrekt und nützlich. Es impliziert auch, dass Custom-Fields im Scope sind, womit slug-äquivalente Felder in eigenen Post-Types und URL-haltige Metadaten-Felder derselben Fehlerklasse ausgesetzt sind. Dieselbe Form gilt für WPML AI Translation, TranslatePress AI und Weglot AI: produktive Pipelines arbeiten standardmäßig mit Full-File-Input. Keine davon liefert ein Audit der strukturellen Integrität als Teil des Produkts mit.

Die Wettbewerbslogik, die Losoviz beschreibt (“wenn alle es tun, kommen Sie nicht voran”), unterschätzt das Risiko. Wenn alle es tun und niemand das strukturelle Audit fährt, driftet die durchschnittliche mehrsprachige WordPress-Site über Jahre hinweg still von der Integrität auf der Indexierungsschicht weg. Die nutzersichtbare Prosa bleibt gut. Der Graph verrottet.

#4 Schritte, damit KI-Übersetzung das mehrsprachige WordPress-SEO nicht zerlegt

Die Minimum-Viable-Verschiebung für jedes Team, das mehr als eine Sprachversion auf KI-Übersetzung betreibt:

1. Schützen Sie die strukturellen Felder. Slug, force-slug-Schalter, kanonische URLs, Quell-URLs für Weiterleitungen, Taxonomie-Begriffe und Hreflang-Verweise gehören in die Engineering-Pipeline, nicht in die Hand des Übersetzers. Unterstützt das Übersetzungstool keine Read-Only-Feldgruppe, behandeln Sie im Workflow das Frontmatter getrennt vom Body: übersetzen Sie den Body im KI-Tool, lassen Sie das Frontmatter unangetastet.
2. Fügen Sie dem Build-Gate eine Diakritika-Prüfung hinzu. Ein einzelner Regex pro Sprachversion, der bei jedem Pull Request mit mehrsprachigen Dateien läuft, fängt die ganze Fehlerklasse vor dem Deploy.
3. Behandeln Sie jede Slug-Änderung als Redirect-Ereignis. Jede Änderung an einem Slug-Feld, gewollt oder versehentlich, verlangt einen passenden 301-Eintrag in der Weiterleitungstabelle. Erzwingt der Build das nicht über einen Fehler bei fehlendem Redirect-Eintrag, kippen Slug-Änderungen aus KI-Übersetzung früher oder später indexierte URLs auf 404.
4. Messen Sie strukturelle Fehler, nicht nur Prosa-Genauigkeit. Eine Pipeline, die 99 Prozent Satzgenauigkeit ausliefert und gleichzeitig 5 Prozent Slug-Drift zwischen den Sprachversionen erzeugt, ist auf der einzig relevanten Metrik schlechter als eine Pipeline mit 95 Prozent Satzgenauigkeit und null Slug-Drift.

#KI-Übersetzung in WordPress 2026: wo die Kosten tatsächlich liegen

Losoviz hat recht damit, dass KI-Übersetzung die Genauigkeit auf Satzebene zur Massenware gemacht hat und dass “rennen, um auf der Stelle zu bleiben” die neue Wettbewerbsbasis ist. Die Polemik ist, dass die 99-Prozent-Marke als Qualitätsdecke gelesen wird, während die tatsächliche Decke die strukturelle Integrität auf der Routing- und Indexierungsschicht ist. Das ganze Kostenpaket lebt in diesem einen Prozent. Und dieses eine Prozent ist operative Hygiene, nicht bessere KI.

Für die Agentur oder das in-house Team, das eine mehrsprachige WordPress-Site betreibt, ist das der Moment, in die strukturelle Schicht zu investieren, weil die Kosten der reinen KI-Übersetzung so weit gefallen sind, dass die relativen Kosten der strukturellen QA inzwischen die größte Position im mehrsprachigen Betriebsbudget sind. Das Preismodell für solche Audits ist individuell und hängt vom Umfang des Clusters ab. Der nächste Pitch-Slot eines Anbieters heißt “KI-Übersetzung plus Audit der strukturellen Integrität”, nicht “KI-Übersetzung, 99 Prozent genau”.

#Quellen

• Leonardo Losoviz im WP Tavern Jukebox (Transkript via WP Tavern)
• Produktseite Gato AI Translations
• WPML AI Translation, TranslatePress AI, Weglot AI: produktive Tool-Seiten
• W3C-Internationalisierungsleitlinien zum URL-Design über Sprachversionen hinweg

#Verwandt

• GEO- und LLMO-Optimierung
• Headless WordPress auf Astro
• Cloudflare Edge für WordPress und WooCommerce