Häufige hreflang-Fehler in mehrsprachigem WordPress

Warum hreflang in WordPress so oft kaputtgeht

Hreflang hängt von einem vollständigen Satz wechselseitiger Sprach-URLs ab. In WordPress wird dieser Satz meist aus Inhaltsbeziehungen, Permalink-Strukturen und dem System zusammengesetzt, das die Sprachzuordnung speichert. Wenn sich irgendein Teil dieser Kette ändert, ohne die anderen zu aktualisieren, beschreiben die Alternativen nicht mehr denselben Inhaltsbestand.

Deshalb sind viele Fehler nicht als defekte Seiten sichtbar. Die Seite lädt weiterhin, aber Suchmaschinen erhalten widersprüchliche Signale: Eine URL sagt, sie sei die englische Version, eine andere verweist auf einen anderen Slug, und eine dritte Version ist möglicherweise nicht mehr indexierbar oder wird anderswo kanonisiert. Das Ergebnis ist ein Beziehungsproblem, nicht nur ein Markup-Problem.

Fehlende Rückverweise

Ein hreflang-Satz muss wechselseitig sein. Wenn die französische Seite auf die englische Seite verweist, muss die englische Seite auf die französische Seite und auf jede andere gültige Alternative im Satz zurückverweisen.

In WordPress scheitern Rückverweise oft, wenn eine Übersetzung später veröffentlicht wird, wenn eine Vorlage Alternativen nur bei bestimmten Beitragstypen ausgibt oder wenn eine Sprachbeziehung nur in eine Richtung besteht. Dadurch entsteht ein unvollständiger Graph: Suchmaschinen sehen zwar, dass eine Seite Alternativen behauptet, können den vollständigen Satz aber nicht von jedem Mitglied aus verifizieren.

Die operative Folge ist, dass ein fehlender Rückverweis den gesamten Cluster schwächen kann. Das Problem ist besonders leicht zu übersehen, wenn Inhaltsredakteure nur eine Sprachversion aktualisieren und annehmen, die Beziehung sei weiterhin intakt.

Falsche Sprach- oder Gebietsschema-Zuordnungen

Ein häufiger Fehler ist die Verwechslung von Sprachcodes, regionalen Varianten oder Website-Bezeichnungen. Der hreflang-Wert muss die tatsächliche Sprach- oder Sprach-Region-Zielversion beschreiben, nicht das Menülabel oder die interne Benennungskonvention der Website.

In WordPress tritt das oft auf, wenn eine Website mehrere englische Varianten hat oder wenn einer Übersetzung nach einer Inhaltsmigration die falsche Gebietsschema-Beziehung zugewiesen wird. Die Seite kann vollständig übersetzt sein, aber wenn die Zuordnung die falsche Sprache oder Region angibt, wird das Signal irreführend.

Das ist wichtig, weil hreflang dazu dient, eng verwandte Versionen zu unterscheiden. Ist die Zuordnung falsch, können Suchmaschinen die falsche Seite als beste Übereinstimmung für die Sprache oder Region eines Nutzers behandeln, obwohl der Inhalt selbst korrekt ist.

Inkonsistente URL-Sätze über Sprachversionen hinweg

Jede Seite in einem hreflang-Cluster sollte auf denselben Satz von Alternativen verweisen. Wenn die englische Seite Englisch, Französisch und Deutsch auflistet, die deutsche Seite aber nur Deutsch und Englisch, ist der Satz inkonsistent.

Das passiert meist, wenn Sprachbeziehungen manuell gepflegt werden, wenn eine Vorlage über Beitragstypen mit unterschiedlicher Übersetzungsabdeckung hinweg wiederverwendet wird oder wenn einige Seiten aus der alternativen Ausgabe ausgeschlossen werden, weil keine passende Übersetzung vorhanden ist. Das Problem ist nicht nur, dass eine URL fehlt; vielmehr beschreibt der Cluster keinen stabilen, gemeinsamen Satz mehr.

Für WordPress-Implementierer ist die praktische Frage, ob die Alternativenliste aus der aktuellen Inhaltsbeziehung abgeleitet oder pro Vorlage fest codiert ist. Fest codierte Listen driften, sobald eine Übersetzung hinzugefügt, entfernt oder unveröffentlicht wird.

Nicht indexierbare Ziele

Hreflang sollte auf URLs verweisen, die Suchmaschinen indexieren können. Wenn ein Ziel blockiert, auf noindex gesetzt, nicht verfügbar oder aus anderen Gründen nicht indexierbar ist, kann es nicht als verlässliche Alternative dienen.

In WordPress kann das passieren, wenn eine übersetzte Seite noch im Entwurf ist, geschützt, durch Website-Einstellungen ausgeschlossen oder über eine Route ausgeliefert wird, die nicht indexiert werden soll. Es kann auch passieren, wenn eine Übersetzung im Inhaltssystem existiert, die öffentliche URL aber tatsächlich nicht erreichbar ist.

Der Fehler ist subtil: Die Beziehung sieht im CMS vollständig aus, aber das Ziel kann nicht an der Suchindexierung teilnehmen. Das bedeutet, dass das hreflang-Signal auf eine Seite verweist, die ihre Rolle im Cluster nicht erfüllen kann.

Weiterleitungen innerhalb des hreflang-Satzes

Hreflang sollte auf die endgültige, kanonische Ziel-URL verweisen und nicht auf eine URL, die sofort weiterleitet. Weiterleitungen fügen eine weitere Interpretationsebene hinzu und können verschleiern, welche URL die Sprachversion repräsentieren soll.

In WordPress treten Weiterleitungen oft nach Permalink-Änderungen, Slug-Aktualisierungen oder sprachspezifischen Routing-Anpassungen auf. Wenn die hreflang-Ausgabe weiterhin die alte URL verwendet, verweist die Beziehung auf ein bewegliches Ziel. Wenn sich die Weiterleitungskette später ändert, kann sich der hreflang-Satz stillschweigend verschlechtern.

Der technische Kompromiss ist klar: Weiterleitungen sind nützlich, um alte Links zu erhalten, aber hreflang sollte auf den stabilen Ziel-URLs gepflegt werden. Andernfalls driften Sprachgraph und Routing-Ebene auseinander.

Canonical-Konflikte

Eine hreflang-URL und ihr Canonical-Signal müssen sich darüber einig sein, welche Seite den Inhalt repräsentiert. Wenn eine übersetzte Seite auf eine andere Sprachversion kanonisiert, stehen die Signale im Widerspruch.

Das kann passieren, wenn die Canonical-Logik von einer Vorlage übernommen wird, wenn eine plugin-eigene Datenebene Alternativen ausgibt, das Theme oder die SEO-Ebene aber ein anderes Canonical ausgibt, oder wenn eine Inhaltsbeziehung von einer Sprache in eine andere kopiert wird, ohne das Canonical-Ziel anzupassen. Das Ergebnis ist, dass ein System sagt: „Das ist die französische Seite“, während ein anderes sagt: „Die englische Seite ist die bevorzugte Version.“

Dieser Konflikt kann hreflang weniger vertrauenswürdig machen, weil Suchmaschinen zwei konkurrierende Anweisungen zur selben URL erhalten. Das sicherste Muster ist Konsistenz: Jede indexierbare Sprachseite sollte auf sich selbst kanonisieren, sofern es keinen bewussten, dokumentierten Grund gibt, dies nicht zu tun.

Veraltete Beziehungen nach Inhaltsänderungen

Inhaltsänderungen in WordPress erhalten Sprachbeziehungen nicht immer automatisch. Eine Slug-Änderung, das Löschen einer Übersetzung, das Duplizieren eines Beitrags oder das Zusammenführen von Inhalten kann veraltete Verweise in Beitrags-Metadaten, benutzerdefinierten Feldern oder plugin-eigenen Beziehungsdaten hinterlassen.

Das ist einer der häufigsten Langzeitfehler, weil die Website beim Start korrekt gewesen sein kann. Im Laufe der Zeit aktualisieren Redakteure eine Sprache, verschieben eine Seite oder nehmen eine Übersetzung aus dem Verkehr, aber der Alternativsatz wird nicht neu aufgebaut. Die hreflang-Ausgabe bewirbt dann URLs, die nicht mehr zusammengehören.

Das operative Risiko ist kumulativ. Je häufiger sich Inhalte ändern, desto wahrscheinlicher wird der Sprachgraph teilweise veraltet, sofern das System die Beziehungen nicht aus der aktuellen Quelle der Wahrheit neu generiert.

Wie diese Fehler in WordPress meist auftreten

Die meisten hreflang-Probleme in WordPress entstehen durch eine Diskrepanz zwischen Inhaltszustand und Ausgabestatus. Das CMS weiß möglicherweise, welche Beiträge Übersetzungen sind, aber die gerenderte Seite, das Canonical-Tag, die Weiterleitungsebene oder die Permalink-Struktur spiegeln diese Beziehung möglicherweise nicht mehr wider.

Deshalb sollten Implementierer in Abhängigkeiten denken: Die Übersetzungsbeziehung, die öffentliche URL, die Indexierbarkeit des Ziels und das kanonische Ziel müssen alle übereinstimmen. Wenn sich eine Ebene ändert, ohne dass die anderen mitziehen, wird der hreflang-Cluster inkonsistent, selbst wenn das Markup syntaktisch gültig ist.