Validiert Scanverra meine gesamte robots.txt-Datei?

Ja, in zwei Ebenen. Der SEO-Score des Website-Audits enthält eine echte robots.txt-Syntaxprüfung - nicht erkannte Direktiven, ein fehlerhafter HTTP-Status beim Abruf der Datei und ähnliche Fehlbildungen. Darüber hinaus laufen zwei weitere gezielte Prüfungen: ob sie bekannte KI-Crawler pauschal blockiert, und ob irgendeine Disallow-Regel sensibel wirkende Pfade (wie ein Admin- oder Backup-Verzeichnis) gegenüber jedem offenlegt, der die Datei liest. Was sie nicht prüft: ob Ihre Sitemap:-Direktive auf eine echte, funktionierende Sitemap zeigt.

Nach welchen KI-Crawlern sucht die Blockierungs-Prüfung?

Bekannte KI-Agenten wie GPTBot, ClaudeBot, CCBot, Google-Extended und PerplexityBot, unter anderem. Die Prüfung sucht speziell nach einem pauschalen Disallow: / oder Disallow: /*, das gegen diese User-Agents gerichtet ist, nicht nach engeren, bewussten Einschränkungen auf konkrete Pfade.

Warum würde das Blockieren von KI-Crawlern meiner Website schaden?

Da immer mehr Suche und Auffindbarkeit über KI-Assistenten läuft, die im Auftrag eines Nutzers im Web browsen oder zitieren, wird eine Website, die diese Crawler pauschal blockiert, für diesen gesamten Kanal unsichtbar - selbst wenn sie in traditioneller Suche gut rankt. Das ist ein Sichtbarkeitsverlust, den die meisten Teams erst bemerken, wenn man sie darauf hinweist.

Verbirgt das Auflisten sensibler Pfade in robots.txt diese nicht?

Nein - das ist ein verbreitetes Missverständnis. robots.txt ist eine öffentliche Datei, die jeder unter ihresite.de/robots.txt abrufen kann. Eine Disallow-Regel schränkt den Zugriff nicht ein, sie bittet nur wohlerzogene Crawler, den Pfad nicht zu indexieren - wer also /admin-backup/ dort aufführt, gibt jedem, der die Datei liest, eine Karte, wo genau man suchen muss.

Wie halte ich KI-Crawler tatsächlich von bestimmten Pfaden fern, ohne sie komplett zu sperren?

Zielen Sie auf den konkreten User-Agent und Pfad statt auf eine pauschale Regel - siehe das Codebeispiel unten. So können Sie zum Beispiel GPTBot von einem internen Suchergebnis-Pfad fernhalten, ohne es vom Rest Ihrer Website zu blockieren.

robots.txt beheben, die KI-Crawler blockiert

robots.txt ist eine Klartext-Datei im Root Ihrer Domain, die Crawlern sagt, welche Pfade sie anfragen dürfen. Eine einzige zu breite Disallow-Regel - oft aus einer Staging-Umgebung kopiert oder geschrieben, um einen einzelnen unerwünschten Bot zu stoppen - kann stillschweigend jeden KI-Crawler von Ihrer gesamten Website aussperren und Sie ohne jede Warnung aus KI-gestützter Suche und Assistenten-Ergebnissen ausschließen.

Warum das passiert

Ein Staging-Disallow: / landet in Produktion - eine pauschale Sperre, die eine Vorab-Website aus Suchmaschinen heraushalten sollte, wird nach dem Launch nie entfernt.
Eine für einen einzelnen aggressiven Scraper gedachte Regel wird auf alles angewendet. Ein Team blockiert alle Crawler, um einen einzelnen bösartigen Akteur zu stoppen, und erwischt dabei jeden legitimen KI-Agenten gleich mit.
Alte Blocklisten stammen aus der Zeit vor heutigen KI-Crawlern. Eine vor Jahren gegen eine feste Liste "schlechter Bots" geschriebene robots.txt schließt heute unbeabsichtigt neuere KI-User-Agents ein, für die niemand an Ausnahmen gedacht hat.
Sensible Pfade werden in robots.txt aufgeführt, als wäre es Zugriffskontrolle. Ein Team fügt Disallow: /admin-backup/ hinzu, um das Verzeichnis zu verstecken, ohne zu bemerken, dass die Datei selbst öffentlich ist und nun genau verrät, wo man suchen muss.

So findet man das Problem

Scanverra prüft Ihre robots.txt auf drei Arten, von allgemeiner Syntax bis zu zwei spezifischen Fehlermodi der KI-Ära:

Syntax und Erreichbarkeit. Der SEO-Score des Website-Audits enthält Lighthouses Standard-robots.txt-Prüfung - sie bestätigt, dass die Datei tatsächlich erreichbar ist (keine 4xx/5xx-Antwort) und dass jede enthaltene Direktive von Crawlern erkannt wird, wobei fehlerhafte Regeln als SEO-Problem markiert werden.
Pauschale KI-Crawler-Blockierung. Eine separate, Scanverra-spezifische Prüfung erkennt ein pauschales Disallow: / oder Disallow: /*, das gegen bekannte KI-Crawler gerichtet ist - GPTBot, ClaudeBot, CCBot, Google-Extended, PerplexityBot und ähnliche - und meldet es als Problem in Ihrem Agent-Readiness-Score des Website-Audits.
howToRobotsTxt.identifyItem3

Eine echte Lücke bleibt: Keine der drei Prüfungen bestätigt, dass Ihre Sitemap:-Direktive tatsächlich auf eine funktionierende Sitemap zeigt - nur, dass die Zeile selbst syntaktisch erkannt wird.

So behebt man es

1. Eine pauschale KI-Sperre durch gezielte Regeln ersetzen, falls Sie überhaupt sperren

Entscheiden Sie bewusst, welche KI-Crawler, wenn überhaupt, Sie tatsächlich aussperren wollen - und beschränken Sie das nur auf die konkreten relevanten Pfade, nicht Ihre ganze Website:

Vorher: blockiert jeden KI-Crawler von allemtypescript

1User-agent: GPTBot
2Disallow: /
3
4User-agent: ClaudeBot
5Disallow: /
6
7User-agent: CCBot
8Disallow: /

Nachher: erlaubt KI-Crawlern Zugriff, hält sie nur von einem internen Pfad ferntypescript

1User-agent: *
2Allow: /
3Disallow: /internal-search/
4
5Sitemap: https://example.com/sitemap.xml

2. robots.txt nie verwenden, um sensible Pfade zu verstecken

Muss ein Pfad wirklich privat bleiben, schützen Sie ihn mit Authentifizierung oder einem noindex-Meta-Tag auf der Seite selbst - nicht mit einer öffentlichen robots.txt-Regel, die nur verrät, wo er liegt. Entfernen Sie alle Disallow-Einträge, die auf Admin-, Backup- oder Staging-Verzeichnisse zeigen.

3. Bestätigen, dass die Korrektur wirkt

Führen Sie nach dem Bearbeiten der robots.txt erneut einen Website-Audit durch - die "KI-Crawler nicht blockiert"-Prüfung des Agent-Readiness-Scores spiegelt die Änderung sofort wider, da sie bei jedem Scan die live Datei liest.

Wie Scanverra dies erkennt

Der SEO-Score des Website-Audits führt bei jedem Scan eine standardmäßige robots.txt-Syntax- und Erreichbarkeitsprüfung durch. Zusätzlich liest eine dedizierte KI-Crawler-Prüfung dieselbe live Datei und sucht gezielt nach einem pauschalen, gegen bekannte KI-User-Agents gerichteten Disallow, das im Agent-Readiness-Score sichtbar wird; eine separate Prüfung im Security-Scan markiert sensibel wirkende Pfade, die in Disallow-Regeln genannt werden. Drei Prüfungen, jede auf einen anderen Fehlermodus ausgerichtet.