Das Hreflang Tag für internationale Websites

Viele Unternehmen haben ihre Websites nicht nur in einer Sprache oder nur für ein einziges Land, sondern bieten Inhalte in verschiedenen Sprachen oder für verschiedene Länder bzw. Regionen oder Märkte an.
Damit mehrsprachige bzw. internationale Websites bei Suchmaschinen auch gut und richtig ranken, gibt es neben dem Inhalt auch aus technischer Sicht einiges zu beachten.

Targeting Strategie: Sprache oder Land?

In einem ersten Schritt sollte man entscheiden, welche Strategie für ein Projekt verfolgt wird. Zielt man mit verschiedenen Versionen auf User ab, die unterschiedliche Sprachen sprechen oder eher doch auf User in verschiedenen Ländern oder Regionen?

Von dieser Grundsatzentscheidung hängt ab, auf welche Weise die verschiedenen Versionen zur Verfügung gestellt werden sollen.

Was hier die richtige Strategie ist, hängt stark vom einzelnen Projekt ab. Ausschlaggebend sind oft organisatorische Aspekte in der „Offline Welt“:

• Hat man überall das gleiche Sortiment, oder gibt es marktspezifische Produkte?
• In welche Länder kann und will man überhaupt versenden?
• Unterscheiden sich Produkte und Inhalte überhaupt für User, die dieselbe Sprache sprechen (D-A-CH)?
• …

Die Wahl des richtigen Targetings ist sehr wichtig und es sollten klare Ziele definiert und alle Faktoren berücksichtigt werden, bevor eine Entscheidung getroffen wird.

Domainstrategie: Welche Struktur ist die richtige?

Um verschiedene Versionen technisch voneinander zu trennen, gibt es drei Möglichkeiten, die von Google empfohlen werden:

• eigene ccTLDs für jedes Land
• Subdomains
• Subfolder

Eine Auslieferung des richtigen Inhalts via URL-Parameter (also z.B. domain.com?loc=de) sieht Google nicht gern (obwohl man bei Google selbst damit arbeitet), weshalb darauf verzichtet werden sollte.

Jede der drei Möglichkeiten hat ihre spezifischen Vor- und Nachteile. So sind eigene ccTLDs natürlich in erster Linie dann sinnvoll, wenn man sich in seiner Targeting-Strategie entschieden hat, seine Inhalte auf Länder auszurichten.

Länderspezifische Top-Level-Domains können auch Sinn machen, weil Google sie auch in seinen Ländervarianten entsprechend höher listet. Eine domain.fr Seite rankt auf Google.fr meist besser als eine domain.ch Seite, auch wenn beide auf Französisch sind, vorausgesetzt alle anderen Faktoren sind gleich.

Subdomains und Subfolder sollten nur verwendet werden, wenn die Hauptdomain keine länderspezifische Endung hat, sondern eine generische TLD ist: Eine Subdomain at.domain.com ist gut, eine Subdomain at.domain.fr eher suboptimal.

Auch Kombinationen der drei Varianten für kompliziertere Setups sind möglich; etwa eine Trennung verschiedener Länder über ccTLD und innerhalb von Sprachen über Sufolder. Während etwa die Versionen für Österreich, Deutschland und die Schweiz über .de, .at und .ch getrennt werden, kann es für die Schweiz vielleicht eine deutsche und französische Sprachvariante auf .ch/de/ und .ch/fr/ geben.

Neben der Kostenfrage – viele eigene ccTLDs bedeuten höhere Kosten – ist auch zu bedenken, dass man für eigene ccTLDs und Subdomains später eigenen Linkaufbau betreiben muss.
Subfolder dagegen profitieren direkt von der Autorität der Domain, da „Page Rank“ innerhalb der Website ungehindert fließen kann. 
Subdomains hingegen werden als eigenständige Domains gesehen, die nicht notwendigerweise von der Hauptdomain profitieren.

