WPML-Links zeigen auf die falsche Sprache – ein Praxisfall

Eigentlich sollte es ein überschaubares Aufräumprojekt werden. Ein Kunde betreibt einen WooCommerce-Shop auf Deutsch, Englisch und Spanisch, übersetzt mit WPML. Über die Jahre hatten sich in den Inhalten jede Menge interne Links angesammelt, die nur noch über 301-Weiterleitungen funktionierten. Die wollte ich programmatisch durch das richtige Ziel ersetzen. Mehr nicht.

Bei der ersten Inventur kam dann etwas ganz anderes zum Vorschein: 4.703 Links in englischen und spanischen Inhalten führten am Ende auf eine deutsche Seite. Dazu kamen 7.217 Links in einer Form, die in einem sauberen Shop gar nicht vorkommen sollte: /?product_cat=produktname. Jeder einzelne davon stand in einer Übersetzung, kein einziger im deutschen Original. Und genau da wurde es interessant.

In diesem Beitrag geht es um dieses WPML-Problem: warum die Links in den Übersetzungen auf die falsche Sprache zeigten, warum das WPML-eigene Werkzeug alles schlimmer gemacht hat und was am Ende wirklich geholfen hat. Die Bereinigung der übrigen 301-Weiterleitungen und 404-Links hat einen eigenen Beitrag: Interne 301- und 404-Links in WordPress per Bulk fixen.

Das Projekt in Zahlen

Punkt	Details
System	WordPress 6.9, WooCommerce 11.0, WPML Multilingual CMS 5.1 mit String Translation und WooCommerce Multilingual & Multicurrency 5.6
Übersetzung	WPML Advanced Translation Editor (ATE) mit DeepL
Theme	Flatsome mit Child-Theme, Inhalte zum großen Teil aus Shortcodes und UX-Blöcken
Sprachen	Deutsch (Standard), Englisch, Spanisch
Inhalte	1.793 Produkte, rund 830 Blogbeiträge, rund 280 Seiten, 900 UX-Blöcke
Interne Links	37.703 Link-Einbindungen in 3.420 Inhalten (erste Messung)
Problem	4.703 Links mit Sprachwechsel, 7.217 kaputte ?product_cat=-Links, nur in den englischen und spanischen Inhalten
Ergebnis	0 Sprachwechsel (bis auf 8 bewusste Ausnahmen), 0 ?product_cat=-Links, jeder Link einzeln geprüft
Zeitraum	Oktober 2026

Was war eigentlich das Problem mit den WPML-Links?

Für alle, die mit WPML noch nichts zu tun hatten: WPML ist ein Plugin, das WordPress mehrsprachig macht. Jede Seite, jedes Produkt und jeder Beitrag existiert dann pro Sprache als eigene Fassung, und WPML merkt sich, welche Fassungen zusammengehören. Damit das für Besucher funktioniert, muss ein Link auf einer englischen Seite auch auf die englische Fassung des Ziels zeigen.

Genau das hat in diesem Shop an tausenden Stellen nicht gestimmt. Die Fehler kamen in 2 Varianten vor:

1. Links in die falsche Sprache. Ein Link auf einer englischen oder spanischen Seite landete auf der deutschen Fassung, entweder direkt oder über eine Weiterleitung. Wer auf der englischen Produktseite auf eine Kategorie geklickt hat, war danach im deutschen Shop. Betroffen waren 4.703 Links in 700 Inhalten.
2. Links der Form ?product_cat=. product_cat ist bei WooCommerce die Produktkategorie. Ein solcher Link fragt also eigentlich eine Kategorie ab. In diesem Shop stand dahinter aber kein Kategoriename, sondern der Name eines Produkts. Der Shop hat diese Links per 301 auf eine Produktseite weitergeleitet, oft aber auf die falsche Sprachfassung und manchmal ins Leere.

So haben sich die 7.217 kaputten Kategorie-Links verteilt:

Was beim Klick passiert ist	Links
Umweg über 301, Ziel in der richtigen Sprache	2.922
Umweg über 301, Ziel in der falschen Sprache	4.238
Ziel existiert nicht (404)	57

Auffällig war, wo diese Links standen: ausschließlich in den englischen (3.120) und spanischen Inhalten (4.097). In den deutschen Originalen waren dieselben Produktlinks sauber. Irgendwo zwischen Original und Übersetzung ist also etwas schiefgelaufen. Bei 319 verlinkten Adressen hing der Parameter nach der Weiterleitung sogar noch an der Ziel-URL.

Eine Besonderheit des Shops wird später noch wichtig: Produkte und Produktkategorien teilen sich dieselbe URL-Basis. Ein Produkt liegt unter /basis/produktname/, eine Kategorie unter /basis/kategorie/, und ein eigener Filter im Theme entscheidet, was gemeint ist. Das ist bewusst so gebaut und soll auch so bleiben.

Warum fällt so etwas niemandem auf?

Ganz einfach: Für Besucher funktioniert ja alles. Der Browser folgt einer Weiterleitung still, die Seite lädt, fertig. Dass zwischendurch eine 301 im Spiel war, sieht niemand. Und dass man auf der deutschen statt auf der englischen Seite gelandet ist, merkt man im Zweifel erst beim Lesen.

Auch ein normaler Crawler folgt der Weiterleitung und meldet am Ende brav eine 200. Ob das Ziel die richtige Sprache hat, steht nämlich in keinem Statuscode.

Für die Suchmaschine ist das ein Problem, aber ein anderes, als man vielleicht denkt. Eine einzelne 301 kostet wenig, Google gibt darüber den Großteil der Signale weiter. Schwerer wiegt die Sprache. Jede Seite gibt über hreflang (eine Angabe im Seitenkopf, welche URL welche Sprachfassung ist) an, wo ihre englische und spanische Fassung liegt. Wenn die interne Verlinkung gleichzeitig tausendfach in eine andere Sprache zeigt, widerspricht sich die Website selbst. Dazu kommen Umwege beim Crawling und Besucher, die beim Klicken unfreiwillig die Sprache wechseln.

Hilft das WPML-Werkzeug „Interne Links aktualisieren“?

WPML bringt selbst ein Werkzeug mit, das dafür gedacht ist: interne Links in Übersetzungen auf die passende Sprachfassung umstellen. Der naheliegende erste Schritt war, das einmal laufen zu lassen. Ich wollte allerdings wissen, was es konkret tut, und nicht nur, ob danach alles „irgendwie besser“ aussieht. Deswegen lief der Test mit Backup und mit einem Export der Inhalte vorher und nachher, damit sich jede einzelne Änderung vergleichen lässt.

Das Ergebnis war eindeutig, nur eben nicht im gewünschten Sinn:

• 75 Inhalte wurden geändert, mit 3.530 ersetzten Links.
• 3.516 davon waren vorher in Ordnung, also direkt erreichbar und in der richtigen Sprache. Danach waren es ?product_cat=-Links mit 301. Das Werkzeug hat damit genau den Fehler erzeugt, den es beheben sollte.
• Nur 1.701 dieser Links landeten nach der Weiterleitung überhaupt noch auf derselben Seite wie vorher.
• 9 neue Sprachfehler kamen dazu.
• Repariert hat das Werkzeug 12 Links.
• Ein Link zeigte danach auf ein internes Theme-Template, das Besucher nie zu sehen bekommen sollten.

Das Backup ging sofort zurück, und ein neuer Export hat bestätigt, dass der Ausgangszustand wiederhergestellt war. Eine Stolperfalle gibt es dabei: Bei einem Shop ist das Einspielen eines Backups nie ganz ohne, weil alles, was zwischen Sicherung und Wiederherstellung passiert (z.B. neue Bestellungen), danach fehlt. Das Zeitfenster sollte deswegen so kurz wie möglich sein.

Für diesen Shop ist das Werkzeug seitdem tabu. In dieser Konstellation mit gemeinsamer URL-Basis für Produkte und Kategorien richtet es mehr Schaden an, als es behebt.

Was sagt der WPML-Support dazu?

Bevor es an die eigentliche Bereinigung ging, habe ich ein Ticket beim WPML-Support aufgemacht. Kurz, auf Deutsch, mit allen Versionen, Live-Beispielen und 3 Punkten: Links in Übersetzungen zeigen auf die falsche Sprache, Links sind als ?product_cat= kaputt, und das WPML-Werkzeug hat es schlimmer gemacht.

