Sie sind in sieben Sprachen online – die Suchmaschine sieht eine Website

Die Geschichte einer in sieben Sprachen übersetzten Agentur-Website verläuft fast immer gleich. Auf Deutsch läuft das Geschäft, auf Englisch mit Mühe, in den übrigen fünf Sprachen praktisch gar nicht. Zuerst gerät der Inhalt in Verdacht: Übersetzungen werden überarbeitet, ein paar Beiträge kommen dazu, eine Textagentur wird gebrieft. Die Zahlen bewegen sich nicht. Denn das Problem liegt meist nicht im Text, den Sie geschrieben haben, sondern darin, über wie viele verschiedene Adressen dieser Text ausgeliefert wird, mit welchem Statuscode und unter welcher Sprachauszeichnung.

Dieser Beitrag macht aus den Befunden eines durchgängigen technischen Audits auf der Website eines siebensprachigen Reisesoftware-Anbieters einen Arbeitsleitfaden. Alle Zahlen stammen entweder aus diesem Audit oder aus externen Studien mit benannter Quelle; keine davon ist geschätzt. Das Audit umfasste 1.088 Live-Seiten, 1.469 Sitemap-Adressen und alle sieben Sprachen. Das Bild, das dabei entstand: Bei 85 % der Seiten fehlte die kanonische Adresse vollständig, die gesamte Website war über zwei verschiedene Hosts doppelt erreichbar, und die in sechs Sprachen deklarierten Übersetzungen lieferten in Wahrheit die Meldung "Seite nicht gefunden".

Jeder der folgenden Abschnitte liefert eine Prüfung, einen Schwellenwert oder eine Entscheidungsregel, die Sie mit Browser und curl auf Ihrer eigenen Website anwenden können, ohne Software zu kaufen. Auch die Reihenfolge zählt: Ohne technische Aufräumarbeit wirkt keine Inhaltstiefe, und ohne Inhaltstiefe wirkt keine KI-Sichtbarkeit.

Die Reihenfolge des Audits: zuerst eine einzige Quelle der Wahrheit (kanonische Adresse, gegenseitiges hreflang, ehrlicher Statuscode), dann der Inhalt, ganz zuletzt die KI-Sichtbarkeit.

1. Erst zählen: über wie viele Adressen ist dieselbe Seite erreichbar?

Beginnen Sie das Audit nicht mit dem Inhalt, sondern mit dem Zählen von Adressen. Zu messen, über wie viele verschiedene URLs eine Seite aufrufbar ist, dauert zehn Minuten und legt in der Regel schon im ersten Durchgang den größten Verlust offen.

Auf der geprüften Website gab es zwei grundlegende Fehler. Erstens lieferte die Domain mit und ohne www jeweils 200, die gesamte Website war also doppelt erreichbar. Zweitens waren alte und neue Pfadnamen nebeneinander offen geblieben, sodass /de/portfolio und /de/referenzen denselben Inhalt auslieferten; allein dieses Muster erzeugte rund 1.713 Schattenadressen.

Rufen Sie auf Ihrer eigenen Website nacheinander diese fünf Varianten auf und notieren Sie den zurückgegebenen Statuscode:

Variante	Beispiel	Erwartetes Ergebnis
Host ohne www	beispiel.de/de/blog	301 → Variante mit www
Host mit www	www.beispiel.de/de/blog	200
Abschließender Schrägstrich	www.beispiel.de/de/blog/	301 → Variante ohne Schrägstrich
Tracking-Parameter	www.beispiel.de/de/blog?utm=x	200 + Canonical ohne Parameter
Alter Pfadname	www.beispiel.de/de/artikel	301 → neuer Pfad

Auf der Kommandozeile genügt eine Zeile:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -I <adresse>

Liefern zwei oder mehr der fünf Varianten 200, dann sieht die Suchmaschine nicht eine Seite von Ihnen, sondern mehrere fast identische Seiten. Das ist keine Frage einer Abstrafung, sondern eine Frage der Signalteilung. Eingehende Links, Klickdaten und Crawl-Budget, die auf einer Adresse landen sollten, verteilen sich auf mehrere.

Liefern alle fünf Varianten 200, teilt sich das Signal auf fünf Adressen auf. Die Lösung hat eine Reihenfolge: Alte Pfade laufen per 301 zusammen, der Rest wird über ein selbstreferenzierendes Canonical-Tag gebündelt.

Entscheidungsregel

Definieren Sie pro Seite genau eine kanonische Form und legen Sie drei Dinge darauf fest: den Host (mit oder ohne www – eines von beiden), die Regel für den abschließenden Schrägstrich (immer oder nie) und die Groß-/Kleinschreibung. Solange diese drei Entscheidungen nicht schriftlich festgehalten sind, erfindet jede neue Seitenvorlage ihre eigene Variante.

2. Canonical ist ein Signal, keine Anweisung

Das war die auffälligste Zahl im Audit: Von den 1.088 Seiten mit Statuscode 200 hatten 921 (85 %) überhaupt kein Canonical-Tag. Von den 167 Seiten mit Tag waren 60 nicht selbstreferenzierend – die Seite wurde über www.beispiel.de/de ausgeliefert, während im Canonical https://beispiel.de/de/ stand. Weder Host noch Schrägstrich stimmten überein.

