KI-Crawler & Crawlbarkeit

Bevor ein KI-Assistent eine Marke nennen kann, muss sein Crawler die Website überhaupt lesen dürfen. CrunchJunkie gibt dir dafür zwei Werkzeuge, die sich ergänzen — unter KI-Sichtbarkeit → ein Kunde → Gruppe „Agent analytics“: • Crawlbarkeit — prüft die robots.txt einer Website und zeigt, welche KI-Crawler (GPTBot, ClaudeBot, Google-Extended, PerplexityBot und rund 20 weitere) erlaubt, teilweise blockiert oder komplett blockiert sind. Das ist der schnellste Weg, das klassische Eigentor zu entdecken: versehentlich genau die Bots zu blockieren, die KI-Antworten speisen. • Crawl-Insights — zeigt, welche KI-Bots die Website tatsächlich besucht haben, wie oft und welche Seiten sie abgerufen haben, indem es deine Server- oder CDN-Zugriffslogs liest. Crawlbarkeit sagt dir, was erlaubt ist; Crawl-Insights sagt dir, was wirklich passiert.

Für die Crawlbarkeit brauchst du nichts weiter als die Adresse der Website. 1. Stelle sicher, dass beim Kunden eine Website hinterlegt ist: Kunden → Kunden öffnen → Website-URL setzen (z. B. example.com). Damit wird das Analysefeld vorausgefüllt. 2. Öffne KI-Sichtbarkeit → den Kunden → Crawlbarkeit. 3. Die Domain ist vorausgefüllt (oder gib eine beliebige Domain ein). Klicke auf „Analysieren“. CrunchJunkie ruft die robots.txt der Domain ab und zeigt eine Tabelle bekannter KI-Bots mit einem Status — Erlaubt, Teilweise oder Blockiert — und für jeden Bot, warum er so eingestuft ist und wie du es änderst. Jede Prüfung wird im Verlauf gespeichert, du kannst sie später also erneut ausführen und genau sehen, was sich seit der letzten Prüfung geändert hat. Keine Einrichtung, keine Tags — es wird direkt die öffentliche robots.txt gelesen.

