So implementieren Sie hreflang-Tags für mehrsprachiges WordPress
Sie haben Ihre gesamte WordPress-Website in sechs Sprachen übersetzt. Die .po-Dateien sind sauber, die .mo-Dateien sind kompiliert, jede Zeichenkette wird perfekt in Französisch, Deutsch und Japanisch angezeigt. Doch Wochen nach dem Start überprüfen Sie die Google Search Console und stoßen auf etwas Verblüffendes: Ihre französische Seite rankt für deutsche Suchanfragen, Ihre spanisch-mexikanische Seite wird Suchern in Spanien angezeigt, und zwei Ihrer Sprachversionen kannibalisieren sich leise gegenseitig in den Rankings. Der Inhalt ist in Ordnung. Das Problem ist, dass Google keine Ahnung hat, welche Version zu welchem Publikum gehört.
Genau das sollen hreflang WordPress-Tags beheben. Hreflang ist das Signal, das Suchmaschinen mitteilt, welche Sprach- und Regionalversion einer Seite welchem Nutzer angezeigt werden soll. Macht man es falsch, leidet man unter doppelter Content-Verdünnung, falschen Sprachergebnissen und verschwendetem Crawl-Budget. Macht man es richtig, erreicht jede übersetzte Seite das Publikum, für das sie geschrieben wurde. Dieser Leitfaden behandelt die Syntax, den Unterschied zwischen Sprach- und Sprach-Regions-Codes, das obligatorische x-default, die Reziprozität von Rückgabe-Tags und drei praktische Möglichkeiten zur Implementierung in WordPress.
Was hreflang wirklich tut
Hreflang übersetzt nichts. Es ist eine Beziehungsübersicht. Wenn Sie dieselbe Seite in mehreren Sprachen haben, teilen hreflang-Annotationen Google mit: „Diese URL ist die englische Version, diese die deutsche Version, diese ist für Spanisch sprechende Personen in Mexiko.“ Google verwendet diese Übersicht, um die korrekte Version in den Suchergebnissen basierend auf den Spracheinstellungen und dem Standort des Benutzers anzuzeigen.
Die Annotation befindet sich im <head> Ihres HTML als eine Reihe von <link>-Elementen. Jedes Element benennt eine Zielseite und die Sprache (und optional Region), die es bedient. Hier ist ein korrekter Satz von hreflang-Tags für eine Seite, die in US-Englisch, UK-Englisch und mexikanischem Spanisch verfügbar ist, mit einem Standard-Fallback:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Jede Seite im Set sollte denselben Block ausgeben und dabei jede Alternative auflisten, einschließlich sich selbst. Dieser letzte Punkt bringt die meisten Leute durcheinander, und wir werden darauf zurückkommen.
Warum das für SEO wichtig ist
Ohne hreflang behandelt Google Ihre übersetzten Seiten als Beinahe-Duplikate, die um dieselben Keywords konkurrieren. Das Ergebnis ist eine Verdünnung: Ranking-Signale werden auf verschiedene Versionen aufgeteilt, anstatt sich zu konsolidieren. Mit korrektem hreflang erbt jede Version die Autorität des gesamten Sets und erscheint den richtigen Suchenden. Dies ist einer der wirkungsvollsten SEO-Schritte, die eine mehrsprachige Website unternehmen kann, und er ergänzt die eigentliche Inhaltsübersetzung in Ihren .po-Dateien, anstatt sie zu ersetzen. Wir behandeln die Inhaltsseite ausführlich in unserem Leitfaden zu wie die Übersetzung von PO-Dateien Google Rankings beeinflusst.
Sprach- vs. Sprach-Regions-Codes
Was sollten Sie verwenden, en oder en-GB? Verwenden Sie den einfachsten Code, der zutrifft. Wenn Ihr englischer Inhalt generisch ist und Sie keine separaten britischen und amerikanischen Versionen pflegen, verwenden Sie en allein. Fügen Sie nur dann einen Regions-Subtag hinzu, wenn Sie tatsächlich unterschiedliche Inhalte für unterschiedliche Länder bereitstellen.
Hreflang-Werte folgen dem Format language oder language-region. Der Sprachteil ist ein ISO 639-1 Code (en, es, de, pt). Die optionale Region ist ein ISO 3166-1 Alpha 2 Ländercode (US, GB, MX, BR). Also:
enrichtet sich an alle Englischsprachigen, unabhängig vom Land.en-GBrichtet sich an Englischsprachige im Vereinigten Königreich.esrichtet sich an alle Spanischsprachigen.es-MXrichtet sich speziell an Spanischsprachige in Mexiko.
Ein kritisches Detail: Der Regions-Subtag ist ein Land, keine Sprachvariante. es-MX bedeutet nicht „mexikanischer spanischer Dialekt“, sondern „Spanisch, angezeigt für Benutzer in Mexiko.“ Google liefert es weiterhin basierend auf dem Standort des Benutzers aus. Wenn Sie regionale Dialekte in Ihren Übersetzungen pflegen, ist der Regionscode der Weg, wie Sie diese weiterleiten. Wir gehen in unserem Leitfaden zu regionalen spanischen und portugiesischen Varianten auf die linguistische Seite davon ein.
Ein häufiges falsches Beispiel
Hier ist ein fehlerhafter hreflang-Block, den wir ständig sehen:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Drei Fehler. en-uk ist ungültig, da der Ländercode für das Vereinigte Königreich GB ist, nicht UK. sp ist überhaupt kein Sprachcode; Spanisch ist es. Und pt-PT_BR mischt zwei Regionen mit einem Unterstrich, der in hreflang keine Bedeutung hat. Suchmaschinen ignorieren fehlerhafte Werte stillschweigend, sodass Sie keine Fehlermeldung und keinen Nutzen erhalten, sondern nur stundenlang debuggen und sich fragen, warum sich nichts geändert hat.
Beachten Sie, dass hreflang einen Bindestrich (en-GB) verwendet, während WordPress-Lokalisierungsdateien einen Unterstrich (en_GB) verwenden. Kopieren Sie Ihre .po-Dateinamen-Codes nicht direkt in hreflang-Tags.
Das x-default und die Reziprozität von Rückgabe-Tags
Zwei Regeln verursachen mehr stille hreflang-Fehler als alles andere: das fehlende x-default und die gebrochene Reziprozität.
Der x-default-Wert teilt Google mit, welche Seite angezeigt werden soll, wenn keine andere Sprache mit dem Benutzer übereinstimmt. Es ist Ihr Fallback, typischerweise Ihr Sprachwähler oder Ihre Homepage für den Hauptmarkt. Es ist laut Spezifikation nicht zwingend erforderlich, aber in der Praxis sollten Sie es immer angeben. Ohne es erhält ein portugiesischsprachiger Besucher, für den Sie keine portugiesische Version haben, eine Zufallsentscheidung anstelle einer bewussten Standardeinstellung.
Die Reziprozität von Rückgabe-Tags ist nicht verhandelbar. Jede Seite in einem hreflang-Set muss auf jede andere Seite zurückverweisen, einschließlich sich selbst. Wenn Ihre englische Seite Deutsch als Alternative auflistet, muss Ihre deutsche Seite Englisch als Alternative auflisten. Wenn die deutsche Seite den Rückverweis weglässt, misstraut Google der gesamten Beziehung und ignoriert die Annotationen.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
Der Selbstverweis (de, der auf die deutsche Seite verweist, während die deutsche Seite betrachtet wird) ist erforderlich, nicht optional. Ein Satz von fünf Sprachversionen bedeutet, dass jede der fünf Seiten alle fünf <link>-Tags plus x-default ausgibt.
Drei Wege zur Implementierung von hreflang in WordPress
Sie haben drei praktische Optionen, die von vollständiger manueller Kontrolle bis hin zu vollständig automatisierter reichen.
Methode 1: Manuell via wp_head
Für eine kleine statische Gruppe von Seiten können Sie hreflang-Tags direkt über die wp_head-Aktion in der functions.php Ihres Themes einfügen:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Dies gibt Ihnen präzise Kontrolle, skaliert aber nicht. Die manuelle Aufrechterhaltung der Reziprozität über Hunderte von Beiträgen hinweg ist eine Wartungsfalle.
Methode 2: Ein mehrsprachiges Plugin
Wenn Sie Polylang, WPML oder TranslatePress verwenden, wird hreflang automatisch basierend auf Ihren Übersetzungsbeziehungen generiert. Dies ist die richtige Antwort für die meisten Websites, da das Plugin bereits weiß, welcher Beitrag die Übersetzung wovon ist, sodass Reziprozität und x-default für Sie erledigt werden. Die Kosten sind der Laufzeit-Overhead, den diese Plugins hinzufügen, was der Kompromiss ist, den wir in unserem Vergleich von manuellen versus KI-Übersetzungsansätzen untersuchen.
Methode 3: XML-Sitemap mit xhtml:link
Anstatt hreflang in den <head> jeder Seite zu setzen, können Sie die Beziehungen in Ihrer XML-Sitemap mithilfe des xhtml:link-Namespace deklarieren. Jeder <url>-Eintrag listet alle seine Sprachalternativen auf:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Dies hält Ihr Seiten-HTML schlank und zentralisiert die Sprachübersicht in einer einzigen crawlable Datei, die Google gerne liest. Die meisten SEO-Plugins können dies automatisch generieren.
hreflang ergänzt die Übersetzung, es ersetzt sie nicht
Hier ist der Punkt, den alle übersehen: hreflang ist wertlos, wenn die zugrunde liegenden Seiten nicht tatsächlich übersetzt sind. Das Tag teilt Google mit „dies ist die deutsche Version“, aber wenn die deutsche URL immer noch englische Plugin-Strings, unübersetzte Kassenetiketten oder halbfertige .po-Dateien anzeigt, haben Sie Google einfach angewiesen, deutschen Benutzern mit vollem Vertrauen fehlerhaften Inhalt zu liefern.
Echtes mehrsprachiges SEO besteht aus zwei Schichten. Die Inhaltsschicht sind Ihre übersetzten .po-, .pot-, .json- und .xliff-Dateien, die jede Theme- und Plugin-Zeichenkette in die Zielsprache bringen. Die Signalschicht ist hreflang, das jede fertige Version ihrem Publikum zuleitet. Beide müssen solide sein. Ein makelloses hreflang-Set auf einer zu 40 Prozent übersetzten Website garantiert lediglich ein schnelleres, schlechteres Erlebnis.
Hier ist es am wichtigsten, die Übersetzungsschicht sauber zu halten. Wenn Sie Ihre Oberflächendateien übersetzen, müssen Platzhalter wie %s, %1$s und {name} intakt bleiben, sonst wird Ihre „übersetzte“ deutsche Seite mit wörtlichen %s-Tokens gerendert, die sowohl für Benutzer als auch für Suchmaschinen fehlerhaft aussehen. Eine gettext-fähige Übersetzungs-Pipeline mit Syntax Locking schützt diese Tokens automatisch, sodass jede alternative Seite, auf die Sie hreflang verweisen, wirklich produktionsreif ist. Da es in der Cloud mit Smart Batching läuft, können Sie eine gesamte Multi-Locale-Site darüber verarbeiten, ohne Übersetzungs-Plugins installieren zu müssen, die die Laufzeit, die diese Seiten bereitstellt, aufblähen.
Sorgen Sie zuerst für den richtigen Inhalt, dann lassen Sie hreflang seine Arbeit tun. Die beiden zusammen konsolidieren Ranking-Signale, eliminieren falsche Sprachergebnisse und platzieren jede übersetzte Seite vor den Leuten, die sie lesen können.
Bereit, Suchergebnisse in der falschen Sprache an der Quelle zu beheben? Testen Sie SimplePoTranslate kostenlos – keine Kreditkarte erforderlich. Übersetzen Sie Ihre
.po-,.pot- und.json-Dateien im kostenlosen Tarif und verweisen Sie dann Ihre hreflang-Tags auf Seiten, die tatsächlich für jeden Markt bereit sind.