Ratgeber

HREFLANG richtig nutzen: So wird dein SEO auch international erfolgreich

(Grafik: Shutterstock)

Lesezeit: 10 Min. Gerade keine Zeit? Jetzt speichern und später lesen

HREFLANG wird inzwischen seit April 2013 von SEOs genutzt, um Entwickler in den Wahnsinn zu treiben. Und umgekehrt. Wir erläutern, was es bringt, und was ihr beachten solltet.

Nach mehr als drei Jahren ist nun einmal Zeit, über die bisherigen Learnings, die häufigsten Fallstricke und Irrtümer zu reden. Außerdem schauen wir, was man tun kann, wenn es mit dem HREFLANG einfach nicht klappen will.

Was ist das Ziel von HREFLANG?

Wenn Inhalt für mehrere Sprachen und vor allem in einer Sprache für mehrere Regionen erstellt wird, dann entsteht häufig Duplicate Content. Angenommen die Produktseite A gibt es als:

  • Deutsch für Deutschland (Impressum, Telefonnummer, Preis, Versandbedingungen)
  • Deutsch für Österreich (Impressum, Telefonnummer, Preis, Versandbedingungen)
  • Deutsch für Schweiz (Impressum, Telefonnummer, Preis, Versandbedingungen)
  • Italienisch für Schweiz (Impressum, Telefonnummer, Preis, Versandbedingungen)

Die Seiten sind fast identisch. Suchmaschinen stellt das vor das Problem, im Einzelfall entscheiden zu müssen, welche Variante für welchen Nutzer in welchem Szenario die passende ist. Ohne das HREFLANG werden diese Varianten schnell als Duplicate Content gewertet und treten zueinander in Konkurrenz. Um Suchmaschinen bei dieser Entscheidungsfindung zu unterstützen, haben Google und Yandex das HREFLANG eingeführt.

Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Was passieren kann, wenn es mit dem HREFLANG nicht klappt, sieht man, wenn man “oneplus” googlet. Hier rankt bei einer Abfrage aus Deutschland die österreichische Variante. Oneplus versucht das Problem über ein Banner nach dem Seitenladen zu lösen. Aber wenn ich als Nutzer das ignoriere, dann kann ich am Ende das Formular nicht abschicken. Mit einem HREFLANG wäre es einfach, dafür zu sorgen, dass Nutzern aus Deutschland die richtige Seite angezeigt wird.

(Screenshots: Google / Oneplus)

(Screenshots: Google / Oneplus)

Was ist HREFLANG?

Doch zuerst die Basics:

HREFLANG ist ein Link-Tag-Attribut für den Headbereich. Es ermöglicht Webseitenbetreibern, zu spezifizieren, für welche Sprach-/Land-Zielgruppe welche URL relevant ist. Das Tag ist also URL-basiert, eine globale Auszeichnung ist damit nicht möglich.

Das HREFLANG-Attribut wirkt sich nicht direkt auf das Ranking aus. Google sagt, dass die Rankingsignale der einen URL nicht auf eine andere Sprach-/Land-URL übertragen werden. Die Möglichkeit, dies zu tun, könnte aber natürlich irgendwann verlockend sein. Und selbst wenn das HREFLANG-Attribut nicht zur Vereinheitlichung der Rankingsignale führt, so hilft es, dass der Nutzer in den Suchergebnissen das richtige Dokument angezeigt bekommt. Das unterstützt positive Nutzersignale und dient der Optimierung der Konversionsrate, da der Nutzer — nach dem Klick auf ein Suchergebnis — direkt auf der richtigen Seite landet.

Das HREFLANG-Link-Tag besteht aus drei zusammengesetzen Attributen:

Darstellung des HREFLANG-Link-Tag-Schemas.

Darstellung des HREFLANG-Link-Tag-Schemas.

Grundsätzlich verweist dabei jede URL auf ihre Sprach-/Landgeschwister. Das Hauptproblem: Sobald eine URL nicht valide ist, wird der komplette Block aller Sprach- / Landgeschwister ignoriert.