An dieser Stelle sind zwei technische Fakten wichtig. Googles eigene Dokumentation beschreibt rel="canonical" nicht als Anweisung, sondern als "starkes Signal dafür, dass die angegebene URL die kanonische sein sollte"; die endgültige Entscheidung trifft die Suchmaschine. Dieselbe Dokumentation ordnet die Methoden der Kanonisierung von stark nach schwach: Weiterleitung > Canonical-Tag > Eintrag in der Sitemap. Die Sitemap wird ausdrücklich als schwaches Signal geführt.

Die praktische Folge: Ein Canonical-Tag ist für sich genommen kein Aufräumwerkzeug. Wenn Sie eine alte Adresse stilllegen wollen, leiten Sie sie weiter; das Canonical bleibt den Varianten vorbehalten, die sich nicht weiterleiten lassen – parametrisierte Fassungen, Filterkombinationen, sitzungsbehaftete URLs.

Der zweite Fakt: Google empfiehlt, dass die kanonische Seite ein selbstreferenzierendes Canonical trägt. Die verbreitete Annahme, "Canonical schreibt man nur auf Duplikate", ist also falsch – auch die Hauptseite soll auf sich selbst zeigen.

Warum handgeschriebene Canonicals zwangsläufig kaputtgehen

Auf der geprüften Website war das Canonical in zehn verschiedenen Seitenvorlagen von Hand eingetragen: einmal mit Schrägstrich, einmal ohne www, einmal mit einem Pfadbestandteil, den es nicht mehr gab. In vierzehn weiteren Vorlagen fehlte es ganz. Das ist keine Unachtsamkeit, sondern ein strukturelles Ergebnis: Wenn jede Person, die eine neue Vorlage schreibt, die Regel neu erinnern muss, wird die Regel früher oder später vergessen.

Die praktikable Regel: Canonical, hreflang und og:url werden nicht in den Seitenvorlagen erzeugt, sondern an einer einzigen gemeinsamen Stelle – und pro Seite genau einmal ausgegeben. Versucht eine Seite, ihr eigenes Canonical zu schreiben, muss der Veröffentlichungsprozess das verhindern. In der nach dem Audit aufgebauten Struktur wurde diese Regel an eine Build-Prüfung gekoppelt: garantiert durch Architektur, nicht durch Disziplin.

3. hreflang: der Preis für eine Sprache, die es gar nicht gibt

Hier machen mehrsprachige Websites ihren teuersten Fehler. Auf der geprüften Website deklarierte ein deutscher Blogbeitrag eine Adresse als englisches Pendant. Diese Adresse lieferte HTTP 200 – im Textkörper stand aber "Blog Post Not Found". Dasselbe Muster wiederholte sich in sechs Sprachen. Die Website meldete der Suchmaschine also eigenhändig Hunderte leerer Seiten.

Googles Dokumentation zu lokalisierten Versionen ist an dieser Stelle eindeutig: "Wenn Seite X auf Seite Y verweist, muss Seite Y zurück auf X verweisen. Trifft das nicht auf alle Seiten zu, die hreflang verwenden, können diese Auszeichnungen ignoriert oder nicht korrekt interpretiert werden." Dieselbe Dokumentation formuliert es noch schärfer: "Zeigen zwei Seiten nicht aufeinander, werden die Tags ignoriert."

Daraus folgen drei Regeln:

Situation	Richtiges Verhalten	Falsches Verhalten
Übersetzung vorhanden und veröffentlicht	hreflang gegenseitig setzen	Nur in eine Richtung deklarieren
Keine Übersetzung	Gar kein hreflang setzen	Denselben Slug auch für diese Sprache setzen
Übersetzung als Entwurf vorhanden	Bis zur Veröffentlichung nichts setzen	"Kommt ja bald" deklarieren

Links: eine einseitig deklarierte Sprache verweist auf eine Adresse, die zwar 200 liefert, aber keinen Inhalt hat. Rechts: Nur Sprachen mit echter Übersetzung werden gegenseitig deklariert, die dritte Sprachzeile wird gar nicht erst geschrieben.

Zwei weitere Fehler aus Googles eigener Aufzählung verdienen Aufmerksamkeit: Sprachcodes außerhalb von ISO 639-1 und inoffizielle Regionswerte wie EU, UK oder UN. Der Regionscode muss ISO 3166-1 Alpha 2 sein, und eine Region allein ist nicht gültig – man schreibt nicht hreflang="DE", sondern hreflang="de" oder hreflang="de-DE".

x-default definiert eine Ausweichadresse für Nutzer, deren Sprache sich nicht auflösen lässt. Auf einer mehrsprachigen Agentur-Website ist die sinnvollste Wahl die Startseite der Sprache, in der international verkauft wird – meist Englisch – oder, falls vorhanden, ein Sprachauswahlbildschirm.

4. Soft 404: "nicht gefunden" schreiben und 200 liefern

Ein Soft 404 ist nach Googles Definition eine Seite, deren Inhalt eine Fehlermeldung oder ein leeres Ergebnis ist, während der Server einen 2xx-Erfolgscode zurückgibt. Es ist der am schwersten zu bemerkende Fehler, weil kein Monitoring-Werkzeug Alarm schlägt: Die Seite "funktioniert", und Menschen rufen diese Adresse ohnehin nicht auf.

