KI-Crawler auf dem eigenen Server: messen, drosseln, sperren

Kleine Server merken es zuerst: Die Last steigt, ohne dass mehr Menschen die Seite besuchen. Ein Blick ins Logfile zeigt Besucher, die in Minuten durch das gesamte Archiv gehen, jede Seite genau einmal holen und nie ein Bild anfassen. Das sind Crawler, die Trainings- und Antwortdaten sammeln.

Dieser Beitrag geht die Sache in der Reihenfolge an, die sich bewährt hat: erst messen, dann drosseln, erst zuletzt sperren. Wer mit dem Sperren anfängt, sperrt zuverlässig auch Google aus.

Zuerst: wie viel ist es überhaupt?#

Zu den Anteilen kursieren sehr unterschiedliche Angaben, und sie sagen wenig, weil sie stark von der Art der Seite abhängen. Die einzige belastbare Zahl steht in deinem eigenen Zugriffsprotokoll.

# Die zwanzig häufigsten Kennungen der letzten Logdatei
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Anteil bekannter KI-Crawler an allen Anfragen
gesamt=$(wc -l < /var/log/nginx/access.log)
ki=$(grep -icE 'GPTBot|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|Bytespider|meta-externalagent|Amazonbot|CCBot|OAI-SearchBot' /var/log/nginx/access.log)
echo "$ki von $gesamt Anfragen = $(( ki * 100 / gesamt ))%"

# Und was sie an Daten kosten (Feld 10 ist bei nginx die Antwortgröße)
awk '/GPTBot|ClaudeBot|PerplexityBot|Bytespider/ {s+=$10} END {print s/1024/1024 " MB"}' /var/log/nginx/access.log

Bei Caddy liegt das Protokoll im JSON-Format; dort macht jq dasselbe:

jq -r '.request.headers["User-Agent"][0]' /var/log/caddy/access.log | sort | uniq -c | sort -rn | head -20

Wenn dabei ein einstelliger Prozentsatz herauskommt, hör hier auf. Dann ist das ein Rauschen und kein Problem, und jede Regel, die du jetzt schreibst, kann dir später Suchtreffer kosten.

Wer da unterwegs ist und mit welchem Zweck#

Die Unterscheidung ist wichtiger als die Liste, weil sie erklärt, warum manche Sperren wirken und andere nicht:

Die dritte Zeile ist die, an der sich Diskussionen entzünden. Ein Abruf auf Nutzerwunsch ist technisch näher an einem Menschen, der die Seite öffnet, als an einem Crawler und viele Anbieter behandeln ihn deshalb ausdrücklich nicht wie einen Crawler. Wer das unterbinden will, muss es aktiv tun; robots.txt allein reicht dafür meist nicht.

Die vierte Zeile ist die häufigste Verwechslung: Wer Google-Extended sperrt, verliert nicht seine Google-Treffer. Wer Googlebot sperrt, schon.

robots.txt: schwächer als gedacht, wichtiger als gedacht#

robots.txt ist eine Bitte, kein Schloss. Sie hält niemanden auf, der sich nicht daran halten will. Trotzdem gehört sie an den Anfang, aus zwei Gründen: Die großen Anbieter halten sich daran, und in Deutschland ist sie Rechtsgrundlage.

# /robots.txt — Suchmaschinen willkommen, Trainingssammler nicht
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# Alle anderen dürfen, inklusive Googlebot und Bingbot
User-agent: *
Disallow:
Crawl-delay: 5

Drosseln statt sperren#

Eine Drossel wirkt gegen alles, was zu schnell ist, auch gegen Crawler, die morgen einen neuen Namen tragen. Und sie sperrt niemanden aus, sie verlangsamt ihn nur.

nginx, zehn Anfragen pro Sekunde, kurze Spitzen erlaubt, freundliche Absage statt Fehler:

# im http-Block
limit_req_zone $binary_remote_addr zone=allgemein:10m rate=10r/s;
limit_req_status 429;

server {
    location / {
        limit_req zone=allgemein burst=20 nodelay;
        # ...
    }
}

Caddy, dieselbe Idee, andere Schreibweise:

example.com {
    @ki header_regexp User-Agent "(?i)(GPTBot|ClaudeBot|CCBot|Bytespider|PerplexityBot)"
    respond @ki "Zugriff für automatisierte Sammler nicht gestattet" 403

    root * /var/www/example.com
    file_server
}

Zum Statuscode: 429 ist die richtige Antwort auf „zu schnell“, 403 auf „nicht erwünscht“. Ein 429 sagt dem Gegenüber, es solle langsamer wiederkommen, gut erzogene Crawler tun das. Ein 403 sagt „nie wieder“, und wer das flächig auf IP-Bereiche anwendet, trifft irgendwann echte Besucher.