Beispiel

Nehmen wir an wir haben einen kleinen Webshop, der sich an Kunden in Deutschland und in Österreich wendet. Für jedes Land hat dieser Shop eine eigene Version, weil sich zum Beispiel die Preise, Versandkosten und andere Kleinigkeiten unterscheiden. Im Prinzip gleichen sich die beiden Versionen stark. Außerdem gibt es auch noch eine englische Version des Shops. Insgesamt haben wir also 3 Versionen – zwei deutschsprachige und eine auf Englisch.

Wir haben uns entschieden die drei Versionen auf einer gemeinsamen, generischen TLD laufen zu lassen und über Subfolder zu unterscheiden. Unsere drei Startseiten liegen also unter:

https://www.meinshop.com/de/
https://www.meinshop.com/at/
https://www.meinshop.com/en/

hreflang: Versionen für Suchmaschinen verknüpfen

Haben wir uns für eine Domainstrategie entschieden, gilt es nun die verschiedenen Sprach- bzw. Länderversionen für Google korrekt miteinander zu verknüpfen. Zu diesem Zweck gibt es die sogenannten hreflang-Auszeichnungen.
Ziel dieser Auszeichnung ist es, Googlebot zu zeigen, dass es den Inhalt einer bestimmten Seite auch in der Sprache x für die Region Y gibt, und wo dieser liegt.
Ausgeben kann man diese Verknüpfungen entweder im HTML-Head, als Zusatzinformation in einer XML-Sitemap oder auch per HTTP-Header.

Besonders wichtig werden die hreflang-Auszeichnungen, wenn es verschiedene Versionen für User in unterschiedlichen Ländern gibt, die aber alle dieselbe Sprache sprechen:
Mittels hreflang-Attributen kann man dann klarmachen, dass zum Beispiel zwei fast idente Seiten zu ein und demselben Produkt eben kein „Duplicate Content“ sind, sondern, dass sich z.B. Seite A an User in Deutschland richtet und Seite B an User in Österreich.

Beispiel

In unserem Beispiel können wir Suchmaschinen mittels hreflang klarmachen, wie unsere drei Versionen zueinander im Verhältnis stehen und so dafür sorgen, dass Google jeweils die richtige Version listet. Also eben Usern in Deutschland die deutschsprachige Version für Deutschland in den Ergebnissen anzeigt, aber für User in Österreich die deutschsprachige Version für Österreich. Nutzern, die auf Englisch suchen, soll dagegen die englischsprachige Version in den Suchergebnissen angezeigt werden.

Die hreflang-Auszeichnungen auf unseren drei Startseiten würden entsprechend so aussehen:

<link rel="alternate" hreflang="de-DE" href="https://www.meinshop.com/de/" />
<link rel="alternate" hreflang="de-AT" href=" https://www.meinshop.com/at/" />
<link rel="alternate" hreflang="en" href=" https://www.meinshop.com/en/" />

Im hreflang-Atrribut der, hier als HTML Tag ausgegebenen, Auszeichnung wird das passende Sprach- bzw. Regionalkürzel angebenden Die ersten beiden Buchstaben stehen immer für die Sprache, die hinteren beiden geben optional eine Region an

hreflang: Regeln für ein valides Mark-Up

Damit die hreflang-Auszeichnungen valide sind und von Google auch beachtet werden, ist es wichtig einige Regeln zu beachten.

Alle verfügbaren Versionen listen…wenn es sie denn auch gibt

Die oberste Regel lautet, sobald es einen Inhalt als weitere Version für einen anderen Zielmarkt gibt, muss das hreflang-Markup auf allen diesen Versionen ausgegeben werden.
Denn die hreflang-Tags müssen zum einen immer selbstreferenziell sein – also sich selbst mitführen – und sie brauchen Bestätigungs-Rücklinks von allen geführten alternativen Versionen.

In der Praxis heißt das: Gibt es drei Versionen, erscheint auf allen drei URLs der idente Block. Also eine Auflistung aller alternativer Versionen mit dem Hinweis für welche Zielgruppe die jeweiligen Versionen gedacht sind und wo, also unter welcher URL, diese zu finden sind. Die Reihenfolge der Sprachen ist dabei egal.
Damit verweist jede URL immer auf SICH SELBST, alle ANDEREN Versionen und bekommt damit auch von allen anderen Versionen einen RÜCKLINK.

Auf Unterseiten müssen natürlich die alternativen Versionen der jeweiligen Unterseite verknüpft sein, und nicht etwa die Startseite. Gibt es eine bestimmte Unterseite nur in einer Sprache, z.B. weil deren Inhalt nur für User in Deutschland relevant ist, aber nicht für User im Ausland, dann darf auch kein hreflang-Link auf nicht existente alternative Sprachversion zeigen.
Denn listet man trotzdem eine URL, die gar nicht existiert (also einen 404-Fehler zurückwirft), kann von dort auch kein Rücklink kommen.

Korrekte Sprach- und Länderkürzel

Wichtig ist, dass die richtigen Sprach bzw. Länderkürzel verwendet werden. Je nach Projekt kann entweder nur eine Sprache angegeben werden oder eine Sprache für User in einer bestimmten Region.

Beispiel

In unserem Beispiel gibt es eine englische Version für alle User, die Englisch sprechen – egal wo sie sind.

hreflang="en"

Und je eine Version für User, die Deutsch sprechen, und in Deutschland

hreflang="de-DE"

oder eben Österreich

hreflang="de-AT"

sind. Während man auch nur die Sprache alleine angeben kann, ist ein Ländercode ohne Sprache nicht valide!

Die Sprach- und Ländercodes müssen dabei den ISO Standard verwenden. Die Sprache folgt dem Format ISO 639-1 und die Region dem Format ISO 3166-1 Alpha 2!

Auszeichnungen wie „en-UK“ (für Englisch für alle User im Vereinigten Königreich) gibt es nicht. Der korrekte Ländercode ist GB (Great Britain). Es müsste dann also „en-GB“ lauten.

Absolute URLs verwenden

Nicht nur bei Sprach- und Länderkürzeln sollte man aufpassen, auch bei der angegebenen URL ist es wichtig, dass die alternative Version als absoluter Link, also mit Domain inklusive Protokoll angegeben wird.

href="https://www.meinshop.com/de/"

X-default

Eine Besonderheit bei den hreflang-Sprachverküpfungen stellt der x-default Wert da, der statt des Sprach- bzw. Länderkürzels verwendet werden kann. Das x-default kann dabei 2 verschiedene Funktionen übernehmen. Einerseits dient es dazu, eine Sprachweiche zu kennzeichnen, andererseits um eine Fallback-Version zu definieren.

X-default als Sprachweiche

Gibt es auf einer Startseite die Option, die Sprache auswählen zu können, sollte auch das den Suchmaschinen signalisiert werden. Das x-default Tag macht Google dann darauf aufmerksam, dass sich diese Seite an User unabhängig von Sprache und Region richtet.

In unserem Beispiel könnte etwa auf der Domain-Root eine Sprachweiche liegen. Dementsprechend müsste die Root ebenfalls als Variante der Startseiten ausgegeben werden:

<link rel="alternate" hreflang="de-DE" href="https://www.meinshop.com/de/" />
<link rel="alternate" hreflang="de-AT" href=" https://www.meinshop.com/at/" />
<
link rel="alternate" hreflang="en" href=" https://www.meinshop.com/en/" />
<link rel=”alternate” hreflang="x-default" href="https://www.meinshop.com/"/>

x-Default als Fallback

Außerdem kann der x-default Wert auch dazu eingesetzt werden, um eine „Fallback-Version“ von Unterseiten für User, deren Sprache nicht eigens verfügbar ist, auszuzeichnen. Hier kann eine der verfügbaren Versionen einfach ein zweites Mal mit dem x-default Wert geführt werden.