Auf der geprüften Website lieferten fehlende Inhalte 200 plus "nicht gefunden". Als wir das auf ehrliche 404 umgestellt haben, wurden drei bis dahin völlig verborgene Fehler auf einen Schlag sichtbar:

Sichtbar gewordener Fehler	Betroffene Adressen
Prozentkodierte Pfade wurden nie dekodiert	23
Kategorieseiten in der Sitemap ohne echtes Pendant	33
Datenbank-Slugs stimmten nicht mit der Produktdefinition überein	10

Das dramatischste Ergebnis: Die arabischen Produktseiten hatten seit ihrer Veröffentlichung für keinen einzigen echten Client funktioniert. Als rohes UTF-8 angefragt lieferten sie 200, in der prozentkodierten Form, die ein Browser tatsächlich sendet, lieferten sie 404. Weil es ein Soft 404 war, hatte es niemand bemerkt; das Team ging davon aus, die arabischen Seiten seien online.

Entscheidungsregel

Scheuen Sie den Umstieg auf ehrliche 404 nicht. Ihre Fehlerzahl steigt kurzfristig – das ist keine Verschlechterung, sondern der Moment, in dem Ihre Messung ehrlich wird. Für Adressen, die dauerhaft nicht zurückkehren, ist 410 noch klarer; welche Adresse nicht zurückkehrt, ist allerdings eine inhaltliche Entscheidung, die zuerst getroffen werden muss.

5. Nicht-lateinische Schriften in URLs: die Prozentkodierungsfalle

Pfade mit arabischen, kyrillischen oder türkischen Zeichen werden vom Browser vor dem Senden prozentkodiert. Googles Dokumentation zur URL-Struktur empfiehlt das ausdrücklich: "Zeichen außerhalb des ASCII-Bereichs sollten prozentkodiert werden." Dieselbe Dokumentation unterstützt es auch, Wörter in der Sprache der Zielgruppe – und bei Bedarf deren Transliteration – in der Adresse zu verwenden.

Das Problem: Wenn die Serverseite diese Kodierung nicht auflöst, stirbt eine ganze Sprache lautlos. Für Ihre eigene Prüfung rufen Sie dieselbe Adresse in zwei Formen ab:

• Rohform: /ar/blog/<arabischer-slug>
• Prozentkodierte Form: /ar/blog/%D8%A8...

Liefern beide nicht denselben Statuscode, haben Sie einen Fehler. Die Zahl der zu testenden Sprachen ist klein, die Auswirkung betrifft einen gesamten Markt.

Eine praktikable Vorgabe: Wählen Sie für Sprachen mit nicht-lateinischer Schrift bewusst eine von drei Optionen und wenden Sie sie in allen Sprachen konsistent an – (a) die eigene Schrift der Zielsprache, sofern nachgewiesen ist, dass die Prozentkodierung durchgängig funktioniert; (b) Transliteration (für Russisch etwa budushcheye-...); oder (c) englischer Slug mit Sprachpräfix. Keine der drei Optionen ist falsch. Falsch ist, sich von Sprache zu Sprache unterschiedlich zu verhalten.

Google empfiehlt außerdem den Bindestrich statt des Unterstrichs als Worttrenner: "Wir empfehlen, in Ihren URLs Bindestriche (-) statt Unterstriche (_) zu verwenden." Begründung: Der Unterstrich wird in der Programmierung üblicherweise verwendet, um Begriffe zu verbinden statt zu trennen.

6. Eine Sitemap ist keine Liste, sondern eine Zusage

Mit jeder Adresse, die Sie in die Sitemap aufnehmen, sagen Sie: "Das ist eine echte Seite, die es wert ist, indexiert zu werden." Die geprüfte Website deklarierte 1.469 Adressen; nach der Bereinigung waren es 1.386. Aussortiert wurde:

• 28 Adressen lieferten kein HTML, sondern Rohdaten (JSON) – ein Endpunkt einer Anwendungsschnittstelle war wie eine Seite deklariert worden.
• 21 Adressen ließen sich überhaupt nicht rendern.
• 33 Adressen waren Kategorieseiten ohne Pendant; ihre Textkörper umfassten 21 bis 25 Wörter und gaben alle dieselbe "konnte nicht geladen werden"-Vorlage aus.

Zusätzlich wurden alle 1.469 Adressen mit dem falschen Host (ohne www) veröffentlicht; die Sitemap deklarierte also eine Liste, die der eigenen kanonischen Entscheidung der Website widersprach.

Der zweite stille Fehler steckte im Feld lastmod: Es erzeugte bei jeder Anfrage den Wert "heute". Damit wird das Feld vollständig bedeutungslos. lastmod muss aus dem echten letzten Änderungsdatum des Inhalts gespeist werden; sonst hört der Crawler auf, dieses Signal überhaupt zu berücksichtigen.

Sitemap-Prüfliste

1. Ist der Host in der Sitemap zeichengenau derselbe wie der kanonische Host der Website?
2. Ziehen Sie zehn zufällige Adressen – liefern alle 200 und Content-Type: text/html?
3. Ist die Regel für den abschließenden Schrägstrich auch in der Sitemap angewendet?
4. Unterscheiden sich die lastmod-Werte voneinander, oder tragen alle denselben Tag?
5. Bleiben Sprachen ohne Übersetzung vollständig aus der Sitemap heraus?
6. Sind mit noindex ausgezeichnete Seiten aus der Sitemap entfernt?

