Bot-Erkennung: So funktionieren Anti-Bot-Systeme

Der Betreiber eines Onlineshops sieht sich den Morgenbericht an: Um drei Uhr nachts hat sich die Besucherzahl vervierfacht, die Zahl der Warenkorb-Aktionen hat sich nicht bewegt, und auf der Anmeldeseite stehen Tausende fehlgeschlagene Versuche. Wie viel von diesem Verkehr ist eine Suchmaschine, wie viel ein Preisvergleichsdienst, wie viel ein Skript, das gestohlene Passwörter durchprobiert? Bot-Erkennung ist der Versuch des Seitenbetreibers, diese Frage für jede einzelne Anfrage innerhalb von Millisekunden zu beantworten.

In diesem Beitrag beschreiben wir die Bot-Erkennung aus der Sicht des Seitenbetreibers: Welche Schichten eine Anfrage durchläuft, was jede Schicht misst, wie aus den Signalen ein einziger Score wird und wer die Rechnung zahlt, wenn dieser Score danebenliegt. Wir fassen sechs Schichten der Reihe nach zusammen und überlassen die Details dem jeweils eigenen Beitrag. Wie Headless-Browser erkannt werden, wie gute Bots sich ausweisen und welcher legitime Weg für den Betrieb einer Automatisierung offensteht, finden Sie ebenfalls hier. Wege, Schutzmaßnahmen zu umgehen, sind nicht das Thema dieses Beitrags.

Was ist Bot-Erkennung?#

Bot-Erkennung ist die Aufgabe, zu unterscheiden, ob eine Anfrage an eine Website aus dem Browser eines Menschen oder aus einem automatisierten Programm stammt. Die Software dafür heißt Anti-Bot-System, Bot-Schutz oder Bot-Management; sie läuft meist nicht im Code der Website selbst, sondern im vorgelagerten CDN oder in der Web Application Firewall (WAF). Cloudflare, Akamai und DataDome sind in diesem Feld häufig genannte Anbieter. Das System sucht Antworten auf zwei Fragen: Ist die Anfrage automatisiert, und wenn ja, ist sie von der erwünschten Art?

Was ist Bot-Traffic: Wie unterscheidet man gute von schlechten Bots?#

Bot-Traffic ist jede Anfrage, die nicht durch den Klick eines Menschen, sondern durch die Entscheidung eines Programms entsteht. In den Logs stehen drei Arten nebeneinander:

• Bots, die die Website will. Suchmaschinen-Crawler, Dienste zur Verfügbarkeitsüberwachung, Messenger, die Linkvorschauen erzeugen, die eigene Testautomatisierung der Website.
• Bots, die die Website abwägt. Preisvergleichsdienste, Archivierungswerkzeuge, KI-Crawler, Forschungsskripte. Manche Seiten öffnen die Tür, manche nehmen sie mit einer Ratenbegrenzung an.
• Automatisierung, die die Website nicht will. Das OWASP-Projekt zu automatisierten Bedrohungen katalogisiert diese Gruppe, indem es sie benennt: das massenhafte Durchprobieren gestohlener Passwörter (Credential Stuffing), das Prüfen gestohlener Kartennummern (Carding), das automatisierte Abgreifen knapper Warenbestände (Scalping) und das massenhafte Kopieren von Inhalten (Scraping) stehen auf dieser Liste.

Die Schwierigkeit ist, dass sich alle drei auf der Leitung ähneln. Deshalb sieht das System nicht auf ein einzelnes Zeichen, sondern auf die Summe der Schichten.

In welcher Reihenfolge wird eine Anfrage bewertet?#

1. Die Verbindung kommt an. Noch bevor Inhalte gelesen werden, steht die Quell-IP fest; Reputation, Land und Netz werden abgefragt.
2. Der TLS-Handshake findet statt. Die erste Nachricht (ClientHello) trägt einen Hinweis darauf, welche Software spricht.
3. Die HTTP-Verbindung wird aufgebaut. In HTTP/2 teilt der Client seine Verbindungseinstellungen mit; danach folgen Methode, Adresse und Header.
4. Der serverseitige Score wird berechnet. Die Signale der ersten drei Schritte verbinden sich mit der jüngeren Geschichte der Adresse; hier kann die Anfrage bereits abgelehnt werden.
5. Die Seite erreicht den Browser. Ein kleines Skript auf der Seite prüft die Browserumgebung und meldet das Ergebnis zurück.
6. Die Sitzung wird beobachtet. Anfragehäufigkeit, Navigationsreihenfolge und Interaktion aktualisieren den Score über die Sitzung hinweg.
7. Wird die Schwelle überschritten, folgt eine Maßnahme. Eine Ratenbegrenzung, ein Prüfbildschirm oder eine Sperre.

Die ersten vier Schritte laufen serverseitig ab, ohne dass der Besucher etwas bemerkt; der fünfte und sechste erzeugen nur bei Clients Daten, die JavaScript ausführen.

Die Schichten in einer Tabelle: Welche Schicht misst was?#

Die letzte Spalte trägt den Kerngedanken dieses Beitrags: Jede Schicht hat eine Gruppe von Menschen, bei der sie sich irrt, und die Schwellen werden in Kenntnis dieser Kosten eingestellt.

Die Netzschicht: Was sagen IP-Reputation und ASN?#

Die IP-Adresse ist die früheste Information über eine Anfrage. Das System sieht auf die Missbrauchsgeschichte der Adresse, auf ihr Land und darüber, zu welchem Netz sie über die ASN (Autonomous System Number) gehört. Eine Anfrage aus dem Netz eines Hosting-Anbieters und eine Anfrage aus einem Block, den ein Provider für Privatanschlüsse reserviert hat, werden nicht gleich behandelt: Privatnutzer gehen nicht aus einem Rechenzentrum ins Internet. Wie Websites eine Adresse als „Provider" oder „Hosting" einordnen, haben wir in ISP-Proxy und Residential Proxy im Vergleich beschrieben.

Die Reputation stammt aus zwei Quellen: aus Blacklists, die festhalten, ob die Adresse früher als Quelle von Spam oder Angriffen gemeldet wurde (IP-Blacklist), und aus Risikoscore-Diensten, die Adresstyp sowie die Frage, ob es sich um einen Proxy- oder VPN-Ausgang handelt, auf eine einzige Zahl bringen (IP Fraud Score). Die Schwäche der Schicht ist, dass sie nicht die Person misst, sondern die Adresse. Mobilfunkanbieter und viele Provider stellen sehr viele Anschlüsse hinter dieselbe Adresse (CGNAT); ein Skript, das von dort läuft, senkt die Reputation für alle, die sich diese Adresse teilen.

Die Protokollschicht: TLS-Fingerabdruck und HTTP/2-Einstellungen#

In der ersten Nachricht einer HTTPS-Verbindung sendet der Client offen die von ihm unterstützten Cipher Suites, die Erweiterungen und deren Reihenfolge. Die Liste unterscheidet sich von Browser zu Browser und von Bibliothek zu Bibliothek; verdichtet der Server sie zu einer kurzen Zusammenfassung (JA3 und JA4 sind verbreitete Formate), hat er ein von den Headern unabhängiges Merkmal. Eine Anfrage, deren User-Agent Chrome nennt, deren Handshake aber einer Python-Bibliothek gleicht, fällt durch diesen Widerspruch auf. Wie die Berechnung im Einzelnen abläuft und wo ihre Grenzen liegen, steht in TLS-Fingerabdruck und JA3.

RFC 9113 schreibt vor, dass beide Seiten zu Beginn einer HTTP/2-Verbindung einen SETTINGS-Frame senden. Die Werte in diesem Frame und die Reihenfolge, in der die Pseudo-Header (:method, :authority, :scheme, :path) gesendet werden, fallen in jedem HTTP-Stack anders aus. Der Wert der Schicht liegt darin, dass sie von jeder Angabe unabhängig ist; ihr Risiko besteht darin, dass Beschäftigte hinter Sicherheitsgeräten im Unternehmen, die TLS-Verkehr aufbrechen und neu aufbauen, mit einem Handshake ankommen, der nicht zu ihrem Browser passt.