Neben der Implementierung direkt im HTML gibt es auch die Möglichkeit der Implementierung über eine/mehrere XML-Sitemaps. Letztere kann unter Umständen die Implementierungskomplexität reduzieren.

Google akzeptiert domainübergreifende HREFLANG-Angaben. Yandex akzeptiert nur Folder / Subdomains.

Wie funktioniert die Implementierung?

Für eine korrekte Implementierung des HREFLANG-Attributs gibt es Voraussetzungen, die vorab geklärt werden sollten:

  • Welche Sprachen stelle ich in welchen Länderversionen zur Verfügung?
  • Weiß jedes Dokument für welche Sprach-/Landkombination es relevant ist?
  • Kann ich jede Sprache einem ISO “639-1”-Code zuordnen?
  • Kann ich jedes Land einem “ISO 3166-1 Alpha 2”-Code zuordnen?
  • Kennt jede URL ihre Sprach-/Landgeschwister?
  • Zu welchem Zeitpunkt kennt eine URL ihre Geschwister?
  • Wie häufig kommen neue Geschwister zu einem Block dazu? Wie häufig werden Geschwister entfernt oder ändern ihre URL?

Sind alle Fragen geklärt, sind die Voraussetzungen für die Implementierung gegeben. Denn selbst kleine Fehler in der Implementierung führen dazu, dass alle Angaben ignoriert werden. Der Implementierungsaufwand war dann für die Katz. Und man kann dann natürlich mit der falschen Version in einem Index gerankt werden.

Was macht die Implementierung so kompliziert?

Das Ignorieren des gesamten Blocks bei einer fehlerhaften Angabe macht die Implementierung anspruchsvoll.
Die Checkliste:

  • Alle angegebenen URLs müssen mit HTTP-Status 200 antworten
  • Das Canonical der referenzierten URLs darf nicht von der URL abweichen
  • Gleichzeitig müssen alle URLs alle anderen Sprach-Land-URL-Geschwister ebenfalls referenzieren
  • Zusätzlich müssen alle Sprach- /Land-Angaben valide sein

Eine Menge Anforderungen, die zum Zeitpunkt des Ladens der URL unter einen Hut gebracht werden müssen. Der Server muss beim Aufruf der Seite nicht nur die eigene Sprache kennen, sondern auch wissen, welche Geschwister es gibt, und wie deren URL, das Sprach- und eventuell das Länderkürzel lautet.

Beispiel aller ausgehenden HREFLANG-Links in einem kleinen HREFLANG-Setup.

Beispiel aller ausgehenden HREFLANG-Links in einem kleinen HREFLANG-Setup.

URL auf der wir uns befinden: https://beispiel.de/de/de/1.html HREFLANG-Block auf dieser URL:

  • <link rel="hreflang" hreflang="de" href="https://beispiel.de/de/1.html" />
  • <link rel="hreflang" hreflang="de-DE" href="https://beispiel.de/de-DE/1.html" />
  • <link rel="hreflang" hreflang="de-AT" href="https://beispiel.de/de-AT/1.html" />
  • <link rel="hreflang" hreflang="de-CH" href="https://beispiel.de/de-CH/1.html" />
  • <link rel="hreflang" hreflang="it-CH" href="https://beispiel.de/it-CH/1.html" />
  • <link rel="hreflang" hreflang="en" href="https://beispiel.de/en/1.html" />
  • <link rel="hreflang" hreflang="en-GB" href="https://beispiel.de/en-GB/1.html" />
  • <link rel="hreflang" hreflang="en-US" href="https://beispiel.de/en-US/1.html" />

Ein besonderer Fallstrick: Das x-default

Da diese wechselseitige korrekte Referenzierung noch nicht dazu geführt hat, dass jeder an der Implementierung scheitert, haben sich Google und Yandex einen zusätzlichen Fallstrick ausgedacht: Ein schwammig definiertes x-default-Attribut.

