Gute und schädliche Bots: Erst klassifizieren, dann blockieren

Eine IP fordert 600 Seiten in 10 Minuten an. Ist es ein Preis-Scraper, möchten Sie ihn stoppen. Entdeckt Googlebot dagegen eine neue Sitemap, kann eine Sperre Tausende Produkte verzögern. Das Verhalten wirkt gleichermaßen schnell, die Betriebsentscheidungen sind jedoch gegensätzlich.

Gute und schädliche Bots lassen sich nicht allein anhand von User-Agent, Geschwindigkeit oder JavaScript-Unterstützung trennen. Beantworten Sie drei Fragen: Wer ist es, was tut es und welche Auswirkungen entstehen?

Gute, schädliche und unbekannte Bots

Gute Bots

Ein guter Bot erfüllt einen akzeptierten oder nützlichen Zweck:

• Suchmaschinen-Crawler;
• selbst konfigurierte Link-, Verfügbarkeits- oder Sicherheitsprüfer;
• Abrufdienste für soziale Vorschauen;
• autorisierte Barrierefreiheits- oder Archivierungsdienste;
• vertraglich vereinbarte Partner-API-Clients.

Gut bedeutet nicht uneingeschränkt. Googlebot befolgt Robots-Regeln beim automatischen Crawling; auch eigene Monitore benötigen Endpunkt- und Geschwindigkeitsgrenzen.

Schädliche Bots

Schädliche Automatisierung verursacht Schaden oder greift zweckwidrig zu:

• betrügerische Werbeklicks;
• Auslesen von Preisen, Inhalten oder Kundendaten;
• Credential Stuffing und Passwortangriffe;
• Kontoerstellung, Formular-Spam oder Warenreservierung;
• Schwachstellenscans;
• gefälschter Traffic, der Analytics verfälscht.

Unbekannte Bots

Das ist oft die größte Gruppe: SEO-Werkzeuge, mobile Anwendungen, Headless-Browser, Test-Proxys oder neue KI-Dienste. Sofortige Sperren können Integrationen beschädigen, uneingeschränkter Zugriff schafft Risiken.

Rate-Limits und Beobachtung sind für diese Gruppe oft besser als binäre Entscheidungen.

Ein User-Agent ist kein Identitätsnachweis

Eine Anfrage mit:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

hat ihre Google-Herkunft nicht bewiesen. Jedes Skript kann diesen Text kopieren.

Google empfiehlt:

1. Reverse DNS muss einen gültigen Google-eigenen Hostnamen ergeben und Forward DNS wieder dieselbe IP liefern;
2. die Quell-IP mit Googles veröffentlichten Crawler-Bereichen vergleichen.

Positivlisten allein nach User-Agent laden zu Identitätsfälschung ein. Sperren nur nach User-Agent übersehen Bots, die Browser vortäuschen.

Signalmatrix zur Bot-Klassifizierung

Kein einzelnes Signal ist perfekt. Kombinieren Sie mehrere:

Ein legitimer Crawler kann schnell, zugleich verifiziert, Robots-konform und auf öffentliche Inhalte konzentriert sein. Ein Scraper behauptet vielleicht Chrome, überspringt Ressourcen, wechselt IPs und sammelt nur Produkte.

Sechs verdächtige Verhaltensmuster

1. Hohe Geschwindigkeit ohne menschlichen Rhythmus

Hunderte Klicks im exakten Abstand von 200ms sind kaum menschlich. Auch legitime Crawler sind schnell: Kombinieren Sie Geschwindigkeit mit Identität und Ziel-URLs.

2. Anfragen nur an geschäftlich wertvolle Endpunkte

Warenbestandsbots rufen die Funktion zum Hinzuf?gen zum Warenkorb auf, Bots f?r Angriffe auf Zugangsdaten konzentrieren sich auf die Anmeldung, und Klickbetrug trifft wiederholt die Zielseiten von Anzeigen; das ?berspringen der normalen Navigation ist ein starkes Indiz, um Klickbetrug zu erkennen.

3. Fingerabdruck und User-Agent widersprechen sich

Der User-Agent behauptet Safari auf iPhone, während TLS, Header-Reihenfolge oder Viewport Desktop-Headless-Chromium ähneln. Dieser Widerspruch ist hilfreicher als der Kennungstext selbst.

4. IPs wechseln, Gerätemerkmale bleiben

Residential Proxies ermöglichen wechselnde Adressen. Wiederholen sich Cookies, Fingerabdrücke, Verhalten und Ziele, wird das Sperren einzelner IPs endlos.

5. Zusätzliche Ressourcen werden nie geladen

