KI-Crawler und Sichtbarkeit in der Suche: Website zugänglich machen

Welche Crawler dienen der Suche, welche dem Training?

Bevor Sie die robots.txt ändern, entscheiden Sie, ob Sie Suche, Modelltraining oder beides zulassen. Für die KI-Funktionen der Google-Suche, darunter KI-Übersichten und KI-Modus, ist Googlebot der maßgebliche Crawler. Google-Extended steuert, ob Inhalte für das Training von Gemini und als Quellen für Antworten in bestimmten anderen Google-Produkten verwendet werden dürfen. Dieses Verfahren heißt Grounding. Google-Extended ist ein Token der robots.txt und kein eigener HTTP-User-Agent, nach dem Sie in den Logs suchen könnten. Auf die Aufnahme in die Google-Suche und auf Rankings hat es keinen Einfluss.

Zugriffe auf Nutzerwunsch folgen anderen Regeln als das automatische Crawling. Laut OpenAI gilt die robots.txt für ChatGPT-User möglicherweise nicht, und Perplexity-User ignoriert sie laut Perplexity in der Regel. Schützen Sie private Inhalte daher mit einer Anmeldung. Aktuelle Namen und Zwecke entnehmen Sie der Dokumentation von OpenAI, Perplexity und dem Crawler-Verzeichnis von Google, besonders wenn ein Anbieter seine Systeme umgestellt hat.

robots.txt schreiben und prüfen

Öffnen Sie /robots.txt auf demselben Host, mit demselben Protokoll und demselben Port wie die Seiten, die Sie prüfen wollen. Für https://example.com/services/ ist das https://example.com/robots.txt. Ihre Regeln gelten nicht für https://www.example.com. Sichern Sie die aktuelle Datei, bevor Sie etwas ändern. Öffnen Sie die öffentliche Datei nach dem Deployment erneut und prüfen Sie, ob Ihr CMS oder Ihr Veröffentlichungsprozess die Änderungen überschrieben hat.

Angenommen, Ihr Unternehmen möchte, dass ChatGPT seine öffentlichen Seiten findet, das Sammeln durch GPTBot für das Training aber ausschließen. Im Beispiel unten ist /private/ ein Platzhalterpfad, dessen Daten weiterhin eine Anmeldung brauchen. Die Einschränkung steht auch in der Gruppe für OAI-SearchBot, weil eine spezifische Gruppe die Regeln der *-Gruppe nicht automatisch erbt. Enthält die Datei mehrere Gruppen für denselben Crawler oder sich überschneidende Pfade, klären Sie anhand des Robots Exclusion Protocol, welche Regeln gelten.

Übertragen Sie das Beispiel auf Ihre bestehende Datei und behalten Sie weitere Einschränkungen und Sitemap-URLs bei, die Sie brauchen. Ein Pfad, der nicht gesperrt ist, braucht kein Allow: /. Vergleichen Sie die öffentliche Datei vor Abschluss der Aufgabe mit der freigegebenen Version.

User-agent: *
Disallow: /private/

User-agent: OAI-SearchBot
Disallow: /private/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Welche Seitendirektiven und Header sollten Sie prüfen?

Damit eine Seite in KI-Übersichten oder im KI-Modus als unterstützender Link erscheinen kann, verlangt Google, dass sie indexiert ist und für ein Suchsnippet infrage kommt. Prüfen Sie beides: das Robots-Meta-Tag im HTML und den X-Robots-Tag in den finalen HTTP-Antwort-Headern. Das CDN, das Ihre Seiten ausliefert, kann zum Beispiel ein noindex ergänzen, das im HTML fehlt. Zu Googles Snippet-Steuerung gehören nosnippet, max-snippet und data-nosnippet. Gehen Sie nicht davon aus, dass diese Angaben auf jeder Plattform gleich wirken.

Sperrt die robots.txt den Abruf einer Seite, kann die Suchmaschine deren noindex-Anweisung nicht lesen. Erlauben Sie den Abruf, damit sie die Anweisung verarbeiten kann. Sehen Sie sich in der URL-Prüfung der Search Console das HTML an, das Google erhalten hat. Ein Tag in Ihrem Repository belegt allein nicht, dass er die Suchmaschine erreicht hat.

OpenAI unterscheidet außerdem zwischen Antworten der Suche und Navigationslinks. Eine Website, die OAI-SearchBot sperrt, kann trotzdem als Navigationslink erscheinen. Das Sperren des Crawlings entfernt nicht jeden Verweis auf die Domain.

Ein Testplan für den Start: 32 Versuche an vier URLs

Wählen Sie vier verschiedene öffentliche Seiten, die Ihnen gehören oder die Sie testen dürfen. Nennen Sie die Leistungsseite U1, den Ratgeber U2, eine kürzlich aktualisierte Seite U3 und eine Seite mit JavaScript-abhängigen Inhalten U4. Haben Sie keine Seite der letztgenannten Art, nehmen Sie eine, die anders aufgebaut ist als die anderen drei. Erfüllt eine URL zwei Kriterien, suchen Sie trotzdem eine vierte, eigenständige Seite. Diese Stichprobe genügt für eine erste Diagnose; bei einer Website mit vielen Seitentypen sind weitere Prüfungen nötig. Verwenden Sie URLs, die Sie zugänglich machen wollen. Halten Sie gewollte Ausschlüsse fest, statt sie zu entfernen, nur um ein erfolgreiches Ergebnis zu erzielen.