Eine Vermutung zur Ursache habe ich bewusst weggelassen. Der Verdacht lag zwar nahe, dass die gemeinsame URL-Basis dahintersteckt. Wer dem Support die Ursache aber gleich mitliefert, bekommt im Zweifel diese Vermutung bestätigt, statt dass jemand unvoreingenommen prüft. Eine Antwort auf das Ticket gibt es bis heute nicht (Stand: Oktober 2026).

Der WPML-Support-Bot und seine Theorie

Parallel habe ich mit dem KI-Support-Bot von WPML gechattet. Der war hilfreicher als erwartet, zumindest teilweise. Seine Erklärung: Beim Speichern einer Übersetzung wandelt WPML interne Links zuerst in eine interne Form um und danach in die URL der Zielsprache zurück. Für Kategorien lautet diese interne Form ?product_cat=. Kann WPML das Ziel nicht auflösen, bleibt sie einfach stehen. Das würde zumindest erklären, warum die kaputten Links so aussehen.

Als Ursache hat der Bot dann die Reihenfolge der Rewrite-Regeln vermutet, also im Kern die gemeinsame URL-Basis: Die Regel für Kategorien greift vor der für Produkte, dadurch werde ein Produktlink als Kategorie gelesen. Klingt plausibel. Ich habe es trotzdem getestet:

• Eine englische Seite im Übersetzungseditor mit DeepL neu übersetzt und gespeichert: Der Link stand danach korrekt auf Englisch.
• Im normalen Backend-Editor einen deutschen Produktlink in eine spanische Seite eingefügt und gespeichert: Er zeigte danach auf das spanische Produkt.
• Derselbe Test ohne den Code, den der Bot als Lösung vorgeschlagen hatte: ebenfalls korrekt.

Damit war die Theorie widerlegt, und das hat der Bot auch eingeräumt. Neue Speichervorgänge erzeugen saubere Links, trotz gemeinsamer Basis. Woher die alten ?product_cat=-Links kommen, ist bis heute ungeklärt.

Eine zweite Erkenntnis aus den Tests: Die Übersetzungen einfach noch einmal zu speichern, bringt nichts. Die alten Links bleiben stehen, weil es nämlich keine Kategorie mit dem Produktnamen gibt, auf die WPML sie auflösen könnte.

Der naheliegende Rat wäre jetzt gewesen, Produkte und Kategorien auf getrennte URL-Basen zu legen. Das kam nicht infrage. Die Struktur ist so gewollt, und nach den Tests war nicht einmal klar, ob sie überhaupt die Ursache ist.

Brauchbar war trotzdem, was der Bot geliefert hat: ein Skript, das die kaputten Links direkt in der Datenbank auf die richtige Produktseite in der Sprache des jeweiligen Beitrags umschreibt, ohne Umweg über das WPML-Speichern. Damit habe ich die ersten Trockenläufe gemacht. Und dann begann die eigentliche Arbeit.

Wie lief die Bereinigung der WPML-Links?

Das Skript vom Bot war für Stapel von 50 Beiträgen pro Aufruf gedacht. Bei über 860 betroffenen Beiträgen wäre das eine lange Klickstrecke geworden. Die Frage war also: Ist eine Automatisierung mit Fortschrittsanzeige riskanter als 50 Beiträge pro Klick? Nein. Das Risiko liegt nicht darin, wie viele Beiträge auf einmal laufen, sondern in der Ersetzungslogik. Und die war durch die Trockenläufe bestätigt.

Bewährtes zuerst, Sonderfälle später

Beim Durchsehen des Bot-Skripts sind ein paar Lücken aufgefallen. 17 Links blieben ungelöst, weil Produkt-Slugs (also die URL-Namen der Produkte) mit Zoll-Zeichen in der Datenbank nämlich URL-kodiert gespeichert sind. 36 weitere blieben offen, obwohl das richtige Ziel bekannt war. Dazu wurde kein Cache geleert, und eine Möglichkeit zum Rückgängigmachen gab es auch nicht.

Das alles hätte ich gleich mit einbauen können. Habe ich aber bewusst nicht. Die Logik des Bots war getestet, also habe ich sie 1:1 übernommen und nur das drumherum gebaut, was die Sicherheit erhöht: Fortschrittsanzeige, Sicherung jedes Beitrags, Rückgängig-Knopf und Cache-Leerung am Ende. Die Sonderfälle kamen erst in späteren Läufen dran, denn es muss nicht alles auf einmal funktionieren. Wichtig ist, dass das, was läuft, sicher läuft.