Aufbau und Feinheiten beider Server stehen in Reverse-Proxy mit Caddy oder nginx.

Kennungen lügen, Herkunft prüfen#

Ein User-Agent ist ein frei wählbarer Text. Wer eine Regel darauf baut, sperrt ehrliche Crawler und lässt unehrliche durch. Die großen Anbieter veröffentlichen deshalb ihre IP-Bereiche und lassen sich per Rückwärtsauflösung prüfen, dasselbe Verfahren, das Google seit Jahren für Googlebot empfiehlt:

# 1. Rückwärts auflösen
host 66.249.66.1
# 2. Ergebnis wieder vorwärts auflösen — beide Richtungen müssen zusammenpassen
host crawl-66-249-66-1.googlebot.com

Für die KI-Anbieter gibt es veröffentlichte Adresslisten als JSON, die man einmal täglich zieht und in eine Firewall- oder Proxy-Liste gießt. Nur was in beide Richtungen stimmt, ist der, der es behauptet.

Was du auf keinen Fall mit aussperrst#

Vor dem Scharfschalten diese fünf gegenprüfen, jedes davon ist schon jemandem passiert:

1. Googlebot und Bingbot. Der teuerste Fehler in dieser Liste.
2. Die eigene Überwachung. Der Uptime-Prüfer holt alle 60 Sekunden dieselbe Seite und sieht damit aus wie ein Bot (Monitoring aufsetzen).
3. Feed-Leser. Sie holen die feed.xml regelmäßig und sind echte Leser.
4. Vorschau-Abrufe. Wenn jemand deinen Link in einen Chat stellt, holt ein Dienst die Seite für das Vorschaubild. Sperre das, und dein Link sieht überall nackt aus.
5. Die eigene Gesundheitsprüfung, falls sie über den Proxy läuft.

Wenn es wirklich viel wird#

Ab einer Größenordnung, die den VPS spürbar belastet, ist die Reihenfolge:

1. Caching davor. Eine Seite, die aus dem Cache kommt, kostet fast nichts, dann ist der Crawler ein Rundungsfehler.
2. Drossel pro Netz, nicht pro IP. Crawler kommen aus vielen Adressen desselben Bereichs.
3. Ein Dienst davor (etwa Cloudflare) mit eigener Bot-Erkennung. Der Preis dafür ist ein weiterer Mitleser im Datenweg, das ist eine Abwägung, keine reine Technikfrage.

llms.txt wird derzeit als Ergänzung zu robots.txt diskutiert. Ob und von wem sie ausgewertet wird, ist nicht belegt. Sie kostet nichts, also spricht nichts dagegen, sich darauf zu verlassen aber schon.

Häufige Fragen#

Verliere ich Sichtbarkeit, wenn ich KI-Crawler aussperre?#

In klassischen Suchergebnissen nein, solange Googlebot und Bingbot dürfen. In KI-Antworten ja, wer nicht gelesen wird, wird auch nicht zitiert. Das ist die eigentliche Abwägung, und sie fällt für einen Shop anders aus als für ein Handbuch.

Bringt es etwas, nur den Trainings-Crawler zu sperren, den Such-Crawler aber zuzulassen?#

Genau das ist die übliche Absicht: nicht ins Training, aber in die Antworten mit Quellenangabe. Die Anbieter trennen das über getrennte Kennungen, im Rahmen dessen, was man ihnen glaubt, funktioniert es.

Warum steht in meinem Log ein KI-Bot, obwohl robots.txt ihn verbietet?#

Drei mögliche Gründe: Es ist ein Abruf auf Nutzerwunsch (hält sich absichtlich nicht daran), die Kennung ist gefälscht (Herkunft prüfen), oder die robots.txt wird noch aus dem Zwischenspeicher gelesen. Prüfe zuerst den zweiten Punkt.

Reicht ein Eintrag in den Nutzungsbedingungen?#

Für den maschinenlesbaren Vorbehalt nach § 44b UrhG ist robots.txt der praktikable Weg. Ein Satz im Fließtext ist die schwächere Variante, beides zusammen kostet nichts.

Sollte ich pauschal alle unbekannten Bots sperren?#

Nein. Diese Liste wird täglich länger, und jede Zeile darin ist ein möglicher Fehlalarm. Eine Drossel wirkt gegen alles Unbekannte, ohne dass du sie pflegen musst.

Kurz gesagt#

• Erst zählen. Unter einem spürbaren Anteil ist jede Regel unnötiges Risiko.
• robots.txt hält niemanden auf, ist aber der maschinenlesbare Vorbehalt nach § 44b UrhG.
• 429 bei zu schnell, 403 bei unerwünscht. Nicht vertauschen.
• Kennungen sind frei erfunden, Herkunft in beide Richtungen prüfen.
• Vor dem Scharfschalten die fünf Unbeteiligten gegenprüfen, Googlebot zuerst.