Möchten wir festlegen, dass auch User, die zum Beispiel auf Italienisch nach unseren Produkten suchen, auch die englische Version unserer Seite in der Google Suche finden sollen, würden wir unsere englische Version entsprechend doppelt listen:

<link rel="alternate" hreflang="de-DE" href="https://www.meinshop.com/de/ueber-uns" />
<link rel="alternate" hreflang="de-AT" href="https://www.meinshop.com/at/ueber-uns" />
<link rel="alternate" hreflang="en" href="https://www.meinshop.com/en/about" />
<link rel="alternate" hreflang="x-default" href="https://www.meinshop.com/en/about" />

hreflang in Verbindung mit Canonical

Eine häufige Fehlerquelle beim Einsatz von hreflang-Tags ist das Zusammenspiel von Canonical Tags mit den Sprachauszeichnungen.
Grundsätzlich können beide miteinander verwendet werden. Es ist aber wichtig, dass hreflang- und Canonical-Tags keine widersprüchlichen Signale an Google senden.

Canonical Tags kommen zum Einsatz, wenn es einen Inhalt aus technischen oder strukturellen Gründen nicht nur auf einer URL gibt, sondern ein und dieselbe Seite auf mehreren URLs erreichbar ist. Per Canonical kann dann eine URL als kanonische Version definieren und damit festlegen, dass genau diese URL indexiert werden soll.

In unserem Beispiel könnte es etwa sein, dass im Shop ein Produkt in verschiedenen Kategorien gelistet wird:

https://www.meinshop.com/de/kategorie1/produkt1/
https://www.meinshop.com/de/kategorie2/produkt1/
https://www.meinshop.com/de/kategorie3/produkt1/

Damit Google weiß, welche URL für das Produkt indexiert werden soll, könnte das Canonical Tag genutzt werden, um das Produkt in der ersten Kategorie als „Original“ zu kennzeichnen:

<link rel="canonical" href="https://www.meinshop.com/de/kategorie1/produkt1/">

Weil das die einzige Version ist, die Google indexieren soll, brauchen wir auch nur hier die hreflang-Auszeichungen. Es dürfen also nur kanonische Versionen miteinander verknüpft werden. Auf der kanonischen Version https://www.meinshop.com/de/kategorie1/produkt1/ fänden wir also das selbstreferenzielle Canonical GEMEINSAM mit den hreflang-Tags:

<link rel="alternate" hreflang="de-DE" href="https://www.meinshop.com/de/kategorie1/produkt1/" />
<link rel="alternate" hreflang="de-AT" href="https://www.meinshop.com/at/kategorie1/produkt1/" />
<link rel="alternate" hreflang="en" href="https://www.meinshop.com/de/category1/product1/" />
<link rel="alternate" hreflang="x-default" href="https://www.meinshop.com/de/category1/product1/" />
<link rel="canonical" href="https://www.meinshop.com/de/kategorie1/produkt1/">

Auf nicht kanonischen Seiten, also Seiten, die per Canonical auf andere URLs verweisen, dürfen KEINE hreflang Tags stehen. In unserem Beispiel stünde also auf

https://www.meinshop.com/de/kategorie2/produkt1/
https://www.meinshop.com/de/kategorie3/produkt1/

nur das Canonical Tag auf die kanonische Version:
<link rel="canonical" href="https://www.meinshop.com/de/kategorie1/produkt1/">

hreflang-Implementierung

Die gute Nachricht gibt’s am Ende: Wer seine Website mit verbreiteten CMS wie z.B. WordPress, Drupal oder Joomla umsetzt, der findet bereits fertige Plugins oder Module mit denen Mehrsprachigkeit gut umgesetzt werden kann und die bei korrektem Setup dann auch die hreflang-Tags korrekt ausgeben.