Die Header-Schicht: User-Agent und Stimmigkeit#

Header sind die Selbstauskunft des Clients: User-Agent nennt Browser und Betriebssystem, die Client-Hints-Header (die Sec-CH-UA-Familie) wiederholen dieselbe Information in strukturierter Form, und Accept-Language gibt die Sprachpräferenz an. Diese Auskunft überprüft niemand; jedes Programm kann hineinschreiben, was es will. Wie die Zeichenkette gelesen wird, steht in Was ist ein User-Agent?.

Deshalb sieht ein Anti-Bot-System nicht auf die Angabe selbst, sondern auf ihre Übereinstimmung mit den übrigen Schichten. Sendet die angegebene Browserversion diesen Header-Satz in dieser Reihenfolge tatsächlich? Passt die Sprachpräferenz zum Land der IP, die Zeitzone zu dem, was der Browser meldet? Keine einzelne Abweichung ist für sich genommen ein Beweis (wer im Ausland lebt, verbindet sich aus einem anderen Land mit einem Browser in seiner Muttersprache), aber jede zieht den Score ein Stück nach unten.

Die Browserschicht: JavaScript-Signale#

Wenn die Seite geöffnet wird, erreicht der Schutz einen Bereich, den er serverseitig nicht sehen konnte: den Browser selbst. Ein in die Seite eingefügtes Skript liest Bildschirmmaße, installierte Schriften, die Zeichenausgabe der Grafikhardware, die Zeitzone und die unterstützten APIs; die Kombination dieser Werte ist der Browser-Fingerabdruck. Er erfüllt zwei Aufgaben: denselben Client auch bei wechselnder IP wiederzuerkennen und zu prüfen, ob die angegebene Umgebung echt ist. Eine Umgebung, die Chrome unter Windows angibt, aber einen Grafiktreiber meldet, den es nur auf Linux-Servern gibt, fällt bei dieser Prüfung auf. Die vollständige Liste der Signale steht in Browser-Fingerabdruck.

Clients, die das Skript gar nicht ausführen (HTTP-Bibliotheken wie cURL oder Python Requests), erzeugen in dieser Schicht keine Daten. An einem API-Endpunkt ist das der erwartete Fall; auf einer HTML-Seite genügt das vollständige Ausbleiben eines Skriptergebnisses, damit der Client nicht als Browser gilt.

Was ist ein Headless-Browser und wie erkennen ihn Websites?#

Ein Headless-Browser ist ein echter Browser, der ohne Fenster auf dem Bildschirm läuft: Er lädt die Seite, führt das JavaScript aus und übergibt das Ergebnis an den Code. Eingesetzt wird er in End-to-End-Tests, bei der PDF-Erzeugung, bei der Überwachung eigener Seiten und bei erlaubter Datenerhebung; verbreitete Werkzeuge sind Playwright, Puppeteer und Selenium. Wann er nötig ist, steht in Statische und dynamische Seiten, der Unterschied zwischen den beiden Werkzeugen in Playwright und Selenium.

Websites erkennen einen durch Automatisierung gesteuerten Browser an drei Merkmalen:

Das Flag in der ersten Zeile ist kein Trick zur Erkennung, sondern Teil des Standards: Der W3C-Text beschreibt es als den standardisierten Weg, auf dem der Browser dem Dokument mitteilt, dass er von WebDriver gesteuert wird.

Das Gewicht der zweiten Zeile hat mit der Zeit abgenommen. Nach Chromes Headless-Dokumentation war der alte Headless-Modus eine eigene Anwendung, die den Browsercode nicht teilte; seit Chrome 132 wird er nur noch als eigene Binärdatei namens chrome-headless-shell angeboten, während --headless den echten Chrome-Code ausführt. Je kleiner die Umgebungsunterschiede wurden, desto stärker verlagerte sich das Gewicht auf das Verhalten.

Für den Seitenbetreiber lautet die Lehre: Einen Headless-Browser zu erkennen heißt nicht, böse Absicht zu erkennen. Ihr QA-Team und Ihr Überwachungsdienst tragen dieselben Merkmale; diesen Verkehr über eine bekannte IP oder eine Regel für signierte Anfragen abzutrennen, richtet weniger Schaden an, als auf das Flag zu sehen und pauschal zu sperren.

Die Verhaltensschicht: Tempo und Navigationsmuster#

Die vorherigen Schichten sehen darauf, von wem die Anfrage kommt, die Verhaltensschicht darauf, was sie tut. Das einfachste Maß ist das Tempo: die Zahl der Anfragen, die in einem bestimmten Zeitraum von derselben Adresse, Sitzung oder demselben Konto kommen. Wird die Grenze überschritten, antwortet der Server mit 429 Too Many Requests. Woran die Zähler hängen und wie die Algorithmen Fixed Window, Sliding Window und Token Bucket arbeiten, haben wir in 429 Too Many Requests beschrieben.

Jenseits des Tempos steht das Navigationsmuster. Ein Mensch geht von der Startseite in eine Kategorie und von dort zum Produkt, und sein Browser lädt auch Bilder und Stylesheets; eine Sitzung, die nur Produktadressen in gleichmäßigen Abständen aufruft und keine einzige Nebendatei anfordert, sieht anders aus. Auch Anfragen an versteckte Links, die ein Besucher nie sehen kann, sind ein Signal dieser Schicht (Honeypot-Fallen). Neuere Systeme beobachten die Interaktion auf der Seite (Mausbewegung, Sichtbarkeit des Tabs) über die ganze Sitzung; ein aktuelles Beispiel haben wir in Cloudflare Precursor untersucht.

Diese Schicht sagt über eine einzelne Anfrage wenig und über hundert Anfragen viel. Ihr Preis ist Verzögerung: Für die Entscheidung müssen sich erst Daten ansammeln.

Wie aus Signalen eine Entscheidung wird: Scoring und Prüfung#

Keine der Schichten sagt für sich genommen „das ist ein Bot". Ihre Ergebnisse fließen in einen Score. Cloudflares Dokumentation zum Bot-Score ist ein deutliches Beispiel für diesen Ansatz: Jede Anfrage erhält einen Wert zwischen 1 und 99, wobei 1 hohe Sicherheit bedeutet, dass die Anfrage automatisiert war, und 99 hohe Sicherheit, dass sie von einem Menschen kam; alles unter 30 gilt als „wahrscheinlich automatisiert". Laut Dokumentation speisen Heuristiken, maschinelles Lernen, Anomalieerkennung und JavaScript-Prüfungen diesen Wert.

Ein Score ist keine Maßnahme. Die Maßnahme legt die Regel des Seitenbetreibers fest, und die Möglichkeiten bilden eine Leiter:

1. Erlauben. Der Score ist hoch, oder die Anfrage kommt von einem verifizierten Bot.
2. Tempo begrenzen. Die Anfrage wird angenommen, ihre Häufigkeit gedeckelt.
3. Prüfung zeigen. Dem Browser wird ein unsichtbarer Test, dem Besucher ein Kontrollkästchen vorgelegt; was dieser Bildschirm auf Besucherseite bedeutet, steht in Cloudflare „Verify You Are Human".
4. Sperren. Die Anfrage wird mit einem 403 oder einer Sperrseite abgewiesen.

Die Leiter wird je Endpunkt eingestellt: Auf einer Blogseite kosten ein paar Kilobyte Verkehr, wenn eine Anfrage mit niedrigem Score durchgelassen wird, auf einer Anmeldeseite kostet es ein übernommenes Konto.

Der Preis falsch positiver Treffer: Was passiert, wenn ein echter Besucher als Bot gilt?#