7. Der stille robots.txt-Fehler: die Gruppenregel

Das war einer der billigsten und zugleich teuersten Fehler im Audit: In der Datei stand eine Disallow-Zeile, korrekt geschrieben, die für den Googlebot völlig wirkungslos war, weil sie in der falschen Gruppe stand.

Der Grund ist die mit RFC 9309 standardisierte Gruppenlogik. Der Standard besagt: Ein Crawler sucht die Gruppe, die zu seinem Product Token passt, und befolgt die Regeln dieser Gruppe. Die Wildcard-Gruppe * greift nur, wenn keine passende Gruppe existiert. Stellen Sie sich folgende Datei vor:

Gruppe	Regeln darin
User-agent: Googlebot	Disallow: /suche
User-agent: *	Disallow: /suche und Disallow: /warenkorb

In dieser Datei darf der Googlebot /warenkorb crawlen, denn in seiner eigenen Gruppe steht diese Zeile nicht, und eine Zusammenführung mit der Wildcard-Gruppe findet nicht statt. Die Regel ist einfach: Soll eine Regel gelten, wiederholen Sie sie in jeder User-agent-Gruppe einzeln.

Statt die Prüfung von Hand vorzunehmen, kopieren Sie Ihre Datei in den robots.txt-Bericht der Search Console und testen Sie den Zielpfad. Die erste Zeile, bei der Ergebnis und Erwartung auseinandergehen, ist mit hoher Wahrscheinlichkeit dieser Gruppierungsfehler.

8. CDN-Cache: die Sprache eines Besuchers wird allen ausgeliefert

Das war das seltsamste Verhalten, das im Audit zutage trat. Die Wurzeladresse erzeugte eine 302-Weiterleitung, die sich nach der Browsersprache des Besuchers richtete. Die Zwischenschicht hielt diese Antwort eine Stunde lang im Cache, ohne einen Vary-Header zu senden. Das Ergebnis: In dieser Stunde wurde die Sprache der Person, die als Erste auf die Website kam, allen nachfolgenden Besuchern ausgeliefert. Ein Firmenkunde, der mit deutschem Browser kam, landete auf der türkischen Seite, und niemand konnte erklären, warum.

Genau dafür ist der Vary-Header da: Er sagt dem Cache, von welchen Anfrage-Headern die gespeicherte Antwort abhängt. In der Formulierung von MDN sorgt Vary dafür, "dass Antworten anhand der im Vary-Feld aufgeführten Header getrennt zwischengespeichert werden." Fehlt der Header, hält der Cache alle Anfragen an dieselbe Adresse für identisch und liefert dieselbe Antwort – unabhängig von Sprache, Cookie oder Gerät.

Die Antwort hängt von der Sprache ab, der Cache-Schlüssel besteht aber nur aus der Adresse. Eine Stunde lang wird die Sprache des ersten Besuchers zur Sprache aller.

Wählen Sie eine von zwei Lösungen:

A – Antwort auftrennen. Ergänzen Sie jede sprachabhängige Antwort um Vary: Accept-Language. Der Cache legt dann pro Sprache einen eigenen Eintrag an. Der Preis: Die Trefferquote des Caches sinkt.

B – Antwort festschreiben (bevorzugt). Die Wurzeladresse führt eine einzige dauerhafte Weiterleitung ohne Sprachprüfung aus (etwa / → 301 → /de), die Sprachwahl wird innerhalb der Seite aufgelöst. So bleibt der Cache effizient und die Suchmaschine sieht ein einziges, konsistentes Verhalten.

Zweite Regel: nicht messen, bevor der Cache geleert ist

Ein CDN kann HTML-Antworten bis zu vierundzwanzig Stunden vorhalten. Messen Sie eine Korrektur unmittelbar nach der Veröffentlichung, messen Sie den alten Stand und kommen zum Schluss, "es hat nichts gebracht". Die richtige Reihenfolge nach dem Deployment lautet: veröffentlichen → Cache der betroffenen Pfade leeren → messen. Weil dieser Schritt übersprungen wurde, haben wir mehr als einmal erlebt, dass eine korrekt funktionierende Korrektur zurückgenommen wurde.

9. Weiterleitungsketten und nicht-kanonische Ziele

Vor dem Audit verhielt sich die Wurzeladresse so: / → 302 → /de/ → 308 → /de. Drei Stationen. Jede Station bedeutet zusätzliche Latenz für den Browser und Signalverlust für die Suchmaschine; hinzu kommt, dass der erste Schritt als 302 (temporär) aussagt, das Ziel sei nicht das dauerhafte Kanonische. Reduziert wurde das auf einen einzigen Schritt: / → 301 → /de.

Der zweite Befund war heimtückischer. Die Website hatte eine Weiterleitungstabelle, die alte Adressen auf neue führte, und 329 Ziele in dieser Tabelle waren selbst nicht kanonisch – sobald die Regeln griffen, hätte also jedes davon eine zweite Weiterleitung erzeugt. Der Fehler wurde vor dem Livegang der Kanonisierung entdeckt; wäre er es nicht, wären am Tag der Veröffentlichung 329 neue Ketten entstanden.

