Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

HREFLANG richtig nutzen: So wird dein SEO auch international erfolgreich

(Grafik: Shutterstock)

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.

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.

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

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

Abbrechen