Entschlüssele deine SEO-Daten

hreflang tags implementation guide - Wie man hreflang implementiert

Die Implementierung von hreflang-Anmerkungen kann schwierig sein und wird oft falsch gemacht. Hier erfährst du, wie du deine hreflang-Anmerkungen richtig umsetzt.

Webmaster, die mehrere Versionen ihrer Inhalte in verschiedenen Sprachen oder für Nutzer in verschiedenen Ländern bereitstellen, sollten die hreflang-Anmerkungen um Google zu helfen, die richtige Version in den Suchergebnissen für jeden Nutzer anzuzeigen.

Hinweis: Dieser Leitfaden wurde erstmals 2014 auf rebelytics.com veröffentlicht und seither mehrmals aktualisiert und in diesen Blog verschoben.

Die korrekte Umsetzung der hreflang kann eine ziemliche Herausforderung sein. Mit diesem Leitfaden möchte ich dir helfen, eine korrekte Implementierung für deine Website zu entwickeln. Allerdings gibt es keine Einheitslösung für hreflang. Wenn also irgendetwas unklar bleibt, Du kannst gerne deine Fragen stellen im Kommentarbereich dieses Artikels. Ich antworte normalerweise innerhalb von ein paar Tagen.

Google gibt zwar Anweisungen für die Implementierung von hreflang, aber wenn du dir ansiehst, wie hreflang auf den meisten Websites implementiert wird, wird klar, dass Webmaster diese Anweisungen oft missverstehen. Bevor du diesen Artikel weiterliest, solltest du dir trotzdem die Anweisungen von Google ansehen hier.

Nachdem du die offiziellen Anweisungen von Google gelesen hast, kannst du die Ratschläge in diesem Artikel befolgen, um die häufigsten Fehler zu vermeiden und einige zusätzliche Tipps zu erhalten.

Los geht's! Das sind die Schritte, durch die ich dich leiten möchte. Wie implementierst du hreflang richtig?

Schritt 1: Bestimme, ob du hreflang-Anmerkungen auf deiner Website brauchst

Es ist ganz einfach: Sobald es mehr als eine Version deiner Website für Nutzer/innen aus verschiedenen Ländern gibt oder wenn deine Website in verschiedenen Sprachen verfügbar ist, solltest du in Betracht ziehen, hreflang-Anmerkungen auf deiner Website zu implementieren.

Hier sind einige typische Beispiele für Websites, die hreflang-Kommentare benötigen:

  • Beispiel 1: Eine Website in englischer Sprache mit einer Version für die USA, einer Version für Großbritannien und einer Version für den Rest der Welt.
  • Beispiel 2: Eine internationale Website mit englischen, französischen und spanischen Sprachversionen.
  • Beispiel 3: Eine globale Website mit einer Version für Europa, einer für die USA und Kanada und einer für Asien/Pazifik, alle in englischer Sprache.
  • Beispiel 4: Eine Website, die sich an Nutzer in den USA richtet, hat eine englische und eine spanische Sprachversion.
  • Beispiel 5: Eine Website mit mehreren Länderdomains, von denen einige mehr als eine Sprachversion haben (für Länder, in denen mehr als eine Sprache gesprochen wird).

Wir werden diese Beispiele in diesem Leitfaden durchgängig verwenden und eine korrekte hreflang-Implementierung für alle diese Beispiele entwickeln.

Ist deine Website einem der oben genannten Beispiele ähnlich? In diesem Fall brauchst du höchstwahrscheinlich eine hreflang-Implementierung. Beginnen wir damit, uns ein genaueres Bild von der Struktur deiner internationalen oder mehrsprachigen Website zu machen.

Schritt 2: Erstelle eine Karte mit den Sprach- und Länderversionen deiner Website

Der Zweck von hreflang-Anmerkungen ist es, Google zu signalisieren, dass es mehrere Versionen einer URL für Nutzerinnen und Nutzer in verschiedenen Sprachen oder aus verschiedenen Ländern gibt. URLs für Nutzer/innen derselben Sprache oder desselben Landes werden normalerweise in Sprach- oder Länderversionen einer Website zusammengefasst. Um herauszufinden, welche hreflang-Werte die einzelnen URLs auf deiner Website erhalten sollen, solltest du zunächst genau festlegen, an welche Nutzer deine verschiedenen Website-Versionen gerichtet sind.

Ich schlage vor, dass du zunächst eine Tabelle mit den folgenden drei Spalten erstellst:

  • Website-Version: Die Versionen deiner Website können sich in verschiedenen Unterverzeichnissen auf derselben Domain, auf verschiedenen Subdomains oder auf verschiedenen Domains befinden.
  • Sprache: Jeder Website-Version kann genau eine Sprache zugewiesen werden, nämlich die Sprache des Inhalts dieser Version. Achte darauf, dass du die Sprachen innerhalb der Website-Versionen nicht vermischst.
  • Länder: Nicht zuletzt kann jede Website-Version Nutzer/innen in einer beliebigen Anzahl von Ländern ansprechen, von einem Land bis zu allen Ländern der Welt.

Für manche Websites mag diese Tabelle sehr einfach sein, aber für andere, vor allem für Websites mit vielen verschiedenen Versionen, ist dieser Ansatz sehr hilfreich.

Erinnern wir uns an die Beispiele für verschiedene internationale oder mehrsprachige Website-Strukturen aus dem vorherigen Schritt und schauen wir uns an, wie die Strukturkarte für diese Beispiele aussehen würde.

Beispiel 1: Eine Website in englischer Sprache mit einer Version für die USA, einer Version für Großbritannien und einer Version für den Rest der Welt.

[table id=1 /]

Dies ist ein typisches Beispiel für Unternehmen aus dem Vereinigten Königreich oder den USA, die bereits in den anderen Markt expandiert haben und zusätzlich englischsprachige Nutzer aus dem Rest der Welt ansprechen wollen. Beachte, dass hier der britische Inhalt auf einer .co.uk-Domain gehostet wird, aber er könnte genauso gut auf der .com-Domain gehostet werden, wie die beiden anderen Versionen. Dieses Beispiel soll nur zeigen, dass hreflang auf verschiedenen Domains implementiert werden kann.

Beispiel 2: Eine internationale Website mit englischen, französischen und spanischen Sprachversionen.

[table id=2 /]

[table id=2 /] Dies ist ein Beispiel für ein Unternehmen, das Nutzer weltweit in verschiedenen Sprachen anspricht, ein Szenario, das man oft bei standortunabhängigen Unternehmen im B2B-Bereich, wie SaaS oder ähnlichen Branchen, sieht. Alle drei Sprachversionen werden auf der .com-Domain in verschiedenen Unterverzeichnissen gehostet.

Beispiel 3: Eine globale Website mit einer Version für Europa, einer für die USA und Kanada und einer für Asien/Pazifik, alle in englischer Sprache.

[table id=3 /]

[table id=3 /] Globale Marken unterteilen ihre Webpräsenzen oft in Versionen für Wirtschaftszonen oder Kontinente, und diese Struktur spiegelt oft die Organisationsstruktur des Unternehmens auf oberster Ebene wider. Obwohl ich einen nutzerzentrierteren Ansatz für die Strukturierung von Website-Versionen bevorzugen würde, ist dies ein Szenario, das wir in der Realität häufig sehen und für das wir eine gute hreflang-Lösung brauchen. Die gemischte Domain- und Subdomain-Struktur würde ich auch nicht unbedingt empfehlen, aber Strukturen wie diese gibt es und sollten berücksichtigt werden. Wenn deine Website-Struktur diesem Beispiel ähnelt, wird dieser Leitfaden eine Lösung für dich bereithalten!

Beispiel 4: Eine Website, die sich an Nutzer in den USA richtet, hat eine englische und eine spanische Sprachversion.

[table id=4 /]

Diese Website-Struktur wirst du häufig in Ländern sehen, in denen mehr als eine Sprache gesprochen wird. Das Land und die Sprachen in diesem Beispiel können ersetzt werden und du wirst diese Struktur oft auf einer länderspezifischen Domain sehen, wie .be für Belgien oder .ca für Kanada.

Beispiel 5: Eine Website mit mehreren Länderdomains, von denen einige mehr als eine Sprachversion haben (für Länder, in denen mehr als eine Sprache gesprochen wird).

[table id=5 /]

Das letzte Beispiel, das wir in diesem Leitfaden betrachten, ist typisch für E-Commerce-Unternehmen, die in mehreren Ländern tätig sind. Während B2B-Unternehmen dazu neigen, globale Sprachversionen den Länderversionen vorzuziehen, bevorzugen Online-Shops und andere B2C-Unternehmen oft Länderversionen. Länderspezifische Versionen können auf länderspezifischen Domains gehostet werden, wie in diesem Beispiel, aber sie können auch auf Subdomains oder in Unterverzeichnissen einer generischen Domain gehostet werden.

Ich habe in den obigen Beispielen absichtlich verschiedene Strategien für Domains, Subdomains und Unterverzeichnisse gemischt, um dir zu zeigen, dass du hreflang für fast alle Kombinationen von Domains, Subdomains und Unterverzeichnissen einsetzen kannst.

Eine Anmerkung zu internationalen Domainstrategien: Mein Lieblingsansatz ist es, verschiedene Domains und Subdomains zu vermeiden und alle Website-Versionen in verschiedenen Unterverzeichnissen auf derselben Domain zusammenzufassen. Ich habe gute Argumente dafür, aber ich werde sie in diesem Artikel nicht besprechen und auch nicht heute 😉 Ruf mich an, wenn du mit mir über internationale Domain-Strategien sprechen möchtest!

Hast du die Struktur deiner internationalen oder mehrsprachigen Website geplant? Ich hoffe es! Wenn du eine internationale oder mehrsprachige Website-Struktur hast, die sich völlig von den hier aufgeführten Beispielen unterscheidet, würde ich gerne davon hören! Fahren wir nun mit Schritt 3 fort...

Schritt 3: Überprüfe deine Website-Struktur und Domain-Strategie

Wenn du den vorherigen Schritt aufmerksam gelesen hast, hast du wahrscheinlich bemerkt, dass ich gesagt habe, dass du hreflang über fast alle Kombinationen von Domains, Subdomains und Unterverzeichnissen. Achtung, es gibt eine wichtige Regel, die du bei der Entwicklung deiner hreflang-Implementierungsstrategie beachten musst:

Google interpretiert Inhalte auf länderspezifischen Domains (ccTLDs) automatisch als auf Nutzer/innen aus genau einem Land ausgerichtet.

ccTLDS (country code top-level domains) sind im Gegensatz zu gTLDs (generic top-level domains) Domains, die mit einem bestimmten Land verbunden sind. gTLDs hingegen sind nicht länderspezifisch.

Das hat wichtige Konsequenzen für dein internationales Targeting. Mit einem Unterverzeichnis oder einer Subdomain auf einer ccTLD (d.h. einer Länderdomain) solltest du nur Nutzer/innen aus dem Land ansprechen, mit dem deine ccTLD verbunden ist.

Suchst du nach Beweisen für das, was ich sage? Gehe zu einer Google Search Console-Eigenschaft für eine gTLD, öffne den Bericht Suchverkehr > Internationales Targeting, Ändere den Reiter auf “Land” und sieh dir die Optionen an, die du hier hast, um deine Inhalte auf Nutzer aus einem bestimmten Land auszurichten.

Du wirst sehen, dass du für jede Eigenschaft einer gTLD, die du in der Google Search Console überprüfst, auswählen kannst, ob der Inhalt dieser Eigenschaft auf Nutzer aus einem bestimmten Land ausgerichtet werden soll. Diese Targeting-Option wird später in diesem Leitfaden wichtig für dich, wenn du mit den Inhalten einer gTLD Nutzer in bestimmten Ländern ansprechen willst.

Gehe jetzt zu demselben Bericht in der Google Search Console für eine ccTLD und versuche, das Land in der Option “Nutzer ansprechen in ...“ zu ändern, die du gerade in der Eigenschaft für die gTLD gesehen hast. Verstehst du, worauf ich hinaus will?

Internationale Targeting-Optionen in der Google Search Console

Bei ccTLDs kannst du bei Google kein Land angeben. Vielmehr wird das Land bereits durch die von dir gewählte ccTLD festgelegt. Mehr über diese Targeting-Option erfährst du in Schritt 10. Lass uns erst einmal sehen, was du tun kannst, um Probleme damit zu vermeiden.

Das folgende Beispiel würde nicht funktionieren, da du versuchen würdest, Nutzer außerhalb Großbritanniens mit einer ccTLD anzusprechen, die mit Großbritannien (.co.uk) verbunden ist:

[table id=6 /]

Wenn du ccTLDs verwendest, zielst du in den Augen von Google mit den Inhalten auf deiner Domain automatisch auf Nutzer/innen aus dem entsprechenden Land und nicht auf Nutzer/innen aus anderen Ländern.

Bevor du fortfährst, solltest du sicherstellen, dass du im vorherigen Schritt keine Struktur geschaffen hast, bei der eine Website-Version, die auf einer ccTLD gehostet wird, Nutzer in anderen Ländern als dem mit der ccTLD verbundenen Land anspricht.

Das gilt auch für die Targeting-Optionen “Rest der Welt” oder “Alle Länder”. Website-Versionen, die sich an Nutzer/innen in mehreren Ländern richten, sollten immer auf gTLDs gehostet werden.

Apropos gTLDs, von denen ich (falls du es noch nicht bemerkt hast) ein großer Fan bin, lass uns einen Blick auf ein Potenzial von mehrsprachigen und internationalen Websites werfen, das viele Unternehmen verpassen: Hast du eine Website-Struktur mit mehreren Versionen für verschiedene Länder, aber keine Version für den Rest der Welt? Warum solltest du dir mehr potenziellen Traffic entgehen lassen, wenn du keine Website-Version für Nutzer/innen außerhalb deines Hauptzielmarktes erstellst?

Nehmen wir an, du hast eine Website mit mehreren Länderversionen (unabhängig davon, ob du sie unter einer gTLD oder ccTLD hostest), aber keine generischen Sprachversionen für Nutzer in anderen Ländern. Deine Struktur könnte so aussehen wie die, die wir bereits oben gesehen haben (Beispiel 5):

[table id=5 /]

Hier wäre es sinnvoll, generische Sprachversionen unter einer gTLD in den Sprachen hinzuzufügen, die wir bereits haben, um Nutzer außerhalb der Märkte, für die wir bereits Website-Versionen haben, besser anzusprechen. Damit hätten wir die folgende Struktur:

[table id=7 /]

Diese Struktur zielt auf die gleichen Nutzer wie in Beispiel 5 ab, bietet aber zusätzlich Website-Versionen für Nutzer in anderen Ländern, die eine der bereits verfügbaren Sprachen sprechen. Da die Sprachen bereits verfügbar sind, ist es normalerweise kein großer Aufwand, diese zusätzlichen Versionen einer Website hinzuzufügen, und auf diese Weise kann viel zusätzlicher Suchverkehr generiert werden.

Nachdem wir nun sichergestellt haben, dass du eine gute internationale oder mehrsprachige Domainstruktur hast, können wir einen hreflang-Wert für jede Website-Version definieren. Der nächste Schritt ist ganz einfach, also lass uns schnell weitermachen:

Schritt 4: Weise jeder Sprach- und Länderversion einen hreflang-Wert zu

Mit all der guten Vorbereitung, die wir in den vorherigen Schritten gemacht haben, kann hier nicht viel schiefgehen. Es gibt ein paar einfache Regeln, die wir bei der Definition von hreflang-Werten für unsere Website beachten müssen:

  • Jeder hreflang-Wert besteht aus einem Sprachcode und, optional, einem Ländercode. Der Sprachcode und der Ländercode werden durch einen Bindestrich getrennt.
  • Die Sprachcodes müssen das folgende Format haben ISO 639-1, die Ländercodes in dem Format ISO 3166-1 Alpha-2.
  • Jeder hreflang-Wert kann nur einmal zugewiesen werden. Das bedeutet, dass du nicht zwei Website-Versionen haben kannst, die sich an Nutzer/innen derselben Sprache und desselben Landes richten. Jede Kombination aus Sprache und Land muss in deiner hreflang-Struktur eindeutig sein.
  • URLs können erhalten mehrere hreflang-Werte. Das ist besonders praktisch bei Beispielen wie Nr. 3. 3 oben, wo eine Website-Version für Nutzer in mehreren Ländern, aber nicht in allen Ländern der Welt gedacht ist.

Fügen wir nun eine vierte Spalte zu unserer Website-Strukturtabelle von vorhin hinzu und legen los!

Beispiel 1: Eine Website in englischer Sprache mit einer Version für die USA, einer Version für Großbritannien und einer Version für den Rest der Welt.

[table id=8 /]

Hier erhält die englische Version für Nutzer im Rest der Welt nur den Sprachcode für Englisch, während die beiden Länderversionen für die USA und Großbritannien die optionalen Ländercodes erhalten.

Beispiel 2: Eine internationale Website mit englischen, französischen und spanischen Sprachversionen.

[table id=9 /]

Die Website-Versionen in diesem Beispiel sind nicht länderspezifisch, also erhalten sie alle nur Sprachcodes und keine optionalen Ländercodes.

Beispiel 3: Eine globale Website mit einer Version für Europa, einer für die USA und Kanada und einer für Asien/Pazifik, alle in englischer Sprache.

[table id=10 /]

[table id=10 /] Jede Website-Version in diesem Beispiel zielt auf mehr als ein Land ab, also erhalten sie alle mehrere hreflang-Werte. Wir werden später sehen, wie man das implementiert, aber wenn du neugierig bist, wie man einer URL mehrere hreflang-Werte zuweist, schau dir das an: Mehrere hreflang-Tags können auf eine URL verweisen.

Beispiel 4: Eine Website, die sich an Nutzer in den USA richtet, hat eine englische und eine spanische Sprachversion.

[table id=11 /]

In diesem einfachen Beispiel sehen wir zwei Versionen mit demselben Ländercode, der an unterschiedliche Sprachcodes angehängt ist.

Beispiel 5: Eine Website mit mehreren Länderdomains, von denen einige mehr als eine Sprachversion haben (für Länder, in denen mehr als eine Sprache gesprochen wird).

[table id=12 /]

[table id=12 /] Alle Website-Versionen in diesem Beispiel sind auf ein bestimmtes Land ausgerichtet und werden unter einer ccTLD gehostet, daher erhalten sie alle die optionalen Ländercodes. Allerdings sind die Ländercodes in diesem Fall nicht wirklich optional, da die Website-Versionen auf ccTLDs gehostet werden. Wie wir oben gelernt haben, werden ccTLDs automatisch mit Ländern verknüpft. Um konsistent zu sein, sollten URLs auf ccTLDs immer hreflang-Werte mit dem richtigen Ländercode erhalten.

Schritt 5: Prüfe, ob du hreflang=”x-default” brauchst”

Wenn du recherchiert hast, wie du hreflang auf deiner Website implementieren kannst, bist du wahrscheinlich schon auf das Konzept hreflang=”x-default”. Google und Yandex 2013 “x-default” eingeführt und es hat die Umsetzung von hreflang für Webmaster sicherlich nicht einfacher gemacht. Ganz im Gegenteil: Dieser neue Wert hat in den letzten Jahren für viel Verwirrung unter internationalen SEOs gesorgt, also klären wir die Dinge auf.

Es gibt drei Szenarien, in denen du einer URL den hreflang-Wert “x-default” zuweisen möchtest:

Szenario 1: Einige deiner URLs leiten automatisch auf eine andere URL um, je nach Standort oder Browsersprache des Nutzers:

Das trifft am häufigsten auf Homepages zu. In Beispiel 2, das wir zuletzt in Schritt 4, kann die URL https://www.rebelytics.com/ Nutzer, die Englisch als Browsersprache eingestellt haben, zu https://www.rebelytics.com/en/ weiterleiten. Nutzer, die Französisch und Spanisch als Browsersprache eingestellt haben, werden möglicherweise automatisch zu https://www.rebelytics.com/fr/ bzw. https://www.rebelytics.com/es/ weitergeleitet.

In diesem Fall würde die URL https://www.rebelytics.com/ in den hreflang-Annotationen enthalten sein und den Wert “x-default” erhalten.

Dies ist natürlich nicht auf Homepages beschränkt. Obwohl solche Fälle viel seltener sind, kann die URL https://www.rebelytics.com/products/ für englischsprachige Nutzer/innen auf https://www.rebelytics.com/en/products/, für französischsprachige Nutzer/innen auf https://www.rebelytics.com/fr/produits/ und für spanischsprachige Nutzer/innen auf https://www.rebelytics.com/es/productos/ umleiten.

In diesem Fall würde eine “x-default”-Version nicht nur für die Startseite, sondern auch für alle Unterseiten der Website definiert werden. Wir werden mehr über die Implementierung von hreflang auf URL-Ebene erfahren im nächsten Schritt dieses Leitfadens.

Schauen wir uns an, wie unsere Website-Strukturkarte mit hreflang-Werten aussehen würde, wenn wir dieses “x-default”-Szenario in Beispiel 2 einbeziehen:

[table id=13 /]

In diesem Fall würde Google allen Nutzern, die Google nicht auf Englisch, Französisch oder Spanisch verwenden, die URL https://www.rebelytics.com/ anzeigen. An dieser Stelle ist es wichtig zu wissen, dass Google die Informationen, die im Snippet des Suchergebnisses angezeigt werden, von der URL ableitet, zu der der Google-Bot weitergeleitet wird, daher solltest du das beachten.

Kommen wir nun zum nächsten (sehr ähnlichen) Szenario, bei dem du die Verwendung von “x-default” in Betracht ziehen solltest.

Szenario 2: Für eine Reihe von Versionen einer URL für verschiedene Sprachen oder Länder stellst du eine Standardversion mit einer Länder- oder Sprachauswahl zur Verfügung.

Wie Szenario 1 gilt auch dieses zweite Szenario normalerweise für (aber nicht nur) Homepages. Im Klartext würde das bedeuten, dass deine mehrsprachige oder internationale Website eine Startseite hat, auf der der/die Nutzer/in die Sprache, in der er/sie den Inhalt angezeigt bekommen möchte, oder das Land, in dem er/sie sich befindet (oder beides), auswählen kann. Der Unterschied zu Szenario 1 besteht darin, dass die Auswahl der richtigen URL-Version für den/die Nutzer/in nicht automatisch durch eine Weiterleitung erfolgt, sondern vom/von der Nutzer/in manuell ausgeführt wird.

Die hreflang-Anmerkungen wären die gleichen wie in Szenario 1: Der URL, die die Sprach- oder Länderauswahl enthält, wird der hreflang-Wert “x-default” zugewiesen, genau wie die URL, die den Nutzer je nach Browsersprache oder Standort des Nutzers in Szenario 1 weiterleitet. Das Ergebnis ist ebenfalls ähnlich: Google zeigt diese Version der URL nun auch Nutzern an, die Google nicht auf Englisch, Spanisch oder Französisch nutzen, mit dem kleinen Unterschied, dass hier die Seite ihren eigenen Inhalt bereitstellt, der in das Suchergebnis-Snippet aufgenommen wird. Überlege dir, wie du dieses Snippet für ein globales Publikum optimierst!

Das dritte und letzte Szenario kann von fast allen Websites genutzt werden, die die URLs nicht wie oben beschrieben mit einer automatischen oder manuellen Sprach- oder Länderauswahl trennen.

Szenario 3: Du möchtest eine der Website-Versionen, denen du bereits einen hreflang-Wert zugewiesen hast, als Standard- oder Ausweichversion für Nutzer/innen deklarieren, die Sprachen verwenden oder sich in Ländern befinden, für die du keine Website-Version hast.

Dieses Szenario lässt sich leicht auf alle oben genannten Beispiele anwenden. Wähle einfach eine der Website-Versionen, für die du bereits hreflang-Werte definiert hast, und füge den Wert “x-default” hinzu, wenn du möchtest, dass diese Version für alle Nutzer angezeigt wird, die Sprachen verwenden oder sich in Ländern befinden, für die du keine Website-Version hast.

Wenn wir wollten, dass die Engländer Rest der Welt Version in Beispiel 1 auch die Fallback-Version für alle Nutzer sein soll, die Google in einer anderen Sprache als Englisch nutzen, fügen wir einfach den Wert “x-default” zu dieser Version hinzu:

[table id=14 /]

Auf diese Weise teilen wir Google mit, dass https://www.rebelytics.com/en/ die Version dieser URL sein soll, die wir Nutzern zeigen wollen, für die wir keine Website-Version angegeben haben.

Jetzt, da du alle benötigten hreflang-Werte definiert hast, können wir fast zur Implementierung übergehen! Aber bevor wir das tun, lass uns über ein weiteres sehr wichtiges Thema sprechen: Die Implementierung von hreflang auf URL-Ebene. Wie du wahrscheinlich schon weißt, erhält jeder Satz von URLs auf deiner Website seine eigenen hreflang-Annotationen (bisher haben wir nur ganzen Versionen deiner Website hreflang-Werte zugewiesen). Die Implementierung von hreflang auf URL-Ebene kann eine kleine Herausforderung sein, deshalb werden wir in Schritt 6 darüber sprechen, wie du die häufigsten Fehler dabei vermeiden kannst.

Schritt 6: Entscheide, welche Seiten mit hreflang-Anmerkungen verlinkt werden sollen

hreflang-Anmerkungen müssen auf URL-Ebene implementiert werden. Das bedeutet, dass jeder Satz von URLs (verschiedene Sprach- und Länderversionen einer URL) seinen eigenen Satz von hreflang-Anmerkungen erhält. Bei der Implementierung von hreflang auf URL-Ebene ist es wichtig, auf die folgenden Details zu achten.

Erstens gibt es möglicherweise nicht alle deine Seiten in allen Sprach- oder Länderversionen deiner Website. Achte darauf, dass du keine hreflang-Anmerkungen verwendest, die auf Seiten verweisen, die es nicht gibt. Ich habe schon mehrfach erlebt, dass dies furchtbar schief gegangen ist.

Zweitens solltest du sicherstellen, dass nur Seiten, die von Suchmaschinen indiziert werden sollen, hreflang-Anmerkungen erhalten. hreflang ist immer ein Indizierungssignal, du willst also nicht, dass hreflang-Anmerkungen auf Seiten zeigen, die du nicht im Index haben willst.

Dieser zweite Punkt ist besonders wichtig, wenn du eine kanonische Tag-Lösung auf deiner Website implementiert hast (um ein Problem mit doppelten Inhalten zu lösen). Achte darauf, dass du keine hreflang-Anmerkungen für nicht-kanonische URLs verwendest (URLs, die ein kanonisches Tag haben, das auf eine andere Seite zeigt). Hier erfährst du mehr darüber, wie du kanonische Tags und hreflang zusammen verwenden kannst:

Wie man hreflang und canonical Tags zusammen verwendet

Die Bestimmung der Seiten, die hreflang-Kommentare erhalten, kann etwas schwierig sein, wenn es große Unterschiede zwischen den Versionen deiner Website gibt oder wenn du viel mit kanonischen Tags arbeitest. Achte einfach darauf, dass du alle Ausnahmen berücksichtigst und dass nur Seiten, die mit hreflang verlinkt werden sollen, Anmerkungen erhalten.

Wenn du separate mobile URLs verwendest, empfiehlt Google derzeit einen Satz hreflang-Annotationen, die die verschiedenen Länder- und Sprachversionen deiner Desktop-URLs miteinander verbinden, und einen weiteren Satz hreflang-Annotationen für deine mobilen URLs. Das Gleiche gilt, wenn du AMP verwendest: Desktop-URLs werden mit ihren Desktop-Äquivalenten verknüpft und AMP-URLs mit ihren AMP-Äquivalenten in anderen Sprachen oder für andere Länder. Lies mehr über dieses Thema hier.

Jetzt, wo du deine hreflang-Struktur fertiggestellt hast, musst du nur noch entscheiden wie du hreflang implementieren möchtest. Lies weiter, um mehr zu erfahren!

Schritt 7: Entscheide, welche hreflang-Implementierungsmethode du wählst

Es gibt drei Methoden, um hreflang auf deiner Website zu implementieren, aus denen du wählen kannst:

  • Im Kopfbereich des HTML-Codes jeder Seite
  • In XML-Sitemaps
  • Im HTTP-Header jeder Seite

Ich werde dir die Vor- und Nachteile der drei Methoden erläutern.

Implementierung von hreflang im Kopfbereich des Quellcodes jeder Seite

Ich bin mir ziemlich sicher, dass dies die beliebteste Version für alle Websites ist, die hreflang verwenden, wahrscheinlich weil sie für die meisten Entwickler am einfachsten zu implementieren ist.

Google verarbeitet die Informationen in der Kopfzeile normalerweise recht gut, daher ist dies eine Option, mit der ich in der Vergangenheit gute Erfahrungen gemacht habe und die ich definitiv empfehlen kann.

Es gibt jedoch ein paar Nachteile dieser Methode, die ich dir gerne mitteilen möchte.

Wenn du einen x-default-Wert für eine Standard-Startseite brauchst, die den Benutzer je nach Standort oder Browsersprache weiterleitet (siehe Szenario 1 in Schritt 5), wird automatisch ein hreflang-Fehler erzeugt, wenn du dich für die Quellcode-Variante entscheidest: Da die x-default-Version auf eine andere URL weiterleitet und daher keinen Quellcode hat, kannst du von der x-default-Version nicht auf die anderen Sprach- und Länderversionen zurückverlinken. Gegenseitige Links sind eine Grundvoraussetzung für hreflang. Wenn deine Website also eine Startseite hat, die Nutzer/innen auf der Grundlage ihrer Browsersprache oder ihres Standorts weiterleitet, solltest du wahrscheinlich eine der beiden anderen Optionen zur Implementierung von hreflang wählen.

Wenn deine Website außerdem viele hreflang-Anmerkungen für verschiedene Sprach- und Länderversionen benötigt (wie in Beispiel 3 unten), werden deine hreflang-Anmerkungen ziemlich lang. Manche mögen argumentieren, dass viel zusätzlicher Code im Kopfbereich deiner Seiten die Ladezeiten verlangsamt, und damit haben sie wahrscheinlich recht. Ich glaube jedoch, dass dies auch für die anderen Methoden gilt: Wenn du viele hreflang-Anmerkungen hast, brauchst du immer eine Menge Code.

Schauen wir uns einmal an, wie die hreflang-Anmerkungen für einige unserer Beispiele aussehen würden, wenn sie im Kopfbereich jeder Seite implementiert würden.

Beispiel 2 war eine globale Website mit einer englischen, französischen und spanischen Version der Website. Die Startseiten der drei Website-Versionen würden alle den folgenden Satz von hreflang-Anmerkungen erhalten:

<link rel="alternate" hreflang="en" href="https://www.rebelytics.com/en/" />
<link rel="alternate" hreflang="fr" href="https://www.rebelytics.com/fr/" />
<link rel="alternate" hreflang="es" href="https://www.rebelytics.com/es/" />

Wenn es auf jeder der Website-Versionen eine Seite “Produkte” gäbe, würde diese Gruppe von URLs die folgenden hreflang-Annotationen erhalten (und so weiter für alle anderen URLs, die auf mehr als einer der Website-Versionen existieren).

<link rel="alternate" hreflang="en" href="https://www.rebelytics.com/en/products/" />
<link rel="alternate" hreflang="fr" href="https://www.rebelytics.com/fr/produits/" />
<link rel="alternate" hreflang="es" href="https://www.rebelytics.com/es/productos/" />

Beispiel 3 von oben war ebenfalls eine Website mit drei verschiedenen Versionen, aber jede davon war auf mehrere Länder ausgerichtet. Dies würde zu den folgenden hreflang-Annotationen für die drei Versionen der Homepage führen:

<link rel="alternate" hreflang="en-AT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-BE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-CH" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-CZ" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-DE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-DK" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-FI" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-FR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-GB" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-GR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-HU" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-HR" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IS" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-IT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-LU" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-NO" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-NL" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-PL" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-PT" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-RO" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-SE" href="https://www.rebelytics.eu/" />
<link rel="alternate" hreflang="en-US" href="https://www.rebelytics.com/" />
<link rel="alternate" hreflang="en-CA" href="https://www.rebelytics.com/" />
<link rel="alternate" hreflang="en-AU" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-CN" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-HK" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-IN" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-ID" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-JP" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-MY" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-NZ" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-PH" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-SG" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-TW" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-TH" href="https://apac.rebelytics.com/" />
<link rel="alternate" hreflang="en-VN" href="https://apac.rebelytics.com/" />

Und um das Ganze abzurunden, lass uns einen Blick auf die hreflang-Anmerkungen für einen möglichen Satz von “Über uns”-Seiten auf den drei Website-Versionen werfen:

<link rel="alternate" hreflang="en-AT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-BE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-CH" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-CZ" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-DE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-DK" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-FI" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-FR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-GB" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-GR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-HU" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-HR" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IS" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-IT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-LU" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-NO" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-NL" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-PL" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-PT" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-RO" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-SE" href="https://www.rebelytics.eu/about-us/" />
<link rel="alternate" hreflang="en-US" href="https://www.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-CA" href="https://www.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-AU" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-CN" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-HK" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-IN" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-ID" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-JP" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-MY" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-NZ" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-PH" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-SG" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-TW" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-TH" href="https://apac.rebelytics.com/about-us/" />
<link rel="alternate" hreflang="en-VN" href="https://apac.rebelytics.com/about-us/" />

Ich hoffe, diese Beispiele geben dir eine gute Vorstellung davon, wie deine hreflang-Anmerkungen aussehen sollten, wenn du sie als HTML-Link-Elemente in den Header-Bereich deines Website-Quelltextes einbauen willst. Wenn nicht, ruf mich einfach an und ich helfe dir gerne.

Werfen wir nun einen Blick auf eine andere Möglichkeit, hreflang zu implementieren: XML-Sitemaps.

Implementierung von hreflang in XML-Sitemaps

Ich sage es dir gleich vorweg: Ich habe sehr schlechte Erfahrungen mit der Implementierung von hreflang in XML-Sitemaps gemacht und ich habe auch mit anderen SEOs gesprochen, die ähnliche Probleme hatten.

Google crawlt und verarbeitet XML-Sitemaps nicht so oft wie HTML-Seiten und hat daher Probleme, die in Sitemaps enthaltenen Informationen rechtzeitig zu verarbeiten. Wenn du diese Option wählst, wirst du wahrscheinlich viele hreflang-Fehler in der Google Search Console sehen und viele Seiten werden den falschen Nutzern in den Suchergebnissen von Google angezeigt.

Entwickler ziehen es oft vor, hreflang in XML-Sitemaps zu implementieren, anstatt es in den HTML-Quellcode jeder Seite einzubauen, wenn sie mit sehr großen Websites arbeiten, die viele verschiedene Sprach- und Länderversionen haben.

Ich glaube tatsächlich, dass eine große Menge an hreflang-Anmerkungen in einer XML-Sitemap viel mehr Probleme verursacht als im Kopfbereich des Quellcodes einer Seite.

Wenn du deine hreflang-Annotationen trotzdem in deine XML-Sitemaps implementieren möchtest, dann schau dir die Die Empfehlungen von Google zum Thema. Ich komme nun zur letzten (und wahrscheinlich besten) Methode, hreflang auf deiner Website zu implementieren:

Implementierung von hreflang in den HTTP-Header jeder Seite

Dies ist die Option, die ich in der Praxis am wenigsten beobachtet habe und mit der ich daher die wenigsten praktischen Erfahrungen habe. Ich weiß ehrlich gesagt nicht, warum sich so wenige Entwickler für diese Variante entscheiden.

Aus theoretischer Sicht hat diese Option alle Vorteile, die du dir vorstellen kannst:

  • Im Gegensatz zu XML-Sitemaps wird der HTTP-Header jedes Mal verarbeitet, wenn die Seite gecrawlt wird, sodass Google die mit einer Seite verbundenen hreflang-Informationen immer gleichzeitig mit dem Besuch der Seite erhält.
  • HTTP-Header können für jede URL gesetzt werden, auch für solche, die keinen eigenen Quellcode haben (wie die Homepage, die Nutzer je nach Standort oder Browsersprache weiterleitet) und auch für Nicht-HTML-Dateien wie PDFs.

Ein kleiner Nachteil könnte sein, dass die Fehlersuche und Qualitätssicherung bei dieser Option etwas schwieriger ist, da die meisten gängigen SEO-Tools HTTP-Header nicht wirklich beachten. Aber ich bin sicher, dass sich das in naher Zukunft ändern wird.

Der Code, den du für die Implementierung von hreflang-Annotationen in HTTP-Headern brauchst, ist der HTML-Header-Variante, die wir oben gesehen haben, sehr ähnlich, mit leichten syntaktischen Unterschieden.

So würde die Implementierung im HTTP-Header für die drei Homepages aus Beispiel 2 aussehen:

Link: ; rel="alternate"; hreflang="en",
; rel="alternate"; hreflang="fr",
; rel="alternate"; hreflang="es"

Genau wie die HTML-Header-Option erfordert auch diese Methode eine Implementierung auf URL-Ebene. Der Code für die HTTP-Header der drei Versionen der “Produkte”-Seite auf dieser Website würde also wie folgt aussehen:

Link: ; rel="alternate"; hreflang="en",
; rel="alternate"; hreflang="fr",
; rel="alternate"; hreflang="es"

Das war's! Mit diesen Informationen solltest du in der Lage sein, zu entscheiden, welche Option für dich und deine Entwickler die beste und praktikabelste ist.

Lies weiter, um zu erfahren, wie du deine hreflang-Implementierung vervollständigen und debuggen kannst!

Schritt 8: Implementiere hreflang auf deiner Website

Wenn du nach einer Anleitung suchst, wie du die hreflang-Struktur, die du entwickelt hast, tatsächlich auf deine Website bekommst, muss ich dich leider enttäuschen (oder vielleicht doch nicht? - Lies weiter!). Dieser Leitfaden soll dir vor allem dabei helfen, zu verstehen, wie die hreflang-Anmerkungen auf deiner Website aussehen sollen.

Die genaue Art und Weise, wie du hreflang auf deiner Website implementierst, hängt von vielen verschiedenen Faktoren ab, z. B. von der Methode, die du wählst, und auch von dem Content-Management- oder Shop-System, das du verwendest. Wenn du Glück hast, findest du ein geeignetes Plugin, aber in den meisten Fällen brauchst du für die eigentliche Implementierung die Unterstützung eines Entwicklers.

Es gibt eine Möglichkeit, hreflang zu implementieren, die für die meisten Websites funktioniert, unabhängig von ihrem CMS oder Shopsystem. Sie ist ein wenig experimentell und nicht offiziell empfohlen, Wenn du aber wirklich keine andere Möglichkeit findest, hreflang zu implementieren, und wenn du ein Heimwerker bist, solltest du dir das hier ansehen (du solltest es dir auf jeden Fall ansehen, denn es ist wirklich interessant):

Wie man hreflang mit Google Tag Manager implementiert

Schritt 9: Erstellen einer Google Search Console-Eigenschaft für jede Sprach- und Länderversion

Nachdem du hreflang auf deiner Website implementiert hast, solltest du eine Google Search Console-Eigenschaft für jede Sprach- oder Länderversion deiner Website erstellen, falls du das nicht bereits getan hast.

Warum brauchst du für jede Website-Version eine eigene Eigenschaft? Der wichtigste Grund ist, dass du in einigen Fällen über die Search Console zusätzliche Signale an Google senden kannst, die bei der korrekten Interpretation von hreflang helfen. Mehr darüber erfahren wir in Schritt 10. Ein weiterer guter Grund ist, dass separate Eigenschaften bei der Überwachung von Indexierungsproblemen oder der Analyse von Suchanfragen pro Sprache und Land sehr hilfreich sind.

Gehe einfach zur Google Search Console, klicke auf die Schaltfläche “EIGENTUM HINZUFÜGEN” und füge die genaue URL jeder deiner Länder- oder Sprachversionen hinzu (einschließlich Subdomains, Verzeichnisse und das richtige Protokoll).

Für das obige Beispiel 2 könnten die Eigenschaften wie folgt aussehen (eine für die gesamte Domain und eine für jede Sprachversion auf Unterverzeichnisebene):

Google Search Console-Eigenschaften für mehrere Sprachdomains in Unterverzeichnissen

Du wirst sehen, dass diese Struktur dir wirklich hilft, Probleme und die Leistung der verschiedenen Versionen deiner Website getrennt zu analysieren. Kommen wir nun zur nächsten sehr wichtigen Einstellung, die du in der Google Search Console vornehmen solltest: Das Länder-Targeting.

Schritt 10: Richte deine internationalen Targeting-Optionen in der Google Search Console an deiner hreflang-Implementierung aus

Über (ganz oben), Wir haben bereits darüber gesprochen, dass ccTLDs (länderspezifische Domains wie .de, .fr oder .co.uk) automatisch auf Nutzer aus den Ländern ausgerichtet sind, für die sie stehen. Wenn du nur ccTLDs verwendest, kannst du diesen Schritt auslassen.

gTLDs (und Subdomains oder Unterverzeichnisse auf gTLDs) hingegen können sich entweder an Nutzer/innen aus mehreren Ländern, aus allen Ländern oder nur aus einem oder zwei Ländern richten.

Mit der Google Search Console kannst du Eigenschaften auf ein Land oder auf alle Länder ausrichten.

Wie passt das also zusammen?

Wenn du eine Länderversion hast, die auf einer gTLD gehostet wird, stelle sicher, dass du in den Einstellungen für die Länderausrichtung in der Google Search Console das gleiche Land auswählst, auf das sie über hreflang ausgerichtet ist. Achte auch darauf, dass du das Länder-Targeting eines Verzeichnisses, einer Subdomain oder einer ganzen Domain nicht auf ein bestimmtes Land einstellst, wenn es eigentlich für Nutzer/innen aus mehreren Ländern oder aus einem anderen Land gedacht ist.

Für deine Objekte, die unter einer gTLD stehen und die über hreflang auf Nutzer aus genau einem Land ausgerichtet sind, gehe zu Suchverkehr > Internationales Targeting in der Google Search Console und wähle das Land aus. Für alle anderen Eigenschaften lässt du die Option für die Länderauswahl deaktiviert.

Für Beispiel 1 von oben sollten die Länderoptionen in der Google Search Console so aussehen:

[table id=15 /]

(OPTIONAL) Schritt 11: Prüfe deine hreflang-Einstellung mit searchVIU

Sobald du deine hreflang-Einrichtung eingerichtet hast, kannst du unsere erweiterten SEO-Berichte und Daten nutzen, um deine hreflang-Anmerkungen zu überprüfen. Unser hreflang-Bericht zeigt die folgenden Probleme auf, die bei hreflang-Implementierungen auftreten können:

  • hreflang, der auf nicht-kanonische URLs verweist
  • hreflang, der auf nicht indizierbare URLs verweist
  • hreflang, der auf umgeleitete URLs zeigt
  • hreflang, der auf URLs verweist, die 404 oder Serverfehler zurückgeben
  • hreflang, der auf URLs zeigt, die über robots.txt blockiert werden
  • Die in der hreflang-Anmerkung angegebene Sprache unterscheidet sich von der Sprache des Inhalts auf der URL, auf die sie verweist
  • Das in der hreflang-Anmerkung angegebene Land unterscheidet sich vom Land der ccTLD, auf die es verweist
  • Über hreflang verlinkte URLs werden nicht über HTML-Links miteinander verknüpft (fehlender Länder- oder Sprachumschalter)
  • Übersetzungen, die über hreflang verknüpft sind, sind semantisch nicht ähnlich

Die hreflang-Berichte sind Teil unserer umfassenden SEO-Datenlösung. Wenn du darüber sprechen möchtest, wie unser Produkt dir helfen kann, kannst du hier eine kostenlose Testversion anfordern: Testversion anfordern

Das war's! Hast du noch Fragen? Dann ruf mich an.

Wenn noch Fragen zur Implementierung von hreflang unklar sind, zögere nicht, mich zu kontaktieren oder einen Kommentar unter diesen Artikel zu schreiben. Ich werde dir gerne helfen.

Zusammenfassung der 138 Kommentare

Kommentar Highlights & Key Takeaways

Die Verwaltung mehrsprachiger und multiregionaler Websites birgt einige Herausforderungen - und die vielfältigen Diskussionen unten zeigen, dass hreflang in der Praxis oft schwieriger ist als auf dem Papier! Hier sind die wichtigsten Erkenntnisse und die am häufigsten gestellten Fragen, die wir für mehr Klarheit und praktischen Nutzen zusammengefasst haben.


1. Sprache vs. Land Targeting

Kerneinsicht:

  • Wenn du nur eine Sprachversion für deinen Inhalt hast, brauchst du in der Regel keine komplexen hreflang-Tags. Eoghan erklärt:

    “Ein englischer Artikel auf einer internationalen Domain wird automatisch englischsprachige Nutzer in den USA, Großbritannien, Kalifornien, Australien und darüber hinaus ansprechen.”

Mitnehmen:

  • Füge nur Ländercodes hinzu (
    en-US

    ,

    en-GB

    ) zu hreflang, wenn du tatsächlich Variationen für jedes Land hast. Ansonsten kann ein einfacher Sprachcode (z.B.,

    hreflang="en"

    ) ist genug.


2. Wann verwendet man
x-default

Kerneinsicht:

  • x-default

    ist für Fälle reserviert, in denen keine andere Sprache/Region passt, oder wenn eine Splash-/Stammseite Nutzerinnen und Nutzer je nach Browser/Sprache umleitet.

  • Ich zitiere Eoghan:

    “In deinem Fall würde ich auf jeden Fall empfehlen, ‘x-default’ für die Root-Domain zu verwenden, die die Nutzer auf die richtige Sprachversion umleitet. Das hilft Google, deine Struktur zu verstehen.”

Mitnehmen:

  • Nur verwenden
    x-default

    für “Catch-all”-Seiten (nicht für lokalisierte Sprachseiten).

  • Für Seiten, denen bereits eine Sprache zugewiesen wurde,
    x-default

    ist optional und bringt keinen großen Mehrwert.


3. Die URL-Struktur muss nicht genau dem hreflang entsprechen

Kerneinsicht:

  • Deine Verzeichnis- oder Subdomainstruktur (z. B.,
    /us/

    ,

    /eu/

    ) muss nicht genau mit deiner hreflang-Anmerkung übereinstimmen.

    “URL-Verzeichnisse und hreflang-Anmerkungen müssen nicht übereinstimmen - die Struktur, die du im Kopf hast, scheint in Ordnung zu sein.”


4. Vermeide es, einer URL mehrere Sprachcodes zuzuweisen

Kerneinsicht:

  • Die Zuweisung mehrerer Sprach-Länder-Codes (z. B.,
    en-FR

    ,

    de-DE

    ) auf einer einzigen englischen Seite zu platzieren, ist technisch möglich und funktioniert manchmal auch, wird aber als “kontra-intuitiv” angesehen und kann Google verwirren.

    “Du missbrauchst auf diese Weise eindeutig hreflang-Tags... Google könnte deine Anmerkungen am Ende komplett ignorieren, wenn sie verwirrende Signale senden.”

Mitnehmen:

  • Wenn möglich, stimme die hreflang-Anmerkung mit der tatsächlichen Sprache der Seite ab.

5. Geo-Targeting in der Google Search Console

Kerneinsicht:

  • Wenn du mehrere hreflang-Tags für eine URL verwendest, setze das GSC-Geotargeting auf “unlisted” (d.h. wähle kein einzelnes Land).

    “In diesem Fall würde ich das Kästchen für die Länderausrichtung im GSC nicht ankreuzen.”


6. Keine Inhalte in einer Sprache? Nimm diese Sprache nicht ins Visier!
  • Kannst du in Frankreich/Italien für englische Inhalte ranken? Ja, aber nur für englische Suchanfragen oder zweideutige Keywords.

    “Ohne französische Inhalte auf der Website wirst du nicht viel Traffic von französischsprachigen Suchanfragen bekommen.”

Mitnehmen:

  • Füge kein hreflang für Sprachen hinzu, die du nicht wirklich unterstützt.

7. Reziproke und selbstreferenzierende Tags

Kerneinsicht:

  • Jede Seite sollte sich selbst und alle alternativen Versionen mit korrekten hreflang-Anmerkungen referenzieren - eine häufige Ursache für Fehler.

8. Technische Überlegungen & Tools
  • Bei einigen Nutzern treten Fehler bei 301/302-Weiterleitungen und IP-basierten Weiterleitungen auf - Googlebot verhält sich möglicherweise nicht wie erwartet! Teste gründlich und vermeide Einstellungen, bei denen Googlebot den Inhalt nicht erreichen kann.

Über WordPress und CMS-Plugins:

  • Mehrere WordPress-Installationen werden nicht empfohlen. Verwende stattdessen, wenn möglich, vertrauenswürdige mehrsprachige Plugins.

9. Konsolidierung von Domains (ccTLD zu gTLD, oder Migrationen)
  • Migrationen sind riskant, aber manchmal auch nützlich. Eoghan verlinkt auf Ressourcen und rät zur Planung und zu richtigen hreflang Updates.

10. Mehrsprachige Seiten (unter einer einzigen URL)
  • Wenn eine Seite zwei Sprachen enthält (z. B. Chinesisch und Englisch), gibt es keine perfekte hreflang-Lösung:

    “Es gibt keine offizielle Unterstützung für die Zuweisung mehrerer Sprachcodes zu einer URL. Es wird nicht empfohlen, aber du kannst experimentieren.”


👉 Die wichtigsten Ratschläge in aller Kürze

  • Passe hreflang an den Inhalt an: Kommentiere nur das, was du anbietest, und weise nicht auf nicht-englische Codes hin, wenn du die Besonderheiten nicht genau kennst.
  • Verwende
    x-default

    für Catch-alls, nicht für lokalisierte Seiten.

  • Überlege zweimal, bevor du die Dinge zu komplex machst - Einfachheit ist dein Freund, sowohl bei SEO als auch bei der Wartung.
  • Im Zweifelsfall solltest du dich auf die Sprachcodes beschränken und die Ländercodes nur bei wesentlichen, lokal begrenzten Unterschieden hinzufügen.
  • Reziproke Links und Selbstreferenzen in deinem Markup sind unerlässlich.
  • Wenn du mit ungewöhnlichen Situationen konfrontiert wirst, experimentiere vorsichtig und beobachte die Ergebnisse, aber halte dich, wenn möglich, an bewährte Verfahren.

138 Antworten

  1. Hallo Eoghan~

    Danke für diesen und den dazugehörigen Artikel über hreflang mit canonicals!

    Ich habe ein paar technische hreflang Fragen, bei denen ich hoffe, dass du mir helfen kannst:

    1) Ist es in Ordnung, hreflang zu verwenden, wenn man einen großen Teil eines Artikels umschreibt (z. B. einen neuen Titel, neue Abschnitte, größere Änderungen usw.)? Was ist, wenn man auch die URL ändert?

    2) Weißt du, welche Faktoren dazu führen können, dass Google eine globale oder internationale Version einer Seite anstelle der aktuellen Version rankt (z. B. globales Ranking oder /in-en/ in den USA, wenn eine hreflang-Version /us-en/ existiert)?

    3) Weißt du, wie Google Backlinks in Bezug auf hreflang-Varianten eines Artikels behandelt? z.B.: Hilft ein Link, der auf /us-en/ zeigt, auch der globalen /-Version sowie einer /in-en/-Version? Sickern Links von einer globalen Version zu /us-en/ und /in-en/?

    Danke und herzliche Grüße!
    Daniel

    Antworten

    1. Hallo Daniel, danke für deine Fragen. Hier sind meine Antworten:

      1) Angenommen, du hast einen Artikel über Handys für US-Nutzer und willst ihn für britische Nutzer umschreiben. Du sprichst also von Mobiltelefonen statt von Handys, änderst den Titel, die URL und die Sprache und Rechtschreibung. Vielleicht ersetzt du eine Passage über AT&T durch einen Absatz über BT, einen britischen Anbieter. Aber du sprichst immer noch von der gleichen Sache, nämlich von Mobiltelefonen, also ist es absolut korrekt, die Artikel mit hreflang zu verlinken.

      2) Das hört sich an, als ob hreflang von Google ignoriert wird. Das passiert normalerweise nicht, wenn hreflang korrekt implementiert ist. Es könnte also etwas mit deiner Implementierung nicht stimmen. In seltenen Fällen kann es auch sein, dass andere Ranking-Signale schwerer wiegen als hreflang, z. B. viele britische Links, die auf deine US-Version verweisen und umgekehrt, oder widersprüchliche ccTLDS. Vergewissere dich, dass hreflang korrekt implementiert ist und mit allen anderen Rankingsignalen übereinstimmt.

      3) Ja, Backlinks zu einer Version eines Artikels helfen definitiv den anderen Versionen, die mit hreflang verbunden sind.

      Ich hoffe, das hilft! Ich habe das auf meinem Handy getippt, daher entschuldige ich mich für die kurze Antwort.

      Eoghan

      Antworten

  2. Ich denke schon, dass das eine dumme Frage ist.
    Ich habe eine .com und eine .ie Website.
    Soll ich die hreflang-Tags sowohl auf meiner .com- als auch auf meiner .ie-Website verwenden?
    Danke!

    Antworten

    1. Hallo Tim, hreflang wäre in deinem Fall perfekt geeignet, um Suchmaschinen zu zeigen, dass die Inhalte auf deiner .ie-Website für irische Nutzer gedacht sind, während die Inhalte auf deiner .com-Website für internationale Nutzer gedacht sind. Die Tags sollten auf beiden Seiten enthalten sein, wobei jede Seite auf die andere verweist. Wenn du weitere Fragen hast, helfe ich dir gerne weiter.

      Antworten

    1. Hallo! hreflang-Anmerkungen sind immer bidirektional, d.h. jede Seite, auf die du verlinkst, muss auf die Seite zurückverweisen, von der sie verlinkt ist. Das bedeutet, dass hreflang-Anmerkungen auf allen Sprach- und Länderversionen deiner Website platziert werden müssen.

      Antworten

  4. Wie verwendet man hreflang, wenn man keine gleiche oder ähnliche Seite in einer anderen Sprache und Domain hat, z.B. einen Blog oder einen speziellen Artikel über dieses Land. Kannst du hreflang auf die Indexseite verweisen, wenn du nicht die gleiche Seite auf einer anderen Domain hast?.
    Ich möchte immer noch, dass die Nutzer auf allen Seiten zwischen meinen Domains zu ihrer Sprachdomain gehen.

    Antworten

    1. Hallo Johan,

      Wenn du keine Version einer Seite in einer anderen Sprache oder für ein anderes Land hast, solltest du hreflang auf dieser Seite nicht verwenden.

      Du kannst nicht auf die Startseite einer anderen Sprachversion verweisen. Der Grund dafür ist einfach: hreflang-Anmerkungen sind bidirektional, d. h. eine Seite, auf die mit hreflang verlinkt wird, muss auch zurück verlinken. Das bedeutet, dass Seiten mit hreflang-Anmerkungen immer in Paaren oder Gruppen auftreten und dass eine Seite (wie die Homepage) nicht das Ziel von hreflang-Links von vielen verschiedenen Seiten in einer anderen Sprach- oder Landesversion sein kann, sondern nur von einer gleichwertigen Seite in jeder anderen Version (in diesem Fall die Homepage).

      Ich hoffe, das hilft!

      Eoghan

      Antworten

  5. Hallo Eoghan, in der Hoffnung, dass du hier noch Fragen beantwortest. Ich habe eine .co.uk und eine .com cctld mit gleichem Inhalt, der einzige Unterschied ist das Preissymbol. Sollte ich hreflang für beide cctlds verwenden, auch wenn die cctld länderspezifisch ist? Wird Google das als Duplikat betrachten?

    Antworten

    1. Hallo Jerry,

      Ja, ich beantworte hier immer noch Fragen. Ich hatte in letzter Zeit nur Schwierigkeiten, mit den Fragen Schritt zu halten, weil ich sehr beschäftigt war. Danke, dass du mir das unter die Nase gerieben hast 🙂 Das hat mich motiviert, alle unbeantworteten Fragen sofort zu beantworten.

      Also, zu deiner Frage: Ja, du solltest hier auf jeden Fall hreflang verwenden! Du kannst die .com-Version als “en” (englische Sprachversion ohne spezifisches Land) und die .co.uk-Version als “en-gb” (englische Sprachversion für Nutzer in Großbritannien) taggen. Auf diese Weise zeigt Google deine .co.uk-Version den Nutzern in Großbritannien an und deine .com-Version allen anderen Nutzern, die auf Englisch suchen.

      Google wird deine Inhaltsversionen nicht als Duplikate betrachten, wenn du sie mit hreflang kennzeichnest.

      Lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  6. Lieber Eoghan,

    Ich brauche Hilfe in unserem Fall.

    Wir haben dieselbe URL für alle Länder, auf die wir abzielen: Es ist eine globale Website auf Englisch und auf einer einzigen Domain.
    Wir wollen die IP erkennen und die Preise ändern. Außerdem sollen die Nutzer die Möglichkeit haben, das Land zu wechseln und ein Standardland zu haben, ,

    Neben dem Preis ändert sich auch der Inhalt der Seitenleiste je nach Land.
    Der Hauptartikel und der Kommentarbereich bleiben für alle Länder gleich.

    Spielt der hrelang-Tag in unserem Fall also eine Rolle?

    Das Anliegen ist z.B.
    Google indexiert Websites aus den USA
    und die Preise in den USA werden indexiert.

    Wird dies also unsere Nutzer in Großbritannien oder Indien behindern, wo der Hauptunterschied die Preise sind.
    Ich habe diesen Tag nie in Betracht gezogen, aber da der Start kurz bevorsteht, mache ich mir darüber Gedanken.

    Mit freundlichen Grüßen
    Sungod

    Antworten

    1. Hallo Sungod,

      Vielen Dank für deinen Kommentar und deine interessante Frage.

      Wenn du die Lösung mit einer URL für alle Länder beibehältst, brauchst du keine hreflang-Tags auf deiner Seite. Du hast jedoch Recht, wenn du dich fragst, ob es ein Problem sein könnte, dass Google nur US-Preise indexiert.

      Du könntest eine Lösung in Betracht ziehen, bei der du unterschiedliche URLs für die verschiedenen Währungen/Länder hast und die verschiedenen Versionen mit hreflang-Anmerkungen verlinkst. Auf diese Weise kannst du sicherstellen, dass Google alle deine Preise (und auch die zusätzlichen Inhalte) indexiert und dem richtigen Nutzer in den SERPs die richtige Version anzeigt.

      Wenn hreflang richtig implementiert ist, funktioniert es sehr gut und Google liefert sehr zuverlässig die richtigen Ergebnisse basierend auf dem Standort des Nutzers.

      Über wie viele Länderversionen reden wir? Zielt ihr auf Nutzer in der ganzen Welt ab oder nur in einer begrenzten Anzahl von Ländern? Eine Lösung für die von dir genannten Länder könnte wie folgt aussehen:

      <link rel="alternate" href="http://www.yourwebsite.com/en-us/" hreflang="en-us">
      <link rel="alternate" href="http://www.yourwebsite.com/en-gb/" hreflang="en-gb">
      <link rel="alternate" href="http://www.yourwebsite.com/en-in/" hreflang="en-in">

      Diese Liste kann natürlich noch erweitert werden. Du kannst gerne weitere Fragen stellen, wenn etwas unklar bleibt!

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

      1. Deine Antwort bedeutet viel für jemanden, der nur begrenzte Ressourcen hat.
        Und du hast so schnell geantwortet, das ist auf eine gute Art sehr unerwartet.

        Zurzeit sind es 10-15 Länder und sie könnte bei Bedarf erhöht werden.
        Eine einzige URL ist für mich am logischsten.
        Es ist einfacher zu verwalten, für die Nutzer/innen einfach zu teilen usw.

        Für jedes Land eine eigene URL für kleinere Änderungen zu haben, ist hingegen eine zusätzliche Belastung.
        Aber ich frage mich, ob es uns hilft 🙂 .

        Je mehr ich nachdenke, desto schwieriger wird es für uns, denn wir haben nicht nur Seiten, die von Inhouse-Publishern wie mir erstellt werden.
        Aber die Nutzer können Seiten erstellen und speichern, so dass es schwierig ist, für jedes Land eine eigene URL zu verwalten.
        In der Tat hat es für mich keinen Nutzen und sieht eher schädlich aus.

        Obwohl Google sagt, dass es ein lokales Crawling einführen wird
        https://support.google.com/webmasters/answer/6144055

        Allein das Gespräch mit dir hilft mir schon sehr 
        Was ist deine Meinung, da wir in Zukunft mehr Länder usw. bearbeiten können? .
        Und berücksichtige auch Seiten, die von Nutzern aus jeder Region unter der Domäne gespeichert werden können,

        Mit freundlichen Grüßen
        Sungod

        Antworten

        1. Hallo Sungod,

          Wenn eine eigene URL für jede Währung oder jedes Land zusätzlichen Aufwand bedeuten würde, solltest du einfach bei der Lösung bleiben, die du hast - eine URL für alle Länder. Das ist für Suchmaschinen natürlich etwas schwieriger zu crawlen und zu interpretieren, aber wie der Link, den du oben geteilt hast, zeigt, versucht Google bereits, diese Art des Content Serving zu verstehen.

          Ich hoffe, das hilft! Du kannst gerne weitere Fragen stellen 🙂 .

          Mit freundlichen Grüßen,

          Eoghan

          Antworten

  7. Bedenke auch dies

    example.com/de-us/test1.html hat 5000 Treffer
    example.com/de-in/test1.html hat 10000 Treffer
    gegen

    example.com/test1.html hat 15000 Hits, davon 5000 aus den USA und 10000 aus Indien
    Wird eine solche Seite besser

    Dann macht es das Gleiche.
    Welche Seitenkonfiguration hat eine Chance auf ein höheres Ranking?

    Ich bin verwirrt.
    🙁

    Mit freundlichen Grüßen
    Sungod

    Antworten

    1. Hallo Sungod,

      Wenn du zwei oder mehr Seiten mit hreflang verlinkst, werden sie als Varianten derselben Seite betrachtet und haben daher zusammen gute Chancen auf ein gutes Ranking.

      Eine Seite für die ganze Welt hingegen hat ebenfalls sehr gute Chancen auf ein gutes Ranking, da sie die gesamte Relevanz auf nur einer URL bündelt. Das einzige Problem dabei könnte sein, dass Google Schwierigkeiten hat, herauszufinden, dass es je nach Standort des Nutzers dynamische Inhalte gibt. Der Google-Bot müsste mit einer IP aus jedem Land, das du bedienst, kommen und dann verstehen, dass die Änderungen, auf die er bei jedem Besuch stößt, auf den IP-Wechsel zurückzuführen sind. Vielleicht gibt es dafür in Zukunft ein neues Markup. Im Moment ist die einzige wirklich gute Lösung, die ich mir vorstellen kann, verschiedene URLs für verschiedene Länder zu haben und sie mit hreflang-Annotationen zu verknüpfen. Aber wie du bereits gesagt hast, wäre das zu viel Arbeit für dich. Also solltest du wahrscheinlich einfach bei der Lösung bleiben, die du hast, testen, wie gut sie funktioniert und sehen, ob Google Probleme damit hat.

      Antworten

      2. Hi,
        Ich bin zurück xd
        So werden wir vorgehen

        ink rel=”alternate” href=”https://example.com/in/mobiles” hreflang=”en-in”
        link rel=”alternate” href=”https://example.com/us/mobiles” hreflang=”en-us”
        link rel=”alternate” href=”https://example.com/mobiles” hreflang=”x-default”

        Und in google webmaster können wir geo target wie
        https://example.com/in/ Indien
        href=”https://example.com/us/ USA
        href=”https://example.com/mobiles” Nicht gezielt?

        Sollten wir eine Geobeschränkung vornehmen oder nicht?

        Sungod

        P.S.
        Du und ein anderer Experte haben mich überzeugt und wir werden von Anfang an auf hreflang setzen 🙂

        Antworten

        1. Hallo Sungod,

          Willkommen zurück 🙂 Das sieht gut aus! Nur eine Frage:

          Leitet deine “x-default”-Version auf der Grundlage der IP des Nutzers auf eine der anderen Versionen um oder hat sie einen Inhalt? Wenn sie Inhalte hat, solltest du ihr zusätzlich zum “x-default”-Wert einen Sprachwert zuweisen (“en”, nehme ich an).


          <link rel="alternate" href="https://example.com/in/mobiles" hreflang="en-in">
          <link rel="alternate" href="https://example.com/us/mobiles" hreflang="en-us">
          <link rel="alternate" href="https://example.com/mobiles" hreflang="x-default">
          <link rel="alternate" href="https://example.com/mobiles" hreflang="en">

          Du kannst hier mehr darüber lesen, wie du einer URL zwei hreflang-Werte zuweisen kannst: https://www.rebelytics.com/multiple-hreflang-tags-one-url/

          Antworten

  8. Hallo Eoghan,

    Hat eine 301-Weiterleitung einen Einfluss auf die HREF-Sprach-Tags? Aus irgendeinem Grund wird die englische Version meiner Website in Google.nl vor der niederländischen Version angezeigt.

    Bitte lass mich wissen, was du denkst.

    Antworten

    1. Hallo Mark,

      Ja, eine 301-Weiterleitung hat sicherlich Auswirkungen auf die Interpretation der hreflang-Anmerkungen durch Google. Deine hreflang-Anmerkungen sollten zum Beispiel nicht auf eine URL zeigen, die zu einer anderen URL weiterleitet. Stattdessen sollten sie auf die endgültige URL verweisen. In diesem Fall würde Google deine hreflang-Anmerkungen wahrscheinlich einfach ignorieren.

      Wenn du mir mehr Informationen zu deinem Problem gibst, werde ich es mir gerne ansehen und dir helfen.

      Antworten

  9. Wenn der Nutzer sucht http://example.com
    wird er weitergeleitet zu https://example.com/countrycode/ wenn sein Land eigene Inhalte hat, die von uns unterstützt werden.

    Wenn er einem Land angehört, das wir nicht unterstützen, wird er angezeigt
    https://example.com/
    Der Inhalt dieser Seite wird auf Englisch sein.
    Wenn das Land nicht erkannt wird, wird er jederzeit auf die Standard-Website umgeleitet.

    Ich frage mich
    1) Wenn wir einer Seite “x-default” mit ” hreflang=”en”> zuweisen, hilft das oder schadet es?
    Wird es verhindern, dass Nicht-‘en’-Nutzer auf unserer Website landen?
    3) Oder werden Nutzer, die keine ‘en’ sind, unsere Website nie kennenlernen?
    3) Wird es eine positive Auswirkung haben?

    Antworten

    1. Hallo Sungod,

      In diesem Fall würde ich auf jeden Fall empfehlen, “en” für diese Standardversion einzustellen. Der Wert “en” ist hier der Standard, weil er den Suchmaschinen mitteilt, dass es sich um eine englische Version für Nutzer auf der ganzen Welt handelt. Der Wert “x-default” ist optional, denn damit sagst du der Suchmaschine, dass diese Version auch für Nutzer angezeigt werden soll, die in einer anderen Sprache suchen, die du nicht unterstützt.

      Ich habe kürzlich den Fall einer Website gesehen, die genau das tat, was du vorhast (sie wies einer ihrer Versionen nur “x-default” zu), und Google ignorierte die hreflang-Implementierungen in diesem Fall komplett (obwohl ich mir nicht sicher bin, ob dies der einzige Grund war, warum sie ignoriert wurden).

      Antworten

      2. Kannst du überprüfen
        https://support.google.com/webmasters/answer/189077?hl=en
        Unten geht es zu diesem Beispiel
        Beispiel einer hreflang-Konfiguration: Annotationen in Aktion

        Wenn ich das richtig verstehe,
        http://www.example.com/ Standardseite, die sich nicht an eine Sprache oder ein Gebietsschema richtet; kann Selektoren haben, damit die Nutzer ihre Sprache und Region auswählen können.

        Bei uns gibt es auf jeder Seite der Website einen Selektor, der nur für die Region gilt.
        vielleicht reicht x-default allein aus.

        Mit freundlichen Grüßen
        Sungod

        Antworten

        1. Hallo Sungod,

          Die Spezifikationen von Google lassen viel Spielraum für Interpretationen. Das ist meiner Meinung nach die Wurzel des ganzen Problems.

          Die ursprüngliche Idee von “x-default”, so wie ich sie interpretiere, war für URLs gedacht, die Nutzerinnen und Nutzer entweder auf Basis ihrer IP oder ihrer Browsersprache weiterleiten, oder für Länder-/Sprachauswahl-Homepages wie diese: http://www.britax.com/

          Diese beiden Fälle sind die einzigen, in denen ich den Wert “x-default” allein zuweisen würde, ohne einen Sprachwert. Ich würde das tun, weil diese URLs im Grunde keinen Inhalt in einer Sprache haben.

          Wenn deine Standard-URL einen Inhalt hat, ist es sinnvoll, ihr den entsprechenden Sprachwert zuzuweisen. Es kann auf jeden Fall nicht schaden.

          Ich hoffe, das hilft!

          Antworten

    1. Hallo Sungod,

      Es ist eigentlich egal, welche Ländercodes du für deine URL-Verzeichnisse verwendest, aber ich würde vorschlagen, dass du dich an die ISO 3166-1 Alpha-2 Ländercodes hältst: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

      Das sind die Codes, die du in hreflang verwenden musst, und aus technischer Sicht ist es wirklich gut, wenn du dieselben Codes für deine URL-Verzeichnisse verwendest.

      Für das Vereinigte Königreich wäre das also /gb/.

      Antworten

  12. Hallo, Eoghan

    dein Blog ist sehr hilfreich.
    Ich habe die hreflang-Tags auf allen URLs meiner Website implementiert, die viele lokale Versionen in Unterordnern hat. Für die Root-Homepage leitet der Server eine 301 zum Unterordner weiter, je nachdem, wo sich die IP des Clients befindet.
    Wie kann ich den “x-default” auf die Homepage setzen, wenn er nicht existiert?
    Ist es außerdem immer besser, eine Standardversion der Website zu haben? Was ist, wenn alle lokalen Versionen gleich wichtig sind? Nimmt Google die US-Version als Standardversion? Ich danke dir!
    Alessandro

    Antworten

    1. Hallo Alessandro,

      Ich freue mich, dass du meinen Blog hilfreich findest. Danke für deine netten Worte!

      Du hast recht, das ist ein Fehler im System, der auch mir in der Vergangenheit schon mehrfach aufgefallen ist. Du kannst keine hreflang-Anmerkungen zu einer URL hinzufügen, die weiterleitet, wenn du hreflang-Anmerkungen in der Abschnitt jeder Seite. Du bist also gezwungen, die Regeln zu brechen, indem du nicht von der “x-default” URL zurücklinkst.

      Eine Lösung wäre die Implementierung von hreflang-Annotationen in Sitemaps, obwohl ich generell dazu raten würde, diese Option zu vermeiden, wenn möglich. Ich habe mehrere Szenarien wie das von dir beschriebene gesehen, die perfekt funktionierten, obwohl der Link von der “x-default”-Version zu den anderen Versionen der Homepage fehlte.

      Deine zweite Frage war, ob es immer notwendig ist, eine Standardversion zu definieren. Das glaube ich nicht. Meiner Meinung nach ist “x-default” überstrapaziert, da es ursprünglich nur für zwei Fälle gedacht war: 1. Das von dir beschriebene Szenario, bei dem die Standard-Website je nach Standort oder Sprache umgeleitet wird und sich buchstäblich nicht an Nutzer aus einem bestimmten Ort oder einer bestimmten Sprache richtet. 2. Homepages mit Länder-/Sprachauswahl.

      Google wird versuchen, jedem Nutzer die relevanteste Version zu zeigen (nicht unbedingt die US-Version). Mein Rat: Stelle sicher, dass du deine wichtigsten Zielgruppen mit den richtigen Sprachversionen abdeckst, kennzeichne sie richtig und lass Google den Rest erledigen. Du kannst jederzeit in deiner Search Console und in den Google Analytics-Daten nachsehen, ob es Nutzer/innen gibt, die über die “falschen” Versionen einsteigen und dann die Probleme beheben, die du findest.

      Ich hoffe, das hilft! Du kannst gerne weitere Fragen stellen.

      Antworten

      1. Herzlichen Dank!

        In der Zwischenzeit habe ich diesen Beitrag aus dem offiziellen Blog gefunden, der etwas ganz anderes aussagt als die Einführung einer 302-Weiterleitung anstelle einer 301-Weiterleitung auf der offiziellen Website

        https://webmasters.googleblog.com/2014/05/creating-right-homepage-for-your.html

        Sie lautet wie folgt:

        Ein drittes Szenario wäre, deinen Nutzern je nach Standort und Spracheinstellung automatisch den passenden HTML-Inhalt zu liefern. Dazu verwendest du entweder serverseitige 302-Weiterleitungen oder du lieferst dynamisch den richtigen HTML-Inhalt.
        Denke daran, die Annotation x-default rel-alternate-hreflang auf der Homepage/generischen Seite zu verwenden, auch wenn es sich dabei um eine Weiterleitungsseite handelt, die für die Nutzer nicht direkt zugänglich ist.

        Glaubst du, dass ein Server so konfiguriert werden kann, dass er gleichzeitig eine 302-Weiterleitung UND einen Body mit html mit der x-default-Anmerkung liefert?

        Antworten

        1. Hallo Alessandro,

          Zur Frage 301 / 302: In diesem Fall solltest du auf jeden Fall eine 302 verwenden. Eine geo- oder sprachbasierte Weiterleitung ist nicht dauerhaft, sondern vorübergehend, daher ist 302 die bessere Wahl als 301. Tut mir leid, dass ich nicht gleich darauf hingewiesen habe, das ist mir entgangen.

          Mir ist keine Möglichkeit bekannt, eine 302-Weiterleitung UND einen HTML-Body mit hreflang-Anmerkung zu implementieren. Aber du kannst sicherlich eine “x-default”-Seite, die auf eine andere Homepage-Version weiterleitet, mit einer Annotation versehen, indem du hreflang in den XML-Sitemaps implementierst (obwohl das wahrscheinlich zu anderen Problemen führen wird). Ich vermute, das ist es, was in dem von dir verlinkten Artikel gemeint ist (oder vielleicht auch die dritte Möglichkeit, hreflang in den http-Header zu implementieren, mit der ich aber keine Erfahrung habe). Eine andere Erklärung fällt mir nicht ein.

          Aber wie gesagt, normalerweise funktioniert es auch ohne die “x-default”-Seite, die zurückverlinkt.

          Antworten

  13. Nochmals vielen Dank!
    Letzte Frage... Was ist mit 302, die keinen Link Juice weitergibt?
    Die meisten Legacy-Links gehen zum Stammverzeichnis... und wenn der Crawler diese 302 findet, wäre sie dann verloren?

    Antworten

    1. Hallo Alessandro,

      Es gibt zwei Gründe, warum du dir über dieses Thema keine Sorgen machen musst:

      1. Indem du die x-default-Startseite mit den verschiedenen Sprach- und Länderversionen der Homepage verlinkst, lässt du Google wissen, dass diese Seiten Varianten voneinander sind. Wenn du es so ausdrücken willst, wird der Link-Saft über die hreflang-Anmerkungen weitergegeben.
      2. Verschiedene Google-Mitarbeiter haben in den letzten Monaten gesagt, dass 302 Weiterleitungen Link Juice, Pagerank oder wie auch immer du es nennen willst, weitergeben. Hier sind zwei Quellen:
      https://plus.google.com/u/0/+JohnMueller/posts/PY1xCWbeDVC
      https://twitter.com/methode/status/757923179641839616

      Ich hoffe, das hilft!

      Antworten

      1. Vielen Dank, wirklich!
        Noch... verlinke ich die x-default hp nicht mit den Länderversionen der hp... Derzeit leite ich den Crawler mit einem serverseitigen 301 um (ich werde bald zu 302 wechseln)
        In der Root-HP gibt es weder die Links noch die hreflanfg-Anmerkung... es gibt sogar kein Ereignis auf der Seite selbst.
        Derzeit nimmt Google nur die US-Version als hp, auch bei Suchen aus anderen Ländern. Nur in den Sitelinks erscheinen die lokalen Versionen.
        Wenn die Google-Richtlinien nur klar wären... Ich würde deine Zeit und Geduld nicht missbrauchen!

        Antworten

        1. Mach dir keine Sorgen um meine Zeit und Geduld 😉 .

          Die Dinge sollten besser werden, wenn du zu 302 wechselst. Ich zeige dir zwei Websites, die es genau so machen (Geo-IP/Browsersprache basiertes 302 von x-default zu Unterverzeichnis, hreflang im Quellcode implementiert) und die Ergebnisse sind großartig. Es ist wirklich kein Problem, wenn deine x-default Version nicht zurückverlinkt (obwohl es natürlich besser wäre, wenn sie es täte). Schau dir diese beiden Beispiele an:

          https://www.ecom-ex.com/
          https://www.nfon.com/

          Lass mich wissen, wie es bei dir läuft, nachdem du deine Weiterleitung von 301 auf 302 geändert hast.

          Antworten

  14. Hallo Eoghan,
    Danke für deine tollen Artikel über hreflang!
    Wir haben das hreflang-Tag für unser Produktverzeichnis (www.example.de, http://www.example.at, http://www.example.ch und fr.example.ch) vor 2 Monaten, kann aber keine Veränderungen feststellen - der .de-Shop erscheint immer noch in den Rankings von AT und CH. Kannst du aus deiner Erfahrung sagen, wie lange es dauert, bis sich hreflang auswirkt?
    Ich weiß, dass hreflang eher ein Signal als eine Richtlinie ist, aber ich hätte nicht erwartet, dass die Implementierung überhaupt keine Auswirkungen zeigt. Die Google Search Console hat auch ein paar Fehler entdeckt (etwa 10), also muss Google unsere hreflang-Tags bemerkt haben.
    Andere Überlegungen sind, dass wir den hreflang vielleicht in jedem Verzeichnis (seitenweit) implementieren müssen, um mehr Wirkung zu erzielen?
    Ich danke dir!

    Antworten

    1. Hallo Isa,

      Vielen Dank für deinen Kommentar.

      Normalerweise dauert es nicht so lange, bis Google die hreflang-Anmerkungen verarbeitet. Wenn deine hreflang-Implementierung also überhaupt keine Auswirkungen zeigt, muss es andere Faktoren geben, die Google dazu bringen, deine hreflang-Anmerkungen zu ignorieren.

      Ich würde deine erste Idee auf jeden Fall unterstützen: Es ist ratsam, hreflang auf der gesamten Website zu implementieren, d.h. jede URL, die eine Entsprechung auf einer der anderen Domains hat, sollte hreflang-Annotationen erhalten. Achte darauf, dass deine hreflang-Implementierung so vollständig und sauber wie möglich ist.

      Andererseits solltest du bei einer unvollständigen Implementierung wie dieser sicherstellen, dass du die Auswirkungen richtig misst: Die Änderungen werden natürlich nur für URLs angezeigt, die hreflang haben. Du solltest also überprüfen, ob die richtige Version in den verschiedenen Länderversionen für die spezifischen URLs erscheint, an denen du gearbeitet hast. Andere URLs sind davon nicht betroffen, daher kann es sein, dass du immer noch viele Seiten siehst, die in den falschen Ländern ranken.

      Ich werde dir weitere Informationen per E-Mail schicken.

      Antworten

      1. Hallo Eoghan,
        danke für deine ausführliche Antwort und deine E-Mail auf Deutsch 😉 Wir haben ein paar Seiten gefunden, auf denen die DE-Version auch dann in AT rangiert, wenn der AT hreflang-Link existiert. Aber wir werden den hreflang-Tag auf jeden Fall auf der gesamten Website implementieren. Es ist nur eine Frage der Zeit.

        Antworten

  15. Yo,

    Wir haben hreflang und die Seitenstruktur dank deiner Hilfe fast umgesetzt.

    Für jede Seite wird hreflang auf diese Weise implementiert
    ink rel=”alternate” href=”https://domain.tld/us/test-phone” hreflang=”en-us”
    ink rel=”alternate” href=”https://domain.tld/gb/test-phone” hreflang=”en-gb”
    ink rel=”alternate” href=”https://domain.tld/test-phone” hreflang=”x-default”
    ink rel=”alternate” href=”https://domain.tld/test-phone” hreflang=”en”

    Wenn ein Besucher domain.tld manuell eingibt, erkennen wir sein Land und er wird zum richtigen Unterverzeichnis weitergeleitet.

    Außerdem gibt es auf jeder Seite ein manuelles Dropdown-Menü, um ein bestimmtes unterstütztes Land auszuwählen.

    Es gibt zwei Möglichkeiten, dies umzusetzen: mit Cookie und ohne Cookie.

    1) Ohne Cookie zum Speichern des Landes
    Verhalten bei jedem Seitenaufruf wird das Land erkannt und zum richtigen Unterverzeichnis weitergeleitet, wenn dieses Land unterstützt wird
    Das erwartete Verhalten der Google-Indizierung ist wie folgt.
    1.1) Google wird in der Lage sein, die richtige URL mit dem richtigen Unterverzeichnis für das jeweilige Land zu indexieren und anzuzeigen.
    So erhält der Nutzer immer die richtige URL und eine Umleitung in den Google-Suchergebnissen ist nicht erforderlich.
    1.2) Wenn der Benutzer die domain.tld manuell eingibt, wird er automatisch in das richtige Land umgeleitet und die URL ändert sich mit dem richtigen Unterverzeichnis.

    2) Cookie mit Land wird beim ersten Laden gesetzt.
    Verhalten, wenn das erste Mal ein Land erkannt und im Cookie gespeichert wird.
    Wenn also domain.tld zum ersten Mal eingegeben wird, landet der Benutzer z.B. von domain.tld/us/
    Der nächste Nutzer schließt den Browser und gibt domain.tld manuell ein und bekommt den Inhalt von ‘us’ angezeigt. Aber die URL in der Adressleiste ändert sich nicht.
    So wird er weiterhin in der richtigen Sprache browsen, aber die URL wird sich nicht mit dem Unterverzeichnis ändern.
    In diesem Fall wird der Länderwert nicht geprüft und nicht umgeleitet, um die URL-Struktur zu ändern.

    Welcher Weg ist der richtige?
    Auf diese Weise wird Google Schwierigkeiten haben, die korrekte Variante der Daten zu indexieren, da hreflang verwendet wird, damit die angezeigten Preise je nach Land korrekt sind.

    Antworten

    1. Hallo Sungod! Willkommen zurück und danke für das Update 🙂 .

      Die Cookie-Lösung hat keinen Einfluss darauf, wie Google deine Seiten crawlt. Mach dir also nicht zu viele Gedanken darüber und wähle die Option, die für deine Nutzer am besten ist.

      Das Einzige, was ich mich frage, ist, warum du die URL in Option 2 nicht ändern willst? Warum leitest du den Nutzer nicht anhand des Cookies auf die richtige Bezirksversion um? Schau dir an, wie https://sedo.com/ (das Menü zur Sprachauswahl befindet sich oben in der Fußzeile der Seite). Wenn du die Sprache änderst, wird deine Auswahl in einem Cookie gespeichert und wenn du die https://sedo.com/ (ohne Sprachverzeichnis) wirst du zu dem Sprachverzeichnis weitergeleitet, das du zuvor ausgewählt hast.

      Antworten

      1. Option 2 hatte mein Entwicklungsteam vorgeschlagen und ich tendierte eher zu Option 1, und auch Google bestätigte, dass Option 1 am besten ist.

        Sobald wir richtig gestartet sind, wird es mir eine Ehre sein, wenn du das Projekt besuchst.
        Ich werde die Details mit dir teilen, sobald wir gestartet sind 🙂 .
        Vielen Dank für deine Hilfe.

        Mit freundlichen Grüßen
        Sungod

        Antworten

  16. Hi,

    Ich habe mit einigen Konzepten zu kämpfen. .
    Wie man Analytics mit Seiten verwendet, die hreflang-Alternativen haben.
    Ich möchte das Konzept kennen und wissen, was auf solchen Seiten möglich ist.
    Werden wir getrennte Auswertungen/Hits für verschiedene URLs haben?
    Können wir das Ergebnis kombinieren?
    Wird es nativ unterstützt oder passen wir es an.

    Mit freundlichen Grüßen
    Sungod

    Antworten

    1. Hallo Sungod,

      Standardmäßig werden URLs mit hreflang-Anmerkungen in Webanalysetools immer noch separat verfolgt. Ich würde empfehlen, das Tracking getrennt zu halten, aber es gibt Möglichkeiten, URLs zu gruppieren, wenn du die Daten auswertest. Es kann sogar sinnvoll sein, für jeden Satz von URLs einen eigenen Wert zu tracken, damit du sie in deinen Berichten leicht gruppieren kannst.

      Benutzt du Google Analytics?

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

      1. Hi,

        Derzeit gibt es keine Google Analytics oder andere Analysen.
        Ich werde Piwik einsetzen.
        Nach zwei Wochen oder mehr damit, werde ich mehr über eine Lösung erfahren.
        Es gibt fast keine Artikel zu diesem Fall; vielleicht ist es ein Grenzfall 🙂 .

        Mit freundlichen Grüßen
        Sungod

        Antworten

  17. Hallo Eoghan,

    Ich habe eine Weile herumgesucht, aber ich habe keine richtige Lösung gefunden. Dein Artikel hat mir am meisten geholfen. Aber mein Fall ist ein bisschen anders.

    Ich habe zwei Versionen unserer Website;
    barakudabodrum.com/tr/ für Menschen, die Türkisch sprechen und
    barakudabodrum.com für alle anderen.

    Ich muss etwas falsch gemacht haben, denn ich bekomme die türkische Seite nicht angezeigt, wenn ich suche und klicke.

    Ich habe diesen Code auf jeder Seite in meiner Kopfzeile und nirgendwo sonst:

    Ich habe zwei Einträge in der Google Search Console für jede Sprache.

    Wenn du mir helfen könntest, wäre ich dir sehr dankbar.

    Ich bin gespannt auf den Rest deines Artikels

    Danke
    Mete

    Antworten

    1. Hallo Mete,

      Vielen Dank für deinen Kommentar. Es tut mir leid, dass ich zu spät geantwortet habe und dass meine Website deine Code-Beispiele verschluckt hat (das macht sie immer und ich konnte es noch nicht beheben). Dein Kommentar erinnert mich auch daran, dass ich diesen Artikel unbedingt fertigstellen muss 😉 .

      Ich habe einen Blick auf deine Seite geworfen, aber es scheint, als hättest du etwas geändert, seit du diesen Kommentar geschrieben hast. Du weißt, dass du drei Versionen deiner Homepage hast, zwei auf Türkisch und eine auf Englisch. Kannst du mir mehr Informationen schicken, damit wir das besprechen können?

      Antworten

      1. Hallo Eoghan,

        Danke, dass du dir Zeit für meine Seite nimmst.

        So sah die Seite aus, als ich geschrieben habe:
        hreflang=”x-default” href=”http://barakudabodrum.com
        hreflang=”tr” href=”http://barakudabodrum.com/tr/

        tr für türkische Menschen und x-default(en) für alle anderen
        Englische Suchanfragen in den englischen Einstellungen der Website landen immer auf der 1. oder 2.
        Die türkische Suche in den türkischen Einstellungen zeigt die Startseite überhaupt nicht an. Eine andere Seite erscheint erst ab Seite 6 oder mehr.

        Ich habe verzweifelt alles versucht. Ich habe Sitemaps getrennt. Ich habe Sitemap-Indizes hinzugefügt. Ich habe in der Suchkonsole für jede Sprache (sowohl für die www- als auch für die Nicht-Www-Version) eine andere Eigenschaft eingetragen, aber nichts hat sich geändert.

        Ich habe es vor kurzem auf drei Sprachen geändert:
        hreflang=”x-default” href=”http://barakudabodrum.com (in tr)
        hreflang=”tr” href=”http://barakudabodrum.com/tr/
        hreflang=”en” href=”http://barakudabodrum.com/en/

        Denn ich möchte, dass meine Seite auch auf Türkisch angezeigt wird. Aber ich bin nicht sehr zufrieden. (Es kann sein, dass die Seite ein paar Fehler enthält, weil ich ein Skript geschrieben habe, um die Navigationsleiste und andere allgemeine Dinge zu generieren, aber vorher war sie sauber)

        Die Dinge scheinen einfach nicht richtig zu sein

        Danke

        Antworten

        1. Hallo Mete,

          Vielen Dank für die zusätzlichen Informationen. In deiner alten Implementierung wäre es besser gewesen, einen “en” hreflang-Wert für die englische Version hinzuzufügen:

          hreflang=”x-default” href=”http://barakudabodrum.com”
          hreflang=”en” href=”http://barakudabodrum.com”
          hreflang=”tr” href=”http://barakudabodrum.com/tr/”

          Der “x-default”-Wert ist optional, aber der Sprachwert sollte auf jeden Fall vorhanden sein. Ich vermute, dass Google durch den fehlenden Sprachwert für die englische Version verwirrt worden sein könnte.

          In deiner neuen Implementierung hast du zwei türkische Versionen deiner Seiten und du definierst eine davon als “x-default”. Eine türkische Version wäre besser und der “x-default”-Wert ist wahrscheinlich besser für die englische Version geeignet (sonst würde z.B. einem deutsch- oder französischsprachigen Nutzer die türkische Version angezeigt werden).

          Deine jüngsten Änderungen haben bei Google für zusätzliche Verwirrung gesorgt. Deine alten englischen Seiten im Stammverzeichnis werden zwar noch indiziert, geben aber 404-Fehler zurück. Es könnte eine gute Idee sein, so schnell wie möglich zu deiner alten Struktur zurückzukehren und den Sprachwert für die englische Version hinzuzufügen. Stelle sicher, dass du deine “neuen” englischen URLs im Verzeichnis /en/ auf die alten englischen URLs und deine “neuen” türkischen URLs im Stammverzeichnis auf die alten türkischen URLs im Verzeichnis /tr/ umleitest, damit sie keine 404-Fehler zurückgeben, wenn sie bereits indexiert wurden.

          Ich hoffe, das hilft dir und lass es mich bitte wissen, wenn du weitere Fragen hast!

          Eoghan

          Antworten

          1. Danke Eoghan,

            Ich mache es auf deine Art.

            Übrigens habe ich meine Konkurrenten ausführlich untersucht. Die Konkurrenten mit meiner Art von internationalem Targeting leiden unter demselben Problem. Ihre Sprachen, die nicht zur Root-Domain gehören, rangieren auf den hinteren Plätzen.

            Aber vielleicht liegt das Problem woanders.

            Nochmals vielen Dank

          2. Wenn du möchtest, dass ich einen kurzen Blick auf deine Konkurrenten werfe und dir sage, was ich von ihrem internationalen Targeting halte, schick mir einfach eine E-Mail mit ihren Domains. Und lass mich wissen, wie es mit deiner hreflang-Implementierung läuft!

  18. Hallo Henn,

    Zunächst einmal möchte ich mich bei dir für diesen informativen Beitrag über den Hreflang-Tag bedanken.

    Könnten Sie mir bitte helfen, ich habe eine Frage: Ich habe derzeit eine Website (www.example.co.uk). Jetzt plane ich, zwei alternative Websites in Irland zu erstellen. Zum Beispiel http://www.example.ie und eine andere ist http://www.abc.ie und ich möchte den Hreflang-Tag für alle diese Seiten wie unten beschrieben verwenden.

    Hreflang Tag in http://www.example.co.uk

    Hreflang Tag in http://www.example.ie

    Hreflang Tag in http://www.abc.ie

    Danke
    Satla

    Antworten

    1. Hallo Satla,

      Vielen Dank für deinen Kommentar. Bitte lass mich dir ein paar Fragen stellen, damit ich deine Anfrage besser verstehe.

      • Ist der Inhalt einer der irischen Websites identisch oder sehr ähnlich mit dem der britischen Website?
      • Was ist der Unterschied zwischen den beiden irischen Websites?

      hreflang-Anmerkungen sind sinnvoll, wenn du mehrere Versionen desselben Inhalts unter verschiedenen URLs für verschiedene Länder oder in verschiedenen Sprachen hast. Bitte erzähl mir etwas mehr über die Inhalte auf deinen Websites, damit ich weiß, welche Art der Implementierung du brauchst.

      Antworten

      1. Hallo Henn,

        Vielen Dank für deine Antwort und ich hoffe, es geht dir gut!

        Im Folgenden findest du meine Antworten.
        1. Ist der Inhalt einer der irischen Websites mit dem der britischen Website identisch oder sehr ähnlich? (Ja, gleicher Inhalt)

        2. Was ist der Unterschied zwischen den beiden irischen Websites? Beide sind unterschiedliche Domains und ich möchte den Inhalt der britischen Website mit Hilfe des Hreflang-Tags auf die irische Website übertragen.

        Meine britische Website lautet zum Beispiel http://www.example.co.uk und diese Seite ist komplett einzigartig und viele Seiten wurden von Google indexiert. Jetzt möchte ich mein Geschäft in Irland ausbauen und deshalb möchte ich zwei Domains erstellen.

        Bitte lass mich wissen, wenn du weitere Details benötigst.

        Danke
        Satla

        Antworten

        1. Hallo Satla,

          Mir ist immer noch nicht ganz klar, warum du zwei irische Domains brauchst (statt nur einer), aber für jede Seite, die sowohl auf deiner britischen als auch auf einer deiner irischen Domains existiert, könnten die hreflang-Anmerkungen so aussehen:

          <link rel=”alternate” href=”http://www.example.co.uk/page1/” hreflang=”en-gb”>
          <link rel=”alternate” href=”http://www.example.ie/page1/” hreflang=”en-ie”>

          Oder, wenn es auf deiner britischen Seite und der anderen irischen Domain ist:

          <link rel=”alternate” href=”http://www.example.co.uk/page2/” hreflang=”en-gb”>
          <link rel=”alternate” href=”http://www.abc.ie/page2/” hreflang=”en-ie”>

          Du würdest nur dann Probleme bekommen, wenn du denselben Inhalt auf beiden irischen Domains hättest, da es dafür keine Lösung mit hreflang gibt. Es wäre wahrscheinlich am besten, ein kanonisches Tag von einer der identischen irischen URLs zur anderen zu implementieren und die andere irische URL nur mit ihrem britischen Äquivalent über hreflang zu verlinken. Hier erfährst du mehr darüber, wie du canonical und hreflang zusammen verwenden kannst: https://www.rebelytics.com/hreflang-canonical/

          Ich hoffe, das hilft! Bitte lass mich wissen, wenn etwas unklar bleibt.

          Antworten

          1. Hallo Henn,

            Entschuldigung für die späte Antwort.

            Danke für deine Antwort. Schließlich werden wir nur eine irische Website betreiben. Ich werde alle Ihre wertvollen Punkte auf unserer Website berücksichtigen.

            Nochmals vielen Dank für die wertvollen Beiträge.

            Danke!,
            Satla

  19. Hallo Eognan!
    Danke für die beste Lektüre, die ich zum Thema Freflang gefunden habe. Ich habe noch eine Frage zu einem meiner Kunden und hoffe, dass du einige Fragezeichen für mich klären kannst.

    Sie haben eine Multi-Domain-Einrichtung und einige Domains haben auch Sub-Domains für bestimmte Sprachen. Meine Fragen:

    1. es gibt 4 Versionen auf Deutsch. Soll ich den Länderparameter für eine der Versionen weglassen und nur die Sprache auswählen?

    2. sie haben auch einige englische Versionen. Soll ich auf ihrer Hauptseite für den Rest der Welt die Sprache und x-default language verwenden?

    3. wähle ich in Search Console auch das Land und den Rest der Welt für die Domains aus, für die ich nur die Sprache angebe (wenn das die beste Option ist)?

    Vielen Dank im Voraus.

    Antworten

    1. Hallo Erik,

      Vielen Dank für deinen Kommentar. Es freut mich zu hören, dass du den Artikel hilfreich fandest.

      Hier sind meine Antworten auf deine Fragen:

      1. Das hängt von den Details der verschiedenen Versionen ab. Du kannst eine der deutschen Versionen als allgemeine Sprachversion mit nur dem Sprachcode kennzeichnen, wenn sie nicht auf einer länderspezifischen Domain wie .de oder .at gehostet. Sind die anderen deutschen Versionen für verschiedene Länder? Achte darauf, dass du nicht zwei verschiedenen URL-Versionen denselben hreflang-Wert zuweist. Wenn du aus irgendeinem Grund zwei deutsche Versionen für dasselbe Land (z. B. Deutschland) hast, solltest du wahrscheinlich kanonische Tags verwenden, die von einer der Versionen auf die andere zeigen.
      2. Ja, du kannst der englischen Hauptversion für den Rest der Welt die Werte “en” und “x-default” zuweisen. Siehe hier: Mehrere hreflang-Tags können auf eine URL verweisen
      3. Wenn du nur eine Sprache in den hreflang-Anmerkungen angibst, solltest du nicht ein Land für diese Version in der Google Search Console angeben. Wenn es auf einer Domain mehrere Verzeichnisse für verschiedene Länder gibt, kannst du in der Google Search Console für jedes Verzeichnis eine Eigenschaft einrichten und dort das Land angeben. Achte darauf, dass du kein Land in der Eigenschaft einer ganzen Domain angibst, wenn die Domain Verzeichnisse enthält, die auf andere Länder ausgerichtet sein sollen. Beachte auch, dass du bei einer ccTLD (länderspezifische Domain, wie .se, .de oder .it) die Ländereinstellung in der Google Search Console nicht ändern kannst, daher sollten deine hreflang-Anmerkungen für diese Domain auch immer den entsprechenden Ländercode enthalten. Es ist sehr wichtig, die Signale, die du in deinen hreflang-Anmerkungen und in den Ländereinstellungen in der Google Search Console sendest, aufeinander abzustimmen.

      Du kannst gerne weitere Fragen stellen, wenn etwas unklar bleibt. Du kannst mir auch eine E-Mail schicken, wenn du detailliertere Fragen zur Website hast und die Kundeninformationen nicht öffentlich teilen möchtest.

      Ich hoffe, das hilft!

      Eoghan

      Antworten

      1. Hallo Eognan!

        Vielen Dank für die schnelle Antwort. Ich habe noch ein paar weitere Fragen:

        1.
        Der Aufbau sieht folgendermaßen aus:
        CH = de-CH
        AT = de-AT
        DE = de
        Die deutsche Domain wird auf .de gehostet und wir haben nur eine Domain für DE und doppelte Inhalte für AT und CH.
        Ist es besser, stattdessen de-DE zu verwenden? Oder hat es einen gewissen Effekt, nur die Sprache anzugeben?
        2.
        Ist es besser, alle Länder anstelle von X-Standard anzugeben (es werden viele Länder sein). Brauchen wir den X-Standard oder ist es besser, nur die Sprache und “alle Länder” in SC anzugeben?
        3.
        Toll, danke.

        Vielen Dank im Voraus.

        Antworten

        1. Hallo Erik,

          hier sind meine Antworten auf deine Fragen:

          1. Wenn dein Inhalt auf einer .de-Domain liegt, ist es sinnvoller, ihr den Wert “de-DE” zuzuweisen, da Google .de-Domains standardmäßig als auf Nutzer in Deutschland ausgerichtet interpretiert.
          2. Nein, es ist absolut nicht nötig, alle Länder in hreflang-Anmerkungen für eine Version anzugeben, die für den Rest der Welt bestimmt ist. Außerdem ist “x-default” in den meisten Fällen optional (es sei denn, es gibt eine Standard-URL, die keine eigene Sprache hat, wie z. B. eine Startseite mit Sprachauswahl oder eine Stamm-URL, die je nach Standort oder Browsersprache weitergeleitet wird). Du kannst “x-default” als zusätzlichen Wert für jede Version verwenden, die angezeigt werden soll, wenn keine der anderen Versionen mit der Sprache und dem Standort des Nutzers übereinstimmt, oder du kannst es einfach lassen und Google entscheiden lassen, welche URL den Nutzern angezeigt werden soll.

          Ich hoffe, das hilft! Bitte lass mich wissen, wenn etwas unklar bleibt.

          Antworten

  20. Ich entwickle gerade eine Website im Auftrag eines Kunden.
    Die Seite ist eine Mischung aus Dropshipping und Direktverkauf von Produkten Dritter.
    Etwas Ähnliches wie tiendamia.com oder gugaloo.com
    Die Idee? Geh einen Schritt weiter!
    Mit einem kleinen Code, den ich dynamisch für hrflang erstellt habe
    Auf diese Weise wird die Produktseite, die Homepage oder die Kontaktseite den richtigen hrflang haben.

    Meine Zweifel kommen beim nächsten Punkt.
    Ich habe Seiten wie Tripadvisor, Booking, Godaddy und Ebay beobachtet ...
    Einige werden automatisch übersetzt, andere haben identische Inhalte und andere exklusive Inhalte, je nach Sprache oder Region, in manchen Fällen werden sie automatisch weitergeleitet, oder mittels eines Hinweises (Popup, Banner, Modal).

    Ich konnte keine Antwort finden, die auf dem Abzug basiert, obwohl die Seite, die meinem Bedarf am ähnlichsten ist, Ebay ist.

    Meine Website in einer Sprache für jede Url, zum Beispiel,
    misite.com : Englisch für alle,
    uy.misite.com Spanisch nach Uruguay
    ve.misite.com für Venezuela
    mx.misite.com Spanisch nach Mexiko
    it.misite.com Italienisch nach Italien
    gb.misite.com English to United Kingdom,

    Die Produkte werden von Amazon geladen, indem sie über die API importiert werden.

    Titel, Beschreibung und alles, was importiert wird, ist in englischer Sprache.

    Also, was passt besser zu mir?

    A) alle Subdomains auf Englisch sind und jeder Nutzer selbst entscheidet, welche Sprache er verwenden möchte
    - An dieser Stelle wird beim Ändern der Sprache die mo / po Übersetzungsdatei der Website für die entsprechende Übersetzung aktiviert und eine zusätzliche Option mit google translate, um die Beschreibung und die Produkte zu übersetzen.

    B) dass jede Subdomain ihre Übersetzung mo / po aktiviert, mit der jede Seite in der Sprache entsprechend ihrer Region erscheint, z.B. Italienisch für Italien.

    - An dieser Stelle hat der Nutzer die Möglichkeit, die Produktbeschreibung wie zuvor mit Google Translate zu übersetzen.

    Unter Punkt A könntest du hrflang “en-XX” für jede Subdomain eingeben
    In Punkt B könnte ich hrflang entsprechend der Sprache und der Region für jede Subdomain eingeben (es-UY, en-GB, it, es-VE, ....,)
    Aber meine Frage ist, was passiert, wenn Google die Kopfzeile liest und einen Teil der Sprache auf Englisch findet?

    Saludos!
    Marcelo

    Antworten

    1. Hallo Marcelo,

      Vielen Dank für deinen Kommentar und deine detaillierte Frage. Mal sehen, ob ich dir damit helfen kann...

      Im Fall A würden die Suchmaschinen nur englische Inhalte auf deiner Website finden, weil sie die Benutzeraktion, die für die Übersetzung von Inhalten erforderlich ist, nicht durchführen würden. Das würde bedeuten, dass du nicht in der Lage wärst, viel Traffic von Nutzern zu generieren, die in anderen Sprachen suchen.

      Im Fall B wären deine Inhalte in mehreren Sprachen verfügbar, was dir definitiv mehr Reichweite verschaffen würde. Aber wenn du dich für diese Variante entscheidest, solltest du wirklich sicherstellen, dass du gute und vollständige Übersetzungen deiner Inhalte hast. Gemischtsprachige Inhalte auf einer Seite sind ein verwirrendes Signal für Suchmaschinen (und für Nutzer/innen) und sollten vermieden werden.

      Beide Optionen sind nicht ideal (denn der ideale Weg wäre, automatische Übersetzungen zu vermeiden), aber wenn du dich für Option B entscheidest, wäre es wahrscheinlich besser, die Übersetzung der Produktbeschreibungen usw. nicht dem Nutzer zu überlassen, sondern sie bereits beim Laden der Seite anzuzeigen, damit die Suchmaschine sie auch findet.

      Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  21. Hallo Eoghan,

    Ich komme aus Indien. Ich habe eine Website (www.aroundthelife.com) nur in englischer Sprache. Alle Seiten sind in englischer Sprache. Ich möchte meine Website global ausrichten. Ich habe keine übersetzten Seiten oder Beiträge, die in anderen Sprachen verfügbar sind. welchen hreflang-Tag soll ich verwenden?

    Ich bin sehr beunruhigt über diese Angelegenheit. Bitte hilf mir.

    danke

    Antworten

    1. Hallo Hardik,

      Für eine Website, die nur eine Länder- oder Sprachversion hat, brauchst du keine hreflang-Anmerkungen.

      Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

      1. Danke, Eoghan, für deine Antwort, aber ich möchte noch etwas mehr darüber wissen,

        Ich habe kein bestimmtes Land ins Visier genommen. Meine Seite ist für Englischsprachige auf der ganzen Welt. Alle meine Artikel sind nur in englischer Sprache, aber in der GOOGLE-SUCHE erscheinen folgende Massagen.
        “Deine Website hat keinen hreflang-Tag. Google verwendet hreflang-Tags, um die Spracheinstellung des Nutzers mit der richtigen Variante deiner Seiten abzugleichen.”

        Ich habe folgenden Tag im Abschnitt verwendet,

        Ist das angemessen? Was sollte ich tun?

        Antworten

        1. Hallo Hardik,

          Mach dir keine Sorgen wegen dieser Meldung. Ich glaube, sie wird im GSC für alle Websites angezeigt, die keinen hreflang verwenden, auch wenn sie keinen hreflang brauchen, weil sie nur eine Länder-/Sprachversion haben.

          Dein Codebeispiel wurde von meiner Website verschluckt, das tut mir sehr leid. Du kannst es mir per E-Mail schicken, wenn du magst 🙂 .

          Antworten

    1. Wenn sich deine internationalen Versionen auf verschiedenen Domains befinden, musst du verschiedene XML-Sitemaps einrichten. Wenn sie sich in verschiedenen Verzeichnissen auf derselben Domain befinden, ist das optional, wird aber empfohlen.

      Antworten

  24. Muss ein hreflang-Tag auf eine bestimmte Weise aufgebaut sein? Muss es also sein:
    rel, href, hreflang

    Oder kann es sein:

    rel, hreflang, href

    Danke!

    Antworten

    1. Hallo Cameron,

      Vielen Dank für deine Frage. Soweit ich weiß, spielt die Reihenfolge der Attribute keine Rolle und beide Beispiele, die du genannt hast, sollten funktionieren.

      Ich hoffe, das hilft!

      Antworten

  25. Hey Eoghan,
    Zunächst einmal vielen Dank für die ausführliche Anleitung zum Einrichten von hreflang-Tags und das Ausräumen vieler Zweifel, die wir alle hatten. Ich wollte eine Frage stellen, die ich seit langem versuche zu lösen, aber keine richtige Lösung bekomme

    Wir haben unsere Website für die USA, Großbritannien und Indien und verwenden .com, .co.uk und .in cctlds. Wir verwenden GeoIP-basierte Weiterleitungen. Wir verwenden hreflang-Sitemaps für hreflang-Targeting.

    Das Hauptproblem ist, dass Google früher nicht einmal eine andere Version unserer Website indexiert hat, sondern nur unsere US-Site. Daher schlugen einige SEOs vor, die Umleitung für eine Weile zu stoppen.

    Ein Problem wurde dadurch behoben, dass auch andere Seiten indexiert werden. Der Haken an der Sache ist jedoch, dass die Seiten zwar indiziert werden, aber im Cache nur die .com-Version angezeigt wird.

    Gibt es eine Möglichkeit, dieses Problem zu beheben?

    Antworten

    1. Hallo Ankit,

      Vielen Dank für deine interessanten Fragen.

      GeoIP-basierte Weiterleitungen sollten sehr vorsichtig eingesetzt werden. Meiner Meinung nach sind sie in Ordnung, wenn sie von URLs, die keinen eigenen Inhalt haben (z. B. eine Stamm-URL auf einer .com-Domain), auf eine lokalisierte Version (ein Länder-/Sprachenverzeichnis oder eine ccTLD) verweisen. GeoIP-basierte Weiterleitungen, die von einer Inhaltsversion auf eine andere verweisen, sollten in den meisten Fällen vermieden werden. Es ist keine gute Idee, solche Weiterleitungen von deiner .in auf deine .co.uk- oder .com-Domain oder umgekehrt einzurichten. Du hast selbst gesehen, dass Google die Inhalte auf den beiden anderen Domains nie indexiert hat, weil sie wegen der US IP immer an die .com Domain geschickt wurden. Die Weiterleitungen vorübergehend zu entfernen, ist auch keine besonders gute Lösung. Du kannst zwar erreichen, dass deine Inhalte einmal gecrawlt und indexiert werden, aber was du wirklich willst, ist, dass Google regelmäßig zurückkommt, um deine Seiten erneut zu crawlen. Ich empfehle dir daher, die Verwendung von GeoIP-basierten Weiterleitungen zu überdenken.

      Das andere Problem, auf das du hingewiesen hast, ist ein separates Problem, auch wenn es damit zusammenhängt. Wenn verschiedene Sprachversionen sehr ähnlich oder identisch sind, beschließt Google oft, die URLs zu einer URL zusammenzufassen, oder anders gesagt, sie zu kanonisieren. Hier sind einige Dinge, die dabei helfen können:

      - Korrekte hreflang Implementierung
      - Lokalisierung des Inhalts jeder Version (z.B. Verwendung von Informationen, Vokabular und Grammatik, die für das jeweilige Land relevant sind)
      - Lokalisierung von Titel-Tags und Meta-Beschreibungen
      - Verknüpfung der verschiedenen Sprach-/Länderversionen miteinander
      - Lokale externe Links für jede Version
      und so weiter...

      Du musst an Signalen arbeiten, die Google helfen zu verstehen, dass es sich um verschiedene Versionen desselben Inhalts für verschiedene Nutzer handelt und nicht nur um denselben Inhalt unter verschiedenen URLs.

      Ich hoffe, das hilft dir. Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  26. Danke für diesen Leitfaden, ich weiß ihn wirklich zu schätzen.

    Eine Frage: Ich habe eine WP-Website für .co.uk und .com. Muss ich bei der Implementierung von HREF LANG die href lang en-us und en-gb zu den URLs beider Websites hinzufügen? Ich bin mir nicht sicher, wie ich das in WP überhaupt machen kann!

    Antworten

    1. Hallo Will!

      Ja, jede URL in beiden Versionen braucht hreflang-Annotationen, die auf sich selbst und auf das Äquivalent in der anderen Version verweisen.

      Ich verwende das WordPress-Plugin Polylang für die Verwaltung mehrsprachiger und länderübergreifender Websites. Es fügt automatisch korrekte hreflang-Anmerkungen hinzu. Probier es aus!

      Und wenn das nicht funktioniert, gibt es immer noch die Möglichkeit, den Google Tag Manager zu verwenden, obwohl das dein letzter Ausweg sein sollte, da er unübersichtlich und experimentell ist: https://www.searchviu.com/en/hreflang-google-tag-manager/

      Ich hoffe, das hilft dir. Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  27. Hi,
    So ein wunderbarer Beitrag in der Länge. Meine Website hat die Erweiterung .Pk und der Inhalt ist auf Englisch (US), was auch in den allgemeinen Einstellungen von WordPress eingestellt ist. Aufgrund von .Pk hat Google in webmaster meinen Geostandort auf .Pk festgelegt, aber es sagt auch, dass mein Sprach-Tag fehlt. “Ihre Website hat keine hreflang-Tags.”

    Um den Fehler zu beheben, habe ich dies der header.php vor den Starts hinzugefügt.

    Kannst du mir helfen, ob das die richtige Implementierung ist oder ob ich diesen Tag gar nicht hinzufügen muss?

    Antworten

    1. Hallo Mudassar,

      Vielen Dank für deinen Kommentar. Leider lässt meine WordPress-Installation derzeit keine Code-Beispiele in Kommentaren zu. Ich arbeite daran, eine Lösung zu finden, um das zu beheben.

      Wenn deine Seite nur eine Version hat, brauchst du keine hreflang-Tags. Die Meldung “Deine Seite hat keine hreflang-Tags” im GSC ist nicht wirklich eine Warnung, sondern eher eine Feststellung.

      Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  28. Hi,
    Meine Website zielt auf asiatische Länder ab und endet mit der Endung .asia. Kann ich also hreflang auf meiner Seite verwenden und wie kann ich es implementieren?.
    Danke

    Antworten

    1. Ja, du kannst hreflang mit allen Domain-Endungen verwenden, auch mit .asia. Die Verwendung von hreflang ist nur sinnvoll, wenn du mehr als eine Version deiner Website für Nutzer aus verschiedenen Ländern oder in verschiedenen Sprachen hast. Die obige Anleitung sollte dir dabei helfen, hreflang richtig zu implementieren. Sollte etwas unklar bleiben, kannst du mir gerne detaillierte Fragen stellen. Ich hoffe, das hilft dir erst einmal!

      Antworten

  29. Hallo Eoghan,

    Toller Artikel! Sehr ausführlich und mit vielen hilfreichen Informationen!

    Ich habe einen Kunden, der in über 140 verschiedenen internationalen Märkten vertreten ist. Sie verwenden eine Unterverzeichnisstruktur für ihre Internationalisierungsbemühungen. Ein Bereich der Website, der auf Englisch in den USA ausgerichtet ist, wird zum Beispiel unter http://www.example.com/us/en und Spanisch unter http://www.example.com/us/es und so geht die Struktur für alle Länder und Sprachen weiter.

    Da es über 140 verschiedene Unterverzeichnisse gibt, kann ich mir nicht vorstellen, einen HREFLANG über die Sitemap zu erstellen. Was ist hier die beste Vorgehensweise?

    Müssen wir all diese verschiedenen Variationen von Ländern und Sprachen für jede URL auf der Website angeben, die eine Alternative in einem anderen Markt hat? Das summiert sich leicht auf über 140 hreflang-Tags für jede Seite und ich bin mir nicht ganz sicher, wie sich das auf die Ladezeiten auswirkt, wenn es über HTML implementiert wird, oder ob es das Limit der URLs pro Sitemap-Datei erreicht.

    ......

    Was denkst du, ist die beste Vorgehensweise hier? Danke!

    Antworten

    1. Hallo Scott,

      Vielen Dank für deinen Kommentar. Ich freue mich, dass du den Artikel hilfreich fandest.

      Eine Website mit 140 Länder-/Sprachverzeichnissen ist definitiv eine Herausforderung und ich habe schon viele Fälle gesehen, in denen eine große Anzahl von Website-Versionen viele Probleme verursachen kann.

      Die Implementierung von hreflang in XML-Sitemaps könnte in diesem Fall ein guter Ansatz sein, obwohl das normalerweise nicht meine Lieblingsmethode ist. Bitte beachte, dass hreflang-Annotationen nicht auf das URL-Limit pro Sitemap angerechnet werden. Wenn du also eine Sitemap mit 10.000 URLs hast, die jeweils 140 hreflang-Annotationen enthalten, hast du immer noch eine Sitemap mit 10.000 URLs. Aber die Datei wird deutlich größer, und es gibt auch eine Grenze für die Dateigröße einer XML-Sitemap. Aber auch dafür gibt es eine Lösung: Du kannst immer mit mehreren kleineren Sitemaps arbeiten (z. B. eine pro Seitentyp oder eine pro Inhaltsverzeichnis) und sie in einer Sitemap-Indexdatei verknüpfen. Außerdem solltest du auf jeden Fall mindestens eine XML-Sitemap pro Land/Sprachverzeichnis erstellen, anstatt alle Website-Versionen in einer XML-Sitemap zusammenzufassen.

      Implementierung von 140 Zeilen hreflang-Anmerkungen im HTML scheint eine Menge zu sein, aber ich glaube nicht, dass es eine signifikante Auswirkung auf die Ladezeiten hätte. Du könntest das wahrscheinlich testen und dann anhand der Ergebnisse eine Entscheidung treffen.

      Die dritte Option, nämlich die Implementierung von hreflang über den HTTP-Header, könnte auch eine Möglichkeit für dich sein.

      Letztendlich ist es eine Diskussion, die du mit dem Entwicklerteam deines Kunden führen solltest, um herauszufinden, was aus ihrer Sicht am sinnvollsten ist und was sie bereit und in der Lage sind zu tun. Alle drei Optionen sind möglich, und alle werden aufgrund der vielen Verzeichnisse auf der Website komplex sein.

      Ich hoffe, das hilft dir erst einmal! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  30. Hallo Eoghan,

    danke für diesen sehr detaillierten und hilfreichen Artikel über hreflang. Er hat fast jede Frage beantwortet! Trotzdem gibt es zwei Dinge, mit denen ich noch kämpfe.
    Nehmen wir an, ich habe eine Website mit sprachlichen Unterverzeichnissen wie beispiel.de und beispiel.de/en. Würdest du dich entweder für eine Sitemap entscheiden, die alle mit hreflang-Attributen versehenen Seiten auf .de enthält, oder sollte es zwei Sitemaps geben? Eine “beispiel.de/sitemap.xml” mit allen DE-Seiten und eine zweite Sitemap auf “beispiel.de/en/sitemap.xml” mit nur den englischen Seiten. Das kommt mir sehr merkwürdig vor. Aber ich werde mich auf jeden Fall für eine Sitemap entscheiden. Andererseits... macht es Sinn, die Attribute in der Sitemap und im HTML-Header zu verdoppeln?

    Und die zweite Frage:
    Nehmen wir an, es gibt nur für Teile der Website Übersetzungen. Dann verwende ich den hreflang nur auf diesen Seiten mit mehreren Sprachvarianten. Aber wie muss ich die Seiten kennzeichnen, die nur in einer Sprache verfügbar sind?.
    So gibt es z.B.
    beispiel.de/dienstleistungen/
    und
    example.de/services/best-service/
    Aber im Englischen haben wir nur
    example.de/de/services/
    aber die Übersetzung für “beste Dienstleistungen” fehlt. Muss ich Google auch die Sprache der “besten Dienstleistungen” mitteilen und wenn ja... Wie?
    Ich würde mich sehr über deine Antwort freuen!

    Antworten

    1. Hallo Moritz,

      Vielen Dank für deine interessanten Fragen.

      Für Google spielt es keine Rolle, ob du eine XML-Sitemap mit allen URLs aus beiden Sprachversionen oder zwei getrennte Sitemaps erstellst, aber ich würde die zweite Option empfehlen, da es viel einfacher ist, Fehler zu analysieren, wenn du zwei getrennte Sitemaps hast.

      Du könntest zwei XML-Sitemaps mit den folgenden URLs erstellen:
      beispiel.de/de/sitemap.xml
      beispiel.de/sitemap-de.xml

      Und dann verknüpfe sie beide in einem Sitemap-Index file:
      beispiel.de/sitemap.xml

      Ich würde nicht empfehlen, die hreflang-Annotationen im HTML-Header und in den XML-Sitemaps zu verdoppeln. Du solltest dich für eine Methode entscheiden und nur diese verwenden.

      Wenn nur bestimmte Seiten übersetzt werden, sollten nur diese Seiten hreflang-Annotationen erhalten. In deinem Beispiel könnten example.de/services/ und example.de/de/services/ über hreflang miteinander verknüpft werden, und example.de/services/best-service/ würde keine hreflang-Anmerkungen erhalten.

      Hinweis: In diesem Szenario kann es nicht schaden, wenn example.de/services/best-service/ eine hreflang-Annotation hat, die auf sich selbst mit dem Wert “de” oder “de-de” verweist, wenn dies deine Implementierung insgesamt einfacher macht. Du musst nur darauf achten, dass sie nicht auf die URL einer englischen Version verweist, die es gar nicht gibt.

      Ich hoffe, das hilft dir erst einmal! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  31. Hallo Eohan,

    Wenn ich den gleichen Inhalt für drei Länder mit Unterverzeichnissen dupliziere, sage ich einfach https:www.exmaple.com/us ; /uk ; /au

    Würde das helfen, wenn ich länderspezifische hreflang und canonical Attribute in und

    Beispiel für unsere Website

    Beispiel für eine britische Website

    Beispiel für Au Site

    Passt den Meta-Tag auch länderspezifisch an. = Beispiel USA | Offizieller Beispiel-Händler
    Und so weiter und so fort für UK und AU.

    Auch die Deklaration von Inhaltsattributen wie

    Würden die oben genannten Attribute beim Crawlen und Indexieren durch Google helfen?

    Das Beste,
    Terry

    Antworten

    2. Lieber Eoghan,

      Was für ein interessanter Beitrag und Kommentar!
      Ich habe einen .com-Webshop in 3 Sprachen (Niederländisch, Deutsch und Französisch). Die deutsche Sprache soll Deutschland und andere Länder mit deutscher Sprache ansprechen (zum Beispiel die Schweiz). Die niederländische Sprache soll sich an Menschen in den Niederlanden und an niederländischsprachige Menschen in Belgien richten. Und so weiter.

      Frage 1:
      Ist es aus SEO-Gründen besser, das Land im hreflang-Tag anzugeben? Zum Beispiel so:
      hreflang=”de-de”
      hreflang=”de-ch”
      hreflang=”nl-nl”
      hreflang=”nl-be”

      Oder würde das schon reichen?
      hreflang=”de”
      hreflang=”nl”

      Der Inhalt der deutschen Seiten ist für Deutschland und die Schweiz derselbe, also denke ich, dass es nicht notwendig ist, verschiedene URLs für verschiedene Länder mit derselben Sprache zu erstellen. Es sei denn, es ist besser für SEO. Die Niederlande sind ein wichtiges Zielland. Macht hreflang=”nl-nl” oder hreflang=”nl” einen Unterschied für die SERP in Google.nl?

      Frage 2:
      Die Homepage (.com) leitet einen Besucher immer auf eine bestimmte Sprachversion .com/nl, .com/fr oder .com/en um. Du kannst die .com-Seite nicht ohne eine 301-Weiterleitung aufrufen. Ist es gut, die .com als X-default zu markieren oder ist die .com/en besser für X-default?

      Vielen Dank für deine Antwort.

      Antworten

      1. Hallo Suzan,

        Vielen Dank für deine Fragen und Entschuldigung für meine verspätete Antwort.

        Wenn du derzeit drei Versionen deines Shops hast, eine auf Niederländisch, eine auf Französisch und eine auf Deutsch, reicht es aus, jeder der Versionen nur einen Sprachwert zuzuweisen:

        hreflang=”de”
        hreflang=”nl”
        hreflang=”fr”

        Das Hinzufügen von Länderwerten würde in diesem Fall keine Vorteile bringen.

        Es ist kein Problem, nur eine Version für Deutschland und die Schweiz zu verwenden. Du kannst die Situation mit Niederländischsprechern in den Niederlanden und Belgien vergleichen: Für bestimmte Unternehmen kann es sinnvoll sein, verschiedene Versionen zu haben, wenn in beiden Ländern ein sehr unterschiedliches Vokabular verwendet wird, um die Produkte zu beschreiben, die das Unternehmen verkauft. In den meisten Fällen wird jedoch die gleiche Inhaltsversion für beide Länder perfekt funktionieren. Wenn du dich dafür entscheidest, für jedes Land eine eigene Version zu erstellen, solltest du das nur tun, wenn du tatsächlich unterschiedliche (lokalisierte) Inhalte in jeder Version verwenden willst.

        hreflang=”nl” schließt bereits alle Benutzer in hreflang=”nl-nl” ein. Es bringt also nichts, den Ländercode hinzuzufügen, wenn du nicht verschiedene Versionen in niederländischer Sprache hast, wie “nl-be” und “nl-nl”.

        Und die Antwort auf deine letzte Frage lautet: Ja, in dem von dir beschriebenen Fall sollte die Stamm-URL (.com) als “x-default” markiert werden.

        Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

        Antworten

  32. Für das Beispiel #3...

    Ich versuche, hreflang-Tags für eine .co.uk-Website zu erstellen, die auf Englisch verfasst ist (sie hat ein US-Pendant). Diese Website kann in insgesamt 25 Länder geliefert werden, aber wir haben keine 25 Übersetzungen der Website für die verschiedenen europäischen Länder.

    Ich glaube, wir brauchen für jedes Land einen Dreiflanken, etwa so:

    en-GB
    en-FR
    usw.

    Wenn ich es so mache, wird meine Website nur in den Suchergebnissen für Benutzer angezeigt, die die https://www.google.fr/ Suchmaschine und ihre Sprache auf Englisch eingestellt haben, richtig? Kann ich auch einen hreflang mit (fr-FR) hinzufügen, um französischsprachige Personen anzusprechen, die sich nur in Frankreich aufhalten? Was ist mit jemandem, der Deutsch spricht und in Frankreich lebt und nach meinem Markenbegriff googelt?

    Wenn ich nur die Sprache hreflang ohne Ortsangabe (fr) verwende und jemand in den USA mit Französisch als bevorzugter Sprache sucht, erhält er die .co.uk-Version, die das (fr) angibt - richtig?

    Letztendlich versuche ich, alle Menschen in einem bestimmten Land anzusprechen, aber natürlich brauche ich ein Sprachattribut und kann nicht einfach ein Länderattribut haben.

    Sehe ich das falsch?

    Antworten

    1. Hallo Wes,

      Vielen Dank für deine interessanten Fragen.

      Zunächst einmal: Wenn du eine .co.uk-Domain hast, macht es keinen Sinn, den Inhalten auf dieser Domain einen anderen hreflang-Ländercode als “GB” zuzuweisen. Google interpretiert Inhalte auf einer .co.uk-Domain automatisch als an Nutzer in Großbritannien gerichtet (siehe hier: https://www.searchviu.com/en/hreflang-implementation-guide/#step3), daher sollten die hreflang-Ländercodes, die du für eine ccTLD verwendest, immer mit dem Land übereinstimmen, dem die ccTLD zugeordnet ist, um konsistente Signale zu senden.

      Ein weiterer wichtiger Aspekt, den du beachten solltest, ist, dass die Sprachcodes, die du den Inhalten zuweist, immer mit der tatsächlichen Sprache des Inhalts übereinstimmen sollten.

      Das heißt, wenn du eine englische Sprachversion auf einer .co.uk-Domain hast, kann sie nur mit “en-GB” gekennzeichnet werden. Du könntest eine französische Sprachversion auf derselben Domain einrichten, aber da du eine .co.uk-Domain verwendest, würde sie so interpretiert werden, dass sie auf Nutzer in Großbritannien abzielt, die auf Französisch suchen, was “fr-GB” im hreflang wäre.

      Wenn du Nutzer/innen in anderen Ländern wirklich richtig ansprechen willst, wäre eine gTLD besser geeignet. Und wenn du Nutzer/innen ansprechen willst, die in anderen Sprachen suchen, brauchst du auch Übersetzungen und nicht nur unterschiedliche hreflang-Sprachwerte.

      Ich hoffe, das hilft für den Moment! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  34. Hey Mann,
    vielen Dank für deinen Beitrag. Ich habe vor 3-4 Wochen hreflang in allen Versionen meiner Website implementiert, aber sie werden immer noch nicht in der Google Search Console angezeigt (ich habe internationales Targeting eingerichtet), was könnte deiner Meinung nach der Grund sein? Die Website ist https://www.subdued.com/ für alle Sprachen ( IT, FR, EN, ES )

    Danke schön 🙂 .
    Giulio

    Antworten

    1. Hallo Giulio,

      Vielen Dank für deine Frage. Ich habe mir deine Website angesehen und festgestellt, dass in deinem Head (also dem HTML-Head deiner Website 😉 ) eine Menge Dinge wie Skripte usw. über den Hreflang-Anmerkungen stehen. Das könnte dazu führen, dass Google den Head schließt und deine hreflang-Anmerkungen ignoriert. Hier ist ein toller Artikel zu genau diesem Thema: https://ohgm.co.uk/breaking-head-quietly/

      Lass mich wissen, ob das hilft!

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

  35. Hallo Eohan,

    Vor kurzem haben wir eine spanische Version ( http://bit.ly/2VsTD9c ) unserer ursprünglich portugiesischsprachigen Website ( http://bit.ly/2Vu9HYe ). Unsere portugiesische Sprachdomain verwendet eine .com.br-Url (95% der Besucher kommen aus Brasilien), und wir haben beschlossen, eine .com-Domain für die spanische Version zu verwenden, da es mehrere Länder gibt, in denen Spanisch die Muttersprache ist. Wir planen nun, hreflang-Tags einzufügen, aber da Spanisch in mehreren Ländern gesprochen wird, haben wir beschlossen, nur das Attribut language für hreflang zu verwenden (nicht das Attribut country). Unser hreflang würde also wie folgt aussehen: , und . Auf diese Weise würde ich gerne wissen, ob es eine gute Strategie ist, eine allgemeine .com-Domain für eine spanischsprachige Domain zu verwenden und ob die Verwendung dieses hreflang-Tags der beste Ansatz ist. Vielen Dank!.

    Antworten

    1. Sorry, hreflang war verschwunden. Hier ist es wieder:

      link rel=”alternate” href=”http://www.my-pt-website.com.br/” hreflang=”pt” ,
      link rel=”alternate” href=”http://www.my-pt-website.com.br/” hreflang=”pt-br” ,
      link rel=”alternate” href=”http://www.my-es-website.com/” hreflang=”es”.

      Antworten

      1. Hallo Hilton,

        Ja, dein geplantes hreflang-Setup hört sich für mich gut an. Es ist wahrscheinlich nicht nötig, die beiden hreflang-Werte “pt” und “pt-br” der portugiesischen Sprachversion zuzuweisen, da “pt” in diesem Fall bereits “pt-br” enthält, aber es kann auch nicht schaden. Es ist eine gute Idee, nur mit einer generischen spanischen Sprachversion zu arbeiten, die sich an alle spanischsprachigen Nutzer/innen weltweit richtet.

        Ich hoffe, das hilft dir. Bitte lass mich wissen, wenn du weitere Fragen hast.

        Antworten

  36. Hallo Eoghan,

    Vielen Dank für diese tolle Erklärung von hreflang! Ich fange gerade mit einer internationalen Website an und wollte meine Einstellungen schnell mit dir abgleichen. In meinem Fall dachte ich daran, URLs automatisch auf eine andere URL umzuleiten, die auf der Browsersprache des Nutzers basiert:

    1
    Website-Version: https://www.site.com
    Sprache: Englisch & Standard
    Länder: Alle Länder
    hreflang-Werte: en, x-default

    2
    Website-Version: https://www.site.com/fr
    Sprache: Französisch
    Länder: Alle Länder
    hreflang-Werte: fr

    3
    Website-Version: https://www.site.com/es
    Sprache: Spanisch
    Länder: Alle Länder
    hreflang-Werte: es

    4
    Website-Version: https://www.site.com/de
    Sprache: Deutsch
    Länder: Alle Länder
    hreflang-Werte: de

    Ich habe mir deine Beispiele angesehen und konnte keinen solchen Fall finden... Was hältst du von einer solchen Konstellation? Gibt es Probleme, auf die ich in Zukunft stoßen könnte?

    Tausend Dank für deinen Rat!

    Das Beste,
    Julian

    Antworten

    1. Hallo Julian,

      Vielen Dank für deine interessante Frage. Wenn du sprach- oder IP-basierte Weiterleitungen verwendest, solltest du sehr vorsichtig sein. Normalerweise ist es in Ordnung, deine Root-URL auf ein Sprachverzeichnis umzuleiten, das auf der Browsersprache oder IP des Nutzers (oder Bots) basiert.

      Ich würde dir allerdings davon abraten, URLs umzuleiten, die bereits zu einem Sprach- oder Länderverzeichnis gehören. Wenn du zum Beispiel eine Weiterleitung https://www.site.com/de auf die englische Version, wenn die Browsersprache Englisch ist (oder wenn die IP aus den USA stammt), würdest du riskieren, dass deine deutsche Version nie indiziert wird - Du solltest davon ausgehen, dass Crawler wie Google deine Inhalte immer mit der gleichen Browsersprache und IP-Location anfordern und dies berücksichtigen.

      Das bedeutet auch, dass es bei einer solchen Einrichtung besser wäre, die englische Version nicht im Stammverzeichnis zu hosten, wie in deinem Beispiel oben, sondern in einem eigenen Sprachverzeichnis (/en/). Auf diese Weise könntest du deine sprachbasierten Weiterleitungen für die Stamm-URL haben, sie aber für alle URLs deaktivieren, die bereits zu einem Sprachverzeichnis gehören.

      Ich hoffe, das hilft für den Moment. Bitte lass mich wissen, wenn du weitere Fragen hast.

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

      1. Toll, Eoghan, das macht es für mich viel klarer! Danke auch dafür, dass du mich davor bewahrt hast, einen großen Indizierungsfehler zu begehen... 🙂 .

        Ich habe 2 Folgefragen:

        1. Wenn die Root-URL auf Basis der Browsersprache umgeleitet wird, wäre es dann möglich, das Sprachverzeichnis /en als Englisch & Standard einzustellen?
        2. Würdest du ein Plugin für WordPress-basierte Websites empfehlen, um hreflang zu implementieren?

        Nochmals vielen Dank für deine Meinung!

        Das Beste,
        Julian

        Antworten

        1. Hallo Julian,

          Es freut mich zu hören, dass meine erste Antwort dir geholfen hat. Hier sind meine Antworten auf deine Folgefragen:

          1. In einem solchen Fall wäre “x-default” für die weiterleitende Root-URL reserviert (siehe Szenario 1 hier: https://www.searchviu.com/en/hreflang-implementation-guide/#step5). Bitte beachte, dass Google, wenn die Stamm-URL in den SERPs auftaucht, für die Erstellung des Snippets normalerweise die Inhalte der URL verwendet, zu der der Googlebot weitergeleitet wird.
          2. Ich habe gute Erfahrungen gemacht mit Polylang. Soweit ich weiß, erlaubt es keine benutzerdefinierten hreflang-Anmerkungen, aber es bekommt sie sofort, wenn die internationale Website-Struktur nicht zu kompliziert ist.

          Wenn ich dir sonst noch mit irgendetwas helfen kann, lass es mich einfach wissen.

          Mit freundlichen Grüßen,

          Eoghan

          Antworten

  37. Hallo Eoghan, danke für den tollen Artikel. Ich glaube, ich habe alles richtig gemacht, aber ich habe immer noch ein seltsames Problem: Bei mehreren Suchanfragen wird zwar die richtige Seite/Locale als Hauptergebnis angezeigt, aber die Sitelinks darunter sind für dieselbe Seite, aber in verschiedenen Locales. Das macht keinen Sinn.

    Ich habe alternative hreflang-Links im Kopfbereich und eine gut strukturierte Sitemap.

    Irgendwelche Ideen? Danke!.

    Antworten

    1. Hallo Pavlos,

      Vielen Dank für deine interessante Frage. Ich habe dieses Problem schon mehrmals auf verschiedenen Websites gesehen. Es kann sein, dass hier verschiedene Dinge vor sich gehen:

      - Es kann eine Weile dauern, bis Google alle hreflang-Kommentare entdeckt und verarbeitet - Wie lange ist es her, dass du hreflang implementiert hast?
      - Bei manchen Seiten kann Google hreflang ignorieren und mehrere Länderversionen zu einer kanonischen machen, wenn der Inhalt der verschiedenen Versionen identisch oder sehr ähnlich ist. Hast du das URL-Inspektionstool im neuen GSC verwendet, um die kanonischen URLs zu überprüfen, die Google für deine verschiedenen Länderversionen verwendet?

      Wenn du magst, kannst du mir die URL der Website, an der du arbeitest, per E-Mail schicken und ich schaue sie mir gerne an.

      Ich hoffe, das hilft!

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

  38. Hallo Eoghan

    Die ausführlichste und aktivste Diskussion, die ich bisher gefunden habe. Hut ab für dein Engagement und deine Hilfe für die Gemeinschaft.

    Ich habe deinen gesamten Beitrag zum Thema Währung durchsucht und es scheint ein Thema zu sein, das nicht gut behandelt wird. Dies ist eher eine Frage der Ordnerstruktur und der Architektur als des Markups. Ich habe eine Situation, in der ich versucht bin, nur einen Sprachordner zu verwenden und auf den Länderordner (in meiner Architektur) zu verzichten, um das Budget für Kriechgänge zu sparen. Das Problem ist jedoch die Währung. Die Seiten sind bis auf die Währung alle identisch!

    Mein Problem (und meine Frage an dich) ist:

    1) Einige Seiten zeigen die Preise (Währung) an und andere nicht.

    Das Problem, das ich habe, ist, dass wenn eine englischsprachige Person in den USA nach einem französischen Ort sucht, die Preise in Euro angegeben werden und ich daher /FR/fr/ und /FR/en/ Versionen haben muss.

    Wenn es keine Währung gäbe, könnte ich einfach eine /fr/-Version haben und sie sowohl Kanadiern als auch Franzosen zeigen (oder eine /en/-Version für Englischsprachige). Füge ein Währungssymbol hinzu und schon habe ich Hunderte von fast doppelten Seiten.

    Ich habe überlegt, ob es möglich ist, die Währung dynamisch anzuzeigen? Also eine generische /FR/ Seite mit der Option, die Währung in USD oder Euro anzuzeigen. Das Gleiche würde zum Beispiel für Hongkong gelten, wo ich die Seite /en/ mit HKD anzeigen möchte? Oder muss ich einfach /HK/en/ und /HK/zh/ erstellen?

    Alternativ denke ich, dass es am einfachsten ist, meine Ordnerstruktur nach Sprachen zu ordnen und wenn ich eine Lokalisierung habe, diese in einen Länderordner zu legen. Ich hätte also Folgendes:

    /fr/ in Euro x-default (oder keine Währung, Lokalisierung generisch für alle)
    /fr/CA/ in kanadischen Dollars

    /en/ in USD x-default (oder keine Währungslokalisierung, generisch)
    /de/GB in GBP
    /de/CA/ in kanadischen Dollars
    /de/AU/ in australischen Dollars
    /en/ZA/in Südafrikanische Rands

    Das hat den Vorteil, dass nicht jede Seite eine Währung enthält. So kann ich unnötiges Crawling verhindern, indem ich eine Seite in einer Standardsprache ohne spezifisches Land einstelle.

    Wie du siehst, bin ich hin- und hergerissen zwischen dem Führen mit der Sprache und dem Führen nach Ländern.

    Kennst du eine ähnliche Situation und hast du einen Rat?

    Vielen Dank!
    Tom

    Antworten

    1. Hallo Tom,

      Vielen Dank für deine interessante Frage.

      Ja, du kannst die Währung dynamisch auf der Grundlage von IP-Adressen anzeigen, aber das hätte den Nachteil, dass Google immer USD “sehen” und diese Währung in den SERP-Snippets anzeigen würde. Außerdem könntest du keine strukturierten Daten mit verschiedenen Währungen einbinden, wenn du nur eine URL hast, die die Währung dynamisch anzeigt.

      Du hast über zwei Optionen nachgedacht - die Strukturierung deiner Website nur nach Sprachen oder nach Land + Sprache - aber es gibt noch eine dritte Möglichkeit, die du in Betracht ziehen solltest: Sprache + Währung.

      Schau dir die URL-Struktur und die hreflang-Anmerkungen auf https://digitalmarketinginstitute.com/ - Sie haben ein Verzeichnis pro Währung erstellt und dann mehrere hreflang-Länderwerte zu jeder Währungsversion hinzugefügt (das Hinzufügen mehrerer hreflang-Werte ist OK - siehe hier: https://www.searchviu.com/en/multiple-hreflang-tags-one-url/).

      Eine Struktur wie diese würde auch für dich funktionieren. Einige Empfehlungen:

      - Erstelle nicht für jede Währung der Welt ein Währungsverzeichnis - konzentriere dich auf die wichtigsten Währungen. Deine englische Standardversion (mit der Währung USD) kann immer noch eine Währung dynamisch auf Basis der IP des Nutzers anzeigen (und USD für Googlebot und in strukturierten Daten), damit deine Website alle Währungen abdeckt. Erstelle zusätzliche Währungsverzeichnisse nur für die wichtigsten Währungen und kennzeichne jedes dieser Verzeichnisse mit den entsprechenden Ländern über hreflang.
      - Mit deinen hreflang-Anmerkungen kannst du dich auch auf die wichtigsten Märkte konzentrieren. Sieh dir noch einmal das DMI-Beispiel oben an - sie haben nicht ALLE europäischen Länder zur Euro-Version hinzugefügt, sondern nur die wichtigsten Zielmärkte.

      Ich hoffe, das hilft für den Moment. Bitte lass es mich wissen, wenn du denkst, dass dies eine Lösung für deinen Fall sein könnte. Und wenn du weitere Fragen hast, zögere nicht, sie zu stellen.

      Mit freundlichen Grüßen,

      Eoghan

      Antworten

  39. Hallo Eoghan,

    Was ist mit einer englischen Website, die in CA, UK, AU & UK sichtbar sein soll? Musst du in diesem Fall auch hreflang verwenden?

    1
    Website-Version: https://www.site.com
    Sprache: Englisch
    Länder: CA
    hreflang-Werte: en-ca,

    2
    Website-Version: https://www.site.com
    Sprache: Englisch
    Länder: US
    hreflang-Werte: en-us,

    3
    Website-Version: https://www.site.com
    Sprache: Englisch
    Länder: AU
    hreflang-Werte: en-au,

    3
    Website-Version: https://www.site.com
    Sprache: Englisch
    Länder: UK
    hreflang values: en-uk,

    Dementsprechend:

    Antworten

    1. Hallo Andrzej,

      Vielen Dank für deinen Kommentar. Unsere Website hat die Hälfte deines Kommentars verschluckt (wahrscheinlich Code-Beispiele). Das tut uns leid!

      Gibt es auf deiner Website verschiedene Versionen für die verschiedenen Länder? Nach deinen Beispielen sieht es nicht so aus. Ich würde auch nicht empfehlen, verschiedene Versionen zu erstellen, wenn der Inhalt nicht unterschiedlich ist.

      Wenn du nur eine globale englische Version deiner Website hast, ist es nicht sinnvoll, hreflang zu implementieren.

      Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  40. Hallo Eoghan,

    Danke für den tollen Leitfaden. Ich bin gerade in einer Situation, in der ich mehrere ccTLDs für verschiedene Regionen habe und mir von einer dritten Partei geraten wurde, auf Unterordner für diese Regionen umzusteigen und unsere .co.uk zu nutzen, um von der darauf aufgebauten Autorität zu profitieren.

    Natürlich wird empfohlen, hreflang-Tags in Übereinstimmung mit dem oben Gesagten zu implementieren, aber ich habe bei Tests in einer dieser Regionen mit Bing einige interessante Ergebnisse erzielt. Bei einer kürzlichen Suche nach einem Produkt standen wir mit unserer ccTLD ganz oben in den SERPs, und zwar vor einem unserer Mitbewerber, der eine gTLD und Unterordner für dieselbe Region eingerichtet hat.

    Könnten wir in diesem Fall einfach hreflang mit unseren aktuellen ccTLDs implementieren?

    Nach dem, was du oben gesagt hast, sollten wir es vermeiden, mit unserer .co.uk auf Unterordner umzusteigen, da man im GSC keine anderen Regionen für Unterordner unter einer ccTLD anvisieren kann. Ich bin dabei, eine Liste mit ähnlichen Ratschlägen zu erstellen und frage mich, ob du neben deinem Leitfaden noch andere Links/Seiten kennst, auf die ich mich beziehen kann, um unsere Entscheidung zu erleichtern?

    Antworten

    1. Hallo Stuart,

      Vielen Dank für deine interessanten Fragen.

      Du hast Recht, es ist keine gute Idee, mehrere Länder mit einer ccTLD anzusprechen (wenn du es vermeiden kannst). Eine gTLD ist die bessere Lösung, wenn du mehrere Länderversionen unter einer Domain zusammenfassen willst.

      Ja, du kannst hreflang einfach für deine bestehenden ccTLDs einführen. Es könnte sich aber lohnen, zu einer gTLD zu wechseln. Hier ist ein Artikel, der sich mit diesem Thema befasst: https://www.searchviu.com/en/cctlds-to-gtld/ (dieser Artikel verlinkt auch auf einige andere großartige Ressourcen)

      Hier ist ein weiterer sehr guter und ausführlicher Artikel, der davon abrät, eine ccTLD für mehrere Länderversionen zu verwenden (im Teil “Auswahl der besten Domainstruktur”): https://www.onely.com/blog/ultimate-guide-to-international-seo/

      Ich hoffe, das hilft dir erst einmal! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  41. Hallo Eoghan,

    Ich liebe deine Artikel.

    Wir haben derzeit separate Websites auf Subdomains für einige Länder, die wir anvisieren:
    http://www.example.com - Englisch, USA und Rest der Welt
    au.example.com - Englisch, Australien
    gb.example.com - Englisch, UK

    Die Websites sind identisch, mit Ausnahme der Preisseite, die für jedes Land einen anderen Inhalt hat. Die Websites haben auch kleinere Code-Unterschiede, wie z. B. dass alle internen Links auf der AU-Site auf au.example.com-Seiten verweisen, dass AU-Seiten auf sich selbst kanonisiert werden (die au.example.com-Version der URL) und so weiter für die anderen Sites. Aber ansonsten ist der Inhalt aller Seiten mit Ausnahme der Preisseite für alle Standorte gleich.

    Um die Dinge zu vereinfachen (da 99% der Seiten auf allen Sites gleich sind), lassen wir die Subdomains weg und wechseln zu nur einer Site auf http://www.example.com. Wir müssen immer noch separate Preisinformationen für jedes Land anzeigen, also erstellen wir separate Preisseiten, die alle unter http://www.example.com. Hier ist mein Plan:

    /pricing - zeigt die US-Preise an (diese Preise werden auch für den Rest der Welt außer Großbritannien und Australien angezeigt)
    /pricing/gb - zeigt die britischen Preise an
    /pricing/au - zeigt die Preise in Australien an
    /pricing/us - zeigt den gleichen Inhalt wie /pricing - mehr Informationen zu dieser Seite weiter unten

    Besucher in den USA sehen die US-Preise auf /pricing. Besucher in Großbritannien, die /pricing besuchen, werden automatisch (302?) zu /pricing/gb umgeleitet, und Besucher in Australien werden auf ähnliche Weise von /pricing zu /pricing/au umgeleitet.

    Außerdem wird es unten auf der Preisseite eine Länderauswahl geben, mit der du manuell auf die Preisseite für ein beliebiges Land wechseln kannst, unabhängig davon, in welchem Land du dich befindest. Hier kommt /pricing/us ins Spiel... wenn jemand in Australien in diesem Menü US auswählt, wird er zu /pricing/us weitergeleitet (da /pricing ihn zurück zu /pricing/au führen würde).

    Jede Preisseite wird auf sich selbst kanonisiert, mit Ausnahme von /pricing/us, das auf /pricing kanonisiert wird.

    Die Seiten /pricing und /pricing/gb und /pricing/au werden alle diese hreflang-Tags haben:
    x-default - /Preisgestaltung
    de - /Preise
    en-US - /Preise
    de-GB - /Preise/gb
    en-AU - /Preise/au

    /pricing/us wird keine hreflang-Tags haben (da es zu /pricing kanonisiert wird).

    Alle internen Links zur Preisseite von einer beliebigen Seite auf der Website werden auf /pricing verweisen.

    Alle anderen Seiten der Website (Homepage, "Über uns"-Seite usw.) werden KEINE hreflang-Tags haben.

    Ich möchte sicherstellen, dass Google weiß, dass wir auf die USA, Großbritannien und Australien ausgerichtet sind. Es ist mir egal, ob Google uns für Besucher in anderen Ländern anzeigt. Ist der obige Plan ausreichend, um dieses Ziel zu erreichen?

    Vielen Dank im Voraus.

    -Jon

    Antworten

    1. Hallo Jon,

      Vielen Dank, dass du deinen Plan so detailliert beschrieben hast. Es klingt für mich nach einem sehr soliden Plan und ich habe ehrlich gesagt nichts zu kritisieren oder hinzuzufügen. Nur eine Kleinigkeit, aber es gibt keinen Grund, ihn zu ändern: Die Kennzeichnung der /pricing mit “en-US” zusätzlich zu “en” und “x-default” wird wahrscheinlich keinen Unterschied machen, da “en-US” bereits in “en” enthalten ist, aber es kann sicher nicht schaden, es beizubehalten.

      Ich bin gespannt, ob das bei dir auch so funktioniert! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

    2. Hallo Eroghan

      Vielen Dank, dass du das überprüft hast!

      Was die deutsche Version angeht. Ja, wir hatten mal eine deutsche Titelseite und wollen in etwa 3 Monaten wieder ein paar deutsche Inhalte haben.
      Ich denke, ich kann es bis dahin deaktivieren - denn die deutsche Startseite ist im Moment nur ein Entwurf.

      Hmm... es stimmt, dass wir nur die Startseite, einige Landingpages und einige Blogbeiträge auch ins Dänische übersetzt haben.

      Diejenigen, für die es keine Übersetzung gibt, habe ich im Dropdown-Menü der Polylang-Sprache im Backend des Beitrags einfach als Englisch markiert.
      Aber da es keine dänische Version davon gibt, könnte das der Grund dafür sein, dass die hrflang-Anmerkung nicht auf diesen Beiträgen zu finden ist?

      Ich weiß nicht, wie ich eine Anmerkung für diese Seiten einfügen kann - denn sie kamen automatisch auf den anderen, die eine dänisch übersetzte Version haben - und
      wir können nicht alle unsere Blogbeiträge ins Dänische übersetzen. Weißt du, was du tun kannst :)?

      Vielen Dank!.

      Antworten

      1. Hallo Signe,

        Polylang scheint automatisch hreflang-Anmerkungen in alle Seiten einzufügen, auch in solche, die keine Version in einer anderen Sprache haben. In diesem Fall wird die Seite einfach mit einem hreflang-Vermerk versehen, der auf sie selbst verweist. Das schadet wahrscheinlich nicht und hat auch keine positiven Auswirkungen, aber ich würde trotzdem empfehlen, darauf zu achten, dass diese Anmerkungen den richtigen hreflang-Wert haben.

        Hier ist ein Beispiel für eine Seite, die derzeit noch den Wert “en-GB” in einer selbstreferenzierenden hreflang-Anmerkung hat: https://www.hedia.co/blog/my-internship-experience-hedia/. Du kannst dies wahrscheinlich beheben, indem du den Polylang-Sprachcode einfach in “en” änderst.

        Antworten

        1. Hallo Eroghan

          Danke für deine Antwort!

          Leider weiß ich immer noch nicht so recht, was ich tun soll...

          Ich kann in Polylang keine Option sehen, mit der ich die hreflang-Anmerkung der einzelnen Seiten ändern kann...

          Wenn ich jetzt auf Polylang und Spracheinstellungen gehe, kann ich nur die allgemeinen Einstellungen für die englische Sprache ändern. Im Moment steht dort “country standard”: en_GB und language code: en , flag: united kingdom für alle unsere englischen Seiten. Meinst du, dass ich den Länderstandard für alle englischen Seiten in Polylang einfach auf “en” anstelle von en_GB ändern sollte?

          Nochmals vielen Dank für deine Hilfe.

          Alles Gute, Signe

          Antworten

          1. Hallo Signe,

            Ich glaube, jetzt ist alles in Ordnung. Ich habe die Seiten noch einmal überprüft und konnte auf den englischsprachigen Seiten keine selbstreferenzierenden hreflang-Anmerkungen finden. Sie wurden also entweder entfernt oder waren von vornherein nicht vorhanden (vielleicht habe ich einen Link mit einem hreflang-Attribut - es gibt einige auf deinen Seiten, aber sie sollten keinen Einfluss darauf haben, wie Google deine Website interpretiert - mit einer hreflang-Anmerkung verwechselt, als ich das letzte Mal nachgesehen habe).

            Wie sieht dein hreflang-Bericht in der Google Search Console aus?

  42. Hallo Eoghan

    Ich habe deinen ganzen Beitrag gelesen (der übrigens wirklich toll ist), aber ich bin immer noch ein bisschen verwirrt, was ich tun soll... Ich hoffe wirklich, dass du das für mich aufklären kannst :)!

    Ich habe eine Website mit /co , die im Moment englische Inhalte hat.

    Ich bin dabei, dänische Übersetzungen der Startseite und der wichtigsten Landing Pages hinzuzufügen, damit wir mit der Zeit bei Google für unsere wichtigsten dänischen Keywords sichtbar sind und nicht nur für englische Keywords.

    Im Moment ist die Website nur auf Englisch (und einige alte dänische Blogbeiträge, die vor meinem Einsatz geschrieben wurden, sind irrelevant).

    Unser Zielpublikum wird in Zukunft Großbritannien, Dänemark und die USA sein. Oh, und unser “Produkt” ist eine App, das Produkt ist also nicht ortsgebunden.

    Wir verwenden das Polylang-Plugin, aber der Sprachwechsler ist derzeit nicht aktiviert, weil der alte dänische Inhalt nicht priorisiert wurde. Das war allerdings vor meiner Zeit. Jetzt möchte ich das Plugin wieder verwenden und auch den Sprachwechsler aktivieren, um mehr dänische Inhalte auf die Website zu bringen.

    Aber jetzt habe ich so viele Zweifel an zwei Dingen:

    1) Wenn ich dänische Inhalte einfüge und die Sprachumschaltung im Polylang-Plugin aktiviere, erhalten dann alle aktuellen englischen Inhalte automatisch “/en/” in der URL? Wenn ich im Backend der Live-Startseite bin, heißt sie einfach hedia.co, aber im Polylang-Dropdown-Feld im Beitrag oben rechts ist “Englisch” angekreuzt. Das Gleiche gilt für die englischen Landingpages wie diese: https://www.hedia.co/carb-calculator-and-diabetes/

    2. Wenn die Polylang-Sprachumschaltung aktiviert ist und der englische Inhalt nicht in URLs mit /en/ geändert wird, muss ich dann alle aktuellen Landingpages und Blogbeiträge, die auf Englisch verfasst sind, von hedia.co/landingpage/ auf hedia.co/en/landingpage und hedia.co/us/landingpage ändern? Oder ist es aus SEO-Sicht völlig in Ordnung, wenn die Informationen auf der Seite dieselben sind und nur der englische Inhalt für alle englischsprachigen Länder (hauptsächlich USA und UK) unter hedia.co/landingpage/ zu finden ist?

    3. Im Moment ist der Standard in Polylang auf Englisch eingestellt, Code: en, Länderstandard: en_GB - bedeutet das, dass alle Landing Pages eine größere Chance haben, in Großbritannien zu ranken, und eine viel geringere Chance, in den USA zu ranken?

    Vielen Dank für deine Zeit, ich weiß das wirklich zu schätzen!

    Antworten

    1. Hallo Signe,

      Vielen Dank für deine interessanten Fragen. Wir verwenden Polylang auch auf dieser Website und sind bisher sehr zufrieden damit.

      Hier sind meine Antworten auf deine Fragen:

      1) Ich bin mir nicht sicher, ob Polylang automatisch ein Länder-/Sprachenverzeichnis in alle URLs einfügt oder ob du es selbst auswählen kannst, sobald du es aktiviert hast. Hast du eine Testseite, auf der du das ausprobieren kannst? Ich würde empfehlen, die aktuellen URLs für die englische Version beizubehalten, wenn möglich, und nur für die dänische Version ein Sprachverzeichnis zu verwenden (das beantwortet auch deine zweite Frage). Wenn Polylang die URLs automatisch ändert, solltest du sicherstellen, dass alle alten englischen URLs (die ohne das Sprachverzeichnis) korrekt auf ihre neuen englischen Entsprechungen umgeleitet werden.

      2) Es spielt keine Rolle, ob die URL ein Sprachverzeichnis hat oder nicht, und es ist immer besser, alte URLs beizubehalten, als sie zu ändern (siehe oben).

      3) Das Feld für hreflang in Polylang ist “Sprachcode”. Wenn du hier “en” für die englische Version deiner Website einträgst, fügt Polylang automatisch hreflang-Anmerkungen mit dem hreflang-Wert “en” ein. Dies signalisiert, dass dein englischer Inhalt für englischsprachige Nutzer auf der ganzen Welt bestimmt ist. Das Feld “Locale”, das in deinem Fall derzeit auf “en_GB” eingestellt ist, sollte keine Auswirkungen auf die SEO haben.

      Ich hoffe, das hilft dir erst einmal! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

      1. Hallo Eoghan

        Vielen Dank, dass du das für mich geklärt hast!!!

        1. Okay. Nein, ich kann es nicht wirklich testen, aber wenn es sich automatisch ändert, muss ich es einfach
        leitet dann schnell von /en/ auf die alte URL ohne das /en/ um.

        2. Ok, perfekt!

        3. Ok, super.

        Ich habe ein paar Folgefragen (sorryyyy :D)

        4. Ist es richtig, dass ich das hreflang-Tag immer noch in den HTML-Header jeder Landing Page (und der beiden Startseiten) einfügen muss (auch wenn die englischen Seiten vielleicht kein /en/ in den URLS haben)?

        Oder sollte ich das nicht tun?

        5. Wenn ich als Standardsprache Englisch mit dem Stern in Polylang eingestellt habe, sollte ich dann auch irgendwo anders ein Standard-Tag einfügen oder reicht das aus?

        6. Ich möchte die Einstellung “Browsersprache finden” in Polylang deaktivieren - denn ich möchte, dass der englische Inhalt immer die Standardeinstellung ist. So können die Dänen auf die dänischen Inhalte zugreifen, indem sie auf die dänische Flagge auf der Website klicken - oder über die Suchergebnisse (wenn wir mit dem Ranking beginnen). Ich bin mir bewusst, dass dies Google signalisiert, dass die dänischen Inhalte nicht priorisiert sind, und das ist in Ordnung. Unser Branding in englischer Sprache ist wichtiger. Meine Frage ist jedoch, ob du andere schlechte Erfahrungen mit der Deaktivierung dieser Einstellung gemacht hast, abgesehen von weniger guten Rankings der Sprache, die sich vom Englischen unterscheidet? / Ist es in Ordnung, dies zu tun?

        7. Letzte Frage! Ist es richtig, dass ich, wenn der dänische Inhalt live ist, eine zusätzliche Domain in der Google Suchkonsole für hedia.co/da/ erstellen soll?

        Ich danke dir wirklich sehr für deine Hilfe. Es ist so toll, mit diesen Herausforderungen nicht allein zu sein 😀 Lass mich wissen, ob ich dir irgendwo eine Bewertung oder etwas anderes geben kann, um meine Wertschätzung zu zeigen.

        Ich wünsche dir alles Gute.

        Antworten

        1. Hallo Signe,

          Ich freue mich sehr, dass dir meine ersten Antworten schon geholfen haben. Hier sind meine Antworten auf deine neuen Fragen:

          4. Polylang fügt hreflang automatisch ein. Du musst also nur die hreflang-Anmerkungen überprüfen, sobald du die dänischen Inhalte aktiviert hast, um sicherzustellen, dass alles korrekt ist. Nach meiner Erfahrung mit Polylang sollte es keine Probleme geben.

          5. Ich glaube, Polylang fügt eine “x-default”-Hreflang-Anmerkung für deine Root-URL ein, wenn du Benutzer auf der Grundlage ihrer Browsersprache umleitest. Du brauchst “x-default” nicht wirklich, wenn du das nicht tust.

          6. Das sollte überhaupt keine Probleme verursachen. Ich denke, es ist eine gute UX, die Nutzer entscheiden zu lassen. Und Google wird diese Einstellung so oder so nicht bemerken, so dass sie keine Auswirkungen auf deine SEO-Performance haben wird.

          7. Es ist sinnvoll, eine GSC-Eigenschaft für dein dänisches Verzeichnis zu erstellen, wenn du dieses Verzeichnis leicht separat analysieren möchtest. Das ist aber nicht unbedingt notwendig und hat keine Auswirkungen auf deine SEO-Leistung. In deinem Fall brauchst du in dieser Eigenschaft keine Einstellungen, die sich von den Einstellungen in der Eigenschaft für die gesamte Domain unterscheiden.

          Bitte lass mich wissen, wie das bei dir läuft. Ich würde gerne wissen, ob Polylang all dies wie erwartet handhabt oder ob es in deinem speziellen Fall Probleme gibt. Wenn du möchtest, kann ich deine hreflang-Anmerkungen auch schnell überprüfen, sobald sie live sind.

          Mit freundlichen Grüßen,

          Eoghan

          Antworten

          1. Hallo Eoghan

            Vielen Dank für eure freundlichen Antworten!

            Hast du ein tolles Tool, mit dem ich testen kann, ob die hreflang-Anmerkungen in Ordnung sind?

            Es wäre wirklich toll, wenn du einen Blick darauf werfen könntest, ob die hreflang-Anmerkungen in Ordnung sind? Ich habe den Prozess jetzt abgeschlossen: https://www.hedia.co/

            Das Plugin hatte eine URL-Modifier-Einstellung, bei der ich auswählen konnte, dass sich die URLS für die englische Sprache nicht ändern sollten, also taten sie es auch nicht :)!

          2. Hallo Signe,

            Das sind tolle Neuigkeiten, vor allem, dass Polylang dir erlaubt hat, die alten URLs für die englische Version beizubehalten.

            Ich habe deine hreflang-Anmerkungen überprüft und ein paar Dinge festgestellt:

            - Auf der Homepage gibt es eine hreflang-Anmerkung, die auf eine deutsche Website-Version verweist. Hast du eine Idee, warum Polylang das einfügt? Kannst du ihn deaktivieren, bis es tatsächlich eine deutsche Version gibt?
            - Die Seiten, die nur auf Englisch existieren (z.B. der Blog), haben jetzt hreflang-Anmerkungen mit dem Wert “en-GB”. Hier ist es wahrscheinlich notwendig, den Sprachcode für alle englischen Seiten in “en” zu ändern, nicht nur für die Seiten, die auch auf Dänisch existieren.

            Um deine hreflang-Anmerkungen zu überprüfen, empfehle ich dir, den internationalen Targeting-Bericht in der alten Google Search Console zu verwenden: https://www.google.com/webmasters/tools/i18n?siteUrl=https%3A%2F%2Fwww.hedia.co%2F&hl=en_GB. Es kann sein, dass du ein paar Wochen warten musst, bis Google alle deine hreflang-Anmerkungen verarbeitet hat.

            Es gibt auch einige großartige externe Tools, um hreflang-Annotationen zu überprüfen, wie dieser von Merkle, Aber normalerweise ziehe ich es vor, sie entweder manuell zu überprüfen (bei kleinen Websites) oder einen Crawl mit Screaming Frog durchzuführen und alle hreflang-Annotationen von dort zu exportieren, um sie zu überprüfen.

            Ich hoffe, das hilft für den Moment. Bitte lass mich wissen, wenn du weitere Fragen hast.

  43. Hallo, das ist ein toller Blog, danke, dass du diese Informationen teilst.
    Meine Frage: Wir haben vor kurzem mit der Internationalisierung unserer Website begonnen, indem wir [ hreflang ] verwenden. Ich verwende den Canonical-Tag auf allen Seiten.

    Antworten

  44. Hallo Eoghan,

    Toller Artikel, vielen Dank!

    Meine Situation:
    Ich habe eine Top-Level-Domain (.net) gewählt, um auf dem deutschsprachigen Markt (DE, AT, CH) zu starten.
    Wir gehen davon aus, dass der Inhalt für alle 3 Länder gleich oder fast gleich ist.

    1) Soll ich nur die Top-Level-Domain ohne Unterordner für jedes Land verwenden?
    2) Soll ich den hreflang de-de, de-at und de-ch zu dieser Domain hinzufügen?

    3) Würden Unterordner oder länderspezifische Domains mir einen SEO-Vorteil verschaffen?
    4) Ich bin immer noch flexibel, was die ganze Einrichtung angeht. Wie würdest du das Projekt für die besten SEO-Ergebnisse einrichten?

    Mit freundlichen Grüßen,
    Steffen

    Antworten

    1. Hallo Steffen,

      Vielen Dank für deine Fragen. Wenn du keine unterschiedlichen Inhalte für DE, AT und CH brauchst, ist es nicht nötig, verschiedene Website-Versionen in Unterordnern zu erstellen. Eine Version für alle drei Länder wäre in diesem Fall ideal.

      Wenn du nur eine Website-Version hast, brauchst du auch keine hreflang-Anmerkungen.

      Unterordner nur um der Unterordner willen werden dir keinen SEO-Vorteil verschaffen. Du solltest nur dann unterschiedliche Versionen für DE, AT und CH erstellen, wenn du wirklich einen guten Grund dafür hast (z.B. unterschiedliche Preise, Währungen, Versandkosten, rechtliche Informationen usw.). Aber selbst dann könntest du Probleme bekommen, wenn der Inhalt der drei Versionen zu ähnlich ist.

      Ich hoffe, das hilft dir! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  45. Ausgezeichneter Artikel, der mir geholfen hat, Ordnung in das Thema hreflang zu bringen.
    Ich habe eine Frage. Gibt es ein WordPress-Plugin, das bei der Umsetzung von Beispiel 3 (eine globale Website mit einer Version für Europa, einer für die USA und Kanada und einer für Asien/Pazifik, alle in englischer Sprache) helfen kann?

    Oder eine andere Methode als die GTM-Referenz?

    Egal, ob es sich um einen Header-Abschnitt, eine XML-Datei oder eine “HTTP-Header”-Implementierung handelt. Wie kann ich denselben URLs wie in Beispiel 3 verschiedene Länder zuweisen?
    Vielen Dank!

    Antworten

    1. Hallo Jimena, vielen Dank für deinen Kommentar. Leider kenne ich kein WordPress-Plugin, das diese Option bietet. Normalerweise empfehle ich Polylang für mehrsprachige WordPress-Websites wegen seiner großartigen Reflang-Funktion, aber ich weiß nicht, ob es diese Art der erweiterten Reflang-Implementierung kann.

      Antworten

  46. Hallo Eoghan,

    Fantastischer Artikel, vielen Dank, dass du das so klar aufgeschlüsselt hast.

    Ich frage mich, ob du vielleicht Schritt 5, Szenario 1 anhand von Beispiel 1 durchgehen könntest, da dieses Beispiel meiner Website am nächsten kommt? Wir haben unsere Hauptseite .com, die auf Großbritannien ausgerichtet ist, sowie .com/pl für Polen und .com/row für den Rest der Welt. Die polnische Seite ist die einzige, die nicht in englischer Sprache verfasst ist.

    Ich frage mich auch, ob du einen Artikel über Sitemaps und den Sitemap-Index für mehrere Versionen von Websites (wie meine) hast? Das ist ein weiterer Bereich, in dem ich die Ratschläge von Google verwirrend finde. Mir gefällt, dass du in deinem Artikel mehrere Beispiele anführst.

    Danke!,
    Kirsty

    Antworten

    1. Hallo Kirsty,

      Vielen Dank für deine Fragen. Es freut mich zu hören, dass du den Artikel nützlich fandest.

      In Schritt 5 geht es darum festzustellen, ob du hreflang=”x-default” brauchst. Leitet deine Website Nutzer/innen auf der Grundlage ihrer IP oder Browsersprache um? Wenn nicht, brauchst du hreflang=”x-default” wahrscheinlich nicht, aber du könntest es optional zu deiner .com/row-Version hinzufügen, die wahrscheinlich schon hreflang=”en” hat und dann hreflang=”en” *und* hreflang=”x-default” haben würde. Aber, wie gesagt, das ist optional und macht keinen großen Unterschied. Wenn deine Website die Nutzer/innen nicht aufgrund ihrer IP oder Browsersprache umleitet und du keine reine Länder-/Sprachenauswahl-Startseite hast, musst du wahrscheinlich keine Ressourcen für die Implementierung von hreflang=”x-default” verschwenden.

      Ich kenne keinen Leitfaden für Sitemaps/Sitemap-Indizes für internationale Websites (gute Idee!), aber ich kann diesen allgemeinen Sitemap-Leitfaden von Michelle Race empfehlen: https://www.ricemedia.co.uk/blog/sitemap-optimisation-guide/

      Ich hoffe, das hilft dir erst einmal! Bitte lass mich wissen, wenn du weitere Fragen hast.

      Antworten

  47. Hallo
    Ich hatte Zweifel an der Umsetzung des GSC.
    Ich habe eine bestehende Website in englischer Sprache (UK), die als solche in GSC mit den Urls: example.com
    Ich habe nicht vor, eine französische Version zu starten, die example.com/fr heißen wird.
    In deinen Beispielen sind sowohl das englische /en als auch das französische /fr getrennt, aber in meinem Fall, da ich keinen Unterordner /en habe (und ihn vermeiden möchte, um eine Neuindizierung der Seiten zu vermeiden), ist /fr tatsächlich in example.com/ im GSC enthalten.
    Was wäre hier die beste GSC-Umsetzung?

    Antworten

  48. Hallo,

    Ich möchte dir für diesen Artikel danken. Ich habe noch eine Frage:
    Sollte ich für eine einzelne Version der Website den hreflang-Tag verwenden? Da Google das HTML-Attribut lang ignoriert.

    Vielen Dank!.

    Antworten

  49. Hallo Eoghan, ein sehr interessantes Thema und ich würde es wirklich gerne nutzen, aber...
    Meine Seite ist in HTML und Bootstrap, kein WordPress, kein CMS, kein Shop,
    Mein Szenario ist Beispiel 2: Eine internationale Website mit englischen und italienischen Sprachversionen. Im Moment ist die Website wie folgt strukturiert: eine Indexseite mit einem Skript, das je nach Browsersprache auf index_en oder index_it umleitet. Ich möchte die Indexseite mit dem Skript loswerden und den hreflang auf index_en oder index_it verwenden, aber ich bin mir nicht sicher, wie ich es machen soll.
    Ich bin verwirrt oder muss ich die Indexseite behalten, das Skript löschen und den hreflang in die Verzeichnisse en und it einfügen...sorry, ich glaube, ich bringe es durcheinander, aber ich finde es nicht heraus!

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert