Hreflang richtig einsetzen
Sprach- und Länderversionen für Google, Bing und Yandex eindeutig kennzeichnen
Sprach- und Länderversionen für Google, Bing und Yandex eindeutig kennzeichnen
hreflang kennzeichnet alternative Sprach- oder Regionalversionen eines Dokuments. Die Angabe wird meistens in einem <link rel="alternate">-Element im HTML-<head> verwendet. Sie ist kein Meta-Tag und keine Anweisung zur automatischen Übersetzung.
Suchmaschinen können damit zusammengehörende URLs als Varianten derselben Seite erkennen und Nutzern die passende Version anzeigen. Eine deutschsprachige Seite kann beispielsweise mit einer englischen Übersetzung sowie einer speziell für Österreich lokalisierten deutschen Version verbunden werden.
Hreflang verbessert nicht automatisch das Ranking. Die Auszeichnung hilft bei der Auswahl der geeigneten URL in den Suchergebnissen. Inhaltliche Qualität, technische Indexierbarkeit und die übrigen Ranking-Signale jeder URL bleiben weiterhin entscheidend. Google erkennt die tatsächliche Sprache einer Seite zudem algorithmisch und verwendet weder hreflang noch das HTML-Attribut lang zur Spracherkennung.
Hreflang ist für Seiten gedacht, die inhaltlich dasselbe Ziel erfüllen und sich durch Sprache oder regionale Anpassung unterscheiden. Typische Fälle sind:
de-DE, de-AT und de-CH;Nicht jede URL eines internationalen Websites muss eine Hreflang-Entsprechung besitzen. Eine deutsche Leistungsseite sollte nicht allein deshalb mit der englischen Startseite verbunden werden, weil keine englische Leistungsseite vorhanden ist. Inhaltlich unterschiedliche Dokumente gehören nicht in denselben Hreflang-Cluster.
Der allgemeine HTML-Standard beschreibt den Wert als Sprach-Tag. Suchmaschinen beschränken die praktisch unterstützten Werte jedoch teilweise. Bei Google besteht die gebräuchliche Kennzeichnung aus einem Sprachcode nach ISO 639-1 und optional einem Regionscode nach ISO 3166-1 Alpha-2. Die Sprache steht immer zuerst:
de bezeichnet deutschsprachige Inhalte ohne Einschränkung auf ein Land.de-DE bezeichnet deutsche Inhalte für Nutzer in Deutschland.de-AT bezeichnet deutsche Inhalte für Nutzer in Österreich.de-CH bezeichnet deutsche Inhalte für Nutzer in der Schweiz.zh-Hans und zh-Hant unterscheiden vereinfachte und traditionelle chinesische Schrift nach ISO 15924.Ein alleinstehender Ländercode wie DE ist ungültig. Auch en-UK ist für Google falsch; der Regionscode des Vereinigten Königreichs lautet GB, also en-GB. Besonders tückisch ist be: Der Wert bezeichnet Belarussisch und nicht Belgien. Für Belgien sind beispielsweise de-BE, fr-BE oder nl-BE möglich. Reservierte Regionswerte wie EU, UN oder UK werden von Google nicht als regionale Hreflang-Ziele verarbeitet.
Wer mehrere Regionen derselben Sprache bedient, kann zusätzlich eine allgemeine Sprachversion als Auffangvariante angeben. Neben de-DE, de-AT und de-CH kann beispielsweise de deutschsprachige Nutzer aus allen nicht gesondert definierten Regionen abdecken. Das ist nicht dasselbe wie x-default: de richtet sich weiterhin gezielt an eine Sprache.
https://www.example.de/de/produkt/.Ein vollständiger, auf allen Varianten identischer Satz ist am leichtesten zu warten und zu prüfen. Eine wichtige Feinheit: Google kann auch gegenseitig verknüpfte Teilmengen verarbeiten, wenn bei sehr großen Websites nicht jede Variante mit jeder anderen verbunden werden kann. Neu hinzugefügte Sprachen sollten mindestens bidirektional mit der ursprünglichen oder wichtigsten Sprachversion verbunden sein. Das ist eine zulässige Vereinfachung, aber kein Freibrief für zufällig unvollständige Cluster.
Für drei Varianten einer Leistungsseite kann der identische Satz auf jeder beteiligten URL so aussehen:
<link rel="alternate" hreflang="de" href="https://www.example.com/de/leistung/" />
<link rel="alternate" hreflang="de-AT" href="https://www.example.com/at/leistung/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/service/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/language-selector/" />Die Elemente müssen sich in einem syntaktisch korrekten <head> befinden. Eine serverseitige Ausgabe ist besonders robust. Werden Angaben erst per JavaScript eingesetzt, sollte im gerenderten HTML und mit den Werkzeugen der jeweiligen Suchmaschine kontrolliert werden, ob sie tatsächlich erkannt werden.
Google akzeptiert drei Implementierungswege. Aus Sicht der Google-Suche sind sie gleichwertig. Werden mehrere Wege parallel verwendet, entsteht kein zusätzlicher Rankingvorteil, aber mehr Aufwand und ein höheres Risiko widersprüchlicher Angaben.
| Suchmaschine | HTML-Head | HTTP-Link-Header | XML-Sitemap | Besonderheit |
|---|---|---|---|---|
| Unterstützt | Unterstützt | Unterstützt | Die drei Methoden sind gleichwertig; eine sauber gepflegte Methode genügt. | |
| Bing | Dokumentiert | Keine eindeutige aktuelle Angabe | Keine eindeutige aktuelle Angabe | Microsoft empfiehlt Hreflang für Sprach- und Regionalvarianten, dokumentiert die Methoden aber weniger umfassend als Google. |
| Yandex | Unterstützt | Keine eindeutige aktuelle Angabe | Nicht mehr unterstützt | Yandex empfiehlt die lokalisierte Auszeichnung mit <link> im HTML-Head. |
Für Websites, die gleichzeitig in Google, Bing und Yandex gefunden werden sollen, ist die HTML-Variante deshalb meist der praktikabelste gemeinsame Nenner. HTTP-Link-Header sind bei Google vor allem für nicht auf HTML basierende Dokumente wie PDF-Dateien nützlich. Bei sehr großen Google-Projekten kann eine Sitemap die Verwaltung erleichtern; für Yandex muss die Auszeichnung dennoch im HTML erfolgen.
Eine weitere Besonderheit: Yandex verweist neben ISO 3166-1 Alpha-2 auch auf ISO 3166-2:RU für russische Regionen. Damit dokumentiert Yandex eine feinere regionale Zuordnung als das bei Google gebräuchliche Modell aus Sprache und optionalem Ländercode. Solche suchmaschinenspezifischen Werte sollten vor einer umfangreichen Einführung mit realen URLs und in Yandex Webmaster getestet werden.
In einer für Google bestimmten Sitemap wird jede URL einzeln aufgeführt. Innerhalb jedes <url>-Elements stehen alle Varianten einschließlich der jeweiligen URL selbst. Außerdem ist der XHTML-Namespace erforderlich:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://www.example.com/de/leistung/</loc>
<xhtml:link rel="alternate" hreflang="de"
href="https://www.example.com/de/leistung/" />
<xhtml:link rel="alternate" hreflang="en"
href="https://www.example.com/en/service/" />
</url>
<url>
<loc>https://www.example.com/en/service/</loc>
<xhtml:link rel="alternate" hreflang="de"
href="https://www.example.com/de/leistung/" />
<xhtml:link rel="alternate" hreflang="en"
href="https://www.example.com/en/service/" />
</url>
</urlset>Die xhtml:link-Elemente zählen bei Google nicht gegen das allgemeine URL-Limit einer Sitemap. Trotzdem kann eine große Zahl von Sprachvarianten die Dateien umfangreich und fehleranfällig machen.
rel="canonical" und hreflang erfüllen unterschiedliche Aufgaben. Canonical bezeichnet die bevorzugte URL innerhalb einer Gruppe gleicher oder nahezu gleicher URLs. Hreflang ordnet Sprach- und Regionalvarianten einander zu.
In der Regel sollte jede Sprachversion auf sich selbst oder auf eine kanonische URL derselben Sprache verweisen. Zeigt die deutsche Seite per canonical auf die englische Seite, während Hreflang beide als eigenständige Sprachvarianten auszeichnet, entstehen widersprüchliche Signale. Google empfiehlt bei Hreflang eine kanonische Seite in derselben Sprache oder, falls keine existiert, den bestmöglichen sprachlichen Ersatz.
<!-- Auf der deutschen URL -->
<link rel="canonical" href="https://www.example.com/de/leistung/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/leistung/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/service/" />Parameter-URLs, HTTP-Versionen, Weiterleitungsziele und andere technische Duplikate sollten zuerst konsistent kanonisiert werden. In den Hreflang-Angaben stehen anschließend die kanonischen, indexierbaren URLs.
hreflang="x-default" kennzeichnet eine Fallback-URL für Nutzer, deren Sprache oder Region durch keine andere Variante abgedeckt wird. Der Wert ist besonders für eine neutrale Startseite, eine Sprach- und Länderauswahl oder eine automatische Auswahlseite geeignet.
x-default bedeutet nicht, dass diese URL die kanonische oder wichtigste Seite des Clusters ist. Dieselbe URL kann gleichzeitig als allgemeine Sprachversion gekennzeichnet werden, beispielsweise mit hreflang="en", und zusätzlich als Fallback dienen. Ob das sinnvoll ist, hängt vom Inhalt und der Navigationslogik ab.
UK statt GB oder be für Belgien.noindex ausgeschlossene oder nicht crawlbare URLs.Ein Hreflang-Fehler führt normalerweise nicht zu einer manuellen Abstrafung. Die Suchmaschine kann fehlerhafte oder widersprüchliche Angaben jedoch ignorieren und eine andere Sprach- oder Regionalversion anzeigen als beabsichtigt.
Bei großen Websites sollte nicht nur eine einzelne Seite getestet werden. Entscheidend ist der gesamte Cluster: Eine scheinbar korrekte URL kann trotzdem wirkungslos bleiben, wenn ihre Alternativen falsche Rückverweise, Canonicals oder Statuscodes liefern.
Die technische Zuordnung allein macht eine Seite noch nicht relevant für einen Markt. Gute internationale SEO berücksichtigt Suchbegriffe, Terminologie, Suchintention, Währung, Maßeinheiten, rechtliche Vorgaben, Liefergebiete, lokale Kontaktmöglichkeiten und kulturelle Erwartungen. Eine wortgetreue Übersetzung kann technisch korrekt ausgezeichnet und trotzdem inhaltlich am Zielmarkt vorbeigehen.
Auch die URL-Struktur bleibt eine eigenständige Entscheidung. Länderdomains, Subdomains und Unterverzeichnisse können mit Hreflang verwendet werden; die Varianten dürfen sogar auf unterschiedlichen Domains liegen. Hreflang repariert jedoch keine unklare Informationsarchitektur und ersetzt weder interne Sprachlinks noch eine frei zugängliche Sprach- und Länderauswahl.
Die Angaben dieses Beitrags wurden anhand der Standards und der aktuellen Dokumentation der Suchmaschinen zusammengestellt: