Was bedeutet Crawlability für KI-Suche?
Crawlability für KI-Suche bedeutet, dass ein dokumentiertes Suchsystem eine öffentliche URL abrufen, eine erlaubte und erfolgreiche Antwort erhalten, auf Hauptinhalt und Links zugreifen und die Seite in seiner Discovery-Pipeline verarbeiten kann. Crawlability schafft Eignung; sie garantiert weder Indexierung noch Abruf, Erwähnung oder Zitat.
Es gibt keinen universellen „KI-Crawler“. Googles KI-Funktionen nutzen die Infrastruktur von Google Search. OpenAI dokumentiert getrennte User-Agents für Such-Discovery, nutzerinitiierte Zugriffe und Training. Auch Perplexity unterscheidet Suchindexierung und Abrufe auf Nutzerwunsch. Für jede Richtlinie ist eine ausdrückliche Entscheidung nötig.
Wichtige Plattformregeln
Google AI Overviews und AI Mode
Google erklärt, dass eine Seite indexiert und für die Anzeige mit einem Snippet in Search geeignet sein muss. Die üblichen Googlebot-Regeln gelten; ein besonderer KI-Bot oder spezielles Schema ist nicht erforderlich. Crawl-Blockaden, noindex oder unterbundene Snippets können die Eignung gemäß der jeweiligen Search-Anweisung beeinflussen.
ChatGPT Search
OpenAIs FAQ für Publisher nennt OAI-SearchBot für Discovery und die Aufnahme in Zusammenfassungen und Snippets von ChatGPT Search. GPTBot ist eine separate Steuerung für Modelltraining, während ChatGPT-User bestimmte nutzerinitiierte Anfragen unterstützt. Behandeln Sie diese Bots nicht als austauschbar.
Perplexity
Perplexitys Crawler-Dokumentation unterscheidet PerplexityBot für Suchergebnisse und Perplexity-User für von Nutzern angeforderte Inhalte. Sie enthält auch Netzwerkinformationen, weil WAFs möglicherweise mehr als eine User-Agent-Regel benötigen.
Andere Systeme
Prüfen Sie die aktuelle Primärdokumentation, bevor Sie eine Regel ergänzen. User-Agent-Namen, Produkte und Verhalten können sich ändern. Entscheiden Sie vor einer breiten Freigabe, ob die Plattform für Ihre Zielgruppe relevant ist.
Crawlability-Audit Schritt für Schritt
1. Priorisierte URLs inventarisieren
Beginnen Sie mit Seiten, die maßgebliche Produkt-, Leistungs-, Richtlinien-, Preis-, Dokumentations-, Vergleichs- und Experteninformationen enthalten. Erfassen Sie Canonical-URL, Locale, Template, Verantwortlichen, Indexierungsabsicht und letzte wesentliche Aktualisierung.
2. Die rohe HTTP-Antwort testen
Prüfen Sie für jede zu bewertende Crawler-Richtlinie:
- erfolgreiche DNS- und TLS-Verbindung;
- finalen Status nach Weiterleitungen;
- Zahl und Ziel der Redirects;
- Response-Header;
- Body-Größe und Inhaltstyp;
- Cache- und Edge-Verhalten nach Region;
- Bot-Challenges oder Consent-Zwischenseiten.
Ein Browser-Screenshot zeigt nicht, ob ein Crawler ein 403 oder eine leere Hülle erhalten hat.
3. robots.txt auditieren
Analysieren Sie die Regeln für den exakten User-Agent und die Wildcard-Gruppe. Suchen Sie nach widersprüchlichen Gruppen, breiten Disallow-Pfaden, aus dem Staging kopierten Regeln, Fehlern bei Groß-/Kleinschreibung von Pfaden und Sitemap-Verweisen.
Beispiel für eine bewusste OpenAI-Richtlinie, die Search erlaubt, Training aber nicht:
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /Das drückt eine Richtlinie aus, garantiert aber kein ChatGPT-Zitat. Prüfen Sie OpenAIs aktuelle Dokumentation erneut, bevor Sie die Änderung veröffentlichen.
4. Indexierungs- und Snippet-Anweisungen prüfen
Untersuchen Sie HTML-Meta-Tags und HTTP-Header X-Robots-Tag auf noindex, nosnippet und Vorschau-Limits. Googles Dokumentation zu Robots-Meta-Tags erklärt, dass ein Crawler auf die Seite zugreifen muss, um diese Regeln zu erkennen.
Vermeiden Sie widersprüchliche Anweisungen aus mehreren Systemen.
5. Rohinhalt und gerenderten Inhalt vergleichen
Bestätigen Sie, dass Title, H1, Hauptantwort, relevante Links, Autor, Datum, Canonical, Robots-Angaben und JSON-LD im ausgelieferten oder zuverlässig gerenderten Dokument erscheinen. Testen Sie fehlgeschlagene APIs, langsame Requests, Cookie-Zustände und Hydration-Konflikte.
Bevorzugen Sie SSR oder Prerendering für öffentliche Quellinhalte. Clientseitige Erweiterung ist akzeptabel; ausschließlich clientseitige Existenz ist ein Zuverlässigkeitsrisiko.
6. Canonicals und Duplikate validieren
Stellen Sie sicher, dass der Canonical mit 200 antwortet, zur Indexierungsabsicht passt und in internen Links, Sitemaps, strukturierten Daten und lokalisierten Alternativen konsistent verwendet wird. Konsolidieren Sie Parameter-, Groß-/Kleinschreibungs-, Slash-, Druck- und Duplikatrouten bewusst.
7. Interne Discovery verifizieren
Priorisierte URLs sollten über crawlbare Navigation oder kontextuelle Links erreichbar sein. Verwaiste URLs, die nur in einer Sitemap stehen, sind zwar technisch auffindbar, aber schlecht in die Informationsarchitektur eingebunden.
8. Sitemaps prüfen
Verwenden Sie absolute kanonische URLs, korrekte Statuscodes und wahrheitsgemäße lastmod-Angaben. Teilen Sie Sitemaps nach Inhaltstyp oder Markt, wenn das die Diagnose verbessert. Eine Einreichung ist ein Hinweis, kein Beweis für Crawl oder Aufnahme.
9. CDN, WAF und Bot-Management untersuchen
Prüfen Sie Edge-Logs und Regeln auf:
403-,429- oder Challenge-Antworten;- blockierten Traffic aus Rechenzentren;
- geografische Beschränkungen;
- fehlende JavaScript- oder Cookie-Fähigkeiten;
- Request-Rate-Grenzen;
- gecachte Fehlerseiten;
- veraltete Robots-Dateien;
- fehlerhafte IP-Verifizierung.
Schwächen Sie Sicherheitsregeln nicht pauschal. Erstellen Sie nur enge, dokumentierte Ausnahmen für genehmigte Anwendungsfälle.
10. Mit Logs bestätigen
Server- oder CDN-Logs können User-Agent, verifiziertes Netzwerk, sofern verfügbar, URL, Zeitstempel, Response-Status, übertragene Bytes, Latenz und Cache-Ergebnis zeigen. Logs belegen Anfrage und Antwort — nicht Indexierung oder Verwendung in einer Antwort.
Häufige Fehlerbilder
| Symptom | Wahrscheinliche Ursache | Test |
|---|---|---|
| In Robots erlaubt, aber nie abgerufen | WAF, kein Discovery-Pfad oder geringe Nachfrage | Edge-Logs, Links, Sitemap |
Crawler erhält 200, aber keinen Inhalt | rein clientseitiges Rendering oder fehlerhafte API | Rohes mit gerendertem HTML vergleichen |
| Falsche URL erscheint | Canonical, Redirects, Duplikate | Signalmatrix und Crawl |
| Locale fehlt | erzwungener Geo-Redirect oder defektes hreflang | Regionstests und Alternativen-Graph |
noindex scheinbar ignoriert | URL blockiert, bevor die Anweisung gelesen wird | Robots und Response-Header |
| Bot besucht, aber keine Zitate | Eignung ohne Relevanz oder Quellenwert | Prompt- und Quellenanalyse |
Monitoring-Modell
Messen Sie vier getrennte Ebenen:
- Zugriff: genehmigte Crawler-Anfragen und erfolgreiche Antworten.
- Indexierung oder Discovery: plattformspezifische Nachweise, sofern verfügbar.
- Sichtbarkeit in Antworten: wiederholte Erwähnungen und Zitate für feste Prompts.
- Geschäftlicher Effekt: Verweise, Interaktion, Conversions und Umsatz.
Verwenden Sie nie eine Ebene als Nachweis für die nächste. Ein Request im Log ist kein verdientes Zitat.
Crawlability-Checkliste
- [ ] Priorisierte URLs liefern direkte kanonische
200-Antworten. - [ ] Search-, User-Fetch- und Trainingsregeln sind getrennt dokumentiert.
- [ ]
robots.txt, Meta Robots undX-Robots-Tagwidersprechen sich nicht. - [ ] Genehmigte Crawler passieren CDN und WAF.
- [ ] Hauptinhalt und Links sind ohne Nutzerinteraktion vorhanden.
- [ ] Canonical, Sitemap, interne Links und strukturierte Daten stimmen überein.
- [ ] Locale-Versionen sind direkt erreichbar.
- [ ] Sitemaps enthalten nur kanonische, indexierbare URLs.
- [ ] Logs enthalten ausreichend Daten für die Zugriffdiagnose.
- [ ] Monitoring bezeichnet Zugriff nicht als Zitat.
Sobald der Zugriff zuverlässig ist, verbessern Sie Relevanz und Quellenwert. Der Leitfaden zu technischen SEO-Best-Practices deckt das Gesamtsystem ab; unser Service für KI-Zitate verbindet Crawl-Diagnose mit einer wiederholbaren Kohorte zur Messung der Antwortsichtbarkeit.