hreflang-Fehler.
Die häufigsten Fehler in hreflang-Aufbauten sind fehlende Gegenseitigkeit, das Nicht-Angeben der eigenen Seite, falsche Codes und der Konflikt mit der kanonischen Adresse.
hreflang ist eine Schicht, die richtig aufgebaut lautlos funktioniert und falsch aufgebaut lautlos nicht funktioniert. Es gibt keine Fehlermeldung, die Seite wirkt normal, und nur in den Suchergebnissen beginnt die falsche Sprachversion zu erscheinen — ein Symptom, dessen Bemerken Wochen dauert.
Ein hreflang-Aufbau kann deshalb nicht einmal gemacht und liegen gelassen werden; er braucht Prüfung und vorzugsweise die Bindung an einen Test. Die folgenden Fehler sind die auf realen Websites häufigsten.
Fehlende Gegenseitigkeit
Der verbreitetste Fehler. Seite A gibt B an, aber B gibt A nicht an. Die Suchmaschine zählt die Angabe in diesem Fall als ungültig und verhält sich, als existierte der Satz gar nicht.
Die Ursache ist meist die teilweise Aktualisierung: Beim Hinzufügen einer neuen Sprache wird vergessen, den Hauptsprachseiten die neuen Verknüpfungen hinzuzufügen. Oder beim Löschen einer Seite werden die Verknüpfungen in den anderen Sprachen nicht bereinigt.
Die dauerhafte Lösung ist, die Angaben nicht von Hand zu schreiben: Werden die Verknüpfungen aus einer einzigen Quelle erzeugt, ist die Gegenseitigkeit strukturell garantiert. Auf dieser Website leistet das der Generator, und die Suite verifiziert es zusätzlich.
Die eigene Seite nicht angeben
Der zweithäufigste Fehler und der überraschendste. Jede Seite muss zusammen mit den anderen Versionen des Satzes auch die EIGENE Sprache angeben. Auf einer dreisprachigen Website muss jede Seite drei Verknüpfungen tragen — sich selbst eingeschlossen.
Weil es der Intuition widerspricht, wird es oft übersprungen: „Diese Seite ist doch schon Türkisch, warum soll ich zusätzlich sagen, dass sie Türkisch ist?“ Die Antwort: Der Satz ist als Liste definiert — eine unvollständige Liste ist eine ungültige Liste.
Konflikt mit der kanonischen Adresse
Dieser Fehler ist heimtückischer, weil zwei getrennte Auszeichnungen miteinander sprechen. Sagt eine Seite per hreflang „ich bin die deutsche Version“, aber ihre kanonische Adresse zeigt auf die türkische Seite, widersprechen sich die zwei Signale.
Das Ergebnis ist meist, dass die deutsche Seite nie in den Index gelangt: Weil die Canonical-Angabe „die eigentliche Seite ist jene“ sagt, zählt die Maschine die deutsche Version als Kopie und verwirft sie. Alles, was hreflang gesagt hat, geht ins Leere.
Die Regel ist klar: Jede Sprachversion muss das Canonical auf SICH SELBST geben. Übersetzungen sind keine Kopien voneinander, sondern eigene Seiten. Auf dieser Website gibt jede erzeugte Seite das Canonical auf sich selbst, und das wurde messend verifiziert — keine einzige Seite weicht ab.
Jede Sprachversion gibt das Canonical auf sich selbst; Übersetzungen sind keine Kopien voneinander.
Falsche und erfundene Codes
Sprach- und Regionscodes werden Standardlisten entnommen und lassen sich nicht raten. Die häufigen Fehler sind bekannt.
- Den Regionscode allein verwenden — ein Sprachcode ist immer nötig.
- Falscher Ländercode — die Codes mancher Länder sind nicht intuitiv; in der Liste nachschlagen.
- Ein erfundener Sprachcode — ein nicht im Standard stehender Code macht den ganzen Satz ungültig.
- Groß-klein-Verwirrung — der Lesbarkeit halber wird die Sprache klein, die Region groß geschrieben.
- Einen Unterstrich verwenden — der Trenner ist der Bindestrich; der Unterstrich ist das Format eines anderen Standards.
Das Problem des lautlosen Brechens
Was diese Fehler teilen, ist ihre Unsichtbarkeit. Die Seite öffnet, wirkt richtig, der Nutzer hat kein Problem — und nur die Suchmaschine zeigt die falsche Sprachversion. Das Symptom zu bemerken dauert Wochen, und ist es bemerkt, wird die Ursachensuche schwerer.
Eine zweite Schwierigkeit: Der Fehler kann partiell sein — ein Teil des Satzes richtig, ein Teil kaputt. Ohne eine websiteweite Prüfung bleibt diese Unterscheidung unsichtbar — auf eine einzelne Seite zu schauen und „funktioniert“ zu urteilen ist irreführend.
- Websiteweit scannen — die Prüfung einer einzelnen Seite genügt nicht.
- Die Verknüpfungen an einen Generator binden — ein von Hand geschriebener Satz bricht bei der ersten Ergänzung.
- Die Canonicals gesondert prüfen — ein mit hreflang kollidierendes Canonical ist der heimtückischste Fehler.
- Den Search-Console-Bericht regelmäßig lesen — die einzigen realen Daten von der Live-Website.
- An einen Test binden — sichtbar im Moment des Deployments, nicht Wochen später.
Der fünfte Punkt wird auf dieser Website angewandt: Die Prüfsuite misst bei jedem Lauf, dass der Satz vollständig und wechselseitig ist, jede Seite das Canonical auf sich selbst gibt und die Codes standardkonform sind. Wird eine Seite ergänzt und eine Verknüpfung vergessen, zeigt sich der Mangel im Moment des Deployments.
Und ein Rahmen: Bricht diese Schicht, geht nicht Sichtbarkeit verloren, sondern es entsteht FALSCHE Sichtbarkeit. Einem auf Deutsch suchenden Nutzer wird die türkische Seite gezeigt — die Seite ist im Index, im Ranking, aber bei der falschen Person. Das ist ein Zustand, der weniger auffällt und mehr schadet als gar nicht zu erscheinen.
Noch ein Fehler: fehlende Seiten
Ein weiterer Fehler gehört auf die Liste, und auf großen Websites ist er der häufigste: Eine im Satz angegebene Seite existiert in Wirklichkeit nicht. Die türkische Seite gibt ihr deutsches Gegenstück an, aber diese Adresse liefert einen 404.
Die Ursache ist meist die schablonenhafte Erzeugung: Die Verknüpfungen werden unter der Annahme „jede Seite hat in jeder Sprache ein Gegenstück“ erzeugt, und diese Annahme kollabiert, sobald eine Seite unübersetzt ist. Der Satz gilt als ungültig, und die Suchmaschine ignoriert die gesamte Angabe.
Das richtige Verhalten ist, nur die WIRKLICH existierenden Versionen anzugeben. Existiert eine Seite in zwei Sprachen, werden zwei Verknüpfungen geschrieben, nicht drei. Der Satz muss vollständig sein, aber jedes angegebene Mitglied muss auch real sein.
Auf dieser Website wird die Regel vom Code geschützt: Hat eine Sprache keinen Inhalt, wird für diese Sprache keine Seite erzeugt UND sie tritt nicht in den hreflang-Satz ein. Beide Verhalten kommen aus derselben Quelle und können deshalb nicht auseinanderlaufen.
Eine Prioritätsordnung zum Schluss: Wird gefragt, welcher dieser Fehler zuerst zu beheben ist, lautet die Antwort der Canonical-Konflikt. Denn dieser Fehler bricht nicht nur die Zuordnung, sondern auch die Indexierung — die Seite erscheint gar nicht in den Suchergebnissen. Die anderen zeigen die falsche Version; dieser zeigt keine.
Ein Vorschlag zur Prüfgewohnheit: Führen Sie die hreflang-Kontrolle JEDES Mal durch, wenn eine neue Sprache oder eine neue Seite hinzukommt. Diese zwei Ereignisse sind die Momente, in denen fast alle Fehler entstehen — weil die Verknüpfungen der bestehenden Seiten aktualisiert werden müssen und dieser Schritt der am häufigsten vergessene ist.
Und eine Protokollregel: Welche Sprachen im Satz sind, muss irgendwo schriftlich stehen. Fügt jemand im Team eine neue Sprache hinzu, muss er wissen, welche Seiten zu aktualisieren sind, und dieses Wissen darf in niemandes Gedächtnis leben.
Und ein letzter Rahmen: Keiner dieser Fehler verlangt Intelligenz — alle sind Aufmerksamkeitsfehler, und alle wiederholen sich. Deshalb ist die Lösung auch nicht Aufmerksamkeit, sondern Automatisierung: Die Verknüpfungen sollen aus einer Quelle erzeugt werden, die Gegenseitigkeit soll strukturell sein, und ein Test soll bei jedem Deployment verifizieren.