Entscheidungsregel

Bevor Sie eine Zeile in Ihre Weiterleitungstabelle eintragen, prüfen Sie das Ziel gegen die kanonische Form: richtiger Host, richtige Schrägstrich-Regel, eine Seite, die tatsächlich 200 liefert. Diese Prüfung sollte verpflichtender Schritt jeder Arbeit an der Tabelle sein; sie im Nachhinein Zeile für Zeile zu bereinigen, kostet ein Vielfaches.

10. Seiten, die auf der eigenen Website verloren gehen

Dass eine Seite in der Sitemap steht, macht sie noch nicht auffindbar. Das Audit förderte zwei getrennte Verlustposten zutage.

49 indexierbare verwaiste Adressen. In der Sitemap deklarierte Seiten, die auf der Website keinen einzigen Link erhalten: eine Hilfecenter-Seite (7 Sprachen), fünf Integrations-Kategorieseiten (35 Adressen) und 7 Adressen, bei denen Listen und Code auseinandergelaufen waren. Für einen Teil davon war sogar eine Funktion zur Adresserzeugung geschrieben und in die Menükomponente eingebunden worden – aufgerufen wurde sie nie.

70 kaputte interne Links. Vier Kategoriekarten auf der Hilfeseite zeigten auf einen Pfad, den es nicht gab (4 Karten × 7 Sprachen = 28 Links). Die Breadcrumb-Navigation der Leistungs-Detailseiten verwies auf eine nie gebaute Leistungsübersicht (2 Positionen × 3 Leistungen × 7 Sprachen = 42 Links) – und dieselbe kaputte Adresse floss auch in die strukturierten Daten ein.

Der dritte Befund ist feiner: 21 von 33 Blogbeiträgen lagen auf Klicktiefe 3, und ihr einziger Zugang war ein mit noindex ausgezeichneter Paginierungsschritt. Weil die Links verfolgbar waren, wurden sie technisch gecrawlt – einen echten, indexierbaren internen Link zu den Beiträgen gab es aber nicht.

Messmethode

Legen Sie die Adressliste Ihrer Sitemap auf die eine Seite und den internen Linkgraphen Ihrer Website (die Summe aller <a href> auf allen Seiten) auf die andere und bilden Sie die Differenz. Was in der Sitemap steht, aber nicht im Graphen, ist verwaist; was im Graphen steht, aber kein 200 liefert, ist ein kaputter Link. Diese beiden Mengen einmal im Monat zu erzeugen, macht einen Verlust sichtbar, den die meisten Websites nie bemerken.

11. Dünne Inhalte und Seiten, die nur für übersetzt gehalten werden

In der Messung nach dem Audit lag der Website-Durchschnitt bei 472 Wörtern, mit 176 Seiten unter 300 Wörtern. Der eigentliche Befund war aber nicht die Rohzahl, sondern die Art, sie zu lesen.

Erste Korrektur: den Seitenrahmen abziehen. Zählt man den Seitentext, wie er ist, fließen Kopfbereich, Navigation und Fußzeile in den Inhalt ein. Auf der gemessenen Website machte dieser feste Rahmen 117 bis 233 Wörter pro Sprache aus. Rohe 300 Wörter entsprachen also einem Textkörper von etwa 120 Wörtern. Setzen Sie Ihren echten Schwellenwert auf den rahmenbereinigten Text, nicht auf die Rohzahl.

Zweite Korrektur: die Sprachmorphologie normalisieren. Nach Rohzahlen sahen die deutschen Übersetzungen unvollständig aus (Median 393 gegenüber 610 im Spanischen). Der Inhalt war tatsächlich identisch; der gesamte Unterschied stammte aus der Wortbildung. Flugbuchungssoftware ist im Deutschen ein Wort, im Spanischen sind es für denselben Ausdruck fünf. Über acht vollständig übersetzte Seiten gemessen ergaben sich diese Koeffizienten:

Sprache	Koeffizient (en = 1,00)
Deutsch	0,827
Aserbaidschanisch	0,916
Türkisch	0,929
Russisch	0,939
Arabisch	0,963
Spanisch	1,165

Mit dieser Korrektur zeigte sich, dass es im Deutschen und Spanischen keine Übersetzungslücke gab und die echte Lücke sich im Arabischen (22 Adressen) und Englischen (16 Adressen) sammelte.

Dritter Befund: Eine Zusammenfassung ist keine Übersetzung. Viele der arabischen Fassungen waren keine vollständigen Übersetzungen, sondern gekürzte Wiedergaben des englischen Textes – 38 bis 48 % des Median-Umfangs ihrer Gruppe. Auf dem Papier galten sie als "übersetzt", in der Praxis konkurrierten sie bei keiner einzigen Suchanfrage.

Vierter Befund: 7 Gruppen mit 67 Adressen hatten zeichengleiche Textkörper. Die meisten davon waren Sprachversionen, die freigeschaltet wurden, ohne dass je übersetzt worden wäre.

Entscheidungsregel

Wird eine Sprache "aufgemacht", ohne dass übersetzt wird, produziert diese Sprache doppelte Inhalte und nützt auch den vorhandenen Sprachen nichts. Die Veröffentlichungsschwelle für eine neue Sprache sollte lauten: Der Textkörper in dieser Sprache erreicht mindestens 85 % der normalisierten Wortzahl der Ausgangssprache. Darunter nicht veröffentlichen – und für eine nicht veröffentlichte Sprache auch kein hreflang schreiben (siehe Abschnitt 3).

12. KI-Suche: die Arbeit, die nach dem Aufräumen kommt

Gehen Sie zu diesem Abschnitt nicht über, bevor die elf Punkte davor abgeschlossen sind. Die KI-Suche ist kein eigener Kanal, sondern eine auf denselben Index aufgesetzte Schicht; ist die untere Schicht defekt, arbeitet die obere ebenso defekt.

Die Zahlen sagen Folgendes. Laut BrightEdge, das von Februar 2025 bis Februar 2026 gemessen hat, erscheinen KI-Zusammenfassungen bei etwa 48 % der beobachteten Suchanfragen (ein Jahr zuvor rund 30 %); bei etwa der Hälfte aller Anfragen erscheint weiterhin gar keine Zusammenfassung. In der Messung von Seer Interactive vom Februar 2026 lag die organische Klickrate bei Anfragen mit Zusammenfassung bei 2,4 %, bei Anfragen ohne bei 3,8 %. Im 900-köpfigen US-Panel von Pew Research (März 2025, 68.879 Suchen) führten 8 % der Besuche mit sichtbarer KI-Zusammenfassung zu einem Klick auf einen klassischen Ergebnislink; ohne Zusammenfassung waren es 15 %. Ein Klick auf einen Link innerhalb der Zusammenfassung lag bei lediglich 1 %.

Die für Reise entscheidende Zahl: Laut BrightEdge stammen nur 17,7 % der KI-Zitate bei Reise-Suchanfragen aus den organischen Top 10 (ein Jahr zuvor 5,7 %). Mehr als drei Viertel der Zitate werden also aus Quellen gezogen, die nicht auf der ersten Seite stehen.

Oben der Vergleich der organischen Klickrate, unten die Verteilung der Zitatquellen bei Reise-Suchanfragen. Quellen: Seer Interactive und BrightEdge, Februar 2026.

Zusammen gelesen führen diese beiden Zahlen zu einer praktischen Schlussfolgerung: Platz eins garantiert kein Zitat, und zitiert zu werden ist eine eigene Aufgabe. Und Zitiertwerden hat einen messbaren Gegenwert – laut der Messung von Seer Interactive vom April 2026 erhalten Marken, die bei einer Anfrage zitiert werden, pro Impression 120 % mehr organische Klicks als nicht zitierte Marken.

Was also tun – und was nicht

Klären wir zuerst, was nicht zu tun ist, denn in diesem Feld gibt es viel Lärm.

llms.txt ist keine Lösung. In der Untersuchung von Ahrefs über 137.000 Domains erhielten 97 % der llms.txt-Dateien im Mai 2026 überhaupt keine Anfrage; von den rund 38.000 Domains mit gültiger Datei bekamen nur etwa 1.100 auch nur eine einzige Anfrage, 96 % dieser Anfragen kamen von Bots, und die meisten davon waren Audit- und Profiling-Werkzeuge, keine KI-Agenten. Auch auf Googles Seite ist die Lage eindeutig: Die offizielle Dokumentation zu KI-Funktionen sagt "Sie müssen keine neuen maschinenlesbaren Dateien, KI-Textdateien oder Markup erstellen, um in diesen Funktionen zu erscheinen" und ergänzt: "Es gibt auch keine spezielle schema.org-Auszeichnung, die Sie hinzufügen müssten."

Die Datei zu erzeugen schadet nicht, aber Ihre Sichtbarkeitsstrategie kann nicht darauf aufbauen. Vier Dinge wirken tatsächlich:

1. Auf jeder Seite ein Antwortabsatz, den eine Maschine sauber entnehmen kann. Direkt unter der Überschrift, 40 bis 60 Wörter, definitorisch und für sich verständlich. Sätze wie "In diesem Beitrag behandeln wir…" lassen sich nicht zitieren; ein Satz wie "Ein Void bedeutet, dass ein Ticket nach der Ausstellung als nie ausgestellt gilt, und ist nur innerhalb des vom Anbieter definierten Zeitfensters möglich" lässt sich zitieren.
2. Nachprüfbare Zahlen mit Quelle. Eine Zahl mit Institutionsname und Jahr ist für Mensch und Maschine mehr wert als eine Behauptung ohne Beleg. Was Sie nicht belegen können, schreiben Sie nicht; beschreiben Sie den Effekt stattdessen qualitativ.
3. Standardisierte strukturierte Daten, korrekt umgesetzt. Suchen Sie kein Spezialschema; füllen Sie Standardtypen wie Organization, BreadcrumbList und FAQPage korrekt und konsistent aus. Zwei typische Fehler aus dem Audit: Das Organisationslogo zeigte auf eine Datei, die es nicht gab (kann die Suchmaschine das Logo nicht abrufen, verwirft sie das Verlagsbild vollständig), und die Breadcrumb-Daten wiesen die falsche Kategorie aus.
4. Einzigartige, tatsächlich übersetzte Inhalte. Keine der 67 Adressen mit identischem Textkörper über sieben Sprachen war zitierfähig.