Ergebnis des ersten Laufs: 7.160 ersetzte Links, 55 bekannte Fälle offen, 0 Fehler. Der Vergleich mit einem neuen Export hat gezeigt, dass sich ausschließlich die erwarteten Links geändert haben.

Die richtige Sprache für jedes Ziel

Damit waren die ?product_cat=-Links weitgehend erledigt, die Sprachwechsel aber noch nicht. Viele alte Links liefen über eine Weiterleitung, die zwar auf einer echten Seite endete, nur eben auf der deutschen. Von 781 Weiterleitungszielen, die man auf den ersten Blick einfach hätte übernehmen können, hatten 417 genau dieses Problem. Blind ersetzbar waren nur 364.

Das richtige Ziel habe ich deswegen pro Sprache bestimmt, und zwar über die hreflang-Angaben der Zielseiten selbst. Jede Seite sagt dort, wo ihre englische und spanische Fassung liegt. Für 4.381 von 4.397 betroffenen Links fand sich so die passende Sprachfassung, und jedes neue Ziel wurde live geprüft. Wo es schlicht keine Übersetzung gibt (z.B. bei einer Seite, die bewusst nur auf Deutsch existiert), blieb der Link vorerst stehen.

Genauso wichtig war die andere Seite: In welcher Sprache ist eigentlich der Beitrag, in dem der Link steht? Am Anfang habe ich das aus Slug und Text geschätzt. Das lag bei 8 Inhalten daneben, u.a. bei englischen Produkten mit deutschem Slug. Ab da kam die Sprache nur noch direkt aus WPML. Klingt banal, ist aber wichtig: Wer bei über 1.000 Ersetzungen pro Lauf auf eine Schätzung setzt, ersetzt im Zweifel sehr sauber in die falsche Richtung.

Ein paar weitere Dinge, die so eine Bereinigung fehleranfällig machen:

• Produkt-Slugs täuschen. Der Slug mit „s20-2020“ gehörte z.B. zum Galaxy S20+, der mit „s20-2020-2“ zum normalen S20. Wer nur nach dem Slug geht, verlinkt das falsche Gerät. Sicher zuordnen ließ sich das nur über den Produkttitel.
• Sonderzeichen ändern die Sprache. Einen Slug mit Zoll-Zeichen gab es in dieser Schreibweise nur beim spanischen Produkt. Ein Link mit diesem Slug unter der deutschen URL-Basis landete so auf der spanischen Seite.
• Links haben viele Formen. Sie standen nicht nur als normales href im HTML, sondern auch in Flatsome-Shortcodes, relativ oder absolut, mit http oder www. Jede Form musste beim Ersetzen erhalten bleiben, sonst ändert man mehr als nötig.

Im letzten großen Lauf kamen dann alle Sprachfälle zusammen: Weiterleitungen in die falsche Sprache, direkte Links aus englischen und spanischen Beiträgen auf deutsche Seiten und ein paar Sonderfälle wie Links mit typografischen Anführungszeichen im HTML. Am Ende waren das 1.268 Ersetzungen in 528 Beiträgen. Der Vergleich danach zeigte 0 Abweichungen von dem, was der Trockenlauf angekündigt hatte.

Das Sicherheitsnetz für Massenänderungen in der Live-Datenbank

Alle Änderungen liefen direkt in der Datenbank eines laufenden Shops. Ein Fehler wäre sofort online gewesen, und das bei bis zu 7.160 Links pro Lauf. Deswegen hatte jedes Werkzeug dasselbe Gerüst:

• Vorab eine Simulation gegen einen Export der Datenbank. Erst wenn die Zahlen stimmten, kam das Werkzeug überhaupt ins Backend.
• Ein Trockenlauf im Live-System war Pflicht. Der echte Lauf ließ sich erst danach starten, und erst mit der Bestätigung, dass ein frisches Datenbank-Backup existiert.
• Jeder Beitrag wurde vor der Änderung einzeln gesichert, mit einem Knopf zum Rückgängigmachen.
• Geschrieben wurde direkt in die Datenbank statt über das normale Speichern. Damit liefen keine WPML-Prozesse mit, es entstanden keine Revisionen, und das Änderungsdatum der Beiträge blieb unverändert.
• Am Ende jedes Laufs wurde der Cache von WP Rocket geleert, sonst sieht man im Frontend noch die alten Links.
• Danach ein neuer Export und ein Vergleich Byte für Byte. Jede Änderung musste exakt der geplanten entsprechen, und außerhalb der Liste durfte sich nichts geändert haben.