Die Grundidee ist so logisch wie sinnvoll: Wenn Google nicht weiß, welche Seite zu einem Nutzer passt, welche Seite soll dann angezeigt werden? Doch die Spezifikation ist sehr unspezifisch.

Erst haben viele verstanden, man solle immer die Startseite angeben. Andere haben geglaubt man sollte damit eine Sprache als default definieren.

Dadurch, dass das x-default durch Entwickler und Admins immer unterschiedlich interpretiert wurde, wird es jetzt von Suchmaschinen häufig ignoriert. Gemeint ist eigentlich: Eine URL, die diesen Inhalt in der sprach- und regionalitätsunabhängigsten Form darstellt. Und das bedeutet in der Regel entweder:

  • Es wird die englische (oder deutsche) Variante ohne regionale Einschränkung angegeben
  • Es wird eine Sprachauswahlseite für den konkreten Inhalt angegeben
  • Es wird eine englische Variante mit einem Sprach-/Regionauswahl-Overlay angegeben

Viele geben auch eine URL an, die bereits einer konkreten Sprache zugeordnet ist. Inzwischen ist von Google klargestellt, dass das möglich ist.

Was sind häufige Fehler bei der Implementierung von HREFLANG?

Die Grundstruktur des Tags und viele Fehlerquellen kennen wir jetzt schon. Interessant ist aber der Blick auf die Fehler, die wir am häufigsten im Zusammenhang mit HREFLANG finden.

Fehlende Rückbestätigung aus technischen Gründen

Im HREFLANG referenzierte URLs müssen sich alle exakt gegenseitig bestätigen. Das bedeutet, dass Google alle angegebenen URLs aufrufen und verarbeiten können muss, und dass diese jeweils auf die erste URL zurück bestätigen.

Diese Rückbestätigung scheitert häufig aus technischen Gründen:

  • Im HREFLANG der ersten URL sind HTTP-URLs angegeben, die auf HTTPS weiterleiten. Google kann die HTTP-URL also nicht aufrufen und eine entsprechende Rückbestätigung finden
  • Die Protokollangaben sind missverständlich: Die URLs sind unter HTTP und HTTPS verfügbar – es existieren dadurch zwei HREFLANG-Kreise.
  • Das Canonical der URL weicht ab. Die URL wird innerhalb von HREFLANG referenziert, aber das Canonical sagt, das Original liegt woanders.
  • Angaben sind veraltet. Die Angaben waren möglicherweise einmal korrekt, aber die URL wurde gelöscht oder umgezogen, ohne dass die Sprachgeschwister darüber informiert worden sind.

Vertauschen von Sprache und Land

Sprache und Land werden in der Angabe häufig vertauscht. Oft ist dafür unsere landzentrierte Denke verantwortlich. Wir fragen ja bei jedem Startup immer erst: In wie vielen Ländern bist du aktiv? Und nicht: Wie viele Sprachen musst du managen?

Für Google und Yandex und die HREFLANGs gilt aber immer: Erst die Sprache, dann das Land.

Verwendung falscher Sprach- oder Landkürzel

Wir sehen oft kreative Sprach- oder Landkürzel. Gelegentlich sind es False-Friends bei den Länderkürzeln, die Fehler verursachen, zum Beispiel: “en-UK” statt “en-GB” für Englisch/Großbritannien.

Oft sind aber auch Marktregionen und regionale Online Marketing-Auftritte nicht an Ländergrenzen organisiert. Bei “DACH” ist das Problem nicht groß. Gäbe es hier nur einen Auftritt könnte man damit leben, diesen als “Deutsch” ohne Regionalisierung auszuzeichnen. Für “it-CH” und “fr-CH” müsste man sich überlegen, ob man eigene URLs dafür erzeugt, oder ob dieser Aufwand übertrieben ist. Anders ist es beispielsweise bei Middle-East. Vertriebsseitig häufig als ein Land behandelt und mit einer Domain dargestellt, lässt sich das mit dem HREFLANG nicht umsetzen. Hier gibt es letztlich nur drei Alternativen:

  1. Sprache als arabisch auszeichnen, aber ohne Region. Das ist dann ein Problem, wenn es eine zweite arabische, aber nicht regionalisierte Variante gibt. Dann hätten wir das Problem, dass wir nur eine dieser Varianten als arabisch auszeichnen können.
  2. Das künstliche Land aus dem HREFLANG-Block herauslassen und hoffen, dass Google das Problem korrekt selbstständig löst
  3. Neuschaffung der fehlenden Ländervarianten und damit grundsätzliche Lösung des Problems

