Sehen Sie den Baukasten selbst
Eine Website, bis zu acht Sprachen, mit hreflang und Self-Canonicals, die automatisch für jede Seite erzeugt werden.
„Warum zeigt Google meine englische Seite jemandem, der auf Französisch sucht?“ ist fast immer ein hreflang-Problem – und fast immer ein kleines, stilles. Hreflang ist eine einfache Idee, die still versagt: Machen Sie es leicht falsch, gibt es keinen Fehler, keine Warnung, Suchmaschinen hören einfach auf, es zu beachten. Hier steht, was es tut, die Handvoll Arten, wie es kaputtgeht, und wie Sie Ihres von Hand prüfen.

-Tags (im der Seite oder gleichwertig in einer XML-Sitemap), eines je Sprach- bzw. Regionsvariante, die alle aufeinander verweisen.Hreflang-Fehler haben eines gemeinsam: Keiner von ihnen löst irgendwo eine Fehlermeldung aus. Die Seite lädt weiterhin. Die Tags sind weiterhin vorhanden. Sie sind nur auf eine Weise falsch, die ausschließlich einer Suchmaschine — oder einer sorgfältigen manuellen Prüfung — auffällt.
Nicht reziproke Tags Wenn Seite A eine Alternative deklariert, die auf Seite B verweist, Seite B aber keine deklariert, die auf A zurückverweist, ist das Paar defekt — und das dokumentierte Verhalten der großen Suchmaschinen besteht darin, nicht reziproken Auszeichnungen zu misstrauen oder sie zu ignorieren, statt sie teilweise zu berücksichtigen. Das ist der in der Praxis mit Abstand häufigste Hreflang-Fehler, denn es ist leicht, eine neue Sprachseite hinzuzufügen und dabei zu vergessen, den Tag-Satz jeder anderen Sprache so zu aktualisieren, dass er auf sie verweist.
Tags, die auf eine nicht kanonische, weiterleitende oder 404-URL verweisen Eine Alternative muss auf die tatsächliche, aktive, kanonische Fassung der Seite in dieser Sprache verweisen — nicht auf eine alte URL, die inzwischen weiterleitet, und nicht auf eine URL, die eine Anmeldung verlangt oder einem Crawler einen Fehler zurückgibt.
Teilweise Abdeckung innerhalb eines Clusters Hreflang, das auf einigen Seiten eines übersetzten Bereichs korrekt gesetzt ist, auf anderen aber fehlt, erzeugt ein widersprüchliches Signal über den gesamten Cluster hinweg, was das Vertrauen in die Tags untergräbt, die korrekt sind.
Doppelte oder widersprüchliche Tags aus mehreren Quellen Auf Websites, auf denen mehr als ein Stück Code Head-Tags einfügen kann — etwa ein Skript auf Seitenebene und ein seitenweites Layout — kann ein Wettlauf zwischen beiden doppelte oder widersprüchliche Hreflang-Tags im finalen Markup hinterlassen. Das ist eine reale, subtile Fehlerklasse gerade deshalb, weil sie bei einer schnellen Sichtprüfung der gerenderten Seite unsichtbar bleibt; sie zeigt sich erst beim sorgfältigen Lesen des tatsächlichen -Quelltexts.
Hreflang ohne passenden Sitemap-Eintrag Suchmaschinen nutzen die Sitemap als Signal für die Crawl-Priorität; eine URL, die als Sprachalternative deklariert ist, aber nie in der Sitemap auftaucht, wird schlicht später oder seltener gecrawlt als die Seiten, die Sie tatsächlich ranken lassen wollen.
-Tag. Bei zwei oder drei Sprachpaaren bestätigen Sie, dass jedes zurückverweist: Erklärt /page ein hreflang="es", das auf /es/page zeigt, öffnen Sie /es/page und bestätigen Sie, dass dort ein Tag zurück auf /page zeigt. Bestätigen Sie dann, dass genau ein x-default existiert und auf eine funktionierende Seite verweist, und dass jede URL im Set direkt lädt — keine Weiterleitung, kein 404 — und mit der eigenen Canonical dieser Seite übereinstimmt. Auf einer kleinen Website erwischt dieser manuelle Durchgang die Mehrheit der Fehler aus der Praxis.Jede Sprachversion einer Seite führt jede andere Sprachversion – einschließlich sich selbst – als Alternative auf, sodass das Set vollständig wechselseitig ist und keine einseitige Vermutung.
x-default, immer auflösbarGenau eine Alternative ist mit x-default markiert, und sie zeigt auf eine echte, funktionierende Seite – typischerweise die Version in Ihrer Standardsprache.
Das Canonical-Tag jeder Sprachversion verweist auf sich selbst und nicht auf die Version in der Standardsprache — eine Seite sollte sich nicht zugleich als Alternative und als kanonisches Duplikat einer anderen URL ausgeben.
Auf jeder Website jenseits einer Handvoll Seiten ist das händische Schreiben wechselseitiger Tag-Sätze für jedes Sprachpaar genau die Art von Aufgabe, die still und leise auseinanderläuft. Den Satz aus einer einzigen Quelle der Wahrheit zu erzeugen (der deklarierten Sprachliste der Seite) hält die Tags jeder Seite schon konstruktionsbedingt konsistent.

Die hreflang- und x-default-Alternativen einer Olmira-Website werden aus einer einzigen Quelle generiert — der deklarierten Sprachliste der Seite —, sobald zwei oder mehr Sprachen aktiv sind. Reziprozität ist ein Nebenprodukt davon, wie die Tags gebaut werden, nicht etwas, das pro Seite verfasst wird, und die Tags werden einmal, zentral, für jede Route ausgegeben — genau um den oben beschriebenen Fehlermodus mit doppelten, gegeneinander laufenden Tags zu vermeiden.
x-default löst immer zur eigenen, nicht präfixierten Standardsprach-URL der Website auf, und jede Sprachversion trägt ihre eigene selbstreferenzierende Canonical. Welche Sprachen Sie führen und wie vollständig jede davon vor dem Livegang sein soll, bleibt Ihre Entscheidung — dazu der Leitfaden zur mehrsprachigen Struktur; die Tag-Mechanik wird auf jeder Seite des Website-Baukastens gleich gehandhabt.
Eine Website, bis zu acht Sprachen, mit hreflang und Self-Canonicals, die automatisch für jede Seite erzeugt werden.
URL-Muster, was passieren sollte, wenn eine Übersetzung fehlt, und was zuerst übersetzt werden sollte.
Welche Inhalte sich mit einer leichten Prüfung sicher maschinell übersetzen lassen, und welche jedes Mal einen Menschen brauchen.