Auch die Snippet-Steuerung gilt hier: Google gibt an, dass nosnippet, data-nosnippet und noindex ebenso für KI-Funktionen wirken. Wenn Sie also nicht möchten, dass ein Abschnitt in Zusammenfassungen verwendet wird, haben Sie das Werkzeug bereits.

13. Zwanzig Punkte für die technische Sichtbarkeit

Außer Browser und curl ist kein Werkzeug nötig. Bei jedem Punkt steht das erwartete Ergebnis.

#	Prüfung	Erwartetes Ergebnis
1	Host ohne www abrufen	301 → Variante mit www (oder umgekehrt, konsistent)
2	Variante mit Schrägstrich abrufen	301 → auf die eine Form
3	Wurzeladresse abrufen	Einstufige 301, ohne Sprachprüfung
4	Canonicals auf zehn zufälligen Seiten zählen	Genau eines pro Seite
5	Ist der Canonical-Wert die eigene Adresse der Seite	Ja, inklusive Host und Schrägstrich
6	hreflang-Set auf einer Produkt- oder Blogseite	Nur Sprachen mit echter Übersetzung
7	Jedes hreflang-Ziel einzeln abrufen	Alle 200 und mit echtem Inhalt
8	Verweist jedes Ziel zurück	Ja, gegenseitig
9	Sind die Sprachcodes nach ISO 639-1	Ja; keine Region allein geschrieben
10	Nicht existierende Adresse erfinden und abrufen	404 (nicht 200 plus "nicht gefunden")
11	Nicht-lateinischen Slug roh und kodiert abrufen	Beide Formen liefern denselben Code
12	Ist der Sitemap-Host der kanonische Host	Ja
13	Zehn Adressen aus der Sitemap stichprobenartig prüfen	Alle 200 und HTML
14	lastmod-Werte untersuchen	Voneinander verschieden, echte Daten
15	robots.txt-Gruppen lesen	Jede Regel in jeder Gruppe wiederholt
16	Vary bei sprachabhängiger Antwort	Vorhanden; oder Antwort ist sprachunabhängig
17	Weiterleitungsziele stichprobenartig prüfen	Alle kanonisch und mit 200
18	Sitemap minus interner Linkgraph	Leere Menge (keine verwaisten Seiten)
19	Menü- und Breadcrumb-Links durchgehen	Keiner liefert 404
20	Reihenfolge der Messung nach dem Deployment	Veröffentlichen → Cache leeren → messen

14. Ein Prüfkalender

Setzen Sie diese Arbeit als einmaliges Projekt auf, ist sie binnen sechs Monaten zurück. Auf der gemessenen Website war Verfall nicht nur eine Frage der Nachlässigkeit; das System driftete von selbst, weil jede neue Seitenvorlage ihre eigene Variante erzeugte.

Häufigkeit	Aufgabe	Warum
Bei jeder Veröffentlichung	Punkte 1-5, 10, 20	Eine neue Vorlage kennt die alte Regel nicht
Wöchentlich	Punkte 7, 8, 19	Übersetzungen und Inhaltszugänge zerstören das Set
Monatlich	Punkte 12-14, 18	Sitemap und Wirklichkeit driften langsam auseinander
Vierteljährlich	Punkte 6, 9, 11, 15-17	Infrastruktur und Weiterleitungstabelle ändern sich

Quellen

• Google Search Central — Localized versions of your pages (hreflang)
• Google Search Central — Consolidate duplicate URLs (canonical)
• Google Search Central — HTTP status codes and soft 404 errors
• Google Search Central — URL structure best practices
• Google Search Central — AI features and your website
• IETF — RFC 9309: Robots Exclusion Protocol
• MDN Web Docs — Vary header
• BrightEdge — AI Overviews at the One-Year Mark: Presence, Size, and What They're Citing (Februar 2026)
• Seer Interactive, wiedergegeben von ALM Corp — Google AI Overviews and Organic CTR in 2026
• Seer Interactive, wiedergegeben von Omnibound — Google AI Overviews Statistics (April 2026)
• Pew Research Center — Google users are less likely to click on links when an AI summary appears
• Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (Juni 2026)

Alle Messungen ohne benannte Quelle (1.088 Seiten, 921 fehlende Canonicals, 1.469 → 1.386 Sitemap-Adressen, 49 verwaiste Seiten, 70 kaputte Links, 329 nicht-kanonische Weiterleitungsziele, die Sprachkoeffizienten) stammen aus unserem eigenen Audit einer siebensprachigen Reisesoftware-Website im Juli 2026.

Häufige Fragen

Wofür ist das Canonical-Tag genau da?

Wenn mehrere Adressen denselben oder einen sehr ähnlichen Inhalt tragen, teilt es der Suchmaschine mit, welche davon als "die eigentliche" gelten soll. Es ist aber keine Anweisung, sondern – in Googles eigener Formulierung – ein starkes Signal; die endgültige Entscheidung trifft die Suchmaschine. Für Adressen, die Sie dauerhaft stilllegen wollen, nutzen Sie statt eines Canonicals eine 301-Weiterleitung: Sie ist das stärkere Signal.

Warum ist es ein Problem, wenn Adresse mit und ohne www beide erreichbar sind?