Die schlechteste Variante ist in jedem Fall: “ar-Middle-East” als Auszeichnung anzugeben, also nicht existierende Varianten. Damit kann der gesamte Block an HREFLANG-Angaben nicht mehr validiert werden.

Rückbestätigung für die eigene URL fehlt

Der wohl häufigste Fehler: Bei der Angabe des HREFLANG-Blocks wird die URL vergessen, die aktuell aufgerufen wird. Die Spezifikation ist da eindeutig: Alle URLs, die zum Geschwisterkreis gehören, sind aufzuführen. Das schließt natürlich die aktuell aufgerufene URL ein. Wenn die URL sich nicht selbst referenziert, dann fehlt die Rückbestätigung von sich selbst und die Blöcke sind für Google nicht mehr so leicht zu validieren.

Sprache im Dokument stimmt nicht mit HREFLANG überein

Natürlich sollten die gemachten Angaben korrekt sein. Das heißt im Dokument sollte nicht nur korrekt ausgezeichnet sein, sondern auch, dass das Dokument auch in dieser Sprache bzw. Regionalität sein muss.

Wenn ich anfange, meine russischen Inhalte mit griechisch als Sprache auszuzeichnen, dann wird Google schnell das Vertrauen in meine HREFLANGs verlieren.

Zu diesem Punkt gehört noch ein weiterer, der für Google nicht so relevant ist, aber in anderen Suchmaschinen jetzt oder später eine Rolle spielen kann: Ist das Dokument mit deutsch verlinkt und der Inhalt auf deutsch, dann sollten auch Sprach-Meta-Tags deutsch sein und nicht englisch, weil das CMS-Template das mal als default gesetzt hatte. Beliebte Tags, in denen sich Sprachauszeichnungen verbergen:

  • <meta http-equiv="content-language" content="de">
  • HTTP-Header "content-language": "de"

Zusätzlich ist es mit HTML5 natürlich möglich, jedes einzelne Element mit einem language-Attribut zu versehen.

Diese Angaben sind umso wichtiger, da sich beispielsweise bing und yahoo auf diese Angaben verlassen.

HREFLANG Prüfschema

Du kannst Deine HREFLANG-Implementierung sehr einfach prüfen, wenn du für jedes Template folgendes Schema anwendest.

  1. Welche Sprachen-/Länder sind angegeben? Stehen die verwendeten Länder-Codes in den ISO-Listen und welchen Sprachen- /Ländern entsprechen diese Codes?
  2. Haben alle URLs Status 200, Canonical auf sich selbst, Index=index,follow und erlaubt die robots.txt das Crawling durch Google? Wenn nicht, wird wahrscheinlich das Problem der Rückbestätigung nicht erfüllt sein.
  3. Wie viele / Welche HREFLANG-Tags sind auf den Zielseiten angegeben?
  4. Stimmen die angegebenen Sprachen und Länder mit den real auf der Seite zu findenden Sprachen- / Währungen überein?
  5. Sind alle Sprachen- und Länder angegeben, die es geben sollte?

Grundsätzlich ist Googles Prüfschema identisch. Ist eine URL ohne validen Sprachcode angegeben, oder ist sie nicht abrufbar, dann wird die fehlende Rückbestätigung als gegeben angenommen und der Block mit allen angegebenen URLs devalidiert.

HREFLANG-Validierung

Google unterstützt die Umsetzung von HREFLANG, indem es in der Search Console Fehler mit Sprach-/Regionscodes und fehlende Rückbestätigungen, die im Crawling gefunden werden, listet.