Senden Sie für jede URL vier GET-Anfragen, eine je Profil, und wiederholen Sie sie später. Die erste Runde heißt R1, die zweite R2: 4 URLs × 4 Profile × 2 Runden = 32 Versuche. Verwenden Sie CTRL für AuditCrawler/1.0, GOOG für Googlebot/2.1 (+http://www.google.com/bot.html), OAI für OAI-SearchBot/1.4 und PPLX für PerplexityBot/1.0. Diese User-Agent-Strings dienen nur dem Vergleich der Antworten; echte Bots nutzen möglicherweise vollständige Strings und andere Versionen. Senden Sie die Anfragen nacheinander und notieren Sie jeweils den Zeitstempel. Weiterleitungen erzeugen zusätzliche Netzwerkanfragen über die 32 geplanten Versuche hinaus.

Der folgende Befehl sendet eine GET-Anfrage und speichert Header und Body der Antwort. Eine HEAD-Anfrage ruft nur die Header ab und kann deshalb keine Verifizierungsseite zeigen, die mit Status 200 ausgeliefert wird. Verwenden Sie in PowerShell curl.exe, um den Alias in manchen Versionen zu umgehen; unter macOS und Linux genügt curl. Führen Sie den Befehl in einem eigenen Ordner aus, nachdem Sie die Beispiel-Domain ersetzt haben. Das Limit von 30 Sekunden bricht einen Test ab, der nicht fertig wird. Es ist kein SEO-Schwellenwert.

curl -sS -L --max-redirs 5 --connect-timeout 10 --max-time 30 -A "AuditCrawler/1.0" -D U1-CTRL-R1-headers.txt -o U1-CTRL-R1.html -w "HTTP=%{http_code} URL=%{url_effective} BYTES=%{size_download}\n" "https://example.com/services/"

Identität eines Bots prüfen und eine WAF-Sperre untersuchen

Ihre curl-Tests kommen von Ihrer IP-Adresse, auch wenn Sie den User-Agent eines Crawlers setzen. Sie können einen Filter auf diesen Namen aufdecken, bilden aber nicht jedes Merkmal einer echten Crawler-Anfrage nach. Ein 403 mit dem Namen OAI-SearchBot belegt deshalb noch nicht, dass die Website OpenAI sperrt. Prüfen Sie echte Crawler-Anfragen und klären Sie, woher sie stammen.

Eine Web Application Firewall (WAF) filtert Webanfragen. Steht sie vor dem Server, kann sie einen Besuch abweisen, bevor er die Website erreicht. Suchen Sie in den WAF- oder CDN-Logs und in den Logs des Origin-Servers nach Anfragen an Ihre Beispiel-URLs. Halten Sie Datum, Uhrzeit und Zeitzone, Besucher-IP, User-Agent, URL, HTTP-Status, gelieferte Bytes und jede angewendete Regel fest. Taucht eine Request-ID in beiden Logs auf, verbinden Sie damit die Einträge. Andernfalls vergleichen Sie URL, Zeit und IP und vermerken die Grenzen des Abgleichs. Sitzt ein Proxy davor, fragen Sie den Betreiber, welches Logfeld die von der Infrastruktur verifizierte Besucher-IP enthält. Ein Header, den Besucher frei setzen können, ist kein verlässlicher Beleg.

Für Google folgen Sie der offiziellen Anleitung zur Verifizierung von Anfragen. Vergleichen Sie die IP mit der passenden von Google veröffentlichten Liste. Alternativ ermitteln Sie per Reverse-DNS-Abfrage den Hostnamen zur IP. Prüfen Sie, ob er zur erwarteten Domain dieses Crawlers gehört, und führen Sie dann für diesen Hostnamen eine Forward-Abfrage durch. Das Ergebnis muss die ursprüngliche IP enthalten. Ein Hostname, der nur das Wort „google“ enthält, genügt nicht.

Bei OpenAI und Perplexity prüfen Sie, ob die IP in den Bereichen der JSON-Dateien liegt, auf die die Dokumentation verweist. Speichern Sie eine Kopie der Liste und das Datum der Prüfung, denn die Bereiche können sich ändern. Perplexity empfiehlt, in Firewall-Regeln IP und User-Agent gemeinsam abzugleichen. Lässt sich die Herkunft nicht verifizieren, notieren Sie „Identität nicht verifiziert“. Ein Bot-Name allein rechtfertigt keine WAF-Ausnahme.

Blockiert die WAF einen verifizierten Crawler, den Sie zulassen wollen, passt der Firewall-Administrator die Regel für diesen Verkehr und die betroffenen öffentlichen Seiten an. Authentifizierung und Schutz sensibler Funktionen bleiben aktiv. Sichern Sie vor der Änderung die bisherige Regel und benennen Sie, wer sie wiederherstellen kann. Wiederholen Sie dann die Tests auf den betroffenen URLs.

Enthält eine 200-Antwort tatsächlich die Seite?

Öffnen Sie die gespeicherte HTML-Datei und vergleichen Sie sie mit der Seite im Browser, ohne angemeldet zu sein. Eine 200-Antwort kann „Bestätigen Sie, dass Sie ein Mensch sind“, ein Anmeldeformular oder eine Fehlerseite enthalten. Die wesentliche Formulierung, die Sie vor dem Test gewählt haben, hilft Ihnen, die erwartete Seite von solchen Antworten zu unterscheiden, ohne sich allein auf den Statuscode zu verlassen.

Fehlt die Formulierung im gespeicherten HTML, erscheint aber, nachdem der Browser die Seite geladen hat, prüfen Sie die per JavaScript ergänzten Inhalte und mögliche Skriptfehler. Google kann JavaScript verarbeiten, doch daraus folgt nicht, dass andere KI-Systeme dieselben Skripte ausführen. Bei Google sehen Sie sich in der URL-Prüfung das abgerufene HTML an. Bei anderen Anbietern vergleichen Sie deren dokumentierte Fähigkeiten mit Ihren Belegen. Erscheinen wesentliche öffentliche Informationen erst nach einem Klick oder der Cookie-Einwilligung, bitten Sie den Entwickler, sie ohne diese Interaktionen bereitzustellen. Private Inhalte bleiben hinter einer Anmeldung.

Prüfen Sie, ob Links zu wichtigen Seiten eine href-URL haben, Tabellen klare Kopfzeilen besitzen und informative Bilder einen passenden Alt-Text tragen. Google braucht außerdem Zugriff auf das CSS und JavaScript, die zum Rendern der Seite nötig sind. Betrifft das Problem mehrere Seitentypen, nutzen Sie den Ratgeber zum technischen SEO-Audit.

Ergebnisse festhalten und deuten

Tragen Sie für jede Test-ID, etwa U1-CTRL-R1, OK ein, wenn Sie den erwarteten Inhalt erhalten haben, FEHLER, wenn Sie eine Sperre oder eine andere Seite gefunden haben, und UNGEPRÜFT, wenn der Test fehlt oder nicht aussagekräftig ist. Notieren Sie den HTTP-Status und bewahren Sie die Antwortdateien auf. Halten Sie die Identitätsprüfung getrennt fest: Ein OK bei Ihrer Testanfrage bestätigt den Zugriff eines echten Bots nicht.

Wiederholen Sie nach der Korrektur die vier fehlgeschlagenen Kombinationen und stellen Sie sicher, dass sich der Zugriff der übrigen Profile nicht verändert hat. Speichern Sie die neuen Dateien in einem Ordner, der nach dem Datum des erneuten Tests benannt ist, und behalten Sie die früheren Dateien zum Vergleich. Wenn Sie anschließend beobachten, dass ein Bot mit verifizierter Identität die Seite erhält, haben Sie seinen Zugriff zu diesem Zeitpunkt bestätigt. Ob die Seite indexiert und als Quelle zitiert wird, müssen Sie gesondert prüfen.

Wie prüfen Sie die Auffindbarkeit, sobald der Zugriff funktioniert?

Verlinken Sie wichtige Seiten von anderen passenden Seiten Ihrer Website und nehmen Sie die kanonischen URLs, die indexiert werden sollen, in die Sitemap auf. Prüfen Sie, ob die öffentliche Sitemap erreichbar ist und ob sich lastmod, das Datum der letzten Änderung, ändert, wenn Sie den Inhalt wesentlich überarbeiten. Links und Sitemaps helfen Crawlern, URLs zu entdecken, garantieren aber weder einen Besuch noch eine Zitierung.

Lesen Sie in der URL-Prüfung der Search Console das Datum des letzten Crawls und prüfen Sie, ob die von Google gewählte Canonical-URL der beabsichtigten entspricht. Liegt der Crawl vor der Korrektur, zeigt das abgerufene HTML womöglich noch die alte Version. Ein Live-Test prüft den aktuellen Abruf, den Indexierungsstatus aktualisiert er nicht. Notieren Sie sowohl das Änderungs- als auch das Prüfdatum, damit klar ist, welche Version jedes Ergebnis beschreibt.

Testprotokoll und Übergabe an das Team

Gliedern Sie Ihr Testprotokoll nach der Ausgangskonfiguration, den acht Testergebnissen je URL und einer Zusammenfassung von Befunden und Korrekturen. Legen Sie 32 Zeilen an, eine pro Versuch. Bewahren Sie Header, HTML und Logdateien in einem Ordner auf und verwenden Sie dieselben IDs wie im Testprotokoll.

Legen Sie dem Website-Administrator bei der Übergabe die öffentlichen Regeln und Ihre Entscheidungen zu Suche und Training vor. Geben Sie an, welche Seiten und Profile Sie getestet haben, welche Prüfungen fehlen und welche Identitäten Sie verifiziert haben. Jede Korrektur braucht ein dokumentiertes Problem, einen Verantwortlichen und einen Termin für den erneuten Test. Haben Sie keinen Zugriff auf WAF- oder CDN-Logs, markieren Sie die Identitätsprüfung als UNGEPRÜFT und bitten Sie den Hosting-Anbieter um die Anfragen, die zu Ihren notierten URLs und Zeitstempeln passen.