Crawl-Insights braucht deine Server-/CDN-Zugriffslogs, denn nur dort werden Besuche von KI-Bots festgehalten. 1. Öffne KI-Sichtbarkeit → den Kunden → Crawl-Insights. Beim ersten Besuch siehst du eine eigene Ingest-URL (…/api/crawl-logs/<key>) und einen Upload-Button. Der Schlüssel gehört zum Projekt: Löschst du ein Projekt, dessen Drain in den letzten 14 Tagen Logs geliefert hat, bittet CrunchJunkie dich zuerst, den Schlüssel in ein anderes Projekt des Kunden zu verschieben (der Drain läuft unverändert weiter) oder zu bestätigen; ein Drain, der weiter an die URL eines gelöschten Projekts sendet, bekommt 410 Gone mit dem Datum, nie ein endloses 401. 2. Bring die Daten hinein, auf einem von zwei Wegen: • Einmalig: Lade einen Zugriffslog-Export von deinem Server oder CDN herunter (Nginx/Apache im Combined-Format oder einen Cloudflare-/Vercel-Log-Export als .log/.csv) und lade die Datei auf der Seite hoch. • Fortlaufend: Richte einen Log-Drain auf die Ingest-URL aus, damit neue Treffer automatisch einlaufen — einen Vercel Log Drain, einen Nginx-/Apache-Forwarder, einen Cloudflare Worker (der Free-/Pro-Weg; fertiges Snippet auf der Crawl-Insights-Seite) oder Cloudflare Logpush (nur Enterprise). Eine Falle beim Vercel Log Drain: Seine Sampling-Regeln sind eine Positivliste. Vercel wendet sie von oben nach unten an, und eine Anfrage, auf die keine Regel passt, wird verworfen. Ein Drain, dessen einzige Regel etwa „/api/crawl-logs mit 0 %“ lautet (damit sich die Ingest-Route nicht selbst loggt), leitet deshalb gar nichts weiter – und Vercel zeigt ihn trotzdem als aktiv an, weil keine Zustellung je fehlschlägt. Wenn du eine solche Regel anlegst, setze darunter eine Sammelregel: Pfad leer, Production, 100 %. Ganz ohne Regeln leitet der Drain alles weiter. 3. CrunchJunkie parst die Zeilen, behält nur die Treffer von KI-Bots (alles andere wird verworfen) und baut daraus das Dashboard: Besuche gesamt, aktive Bots, Aufschlüsselungen nach Plattform / Bot / Zweck (Training, Suche, Nutzeranfrage), meistgecrawlte Seiten, HTTP-Statuscodes und einen Besuchsverlauf über 7/14/30/90 Tage. Die Tabelle der meistgecrawlten Seiten zeigt, was echte Crawler lesen: Scanner-Sonden (Pfade wie /.env unter jedem Namen) und Anfragen von Fälschungen (gefälschte IPs, reine robots.txt-Namen, IPs, die die Crawler-Namen mehrerer Betreiber rotieren) bleiben draußen und werden als eine Zahl ausgewiesen. Dasselbe gilt für Aufrufe von API- und Tool-Pfaden (alles unter /api/, dazu /mcp und die MCP-/OAuth-Anmelde-Abfragen unter /.well-known/): Sie werden getrennt als API-/Tool-Aufrufe gezählt, weil ein KI-Client, der deinen MCP-Connector aufruft, keine Person ist, die eine Seite liest. Sie zählen weder zu den Nutzeranfragen noch zu den meistgecrawlten Seiten, die Zahl und die häufigsten Pfade stehen in einer eigenen Zeile; ein Name, den ein Scanner getragen hat, ist auf seiner Anbieterkarte und in der Bot-Liste entsprechend markiert. Unter Statuscodes werden 5xx-Antworten aufgeteilt in solche, die ein echter oder nicht prüfbarer Crawler auf einer Inhaltsseite bekam – ein Ausfall, der zählt –, und solche, die nur Scanner-Sonden trafen. Gespeichert werden ausschließlich User-Agents von KI-Bots — normaler Besucher-Traffic aus den Logs wird verworfen, es entstehen also keine personenbezogenen Besucherdaten, die du verwalten müsstest. Eine Karte, „Markdown angefragt“, hängt davon ab, was deine Log-Quelle überträgt. Seit Frühjahr 2026 senden die Abrufer hinter KI-Antworten Accept: text/markdown auf gewöhnlichen Seiten-URLs, und die Karte zeigt pro Crawler, wie viele Abrufe Markdown angefragt haben — bezogen auf die Abrufe, deren Accept-Header aufgezeichnet wurde (die Stichprobengröße steht immer dabei). Das Cloudflare-Worker-Snippet leitet den Header weiter; ein Vercel Log Drain, Cloudflare Logpush und kombinierte Access-Logs nicht — bei diesen Quellen sagt die Karte, dass der Header unbekannt ist, statt 0 % zu zeigen. Ein eigener Forwarder kann den Header als Feld „accept“ pro Besuch mitsenden.

Crawl-Daten sind nicht nur für deine eigene Diagnose da — sie wandern direkt in einen Kundenbericht. Füge ein Tabellen-Widget ein, wähle die Quelle KI-Sichtbarkeit und setze die Dimension auf „Crawler visits“. Du bekommst eine Zeile pro KI-Crawler, der im Zeitraum des Berichts tatsächlich Seiten der Website angefordert hat — GPTBot, PerplexityBot, ClaudeBot und die übrigen —, verteilt auf fünf Spalten: Bot, Plattform, Typ (Training, Suche oder Nutzeranfrage), Besuche und Anteil, also der prozentuale Anteil dieses Bots an allen Bot-Besuchen der Periode. Es lohnt sich, einem Kunden zu erklären, was diese Tabelle von allem anderen unterscheidet. Jede andere Zahl zur KI-Sichtbarkeit ist eine gesampelte Schätzung: Wir fragen die Modelle viele Male und zählen, was zurückkommt — das ist die ehrliche Art, etwas Nicht-Deterministisches zu messen, aber es bleibt eine Stichprobe mit Fehlerbereich. Diese hier nicht. Jeder Besuch ist eine Zeile in einem Server-Log, die festhält, dass ein namentlich genannter Bot zu einem bestimmten Zeitpunkt eine URL abgerufen hat. Das ist ein harter Fakt und der stärkste Beleg, den du einem Kunden dafür vorlegen kannst, dass KI-Systeme seine Website lesen. Eine Voraussetzung musst du dabei sauber erfüllen. Die Tabelle hat nur dann Daten, wenn für das Projekt die Aufnahme der Crawl-Logs eingerichtet ist (siehe „Crawl-Insights einrichten“ oben). Ohne sie bleibt das Widget schlicht leer — und leer heißt „noch nicht angebunden“, nicht „kein KI-Crawler interessiert sich für diese Website“. Richte den Ingest ein, bevor die Tabelle auch nur in die Nähe eines Kundenberichts kommt, sonst erzählt sie genau die falsche Geschichte.