Es gibt noch weitere Validatoren:

Allerdings: Man weiß immer nicht genau, welche Themen wie genau geprüft werden, was uns dazu geführt hat, einen eigenen Validator zu programmieren. So können wir immer ganze Blöcke validieren und haben einen Überblick, was genau abgeprüft wird.

Für weitere Informationen und Details zu HREFLANG empfehlen wir:

Was funktioniert wo?

Suchmaschine HTML-HREFLANG X-HREFLANG XML-HREFLANG Geotargeting Language Meta-Tags HTTP-Language-Tag
Google
Yandex
Bing / Yahoo

Was kannst Du machen, wenn HREFLANG keine Option ist

Nun haben wir einen Überblick über die HREFLANG-Basics. Wir haben die Komplexität gesehen, die eine Implementierung mitbringen kann, und wir können uns vorstellen, dass es organisatorische Setups gibt, in denen eine Umsetzung von HREFLANG nicht möglich ist.

Wenn wir mehrere Fälle künstlich zusammengefasster Länder haben, die Sprache aber auch noch mal anderswo verwenden wollen (“ar-MIDDLE-EAST” oder “ru-EASTERN-EUROPE”), dann macht es eine Einführung von HREFLANG fast unmöglich. Vor ähnlichen Problemen stehen häufig Seiten mit einer hohen Wechselfrequenz im Sortiment, oder Länderversionen mit unabhängigen technischen Setups. Oder gleichem Setup aber komplett unabhängigen Inhalten oder Sortimenten, die nicht einfach normalisierbar sind.

Im Kern gibt es vier Dinge, die geprüft und umgesetzt werden können, um Google und Yandex in der Auswahl der richtigen URL zu unterstützen. Diese Gedanken sind ohnehin sinnvoll, da andere Suchmaschinen HREFLANG überhaupt nicht unterstützen:

  • Meta-Tags: Setze korrekte Meta-Tags: <meta http-equiv="content-language" content="de">
  • Saubere Strukturierung und Trennung der Inhalte: Sorge dafür, dass Meta-Description und Title immer in der korrekten Sprache vorliegen und unique sind. Organisiere die Inhalte logisch nach Sprachen und Regionen, koordiniere die interne Verlinkung und sorge dafür, dass die einzelnen Varianten Silos bilden.
  • HREFLANG-XML: Wenn HREFLANG im HTML keine Option ist, kann eventuell mit der Nutzung der XML-Sitemap-Variante das Problem, dass die Umsetzung im HTML verhindert, umgangen werden.
  • Multi-(Sub-)Domainstrategie + Ländertargeting Search Console: Wenn du verschiedene Domains für die einzelnen Varianten hast: Domains in Google Search Console / Bing Webmaster Tools anmelden und entsprechende Einstellungen für jede Seite vornehmen.

Das sind allerdings Notlösungen. Nur ein sauber implementiertes HREFLANG sorgt dafür, dass Google die Inhalte korrekt zuordnen und dem Nutzer die korrekte Version anzeigen kann. Das führt dann zu einer höheren Nutzerzufriedenheit. Denn es ist schon ärgerlich, wenn in Mexiko jemand nach einem Produkt von dir sucht und die spanische Produktübersichtsseite angezeigt bekommt, in der die Preise anders sind und Produkte angezeigt werden, die du eventuell in Mexiko überhaupt nicht vertreibst.

Das könnte dich auch interessieren

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Ein Kommentar
ErrorInPersona
ErrorInPersona

Wer mit dem Gedanken spielt, hreflang-Tags zu implementieren, sollte dringend beachten, dass hierdurch ggf. ein Gerichtsstsand in einem nderen Land begründet wird.
Hier übersichtlich beschrieben: https://rewis.io/blog/gerichtsstand-hreflang-tags/

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Digitales High Five
Holger Schellkopf (Chefredakteur t3n)

Anleitung zur Deaktivierung