Wie viel dieses Netz wert ist, hat sich gleich zweimal gezeigt. Beim zweiten Lauf traf der Trockenlauf die Simulation auf die Zahl genau: 1.305 Ersetzungen, 308 übersprungene Links, 309 Beiträge. Beim letzten Lauf wich er um 44 Links ab. Der Grund war die falsch geschätzte Beitragssprache von oben, und der Trockenlauf mit der echten WPML-Sprache lag richtig. Aufgefallen ist das, bevor irgendetwas live ging. Mehr Kontrolle vor dem Klick, weniger Reparatur danach.

Wo Claude Code geholfen hat und wo nicht

In dem Projekt waren gleich 2 KIs beteiligt: der Support-Bot von WPML und Claude Code, ein KI-Assistent, der direkt auf dem Rechner mit Dateien, Datenbank-Exporten und Skripten arbeitet. Mit Claude Code habe ich die Inventur, die Live-Prüfungen, die Simulationen, die Werkzeuge und die Kontrollen nach jedem Lauf gebaut. Das hat das Projekt wirklich schneller gemacht: Zwischen dem ersten Datenbank-Export und der fertigen Live-Prüfung aller 2.932 verlinkten Adressen lagen z.B. keine 20 Minuten.

Die Entscheidungen hat die KI aber nicht getroffen. Ein paar Beispiele:

• Für einen leeren Link, dessen Ankertext nach Ratgeber klang, hat die KI ein Blog-Archiv als Ziel vorgeschlagen. Klingt passend, war aber falsch. Richtig war die Landingpage, die das Geschäftsmodell des Kunden erklärt. So etwas weiß man nur, wenn man den Shop kennt.
• Wann ein Weiterleitungsziel ohne weitere Prüfung übernommen werden darf, habe ich festgelegt. Ebenso, dass die Bot-Logik zuerst 1:1 läuft, statt alles auf einmal zu lösen.
• Bei den Warenkorb-Buttons (dazu gleich mehr) und bei der Frage, welche Seiten bewusst nur auf Deutsch bleiben, ging es um Geschäftsentscheidungen und nicht um Technik.
• Die Theorie des WPML-Bots haben meine Tests im Backend widerlegt.
• Und die KI hat auch Fehler gemacht. Einer fiel erst im Abschlusstest auf: Leere Links landeten durch einen Programmierfehler in der falschen Fehlerkategorie. Gefunden, korrigiert, weiter.

Meine Erfahrung daraus: Ein KI-Assistent ist bei so einem Projekt keine Wunderwaffe, aber ein enormer Hebel. Vorausgesetzt, jemand gibt die Regeln vor, prüft jedes Ergebnis gegen und trifft die fachlichen Entscheidungen selbst. Gerade bei Massenänderungen in einer Live-Datenbank ist das keine Formsache. Die KI hat in diesem Projekt jede Menge Code geschrieben. Ob dieser Code das Richtige tut, hat jedes Mal ein Trockenlauf, eine Simulation oder ein Vergleich gezeigt und nicht das Gefühl, dass es schon passen wird.

Der Abschlusstest – jeder Link einzeln, 3 Prüfungen

Nach den Fixes wollte ich es genau wissen. Der Abschlusstest hat nicht mehr nach eindeutigen Adressen zusammengefasst, sondern jede einzelne Link-Einbindung so geprüft, wie sie im Inhalt steht. Für jede gab es 3 Fragen:

1. Ist das Ziel direkt erreichbar, also Status 200 ohne Weiterleitung, ohne verstecktes 404 und ohne Umweg per Meta-Refresh?
2. Passt die Sprache des Links, so wie er geschrieben ist, zur Sprache des Beitrags?
3. Landet der Klick wirklich auf einer Seite in der Beitragssprache? Geprüft über die Sprachangabe der Zielseite selbst, nicht über die URL.

Punkt 3 klingt doppelt, ist es aber nicht. Eine URL mit /en/ kann trotzdem auf eine deutsche Seite weiterleiten. Genau das war bei der englischen Adresse der Datenschutzerklärung der Fall, die auf die deutsche Fassung zeigte.