Weil das technisch zwei verschiedene Websites sind. Liefern beide 200, ist jede Ihrer Seiten doppelt erreichbar; eingehende Links, Klickdaten und Crawl-Budget teilen sich auf. Wählen Sie eine Variante, leiten Sie die andere per 301 dorthin, und lassen Sie Sitemap und interne Links ebenfalls die gewählte Variante verwenden.

Kann ich hreflang für jede Sprache mit demselben Slug schreiben?

Nur wenn dieser Slug in der jeweiligen Sprache tatsächlich funktioniert. Google knüpft hreflang an die Bedingung der Gegenseitigkeit: Zeigen zwei Seiten nicht aufeinander, können die Tags ignoriert werden. Für eine Sprache ohne Übersetzung hreflang zu schreiben, heißt der Suchmaschine eine Seite zu melden, die es nicht gibt. Fehlendes hreflang ist besser als falsches hreflang.

Was ist ein Soft 404 und wie erkenne ich ihn?

Der Server gibt einen 200-Erfolgscode zurück, obwohl der Inhalt eine Fehlermeldung ist. Am schnellsten erkennen Sie das, indem Sie eine auf Ihrer Website nicht existierende Adresse erfinden und abrufen: Ist der zurückgegebene Code nicht 404, haben Sie Soft 404. Auch der Indexierungsbericht der Search Console führt diese Seiten in einer eigenen Kategorie.

Warum liefern Adressen mit arabischen oder kyrillischen Zeichen manchmal 404?

Der Browser sendet diese Zeichen prozentkodiert; löst der Server die Kodierung nicht auf, wird die Adresse nicht gefunden. Weil die Rohform beim Testen von Hand funktioniert, kann der Fehler lange verborgen bleiben. Die Prüfmethode: dieselbe Adresse sowohl roh als auch prozentkodiert abrufen und bestätigen, dass beide Antworten denselben Statuscode tragen.

Warum ist mein organischer Traffic seit dem Start der KI-Zusammenfassungen gesunken?

Die Messungen zeigen einen strukturellen Unterschied: In den Daten von Seer Interactive vom Februar 2026 lag die organische Klickrate bei Anfragen mit Zusammenfassung bei 2,4 %, bei Anfragen ohne bei 3,8 %. Im Panel von Pew Research führten Suchen mit Zusammenfassung in 8 % der Fälle zu einem Klick auf einen Ergebnislink, ohne Zusammenfassung in 15 %. Selbst bei gleichbleibender Platzierung erhalten Sie also bei Anfragen mit Zusammenfassung weniger Klicks; das Ziel muss sein, innerhalb dieser Zusammenfassung zitiert zu werden.

Sollte ich eine llms.txt-Datei anlegen?

Sie schadet nicht, aber stützen Sie Ihre Sichtbarkeitsplanung nicht darauf. In der Untersuchung von Ahrefs über 137.000 Domains erhielten 97 % dieser Dateien im Mai 2026 überhaupt keine Anfrage. Google stellt in seiner offiziellen Dokumentation zudem ausdrücklich klar, dass für das Erscheinen in KI-Funktionen keine neue maschinenlesbare Datei, kein Markup und keine spezielle strukturierte Datenauszeichnung nötig ist.

Wie oft sollte ich das Audit wiederholen?

Als einmaliges Projekt angelegt, zerfällt es binnen weniger Monate, denn jede neue Seitenvorlage neigt dazu, ihre eigene Adressvariante zu erzeugen. Ein praktikabler Rhythmus: Adress- und Canonical-Prüfungen bei jeder Veröffentlichung, hreflang- und Linkprüfungen wöchentlich, Sitemap- und Waisenanalyse monatlich, Infrastrukturprüfungen einmal im Quartal.

Fünf Dinge für morgen früh

1. Führen Sie den Fünf-Varianten-Test durch. Rufen Sie für Ihre drei traffic-stärksten Seiten die Varianten mit und ohne www, mit und ohne Schrägstrich sowie den alten Pfad ab, falls vorhanden, und tragen Sie die Codes in eine Tabelle ein. Liefert mehr als eine Variante 200, wissen Sie, was Ihre erste Aufgabe ist.
2. Zählen Sie Canonicals auf zehn Seiten. Wie viele rel="canonical" stehen im Quelltext, und ist der Wert die eigene Adresse der Seite? Jede Seite mit null oder mehr als einem Treffer ist ein Befund.
3. Rufen Sie alle hreflang-Ziele eines Beitrags einzeln ab. Liefern alle 200, tragen ihre Textkörper echten Inhalt, verweisen sie zurück? Gibt es eine Sprache ohne Pendant, streichen Sie diese Zeile – das ist für sich genommen der schnellste Gewinn.
4. Erfinden Sie eine nicht existierende Adresse und rufen Sie sie ab. Kommt kein 404, haben Sie Soft 404; eine einzige Korrektur bringt hier mehrere unsichtbare Fehler auf einmal ans Licht.
5. Prüfen Sie zehn Adressen aus der Sitemap stichprobenartig. Stimmt der Host, liefern alle 200 und HTML, sind die lastmod-Werte echt? Meldet die Sitemap nicht die Wahrheit, steht jede weitere Messung auf falschem Fundament.