hreflang für mehrsprachige Inhalte
Was ist das HREFLANG-Attribut und was hat es mit SEO zu tun?
Hreflang ist ein Link-Attribut, mit dem Du Sprache und Land für ein URL definieren kannst. Der Einsatz hilft Google dabei, die geografische Ausrichtung einer URL zu interpretieren. Mittels HREFLANG-Attribut kannst Du effektiv Duplicate Content-Probleme vermeiden, die bei verschiedenen Sprach- und Landesversionen einer URL entstehen können. Gleichzeitig unterstützt Du Google dabei, jedem Nutzer die für ihn passende Version einer Seite anzuzeigen.
Setzt Du bei internationalen Seiten kein HREFLANG-Attribut ein, führt dies mitunter zu großen Problemen. Kann Google zwei regionale Seiten nicht eindeutig zuordnen, wird bei Suchanfragen möglicherweise die falsche Version angezeigt. Dadurch sinkt zum einen die Sichtbarkeit der Seite bei Google insgesamt. Zum anderen ist häufig die Klickrate (CTR) erheblich niedriger, wenn eine anders sprachige oder offensichtlich einem anderen Land zugeordnete Seite (z.B. anhand eines .ch statt .de) angezeigt wird. Als Bounce Rate wird der Anteil der Nutzer, die nach kurzem Besuch auf der Seite in die Suche zurückspringen, bezeichnet. Auch diese ist bei Inhalten in falscher Sprache höher. Dies wiederum wird von Google als negativer Rankingfaktor interpretiert. Unser Partner Sistrix hat dieses Phänomen hier noch einmal am Beispiel verdeutlicht.
Das HREFLANG-Attribut hat in der Regel keinen direkten Einfluss auf das Ranking, ist aber dennoch für internationale Seiten ein wichtiger SEO-Faktor.
Wann Du das HREFLANG-Attribut einzusetzen solltest?
Der Einsatz des HREFLANG-Attributs ist dann sinnvoll, wenn es von einer Seite verschiedene Versionen für verschiedene Sprachen oder Länder gibt. Das gilt für folgende Möglichkeiten:
- Fast identische Seiten für unterschiedliche Länder:
Wenn bei einer Website für zwei gleichsprachige Länder der Inhalt weitgehend identisch bleibt, sich aber Details, wie Preise, Währung, Versandbedingungen oder rechtliche Angaben oder auch einzelne Vokabeln von Land zu Land ändern. Häufig ist dies zum Beispiel bei Produktseiten eines internationalen Online-Shops der Fall. Die Produkte und deren Beschreibungen eines Shops für Amerika und Großbritannien sind identisch, aber die Preise könnten jeweils in US-Dollar oder in Britischen Pfund angegeben werden oder die Versandbedingungen unterscheiden sich. Vielleicht gibt es auch Unterschiede zwischen britischem und amerikanischen Englisch. Wird zum Beispiel Fußball in der Beschreibung erwähnt, könnte es “soccer” (USA) oder “football” (UK) heißen. - (Vollständige) Übersetzung gleicher Inhalte:
Beispielsweise bei Websites, die zwei oder mehr anderssprachige Versionen mit dem selben Inhalt haben. - Seiten bei denen nur das Template übersetzt wird:
Google selbst empfiehlt den Einsatz von HREFLANG-Attributen für Seiten, bei denen nur das Seitentemplate übersetzt wird, der Content aber in der selben Sprache bleibt. Dies könnte zum Beispiel bei einem Forum der Fall sein. Generell ist es nicht ratsam solche Situationen entstehen zu lassen. Besser ist es, die verschiedenen Sprachversionen der eigenen Internetpräsenz möglichst konsequent zu strukturieren. Sollte es sich nicht vermeiden lassen einzelne Seiten nur teilweise zu übersetzen (das kommt zum Beispiel bei User-generated content (UGC) vor), sollten HREFLANG-Attribute unbedingt eingesetzt werden. So erhält Google die notwendigen Hinweise für die richtige Zuordnung der verschiedenen Versionen.
Wonach entscheidet Google, aus welchem Land ein Nutzer kommt?
Im Wesentlichen generiert Google die Sprach- bzw. Landeszuordnung eines Nutzers aus folgenden Faktoren:
- Google Search Settings
- Nutzerverhalten
- IP-Adresse (mittels Geotargeting)
- Regions- /Sprach-Einstellungen des Browsers/des Betriebssystems
- Bei Freigabe der Geolocation-API: (Mehr zur Funktionsweise der Geolocation API)
- das WLAN (mittels WLAN-Kartografie)
- die Funkzelleninformation des Mobilfunknetzes (GSM/CDMA2000)
- das GPS-Satelliten-System
- Sprache in Suchanfrage (sofern eindeutig Identifizierbar)
Bei den Spracheinstellungen im Browser ist es möglich das mehrere Sprachen eingestellt sind. Dann gilt entsprechend der vom Nutzer bestimmten Reihenfolge die erste hinterlegte Sprache als bevorzugte Sprache des Nutzers.
Was beeinflusst Googles Geotargeting und lokalisierte Suchergebnisse?
Das HREFLANG-Attribut ist natürlich nicht der einzige Faktor, den Google (und andere Suchmaschienen) für ihr Geotargeting auswerten. Weitere Faktoren für das Geotargeting sind:
- Sprache der Inhalte:
Google erkennt die Sprache der Inhalte und wertet das natürlich auch als Signal für das Geotargeting. Problematisch für Google sind hierbei Seiten auf denen mehrere unterschiedliche Sprachen verwendet werden. - ccTLDs:
Google wertet ccTLDs (country-code Top Level Domains, also länderspezifische Domainendungen wie .de .fr und so weiter) als ein starkes Signal für das Geotargeting. Eine Domain die auf .de endet wird in erster Linie auf deutsche Nutzer ausgerichtet sein. Ist eine Seite unter einer ccTLD abrufbar, wird es schwer ein gutes Ranking für diese Inhalte in einem anderen Land zu erzielen. Ein Konstrukt wie „www.example.de/fr/“ für die französische Version einer deutschen Seite wird es in Frankreich schwerer haben zu ranken als beispielsweise ein „www.example.com/fr/“. genericTLDs wie .com oder .org werden weder einer Sprache noch einem Land zugeordnet. Das trifft auch auf einzelne, häufig fremdgenutzte ccTLDs zu. Beispiele hierfür sind .tv, die ccTLD des Inselstaats Tuvalu, oder .io, die ccTLD des Britischen Territoriums im Indischen Ozean. Eine Auflistung, welche ccTLDs von Google so gewertet werden, wurde in der Google Search Console-Hilfe veröffentlicht. - Google Search Console Einstellungen:
Der Betreiber einer Website kann in der Google Search Console (ehemals Webmaster Tools) die Sprache und geografische Ausrichtung der Website angeben. Hierbei ist es wichtig, dass die Angaben den anderen Geotargeting-Signalen nicht widersprechen, da es sich sonst negativ auf das Ranking auswirken kann. Entsprechendes gilt beispielsweise auch für Site Region Angaben der Index-Einstellung bei Yandex.webmaster. - Währung und Adressformate auf der Website:
Währungen, Adressformate und Telefonnummern sind ebenfalls eine Informationsquelle für die geografische Ausrichtung einer Seite. Sind die Preise in Pfund (£) ausgezeichnet oder ist die Geschäftsadresse beispielsweise in Leeds? Entsprechen dazu die Telefonvorwahlen britischer Struktur? All dies würde Google einem Geotargeting der Seite in Großbritannien zuordnen. - Backlinks:
Für das regionale Ranking haben Backlinks für Google noch eine zusätzliche Dimension. Google wertet aus, von wo eine Seite hauptsächlich verlinkt wird. Ist sie maßgeblich aus Österreich oder Deutschland verlinkt? Auch das beeinflusst das Geotargeting. - Google My Business:
Daten aus einem Eintrag in Google My Business werden von Google ebenfalls für das Geotargeting ausgewertet. - Serverstandort:
Der Serverstandort ist laut Google kein Faktor für das Geotargeting, aber hat indirekt sehr wohl einen Einfluss auf das Ranking. Google wertet als allgemeinen Rankingfaktor auch den Pagespeed aus. Der Pagespeed wiederum ist (unter anderem) regional vom Serverstandort abhängig. Je näher der Server, desto schneller ist die Seite geladen. - “Content-Language” Meta-Tag:
Das “content-language” Meta-Tag oder andere Meta-Tags, die die Sprache eines Dokuments angeben, werden von Google nicht mehr für das Ranking oder Geotargeting ausgewertet. Andere Suchmaschinen wie Bing oder Yahoo nutzen es aber sehr wohl noch für ihr Geotargeting, es sollte also nicht völlig ignoriert werden.
Wie Du HREFLANG-Attribute in der Praxis nutzt?
Um das HREFLANG-Attribut produktiv einzusetzen, muss zuerst definiert werden, welche Voraussetzungen gegeben sind und was erreicht werden soll:
- Welche URLs sind in welchen Sprachen verfügbar?
- Welche relevanten Sprach-/Landkombinationen gibt es? (Auch Codes wie tr-DE (Türkisch in Deutschland) können sinnvoll sein, wenn Du spezielle Inhalte auf Türkisch für Türken die in Deutschland leben anbietet.)
- Sind diese Seiten bereits (alle) untereinander verlinkt?
- Gibt es alle Seiten in allen Sprach-/Landkombinationen?
- Gibt es Inhalte die nicht für alle Sprachen relevant sind, z. B. Kategorien in einem Online-Shop, die nur in bestimmten Ländern verfügbar sind
- fehlen Übersetzungen der Produktbeschreibungen für bestimmte Produkte?
- Welche Strategien zur Spracherkennung setzt Du selbst ein?
- Browserweiche
- Länderauswahl / Sprachauswahl
- Gibt es diese Auswahl URL-weise oder nur auf der Startseite?
- Ist der Einsatz von x-default sinnvoll, wenn ja, wo?
Wenn dies geklärt ist, muss das HREFLANG-Attribut implementiert werden.
Syntax von Hreflang
Beim Einsatz von HREFLANG-Attributen werden die URLs der verschiedenen Sprach- beziehungsweise Landesversionen einer Seite zu Blöcken zusammengefasst. Jeder dieser Blöcke besteht aus einer Gruppe von äquivalenten URLs für jede vorhandene Sprach- beziehungsweise Landesversion. Es reicht also nicht aus, die HREFLANG-Attribute nur auf den jeweiligen Hauptseiten einzusetzen. Dabei müssen bei jeder URL eines HREFLANG-Blocks die einzelnen HREFLANG-Attribute aller URLs des HREFLANG-Blocks angegeben werden, sodass in jeder URL eines Blocks alle URLs des jeweiligen Blocks mit einem HREFLANG-Attribut referenziert sind. Daraus ergibt sich im Umkehrschluss, das jede URL nur Teil eines einzigen HREFLANG-Blocks sein kann.
Die Reihenfolge in der die einzelnen HREFLANG-Attribute angegeben werden ist dabei egal und muss für einen HREFLANG-Block auch nicht einheitlich sein.
<link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
Jedes HREFLANG-Attribut besteht dabei aus 3 Bausteinen:
- rel=“alternate”
dieser Teil des Attributs weist darauf hin, dass es eine alternative Version der Seite gibt. Dieser Teil bleibt auch immer gleich. Die Syntax entspricht hier auch dem, was bereits von HTML Link-Attributen wie rel=“canonical” und rel=“prev”/“next” bekannt ist. - hreflang=“xx-XX”, z. B. hreflang=“de-DE”
an dem namensgebenden Baustein des HREFLANG-Attributs wird der Sprachcode und optional ein Ländercode für die jeweilige URL angegeben. (Mehr zu den Country Codes im Abschnitt: Hreflang Country Codes) - href=““, z. B. href=“https://www.example.com“
der dritte Baustein ist die Angabe der absoluten-URL. Während die Syntax der ersten beiden Bausteine sich in allen Implementierungsweisen mehr oder weniger gleicht, tanzt hier die Implementierung in der HTTP-Kopfzeile, wie unten zu sehen ist, ein wenig aus der Reihe.
Übrigens macht es dabei keinen Unterschied, ob Du das HREFLANG-Attribut mit HTML 4.01, HTML5 oder XHTML einsetzt.
Wo sollte die Auszeichnung strukturell verortet werden?
Grundsätzlich gibt es drei Möglichkeiten, Hreflang zu implementieren:
HTML Link-Element im HTML-Header
Am Schnellsten und Einfachsten ist in der Regel die Implementierung von HREFLANG-Attributen als (HTML-) Link-Element in den Head-Bereich des HTML:
<link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/" />
<link rel="alternate" hreflang="fr-CH" href="https://www.example.com/fr/ch/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en" />
Die einzelnen URLs der verschiedenen Versionen werden, wie hier dargestellt, im Header des HTML eingebunden. Jede URL inklusive der aktuellen Seite bekommt ein eigenes Link-Element. Jedes Element beginnt dabei mit dem Attribut rel=“alternate”, gefolgt von der Angabe des Sprach- (und Länder-)codes mit dem Attribut “hreflang” und schließt mit der Angabe der jeweiligen absoluten URL über das href-Attribut.
HTTP-Header
Für Nicht-HTML-Inhalte, also z.B. PDFs, kann ein HREFLANG-Attribut im HTTP-Header gesetzt und übergeben werden. Bei einfacher HREFLANG-Auszeichnungen ist dies durchaus eine Option:
Link: ; rel="alternate"; hreflang="es",; rel="alternate"; hreflang="de",; rel="alternate"; hreflang="fr-CH",; rel="alternate"; hreflang="en"
Bei der Implementierung in der HTTP-Kopfzeile werden die HREFLANG-Angaben als Link hinterlegt. Die Syntax ähnelt dabei der eines Canonicals. Dabei wird aber für jede Version einer Seite keine eigene Anmerkung erstellt, sondern für die einzelnen Werte durch Komma getrennt. Jeder Wert beginnt dabei mit der der absoluten URL, danach folgt das Attribut rel=“alternate”. Der letzte Teil ist jeweils das HREFLANG-Attribut, das Sprach– (und Länder-)code angibt.
XML-Sitemap
Für große Websites mit vielen URLs in verschiedenen Sprachen empfiehlt sich die Angabe des HREFLANG-Attributs über die XML-Sitemap. Da JEDE URL einzeln ausgezeichnet werden muss, können viele HREFLANG-Angaben den Quelltext aufblähen. Genauso gibt es einige Systeme, bei denen beim Seitenaufruf die Geschwister nicht bekannt sind. Daher gibt es alternativ die Möglichkeit, die HREFLANG-Attribute über die XML-Sitemap als zusätzliches XHTML:Link-Element zu implementieren. Diese Variante hat zusätzlich den Vorteil, dass die HREFLANG-Angaben nicht Teil des HTTP-Headers oder HTML-Dokumentes sind. Dadurch wird unter anderem die Größe der beim Seitenaufruf zu übertragenen Daten verringert.
In der XML-Sitemap muss zu Beginn der XHTML-Namespace angegeben werden:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
Dann wird für jede URL ein separates URL-Element erstellt. In den Elementen wird jeweils die URL mittels loc-Tag angegeben:
<url>
<loc>https://www.example.com/es/</loc>
Anschließend wird für jede Version der Seite, inklusive der des jeweiligen URL-Elements, ein XHTML:Link-Element angegeben, ähnlich wie die Angabe in der HTML-Kopfzeile:
<xhtml:link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/" />
<xhtml:link rel="alternate" hreflang="fr-CH" href="https://www.example.com/fr/ch/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/" />
</url
Das wird für jede URL ebenso Durchgeführt:
<url>
<loc> https://www.example.com/de/</loc>
<xhtml:link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/" />
<xhtml:link rel="alternate" hreflang="fr-CH" href="https://www.example.com/fr/ch/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/" />
</url>
<url>
<loc> https://www.example.com/fr-CH/</loc>
<xhtml:link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/" />
<xhtml:link rel="alternate" hreflang="fr-CH" href="https://www.example.com/fr/ch/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/" />
</url>
<url>
<loc> https://en.example.com/</loc>
<xhtml:link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/" />
<xhtml:link rel="alternate" hreflang="fr-CH" href="https://www.example.com/fr/ch/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/en/" />
</url>
</urlset>
Ein Beispiel für eine HREFLANG-XML-Sitemap von Google gibt es hier.
In allen drei Fällen ist die Reihenfolge der einzelnen HREFLANG-Elemente egal, aber es ist zu beachten, dass jede Version nicht nur alle anderen Versionen, sondern auch sich selbst verlinkt. Dabei muss immer die absolute URL angegeben werden und keine relative URL. Ansonsten ist die Verlinkung unvollständig und damit wirkungslos.
Hreflang Country Codes
Die Syntax für die Sprach- und Ländercodes (auch Country Codes genannt) für das HREFLANG-Attribut sind in allen drei Varianten gleich.
Der Sprachcode entspricht der ISO 639-1. Mit einem Bindestrich kann optional der Ländercode entsprechend der ISO 3166-1 alpha-2 nachgestellt werden. Nach ISO-Normen werden die Sprachcodes klein geschrieben. Die Ländercodes hingegen werden großgeschrieben. Allerdings funktionieren HREFLANG-Attribute bei Google unabhängig von der Groß- und Kleinschreibung.
Das sieht zum Beispiel so aus:
„en“ für eine Seite auf Englisch ohne besondere regionale Zuordnung
“en-GB” für eine Seite auf Englisch für das Vereinigte Königreich
„en-CA“ für eine Seite auf Englisch für Nutzer aus Kanada
„fr-CA“ für eine Seite auf Französisch für Nutzer aus Kanada
Möglich sind auch weniger offensichtliche Sprach-Land Kombinationen:
“tr-DE” für eine Seite auf Türkisch für Nutzer aus Deutschland
Wichtig ist, dass immer eine Sprache definiert wird. Für eine genauere Eingrenzung kann ein Ländercode hinzugefügt werden. Ein Ländercode alleine wird entweder nicht erkannt oder, wenn er mit einem Sprachcode übereinstimmt, mit selbigem verwechselt werden. Im Falle von zum Beispiel “DE” wird Deutsch statt Deutschland häufig nicht auffallen. In anderen Fällen könnte die Auswirkung gravierender sein. Bei “AE” für die Vereinigten Arabischen Emirate, ergibt der Sprachcode “ae” Awestisch, eine altiranische Sprache. Die Anzahl der Suchanfragen aus den Vereinigten Arabischen Emiraten, bei denen Google eine awestische Seite ranken würde, sind aber (vermutlich) leider eher gering, zumal die Sprache ausgestorben ist. Weiteres Beispiel: “BS” (Bahamas) und “bs” Bosnisch. Von diesen “falschen Freunden” gibt es noch eine Menge mehr.
Cross Domain HREFLANG-Attribute
Das HREFLANG-Attribut funktioniert auch, wenn Du verschiedene Domains oder Subdomains betreibst.
Angenommen es werden folgende Domains für seine internationale Seite verwendet:
https://www.beispiel.de/
https://www.beispiel.at/
https://www.example.co.uk/
https://www.beispiel.com/
https://www.beispiel.com/Turkish/
https://www.exemple.fr/
https://es.example.com/
Eine solche Mischung aus Verzeichnisstrukturen, Subdomains und ccTLDs gäbe einem zwar viele gute Gründe die Domainstrategie grundlegend zu überdenken, aber das HREFLANG-Attribut wäre keiner davon. Die Syntax arbeitet mit absoluten URLs, somit ist es für seine Funktion nicht notwendig, dass die verschiedenen URLs zu einer Domain gehören oder auch nur einer einheitlichen Struktur folgen. Dennoch wäre die Implementation bei solch einem Domain-Wirrwarr sicherlich kein Spaß für die Entwickler.
Sonderfall x-default
Es ist möglich statt eines Sprachcodes einen Default-Wert einzusetzen. Damit wird angezeigt, dass diese Seite für alle Nutzer ist, die sich keiner der anderen mittels Hreflang angegebenen Sprachen bzw. keinem der Länder zuordnen lassen. Dies könnte zum Beispiel eine Landingpage mit manueller Landes- bzw. Sprachauswahl der Fall sein oder beim Einsatz von Sprach und Location abhängigen Weiterleitungen. Außerdem ist es möglich example.co.uk/ nicht nur als “en-GB” für das United Kingdom und “x-default” Default Seite auszeichnen, sondern auch als “en” für alle englischsprachigen Nutzer
<link rel="alternate" hreflang="x-default" href="http://www.example.com/en/" />
<link rel="alternate" hreflang="es" href="http://www.example.com/es/" />
<link rel="alternate" hreflang="de" href="http://www.example.com/de/" />
<link rel="alternate" hreflang="en-GB" href="http://www.example.com/en/" />
<link rel="alternate" hreflang="en" href="http://www.example.com/en/" />
Live übertragen am 08.09.2015
Frage von Nick Williams: „Meine Frage geht um x-default bei Hreflang. Ich habe meine Sprachen auf mehreren Domains. zum Beispiel .co.uk für Englisch, .it für Italien, .com= für Deutsch. Kann ich x-default für meine .co.uk nutzen, obwohl ich es schon für mein „en“ verwendet habe?“
Antwort von John Müller: „Ja, x-default kann zu einer bereits verwendeten Seite zeigen. Man kann für die Seite sagen, dies ist meine Seite für Englisch und es ist auch die Seite, die ich für alle anderen Sprachen angezeigt haben möchte. Man könnte auch sagen, jeder spricht Deutsch, darum ist Deutsch meine x-default Seite. Das liegt ganz an Euch. Ihr könnt auch noch eine Stufe weitergehen und sagen: Dies ist meine englische Seite für UK und auch meine allgemeine englische Seite und x-default Seite.“
Häufige Fehler
Fehlende gegenseitige Verlinkung
Eine der häufigsten Fehlerquellen ist die gegenseitige Verlinkung der HREFLANG-Elemente. Für jede Seite müssen HREFLANG Link-Elemente gesetzt werden.
Es muss also jede URL jede Geschwister-URL und sich selbst verlinken.
Unterseiten nicht mit Hreflang ausgezeichnet
Es reicht doch bestimmt, wenn ich meine Startseite ordentlich mit Hreflang auszeichne, oder? Nein, tut es nicht. Jede einzelne Seite, für die verschiedene Sprach- oder Landesversionen existieren benötigt entsprechende HREFLANG-Angaben. Ausgenommen davon sind nur Seiten, die nicht indexiert werden sollen, dann ist es überflüssig der Suchmaschine bei der Lokalisierung zu helfen.
Falsche Sprachcodes
Ebenfalls für Fehler sorgen falsche Sprach- und Ländercodes. Wenn ein Code nicht existiert, wird das HREFLANG-Attribut schlicht ignoriert. Wird alternativ ein Code angegeben, der auf eine falsche Sprache oder anderes Land verweist, kann auch das negative Auswirkungen haben. Entweder wird die falsche HREFLANG-Angabe ebenfalls ignoriert, weil sie nicht zu den anderen Geotargeting Signalen passt, oder die Seite wird in dem falschen Land ranken.
Einer der beliebtesten falschen Ländercodes ist „en-UK“. Dieser Code wirkt im ersten Moment intuitiv richtig für eine Seite des „United Kingdom“, aber die Iso-Norm sieht hier, anders als bei der ccTLD, offiziell das Kürzel „GB“ vor. Daher ist der korrekte HREFLANG-Code einer englischsprachigen Seite für das Vereinigte Königreich, wie oben im Beispiel schon gezeigt, „en-GB“.
Widerspruch mit Status Code
Google erwartet, dass im Hreflang nur valide URLs referenziert werden. Das bedeutet in diesem Zusammenhang, dass die URLs den Status-Code 200 liefern und der Robots-Status (Meta-Robots und X-Robots) sollte dem Status der Seite entsprechen, auf der das Attribut eingebunden ist.
Widerspruch mit Canonicals
Von Seiten Googles (John Müller) wird empfohlen Canonicals nur dann zu setzen, wenn es wirklich zu 100% der gleiche Inhalt auf beiden Seiten ist. Wenn eine Seite mit einem Canonical auf eine andere Seite verlinkt ist, sollte kein HREFLANG-Attribut gesetzt werden. Eine Gemeinsame Nutzung von Canonical und Hreflang ist nur dann erwünscht, wenn die Canonicals auf eine Seite weisen, die auch über Hreflang verlinkt wird. Aber selbst in so einem Fall will es wohl überlegt sein, Hreflang und Canonical zu kombinieren, da Google das Snippet der Seite auf die das Canonical weist für beide Seiten ausgeben wird. Zumal das HREFLANG-Attribut alleine schon ausreicht, um Duplicate Content Probleme zu vermeiden. Ein Canonical, das auf sich selbst verweist, ist hierbei natürlich trotzdem unproblematisch.
Widerspruch mit „Internationale Ausrichtung“ in der Google Search Console
Bei Seiten mit einer gTLD (generic Top-Level-Domain) hast Du die Möglichkeit in der Google Search Console die internationale Ausrichtung einer Seite zu bestimmen. Diese Angaben sollten natürlich nicht den HREFLANG-Angaben widersprechen.
robots.txt
Wenn über die robots.txt das Crawlen der mittels Hreflang angegebenen Seiten nicht erlaubt wird, darf der Google-Bot nicht auf die Seite, und kann die Angabe daher weder auslesen, noch befolgen.
Auswirkung der Fehler
Laut John Mueller, führt ein Fehler in HREFLANG-Angaben nicht dazu, dass die Angaben für alle URLs in einem HREFLANG-Block ignoriert werden. Das bedeutet grundsätzlich auch, dass einzelne nicht valide Blöcke nicht die Funktionsweise anderer Blöcke beeinträchtigen.
HREFLANG und andere Suchmaschinen
In Deutschland fällt es häufig nicht auf, aber international hat Google Konkurrenten, die Du nicht vernachlässigen darfst.
Googles Marktanteil im Vergleich zu seinen stärksten Konkurrenten in verschiedenen Ländern
Google wertet HREFLANG-Attribute aus, um die Zusammenhänge zwischen den verschiedenen Sprach- und Landesversionen einer Seite zu verstehen und den Nutzern von Google die jeweils zu Sprache (und Land) des Nutzers passenden URLs auszugeben. Wie sieht es mit den anderen wichtigen Suchmaschinen aus?
Yandex
Yandex ist neben Google die größte Suchmaschine die HREFLANG-Attribute auswertet. Dabei ist zu beachten, das Yandex hierfür die Implementierung über die XML-Sitemaps nicht unterstützt.
Bing und Yahoo
Bing und Yahoo nutzen das HREFLANG-Attribut nicht. Stattdessen wird für das Geotargeting stärker auf andere Signale gesetzt. Offiziell gibt es von Bing (die auch die Engine für Yahoo betreiben) seit 2011 die Empfehlung, das Content-Language Meta-Tag (z.B. ) zu verwenden. Dieses Meta-Tag wird zwar in den W3C-Recommendations für HTML5 als nicht spezifikationsgerecht mit definiert, aber seitens Bing gibt es dazu bislang keine aktuellere Aussage. Da keine negativen Auswirkungen zu erwarten sind, kannst Du das Content-Language Meta-Tag dennoch nutzen. Die Country Codes sind dabei die gleichen wie bei Hreflang.
Seznam und Baidu
Seznam nutzt das HREFLANG-Attribut ebenfalls nicht. Die tschechische Suchmaschine konzentriert sich maßgeblich auf ihre Heimat, den tschechischen Markt. Daher ist die internationale Ausrichtung einer Seite für Seznam weit weniger relevant, als für die weit mehr international arbeitenden Konkurrenten.
Baidu konzentriert sich ähnlich wie Seznam (vielleicht sogar noch viel stärker) auf seinen nationalen Markt China. Von daher ist auch bei Baidu das Interesse an HREFLANG-Attributen gering. Meta-Tags werden aber im Allgemeinen von Baidu ausgewertet.
Folgende Newsletter-Beiträge befassen sich mit dem Thema Quality Rater Guidelines
- Newsletter 90 vom 15.02.2022: Heflang SEO Chat Summary & Tipps von Anita
--
Hat Dir der Artikel gefallen?
Neue Artikel, Updates zu unseren Artikeln und Artikel von anderen Stellen wir regelmäßig unserem Newsletter.
Beispielausgaben und Anmeldung findest Du unter Wingmen-Newsletter