Damit der Test selbst nicht danebenliegt, liefen vorab 10 Kontroll-URLs mit bekanntem Ergebnis mit. Wird eine davon falsch erkannt, bricht der Test ab. Jede Anfrage lief außerdem ohne Cookies, damit kein Sprach-Cookie von WPML das Ergebnis verfälscht. Und eine Stichprobe von 1.000 Links wurde zusätzlich einzeln abgerufen: 1.000 von 1.000 identisch.

Was der erste Abschlusstest noch gefunden hat

Der erste Durchlauf über 44.396 Einbindungen hat einiges gefunden, was die vorherigen Prüfläufe nicht gesehen hatten:

• 30 leere Links (href="") in 8 englischen Blogbeiträgen. Linktext vorhanden, Ziel nicht.
• 10 Links auf Produkt-IDs, deren Schreibweise mit & die erste Inventur nicht richtig gelesen hatte. Dahinter steckten u.a. Entwürfe und eine ID, die es gar nicht gibt.
• 48 Links in falscher Sprache, die meisten davon auf Seiten ohne Übersetzung.
• 3 kaputte Telefonlinks und 3 Links mit http bzw. www.

Dazu kamen 6.547 Warenkorb-Buttons in statisch gespeicherten Produktkacheln. Sie zeigen auf eine Schnittstelle, die ohne Anmeldung mit 401 antwortet. Für Besucher funktionieren die Buttons per JavaScript ganz normal, und die Adresse ist per robots.txt ohnehin gesperrt. SEO-technisch ist das kaum relevant, deswegen habe ich sie im Test ausgeklammert.

Für den Rest gab es einen kleinen Nachtrag mit 125 Ersetzungen in 93 Beiträgen. Dabei kamen auch ein paar inhaltliche Entscheidungen dazu. Eine fehlende spanische Seite wurde übersetzt, und die Datenschutzerklärung bleibt bewusst nur auf Deutsch (im Test gilt sie als Ausnahme). Links auf einen Bereich, der ohnehin zusammengelegt werden sollte (inzwischen ist das passiert), sind gleich ganz rausgeflogen. Sonst hätte man in ein paar Monaten wieder dieselben Weiterleitungen in den internen Links.

Und dann hat WPML wieder einen Link kaputt gemacht

Während der Nachtrag vorbereitet wurde, habe ich die fehlende spanische Seite veröffentlicht. WPML hat daraufhin von sich aus 17 spanische Seiten angepasst, die bisher auf die deutsche Fassung verlinkt hatten. An sich richtig so. Der Trockenlauf meines Werkzeugs hat das auch sofort gemeldet, weil die 17 Links, die es ersetzen sollte, schon nicht mehr da waren.

Beim Vergleich der Exporte vor und nach dem Lauf fiel dann aber eine Abweichung auf. In einer spanischen FAQ-Seite hatte WPML bei der Gelegenheit einen korrekten Produktlink umgeschrieben. Vorher zeigte er direkt auf das spanische Produkt, danach stand dort ein ?product_cat=-Link mit 301. Also genau der Fehler, um den sich das ganze Projekt dreht, frisch von WPML selbst erzeugt. Weil das Änderungsdatum der Seite dabei gleich blieb, wäre das ohne den Vergleich niemandem aufgefallen.

Auf Nachfrage hat der WPML-Bot den Prozess benannt: den WPML Link Target Adjuster. Er läuft beim Veröffentlichen einer Übersetzung, geht Beiträge durch, deren Links noch nicht als verarbeitet markiert sind (bis zu 10 pro Aufruf), und schreibt direkt in den Inhalt, weshalb sich auch kein Datum ändert. Der Bot selbst nannte das „kein normales oder sicheres Verhalten“. Warum dabei ausgerechnet ein ?product_cat=-Link entsteht, konnte er nicht sagen. Eine Einstellung, um das abzuschalten, auch nicht.

Den einen Link habe ich von Hand korrigiert und geprüft. Die eigentliche Lehre ist eine andere: Bereinigte Links bleiben bei WPML nicht zwingend bereinigt. Jede neu veröffentlichte Übersetzung kann bestehende Inhalte wieder verändern, ohne dass es irgendwo sichtbar wird. Meine Empfehlung für den Shop ist deswegen, nach jeder neuen Übersetzung den Test noch einmal laufen zu lassen, was ca. 7 Minuten dauert.