Browser laden gewöhnlich benötigte CSS-, JavaScript-, Schrift- und Bildressourcen. Ein einfacher Scraper fordert vielleicht nur HTML oder APIs an. Caches und Datenschutzwerkzeuge machen dies zum unterstützenden Signal statt zum Beweis.

6. Fehlschläge arbeiten eine Liste ab

Aufeinanderfolgende Nutzernamen, Gutscheine, Kartendaten oder Adminpfade zeigen Automatisierung. IP-Limits allein versagen bei verteilten Bots; ergänzen Sie Konto, Fingerabdruck und Aktion.

Gute Bots nicht mit groben Regeln sperren

Alle Rechenzentren blockieren

Viele schädliche Bots nutzen Rechenzentren, ebenso Monitore, Webhooks, Suchcrawler und Geschäftsdienste. Das kann für sensible Gutscheineinlösungen passen, nicht aber für eine gesamte öffentliche Website.

Jeden schnellen Client blockieren

Suchcrawler und Verfügbarkeitsprüfer senden gültige Anfrageserien. Rate-Limits sollten Endpunkt-Sensibilität und verifizierte Identität berücksichtigen.

Überall JavaScript-Prüfaufgaben verlangen

Suchcrawler können teilweise JavaScript rendern, doch Bot-Challenges, Pflichtcookies und CAPTCHAs können die Entdeckung blockieren. Wichtige öffentliche Inhalte benötigen einen ungehinderten Weg für verifizierte Crawler.

Einer alten Positivliste dauerhaft vertrauen

IP-Bereiche, Dienste und Geschäftsanforderungen ändern sich. Jeder Positivlisteneintrag benötigt Quelle, Verantwortlichen, Prüfdatum und Nutzungsprotokoll.

Reaktionsrichtlinie nach Risiko

Stufe 1: Zulassen und protokollieren

Für verifizierte Crawler, eigenes Monitoring und bekannte Partner. Private Bereiche benötigen weiterhin Authentifizierung; „guter Bot“ bedeutet keine Berechtigung.

Stufe 2: Sanftes Rate-Limit

Für unbekannte Automatisierung auf öffentlichen Inhalten. Antworten Sie über dem Schwellenwert mit 429 und Retry-After, statt eine kurze Spitze dauerhaft zu sperren.

Stufe 3: Prüfaufgabe oder Funktionsbegrenzung

Für mittlere Risiken: schnelle Suche, wiederholte Warenkörbe oder Formularübermittlungen. Führen Sie JavaScript-Prüfungen, schwellenabhängige CAPTCHAs oder reduzierte Daten ein.

Stufe 4: Blockieren

Für Credential Stuffing, Ausnutzungsversuche, bestätigten Spam, belegten Klickbetrug oder Treffer hochwertiger Sperrlisten.

Stufe 5: Untersuchen und Beweise sichern

Bewahren Sie bei anhaltendem Werbebetrug oder Angriffskampagnen Anfrage-ID, Zeitstempel, gehashte IP, User-Agent, Fingerabdruck, Kampagne und Aktion auf. Speichern Sie personenbezogene Daten nicht über den Bedarf hinaus; Ziel sind reproduzierbare Entscheidungen.

Jede Angriffsfläche anders schützen

Inhalts- und SEO-Seiten

Verifizierte Crawler zulassen, konsequent cachen, unbekannte Automatisierung begrenzen und Scraping beobachten. Stellen Sie kein CAPTCHA vor indexierungsbedürftige Beiträge oder Kategorien.

Login und Passwortzurücksetzung

Nach Konto und IP begrenzen, Nutzernamenlisten erkennen, MFA nutzen und bei Fehlerspitzen warnen. Auch Bots mit Privatanschluss-IPs lassen sich über Aktionsmuster erkennen.

Leadformulare

Honeypots, Mindest-Ausfüllzeit, Servervalidierung und Rate-Limits reduzieren Spam. CAPTCHA allein reicht gegen menschlich unterstützte Farmen nicht.

Checkout und Gutscheine

Verfolgen Sie Geschwindigkeit nach Konto, Gerät, Karte und Gutschein. Rechenzentrumssperren können helfen, benötigen aber gegebenenfalls Ausnahmen für Geschäftskunden.

Werbe-Landingpages

Erfassen Sie Kampagne, Klick-ID, Zeitstempel und Qualitätswert. Vergleichen Sie Werbenetzwerk-Klicks mit Sitzungen, Logs und Conversions. Finanzielle Ausschlüsse benötigen stärkere Belege als eine verdächtige Anfrage.