Die Bot-Erkennung kennt zwei Fehlerarten. Einen Bot für einen Menschen zu halten (falsch negativ) kommt als Last, als gefälschtes Konto oder als gestohlener Inhalt zurück. Einen Menschen für einen Bot zu halten (falsch positiv) ist entgangener Umsatz: der Kunde, der am Prüfbildschirm aufgibt, die Zahlung, die nie abgeschlossen wird. Der zweite Fehler taucht in Berichten nicht auf, weil ein gesperrter Besucher das Analysewerkzeug gar nicht erst erreicht.

Die Hauptquellen sind diese:

• Geteilte IP-Adressen. Mobilfunkkunden sowie Nutzer in Wohnheimen, Cafés und Firmennetzen zahlen für das Verhalten anderer.
• VPN- und Datenschutzwerkzeuge. Weil die Adresse wie die eines Rechenzentrums aussieht, senkt die Netzschicht den Score (VPN oder Proxy erkannt).
• Skript-Blocker, Barrierefreiheitswerkzeuge, Navigation per Tastatur. Die Browserschicht erhält keine Daten, die Verhaltensschicht findet nicht das Muster, das sie erwartet.

Auf Besucherseite entspricht dem eine Meldung wie „als Bot erkannt" oder „ungewöhnlicher Datenverkehr erkannt": Zwei Beispiele haben wir in Google-Fehler „Ungewöhnlicher Datenverkehr" und „Sorry, You Have Been Blocked" behandelt.

Die praktische Folge: Prüfen Sie, bevor Sie sperren, und beobachten Sie den Anteil derer, die durchkommen. Jede durchgelassene Anfrage ist ein Beleg dafür, dass die Regel die falsche Person aufgehalten hat.

Verifizierte Bots: Wie erkennt eine Website einen guten Bot?#

„Googlebot" in den User-Agent zu schreiben, ist eine Sache von einer Zeile; deshalb wird ein guter Bot nicht an seiner Auskunft erkannt, sondern an einem Nachweis. Heute sind drei Verfahren in Gebrauch.

Reverse-DNS-Prüfung. Googles Dokumentation zur Googlebot-Prüfung gibt das Verfahren an: Für die IP aus dem Log wird eine Reverse-DNS-Abfrage gestellt, der zurückgegebene Name daraufhin geprüft, ob er unter googlebot.com, google.com oder googleusercontent.com liegt, und dieser Name anschließend wieder zu einer IP aufgelöst und mit der ersten Adresse verglichen.

Listen verifizierter Bots. Bot-Management-Dienste übernehmen diese Prüfung für den Seitenbetreiber; Cloudflares Dokumentation zu verifizierten Bots nennt zwei Bedingungen: Der Bot weist sich ehrlich aus (über eine kryptografische Signatur, eine veröffentlichte IP-Liste oder Reverse DNS) und missbraucht dieses Vertrauen nicht, hält sich also an robots.txt und an ein angemessenes Anfragetempo. Die Anweisung crawl-delay zu missachten oder Verkehr zu erzeugen, der nicht zum angegebenen Zweck passt, ist ein Grund für die Streichung von der Liste.

Signierte Anfragen (Web Bot Auth). Beim neueren Ansatz signiert der Bot jede Anfrage mit seinem privaten Schlüssel, veröffentlicht den öffentlichen Schlüssel unter seiner eigenen Domain, und die Website prüft die Signatur. Der zugrunde liegende Standard ist RFC 9421 HTTP Message Signatures; für die Übertragung auf Bots wurde bei der IETF eine Web-Bot-Auth-Arbeitsgruppe gegründet. Die Gruppe hält heutige Lösungen wie IP-Listen, User-Agent-Zeichenketten und geteilte API-Schlüssel für unzureichend; die Identität eines Agenten, der im Auftrag eines Nutzers Anfragen stellt, gehört zum Umfang, die Identität des Endnutzers hinter dem Agenten nicht. Die Header der Signatur haben wir in Warum KI-Einkaufsagenten auf Websites blockiert werden beschrieben.

In allen drei Fällen entsteht Identität nicht aus der Auskunft des Clients, sondern aus einem Nachweis (DNS-Eintrag, IP-Besitz, privater Schlüssel).