Was hat die Bereinigung am Ende gebracht?

Kennzahl	Vorher (8. Oktober)	Nachher
Interne Links, die nicht direkt erreichbar sind (Umweg, 404, Datei)	9.449 von 37.703 (25,1 %)	0 von 37.792
Links mit Sprachwechsel von EN/ES nach DE	4.703	0 (plus 8 bewusste Ausnahmen)
?product_cat=-Links	7.217	0

Zur Einordnung: Der zweite Abschlusstest zeigte noch 1 Fehler, nämlich den WPML-Rückfall von oben, und den habe ich danach von Hand behoben. Die 6.547 Warenkorb-Buttons sind in den 37.792 Links nicht enthalten. Außerdem war der Abschlusstest strenger als die erste Messung, weil er jede Schreibweise einzeln zählt und auch Datei-Links, leere und relative Links prüft. Die Nachher-Zahlen sind also eher streng gerechnet als geschönt.

Was das für die Rankings bedeutet, lässt sich heute noch nicht sagen. Dafür ist es schlicht zu früh. Vor dem Projekt habe ich eine kleine Baseline aus der Search Console gezogen, damit sich nach 4-6 Wochen sauber vergleichen lässt.

Einen großen Sprung allein durch weniger Weiterleitungen erwarte ich ehrlich gesagt nicht, weil Google über eine 301 den Großteil der Signale weitergibt. Der wichtigere Effekt dürfte die sprachkonsistente Verlinkung sein: keine Widersprüche mehr zu den hreflang-Angaben, weniger Umwege beim Crawling und keine Besucher, die beim Klicken die Sprache wechseln.

Einen ersten Hinweis liefert ein Plugin, das die interne Link-Equity auswertet. Die Hauptkategorien liegen dort in allen 3 Sprachen fast gleichauf, z.B. mit 208, 207 und 187 eingehenden Links für dieselbe Kategorie auf Deutsch, Englisch und Spanisch. Das passt zu den Sprachkorrekturen, beweisen lässt es sich allerdings nicht, weil das Plugin keinen Vorher-Stand hat.

Was dabei sonst noch aufgefallen ist

Bei so einer Inventur sieht man zwangsläufig mehr als das, wonach man gesucht hat. Ein paar Befunde, die direkt mit der Mehrsprachigkeit zu tun haben:

• Maschinell übersetzte Produkttitel, die danebenliegen: Aus „Rift“ wurde auf Spanisch „Grieta“, aus „Galaxy A54“ wurde „Galaxia A54“. Übersetzt wurden damit auch Produktnamen, die gar nicht übersetzt werden sollten.
• Deutsche Ankertexte in englischen und spanischen Inhalten, z.B. „Monitor (27 Zoll)“.
• 2 spanische Seiten mit einem Canonical, das auf die englische bzw. deutsche Fassung zeigt. Das widerspricht wieder den hreflang-Angaben.
• 1.084 von 3.108 URLs aus der Sitemap bekommen keinen einzigen Link aus dem Inhalt. Englische und spanische Produkte sind davon ungefähr 3-mal so oft betroffen wie deutsche.

Diese Punkte stehen jetzt auf der Liste und zeigen gut, dass Mehrsprachigkeit mehr ist als übersetzte Texte. Die Struktur dahinter muss in jeder Sprache genauso stimmen.

Kann man WPML bei internen Links also trauen?

Jein. Neue Übersetzungen haben in diesem Shop saubere Links erzeugt, das haben die Tests klar gezeigt. Für neue Inhalte ist das eine gute Nachricht.

Gleichzeitig gab es 3 Stellen, an denen WPML die Lage nicht verbessert, sondern verschlechtert hat. Erstens die Altlast von 7.217 kaputten Links, deren Herkunft niemand erklären konnte. Zweitens das eigene Werkzeug „Interne Links aktualisieren“, das 3.516 saubere Links kaputt gemacht und 12 repariert hat. Und drittens der Link Target Adjuster, der bereinigte Links beim Veröffentlichen einer Übersetzung wieder umschreiben kann, ohne dass sich ein Datum ändert. Eine Antwort auf das Support-Ticket gibt es bis heute nicht.