Die Karte „Nach Bereich der Website“ gruppiert dieselben Seitenabrufe wie die Tabelle der meistgecrawlten Seiten nach dem Teil der Website, den sie treffen. So siehst du, ob Crawler ihre Zeit auf /blog, /products oder /docs verbringen und wo sie abgewiesen werden. Scanner-Anfragen, Anfragen von Nachahmern, API- oder Tool-Aufrufe sowie Abrufe von robots.txt, Sitemaps und Asset-Dateien zählen nicht mit und stehen unter der Karte. Ein Pfad findet seinen Bereich in dieser Reihenfolge. Zuerst kommen deine eigenen Bereichsregeln. Dann die Startseite und der erste Teil des Pfads, wenn darunter mindestens eine abgerufene Seite liegt: /blog/a und /blog/b ergeben den Bereich /blog, und /blog selbst gehört dazu. Ein Sprachordner wie /de/ oder /en-gb/ bleibt ein Präfix, /de/blog und /blog sind also zwei Bereiche. Eine Seite auf oberster Ebene, unter der nichts abgerufen wurde (/about, /pricing), landet unter „Seiten der obersten Ebene“. Die zwölf meistabgerufenen Bereiche werden gezeigt, der Rest wird unter „Weitere Bereiche“ zusammengezählt, mit ihrer Anzahl; ein Bereich aus deinen eigenen Regeln wird immer gezeigt. Jeder Bereich zeigt seine Abrufe und ihren Anteil an allen Seitenabrufen, die Abrufe je Crawler-Betreiber (OpenAI, Anthropic, Google und die anderen), wie viele davon aus den veröffentlichten IP-Bereichen eines Betreibers kamen, die Zahl verschiedener Seiten und den Anteil, der mit 2xx beantwortet, von einer Firewall oder einem CDN abgewiesen (403/406) oder mit einem Fehler beantwortet wurde (404, 410, andere 4xx, 5xx). Diese Anteile beziehen sich auf die Abrufe, deren Logzeile einen Status enthielt, und die Karte nennt diese Zahl. Alle Werte sind Zählungen oder einmal über das ganze Zeitfenster geteilte Anteile, nie Durchschnitte. Eigene Bereiche: Öffne auf der Karte „Bereiche bearbeiten“ und schreib eine Regel pro Zeile, ein Pfad-Präfix und optional nach einem Gleichheitszeichen einen Namen, zum Beispiel /de/blog = Blog (DE). Das längste passende Präfix gewinnt, /de/blog nimmt seine Seiten also vor /de. Bis zu 20 Regeln; sie gelten sofort für die Seite, die Berichtstabelle „Crawl sections“ und den MCP-Connector, für jeden Zeitraum, weil sie nur ändern, wie die gespeicherten Abrufe gruppiert werden. Ein oft gecrawlter Bereich ist kein Bereich, den KI-Antworten zitieren. Crawler rufen Seiten ab, um sie zu indexieren oder eine einzelne Frage zu beantworten; Antworten entstehen meist aus einem Index oder Cache. Lies diese Karte für den Zugriff und für Probleme wie eine Firewall, die einen Bereich abweist, und die Seiten zur KI-Sichtbarkeit für Zitate.

Zeigt die Crawlbarkeit, dass ein KI-Bot, den du willst, Blockiert ist, passe die robots.txt der Website an (der Hinweis „So änderst du es“ in jeder Zeile nennt dir die genaue Direktive), deploye und klicke erneut auf „Analysieren“, um die Änderung zu bestätigen — der Verlauf hält die Verbesserung fest. Teilweise heißt, dass nur einzelne Pfade gesperrt sind: Regeln für /api, /admin oder einen Login-Bereich sind normal und brauchen keine Änderung; prüfe die gelisteten Pfade und ändere sie nur, wenn sie Seiten abdecken, die Antworten nutzen sollen. Zeigen die Crawl-Insights, dass ein Bot viele 404er kassiert oder deine wichtigsten Seiten nie erreicht, ist das ein Signal, interne Verlinkung, Sitemaps oder Serverfehler zu beheben, damit der Crawler die Inhalte auch wirklich indexieren kann, die in KI-Antworten auftauchen sollen.