Wenn Sie Automatisierung betreiben: Was ist der legitime Weg?#

Die Karte zeigt für den Betrieb einer Automatisierung dasselbe Ergebnis: Das System ist so gebaut, dass es Verkehr Platz macht, der sich zu erkennen gibt und maßvoll auftritt.

• Nutzen Sie die offizielle API, wenn es eine gibt. Der Zugang beruht auf einer Vereinbarung, die Bot-Erkennung kommt gar nicht ins Spiel.
• Halten Sie sich an robots.txt. Format und Prüfung in Python stehen in Was ist die Datei robots.txt?.
• Begrenzen Sie Ihr Tempo pro Website. Beachten Sie Antworten mit 429 und Retry-After.
• Geben Sie Ihrem Bot einen Namen. Botname und Kontaktadresse im User-Agent geben dem Betreiber die Möglichkeit, Ihnen zu schreiben, statt Sie zu sperren.
• Fragen Sie für große Zugriffsmengen um Erlaubnis. Wenn Sie einen Crawler betreiben, der der Öffentlichkeit dient, bewerben Sie sich für Programme für verifizierte Bots.
• Hören Sie auf, wenn ein Prüfbildschirm erscheint. Dieser Bildschirm ist die klare Entscheidung der Website; Dienste zum Lösen von CAPTCHAs empfehlen wir nicht.

Die Umsetzung dieser Schritte (Nebenläufigkeit, bedingte Anfragen, der Unterschied zwischen Rotation und Sticky-Sitzung) steht mit erprobtem Code in Daten sammeln, ohne blockiert zu werden.

Anwendungsbereiche: Wer sollte diese Karte kennen, und wofür?#

• Marketing- und Analyseteams: um die Quelle von Verkehrsspitzen zu trennen und das Werbebudget vor gefälschten Klicks zu schützen. Die Werbeseite steht in Klickbetrug bei Google Ads und auf unserer Seite zur Lösung für Werbeprüfung.
• Datenteams: um zu verstehen, welches Verhalten beim Sammeln von Daten aus öffentlich zugänglichen Seiten warum verdächtig wirkt; der allgemeine Aufbau steht auf unserer Seite zur Lösung für Data Scraping, und für Inhalte, die sich je nach Standort ändern, wird ein Residential-Proxy eingesetzt.
• QA- und Testteams: Der Bot-Schutz Ihrer eigenen Website kann Ihre eigene Testautomatisierung aufhalten. Leiten Sie den Testverkehr über eine feste Adresse und schreiben Sie für diese Adresse eine Erlaubnisregel; dafür wird ein ISP-Proxy oder Ihre eigene statische IP genutzt (Lösung für Anwendungstests).
• Markenschutzteams: Auch die Suche nach gefälschten Shops und Plagiatsangeboten ist Automatisierung und durchläuft dieselben Schichten; der Umfang steht auf unserer Seite zur Lösung für Markenschutz.

Häufige Fehler#

• Auf ein einzelnes Signal hin sperren. Eine Regel, die nur auf die ASN eines Rechenzentrums oder auf das Flag navigator.webdriver sieht, hält auch Überwachungsdienste und Ihre eigenen Tests auf.
• Dem User-Agent glauben und „Googlebot" die Tür öffnen. Eine Auskunft ist kein Nachweis; nutzen Sie Reverse DNS oder eine Liste verifizierter Bots.
• Für jeden Endpunkt dieselbe Schwelle setzen. Eine Anmeldeseite und ein Blogbeitrag tragen nicht dasselbe Risiko.
• Falsch positive Treffer nicht messen. Wird der Anteil der Anfragen, die die Prüfung bestehen, nicht verfolgt, wissen Sie nicht, wen Ihre Regel aufhält.
• Auf Seiten der Automatisierung: eine Sperre als technisches Rätsel sehen. Ein Prüfbildschirm ist kein Fehler, sondern die Antwort des Seitenbetreibers; überprüfen Sie Tempo, Umfang und Erlaubnis.