Unterm Strich heißt das für mich: Bei einem mehrsprachigen WooCommerce-Shop mit WPML verlasse ich mich nicht auf die Bordmittel, sondern prüfe die interne Verlinkung selbst. Der Maßstab ist dabei nicht der Status am Ende einer Weiterleitung. Der Maßstab ist, ob jeder Link direkt und in der richtigen Sprache ankommt.

2 Dinge würde ich beim nächsten Mal anders machen. Erstens die Sprache jedes Beitrags von Anfang an aus WPML nehmen, statt sie zu schätzen. Das hätte mir die Abweichung zwischen Simulation und Trockenlauf erspart. Zweitens den strengen Test, der jede Einbindung einzeln prüft, gleich als erste Messung nehmen. Der hat Fälle gefunden (leere Links, die Schreibweise mit &), die die erste Inventur schlicht übersehen hat.

Offen sind noch die Links außerhalb der Beitragsinhalte, also in Menüs, Widgets und Theme-Einstellungen, die nicht Teil dieser Prüfung waren. Und wie sich die Bereinigung auf die Rankings auswirkt, ergänze ich hier, sobald der Vergleich mit der Baseline steht.

Häufige Fragen zu WPML und internen Links

Warum zeigen interne Links in WPML-Übersetzungen auf die falsche Sprache?

In diesem Projekt gab es 2 Ursachen: alte Links, die über eine Weiterleitung auf der deutschen Fassung landeten, und Links, die als ?product_cat= in den Übersetzungen stehen geblieben waren. Neu gespeicherte Übersetzungen haben dagegen korrekte Links erzeugt. Woher die fehlerhaften Altlinks stammen, ist bis heute ungeklärt.

Warum werden Produktlinks in WPML zu ?product_cat=-Links mit 301?

Laut WPML-Support-Bot wandelt WPML interne Links beim Speichern einer Übersetzung in eine interne Form um und danach in die URL der Zielsprache zurück. Für Kategorien lautet diese Form ?product_cat=. Kann WPML das Ziel nicht auflösen, bleibt sie stehen. Der Shop leitet solche Links dann per 301 weiter, in diesem Fall oft auf die falsche Sprachfassung und in 57 Fällen ins Leere.

Repariert erneutes Speichern der Übersetzung die kaputten Links?

Hier nicht. Die alten ?product_cat=-Links blieben nach dem Speichern stehen, weil es keine Kategorie mit dem jeweiligen Produktnamen gibt, auf die WPML sie auflösen könnte. Repariert wurden sie erst durch eine gezielte Ersetzung in der Datenbank.

Hilft das WPML-Werkzeug „Interne Links aktualisieren“ gegen Links in der falschen Sprache?

In diesem Shop nicht. Es hat 3.516 vorher saubere Links in ?product_cat=-Links mit Weiterleitung verwandelt und nur 12 repariert. Wer es trotzdem testen will, sollte das nur mit Backup und einem Vergleich vorher und nachher tun.

Was ist der WPML Link Target Adjuster?

Ein WPML-Prozess, der beim Veröffentlichen einer Übersetzung Links in anderen Beiträgen auf die neue Sprachfassung umstellt. Er schreibt direkt in den Inhalt, das Änderungsdatum bleibt gleich. In diesem Projekt hat er in 17 Seiten einen Link korrekt umgestellt und dabei einen korrekten Produktlink wieder zu einem ?product_cat=-Link gemacht.

Muss man bei WooCommerce die URL-Basis von Produkten und Kategorien trennen, damit WPML funktioniert?

In diesem Projekt war die gemeinsame Basis der naheliegende Verdacht. Die Tests haben ihn aber nicht bestätigt: Neue Links wurden trotz gemeinsamer Basis korrekt gesetzt. Getrennt wurde hier nichts, weil die Struktur so gewollt ist.

Sind interne Links über 301-Weiterleitungen schlecht für SEO?

Eine einzelne 301 kostet wenig, weil Google darüber den Großteil der Signale weitergibt. Bei mehrsprachigen Seiten wird es zum Problem, wenn die Weiterleitung in der falschen Sprache endet. Dann widerspricht die interne Verlinkung den hreflang-Angaben, und Besucher wechseln beim Klick die Sprache. Was das Entfernen interner 301-Weiterleitungen ohne Sprachbezug bringt, steht im Praxisfall zu 2.232 veralteten internen Links.