Eine IP oder einen Fingerabdruck untersuchen

1. Adresse mit dem IP Checker klassifizieren.
2. Reverse DNS prüfen, wenn ein großer Crawler behauptet wird.
3. Aktionsfolge in einem Fenster von 5–30 Minuten abrufen.
4. User-Agent, Header, Fingerabdruck und Ressourcenanfragen vergleichen.
5. Kampagne, Landingpage und Aktionswert prüfen.
6. Vertrauensniveau statt absolut richtig/falsch vergeben.
7. Zulassen, begrenzen, prüfen oder sperren wählen.
8. Vorübergehenden Regeln ein Ablaufdatum geben.

Eine Bewertung von 0–100 erhält Graubereiche:

• 80–100: starke menschliche Signale;
• 50–79: beobachten oder leicht begrenzen;
• unter 50: mehrere Automatisierungs- oder Risikosignale.

Schwellen hängen vom Produkt ab. Blogs, Banken und Spiele besitzen unterschiedliche Risikotoleranz.

Fehlalarme als Produktkennzahl behandeln

Ein System, das 99% der Bots stoppt, aber 5% echter Kunden verliert, kann schlechter sein als ein weniger strenges. Beobachten Sie:

• erfolgreich bestandene Prüfaufgaben;
• gesperrte Besucher mit Supportkontakt;
• Conversions vor und nach einer Regel;
• über neue IPs zurückkehrende Bots;
• Endpunkte mit hohen Fehlalarmquoten.

Jede Regel braucht Grund, Verantwortlichen und Rücknahmepfad. „Diese IP wirkt seltsam“ ist keine Betriebsrichtlinie.

Bot-Regeln wie Produktionscode verwalten

Bot-Kontrollen sammeln sich an. Eine während eines Angriffs hinzugefügte Notfallsperre kann jahrelang bestehen, lange nach dem Besitzerwechsel der Adresse. Behandeln Sie Regeln als versionierte Produktionslogik.

Jede Regel sollte dokumentieren:

• begründendes Verhalten oder Ereignis;
• verwendete Signale und Vertrauensniveau;
• betroffene Endpunkte und Nutzergruppen;
• Verantwortlichen und Freigabedatum;
• Ablauf- oder Prüfdatum;
• Rücknahmeanleitung;
• zu beobachtende Fehlalarmkennzahlen.

Testen Sie neue Kontrollen möglichst zunächst nur berichtend. Protokollieren Sie potenziell begrenzte oder gesperrte Anfragen und vergleichen Sie sie mit erfolgreichen Logins, Käufen, verifizierten Crawlern und Supportbeschwerden. Diese Beobachtungsphase zeigt breite Regex- und Netzwerkregeln, bevor sie Kunden treffen.

Führen Sie Regeln je Angriffsfläche statt global ein. Eine strenge Regel kann bei Gutscheinen sinnvoll und auf Dokumentationsseiten schädlich sein. Endpunktspezifische Richtlinien liefern zudem klarere Änderungskennzahlen.

Bewahren Sie eine Notfallausnahme für verifizierte Abläufe und einen schnellen Rücknahmepfad. Bei Fehlalarmen kann das Warten auf eine vollständige Anwendungsbereitstellung mehr kosten als die bekämpfte Automatisierung.

Prüfen Sie Positivlisten ebenso sorgfältig wie Sperrlisten. Ein kompromittiertes Partnertoken oder eine veraltete Crawler-Ausnahme kann zur dauerhaften Lücke werden. Vertrauen sollte begrenzt, beobachtbar und regelmäßig neu bestätigt sein.

Ist robots.txt ein Bot-Abwehrwerkzeug?

Robots.txt ist eine Vereinbarung für kooperative Crawler. Schädliche Automatisierung kann sie ignorieren. Sie bleibt für Googlebot und legitime Crawler wesentlich, ersetzt aber weder WAF noch Authentifizierung, Rate-Limits oder Verhaltensanalyse.

Stellen Sie mit dem Robots.txt Checker sicher, dass eine Anti-Scraping-Änderung nicht versehentlich Suchcrawler blockiert.

Gesamtbild betrachten: Lesen Sie, wie der Traffic Quality Score funktioniert, und führen Sie vor websiteweiten Sperrregeln ein kostenloses SEO-Audit durch.

Fazit

Verifizieren Sie die Crawler-Identität nach der offiziellen Methode des Anbieters und prüfen Sie seine Aktionen. Sicherheitsheader beweisen weder seine Identität noch seine Freigabe durch die WAF.

Quellen: Google Search Central – Googlebot und Übersicht der Google-Crawler.