Entscheidungshilfe#

Häufige Fragen#

Was ist Anti-Bot und wozu dient es?#

Anti-Bot ist die Softwareschicht, die automatisierten Verkehr an einer Website einordnet und ihn nach den Regeln des Betreibers erlaubt, verlangsamt, prüft oder sperrt. Ihr Zweck ist nicht, alle Bots aufzuhalten, sondern schädliche Automatisierung von erwünschten Bots wie Suchmaschinen zu trennen.

Was bedeutet „als Bot erkannt"?#

Es bedeutet, dass die Schutzschicht der Website Ihrer Anfrage einen niedrigen Score gegeben hat; das heißt nicht, dass Sie ein Programm benutzt haben. Die häufigsten Gründe sind ein VPN oder eine geteilte IP-Adresse, Erweiterungen, die Skripte blockieren, und das Öffnen vieler Seiten in kurzer Zeit. Der erste Schritt ist, VPN und Erweiterungen abzuschalten und die Seite neu zu laden.

Warum bleiben Selenium und Playwright in der Bot-Erkennung hängen?#

Diese Werkzeuge steuern den Browser über WebDriver oder ein ähnliches Protokoll; der Standard verlangt, dass der Browser das mit dem Flag navigator.webdriver mitteilt. Dazu kommen Umgebungsunterschiede und ein Tempo, das menschlicher Interaktion nicht gleicht. Wenn Sie Ihre eigene Website testen, besteht die Lösung darin, für den Testverkehr auf Seiten des Schutzes eine Erlaubnisregel zu schreiben.

Sieht die Bot-Erkennung nur auf die IP-Adresse?#

Nein. Die IP ist das früheste Signal, nicht das einzige: TLS-Handshake, Stimmigkeit der Header, Browserumgebung und Verhalten über die Sitzung werden jeweils eigenständig bewertet. Deshalb wirkt sich der bloße Wechsel der IP nicht auf die übrigen Schichten aus.

Wie erkenne ich Bot-Traffic in Google Analytics?#

Ein plötzlicher Anstieg aus einer einzelnen Stadt oder einem einzelnen Netz, eine Interaktionsdauer nahe null und Sitzungen ohne Bezug zu Conversions sind typische Zeichen. Für eine sichere Trennung reicht ein Analysewerkzeug nicht; sehen Sie sich denselben Zeitraum in den Server- oder CDN-Logs nach IP, ASN und User-Agent aufgeschlüsselt an.

Womit beginnt man beim Schutz einer kleinen Website vor Bots?#

Beginnen Sie mit drei Schritten: Setzen Sie Ratenbegrenzungen auf teure Endpunkte wie Anmeldung, Registrierung und Suche, schalten Sie den Basis-Bot-Schutz Ihres CDN im Prüfmodus statt im Sperrmodus ein, und kontrollieren Sie, dass Suchmaschinen-Bots über die Liste verifizierter Bots durchkommen.

Fazit#

Bot-Erkennung ist keine Mauer, sondern eine Reihe hintereinander gestellter Messungen: Die Netzschicht liest Reputation und ASN der Adresse, die Protokollschicht die Spur von TLS und HTTP/2, die Header-Schicht die Stimmigkeit der Auskunft, die Browserschicht die Echtheit der Umgebung, die Verhaltensschicht das Navigationsmuster. Alles fließt in einen Score; der Seitenbetreiber wählt je nach Risiko des Endpunkts Erlauben, Ratenbegrenzung, Prüfung oder Sperre. Weil jede Schicht echte Nutzer falsch einordnet, prüft ein gut gebautes System zuerst und sperrt erst danach. Gute Bots weisen ihre Identität über Reverse DNS, Listen verifizierter Bots und Signaturen nach RFC 9421 nach; für den Betrieb einer Automatisierung führt der dauerhafte Weg über die offizielle API, robots.txt, maßvolles Tempo und eine offene Identität. Für regelkonforme Datenerhebung finden Sie die Proxy-Arten in unseren Proxy-Diensten.