Zwischen zwei Bestellungen liegen im Shop hunderte Abrufe, die kein Mensch ausgelöst hat. Ein Teil davon ist erwünscht: Suchmaschinen, die eigene Überwachung, Vorschaubilder für geteilte Links. Ein anderer Teil zieht den Katalog Seite für Seite ab, legt Ware in Warenkörbe, die er nicht bezahlt, oder probiert Zugangsdaten durch. 2025 waren mehr als 53 Prozent des gesamten Web-Verkehrs automatisiert, im Jahr davor 51 Prozent (Thales Bad Bot Report 2026). Dieser Beitrag zeigt, wie sich Bot-Verkehr im Onlineshop überhaupt messen lässt, woran ein Sammler im Serverlog auffällt, welche Stufen zwischen robots.txt und Rate-Limit zur Verfügung stehen und wo die Grenze zwischen Aussteuern und Aussperren verläuft.
Wie viel Verkehr überhaupt von Maschinen kommt
Eine der wenigen öffentlich zugänglichen Zahlenreihen zum Bot-Anteil stammt aus der Auswertung des Verkehrs, der über ein weltweit eingesetztes Anwendungsschutznetz läuft. Für 2025 weist sie aus, dass Bots mehr als 53 Prozent des gesamten Web-Verkehrs ausmachten, nach 51 Prozent im Vorjahr, während der menschliche Anteil auf 47 Prozent fiel (Thales Bad Bot Report 2026). Bereits für 2024 hatte dieselbe Auswertung festgehalten, dass automatisierter Verkehr die menschliche Aktivität erstmals seit einem Jahrzehnt übertraf (Imperva Bad Bot Report 2025). Für einen einzelnen Shop sagt das wenig über den eigenen Bestand aus: Die Reihe beschreibt einen weltweiten Durchschnitt über alle Branchen und Anwendungsarten hinweg. Sie taugt als Größenordnung dafür, wie viel Rauschen in Rohzahlen stecken kann, nicht als Erwartungswert für das eigene Protokoll.
Innerhalb der Automatisierung trennen beide Berichte zwischen erwünschten und schädlichen Bots. Für 2025 ordnen sie 40 Prozent des gesamten Verkehrs der schädlichen Gruppe zu (Thales Bad Bot Report 2026); der Bericht des Vorjahres wies 37 Prozent aus, ohne den Wert an ein Erhebungsjahr zu binden (Imperva Bad Bot Report 2025). Entscheidend ist dabei die Bezugsgröße: Die Prozentangabe bezieht sich in beiden Fällen auf den gesamten gemessenen Verkehr, nicht auf den Bot-Anteil. Wer die beiden Werte gegeneinander rechnet, um den Anteil gutartiger Automatisierung zu bestimmen, erhält eine Ableitung und keine der beiden veröffentlichten Messgrößen - und sollte sie auch so ausweisen.
Beide Auswertungen beruhen auf dem Verkehr, den ein weltweit eingesetztes Anwendungsschutznetz sieht - nicht auf einer Stichprobe deutscher Onlineshops. Der Bericht von 2026 wertet dafür das volle Jahr 2025 aus (Thales Bad Bot Report 2026). Eine vergleichbare öffentliche Reihe für den deutschen Handel liegt nicht vor. Wer seinen eigenen Anteil wissen will, misst ihn im eigenen Protokoll; alles andere ist eine Annahme mit fremder Grundgesamtheit.
Verändert hat sich weniger die Menge als die Beschaffenheit. Für 2025 weist die Auswertung aus, dass KI-getriebene Bot-Angriffe gegenüber dem Vorjahr um das 12,5-Fache zunahmen, und beschreibt KI-Agenten als dritte Verkehrskategorie neben erwünschten und schädlichen Bots (Thales Bad Bot Report 2026). Parallel verschiebt sich das Ziel: 27 Prozent der Bot-Angriffe richteten sich 2025 gegen Schnittstellen, wo die Oberfläche übersprungen und direkt mit dem System dahinter gesprochen wird (Thales Bad Bot Report 2026). Für den Shopbetrieb heißt das erfahrungsgemäß: Die Frage lautet nicht mehr, ob ein Zugriff von einer Maschine kommt, sondern was diese Maschine tut. Ein Abgleich mit einer Liste bekannter Kennungen greift dafür zu kurz.
Was Sammler im Shop tatsächlich anrichten
Preise und Katalog abgreifen
Der Fall, der am wenigsten auffällt, ist zugleich einer der häufigsten: Ein Programm ruft Kategorieseiten, Filterkombinationen und Detailseiten der Reihe nach ab und schreibt Preis, Verfügbarkeit und Beschreibung in eine eigene Datenbank. Die OWASP-Systematik automatisierter Bedrohungen führt diesen Fall als eigenes Ereignis unter der Kennung OAT-011 (OWASP Automated Threats). Im Bestellwesen wird davon nichts sichtbar. Im Serverlog dagegen schon: gleichmäßige Abstände zwischen den Anfragen, vollständige Abdeckung des Katalogs statt eines Pfades durch ihn, keine Bilder, keine Stylesheets, keine zweite Ebene der Interaktion. Wer regelmäßig in die Logfile-Analyse schaut, sieht solche Muster, bevor sie auf der Rechnung des Hosters auftauchen.
Zugängliche Daten und verarbeitete Ausgaben sammeln oder kopieren, um sie anschließend zu nutzen - etwa zur Verwertung geschützter Daten oder zur Preisabsprache.
OWASP Automated Threats to Web Applications, OAT-011 Scraping
Der Schaden entsteht auf drei Wegen zugleich. Erstens überträgt der Shop Rechenzeit und Datenvolumen für Abrufe, die keinen Umsatz auslösen - bei einem Katalog mit mehreren zehntausend Positionen ist ein vollständiger Durchlauf eine spürbare Last. Zweitens wandert die eigene Preisstruktur in fremde Systeme und taucht dort als Grundlage automatischer Unterbietung wieder auf. Drittens verzerrt der zusätzliche Verkehr die eigenen Messwerte, weil er in Sitzungen, Seitenaufrufen und Ladezeiten mitzählt, solange er nicht getrennt ausgewiesen wird.
Warenkörbe blockieren und Ware wegschnappen
Zwei Muster treffen vor allem Shops mit knapper Ware. Beim ersten legt ein Programm Artikel in den Warenkorb und bezahlt sie nicht; solange die Reservierung läuft, ist die Ware für andere Kunden nicht verfügbar. OWASP führt das als eigenes Ereignis unter OAT-021 und beschreibt ausdrücklich den Fall, dass Artikel nicht zur Kasse gehen, aber zu einem Ausverkauf-Zustand beitragen (OWASP Automated Threats). Wie ein Shop mit nicht lieferbaren Artikeln umgeht, entscheidet damit auch darüber, wie teuer eine solche Blockade wird - dazu passt der Beitrag zu ausverkauften Artikeln.
Beim zweiten Muster kauft das Programm tatsächlich, nur schneller, als es ein Mensch könnte. OWASP führt den Erwerb von Waren auf eine Weise, die ein normaler Nutzer manuell nicht leisten könnte, unter OAT-005 (OWASP Automated Threats). Betroffen sind vor allem limitierte Auflagen, Aktionsware und Artikel mit harten Startzeitpunkten. Beide Fälle lassen sich nicht über die Kennung des Aufrufers lösen, sondern nur über die Geschäftslogik: Wie lange hält eine Reservierung, wie viele offene Warenkörbe darf eine Sitzung haben, welche Schritte müssen zwischen Artikelseite und Bestellabschluss tatsächlich durchlaufen werden.
Kennzahlen verschieben sich unbemerkt
Der stillste Schaden trifft die Zahlen, auf deren Grundlage Entscheidungen fallen. OWASP führt das wiederholte automatisierte Klicken, Anfragen oder Absenden von Inhalten, das anwendungsbezogene Kennzahlen beeinflusst, unter OAT-016 (OWASP Automated Threats). In einem Shop betrifft das mehr Stellen, als auf den ersten Blick sichtbar sind.
- Conversion-Rate: Bot-Sitzungen zählen im Nenner mit, kaufen aber nicht. Die Rate sinkt, ohne dass sich am Verhalten der Kundschaft etwas geändert hat.
- Absprungrate und Verweildauer: Ein Sammler ruft eine Seite ab und verschwindet. Beides verschiebt sich in Richtung schlechterer Werte, obwohl die Seite unverändert ist.
- Beliebteste Produkte: Ein vollständiger Katalogdurchlauf verteilt Aufrufe gleichmäßig und drückt damit die tatsächlichen Renner in der Rangliste nach unten.
- Ladezeiten aus Felddaten: Automatisierte Abrufe ohne Bilder und ohne Skripte sehen schnell aus. Wer sie mitmisst, unterschätzt die Erfahrung echter Kundschaft - warum Felddaten statt Laborwerte zählen, gilt hier besonders.
- Suchbegriffe im Shop: Automatisierte Abfragen der internen Suche füllen die Auswertung mit Begriffen, nach denen kein Kunde gesucht hat.
Einsortieren statt pauschal sperren
Wer Automatisierung pauschal aussperrt, sperrt zuverlässig auch etwas aus, das er braucht: den Suchmaschinen-Crawler, den Vorschauabruf beim Teilen eines Links, die eigene Verfügbarkeitsprüfung, den Kunden im Firmennetz hinter einer gemeinsamen Adresse. Ein brauchbares Vorgehen sortiert Zugriffe deshalb entlang zweier Fragen: Ist der Zugriff erwünscht? Und gibt er sich zu erkennen? Aus den vier Kombinationen folgen vier verschiedene Reaktionen.
| Fall | Typisches Merkmal | Reaktion | Werkzeug |
|---|---|---|---|
| Erwünscht, deklariert | Feste Kennung, per Reverse-DNS bestätigt, hält Abrufrate ein | Durchlassen, Frequenz steuern | robots.txt, Crawl-Steuerung |
| Erwünscht, nicht deklariert | Viele Sitzungen aus einer Adresse, kauft aber und füllt Formulare aus | Beobachten statt sperren | Ausnahmeliste, Schwelle je Sitzung |
| Unerwünscht, deklariert | Nennt sich beim Namen, ignoriert Ausschlüsse, ruft ganze Kataloge ab | Vorbehalt setzen, dann drosseln | Nutzungsvorbehalt, Rate-Limit |
| Unerwünscht, getarnt | Wechselnde Adressen, kopierte Kennung, Muster nur im Verhalten | Verhalten messen, Logik schützen | Sitzungsgrenzen, Checkout-Schutz |
Die zweite Zeile ist die teuerste, wenn man sie übersieht. Große Firmennetze, Mobilfunk-Zugänge und Datenschutz-Weiterleitungen bündeln viele Menschen hinter wenigen Adressen. Eine Sperre nach Adresse trifft dort typischerweise zahlende Kunden, und der Ausfall fällt erst auf, wenn jemand anruft. Deshalb gilt die Reihenfolge: erst messen, dann einsortieren, dann drosseln - und Sperren nur dort, wo das Verhalten eindeutig ist. Welche dieser Reaktionen sich im eingesetzten System sauber abbilden lässt, hängt von dessen Aufbau ab; für Shopware-Läden gehört das in die laufende Betreuung des Shops.
Erkennen: woran ein Sammler im Log auffällt
Die Grundlage ist das Zugriffsprotokoll des Webservers, nicht das Analysewerkzeug im Browser. Wer nur browserbasiert misst, sieht Sammler in der Regel gar nicht, weil diese kein JavaScript ausführen. Das Protokoll dagegen enthält jede Anfrage - mit Adresse, Zeitstempel, Pfad, Statuscode, übertragener Datenmenge und Kennung des Aufrufers. Sechs Signale sind erfahrungsgemäß die ergiebigsten.
- Gleichmäßiger Takt: Menschliche Abstände zwischen zwei Seiten schwanken stark. Abstände, die über hunderte Anfragen kaum streuen, deuten auf ein Programm mit fester Wartezeit.
- Katalogvollständigkeit: Ein Aufrufer, der binnen Stunden praktisch jede Artikelseite genau einmal abruft, liest den Katalog, statt ihn zu durchstöbern.
- Fehlende Nebenressourcen: Seitenaufrufe ohne die zugehörigen Bilder, Schriften und Stylesheets stammen in der Regel nicht aus einem Browser mit Anzeige.
- Anteil an 404 und 301: Sammler laufen über alte Pfade und Parameterkombinationen, die in der Navigation nicht mehr vorkommen.
- Verhältnis Anfragen zu Sitzungen: Viele Anfragen auf sehr wenige Cookies oder ganz ohne Cookie sind ein deutlicheres Signal als jede Kennung.
- Adressherkunft: Rechenzentrumsnetze sind für Kundschaft untypisch. Wechselnde Anschlussnetze bei gleichbleibendem Verhaltensmuster deuten dagegen auf eine Verschleierung hin.
Das Muster im Beispiellauf ist eindeutig: eine einzelne Adresse mit einem Vielfachen der Anfragen aller anderen, davon fast alles Artikelseiten und kein Abruf eines Bildes oder Stylesheets. Ein Browser verhält sich anders. Wie sich solche Auswertungen fest im Betrieb verankern lassen, statt sie einmal von Hand zu fahren, gehört zur Frage des Hostings - Aufbewahrungsdauer der Protokolle, Rotation und ein Auswertungslauf, dessen Ausgabe irgendwo landet, wo sie jemand liest.
Das Feld mit der Aufruferkennung ist frei wählbar. Ein Sammler kann sich als verbreiteter Browser oder als Suchmaschine ausgeben, und beides kommt vor. Ein Zugriff lässt sich in der Regel nur über das Netz bestätigen: Erst eine Rückwärtsauflösung der Adresse, dann eine Vorwärtsauflösung des gefundenen Namens, und beide Ergebnisse müssen zusammenpassen - für die Suchmaschine von Google sind die zugelassenen Namensräume googlebot.com, google.com und googleusercontent.com (Google Search Central). Eine Regel, die allein auf der Kennung aufsetzt, sperrt erfahrungsgemäß die Ehrlichen und lässt die Getarnten durch.
Aussteuern in vier Stufen
Stufe 1: Die Ansage über robots.txt
Die robots.txt ist der günstigste Hebel und zugleich der am häufigsten überschätzte. Sie ist eine Ansage, keine Sperre: Wer sich daran hält, hält sich daran. Das Protokoll ist seit 2022 als RFC 9309 standardisiert und regelt auch Details, die im Alltag zählen - etwa, dass ein zwischengespeicherter Stand in der Regel nicht länger als 24 Stunden verwendet werden soll und dass die Parsegrenze mindestens 500 Kibibyte betragen muss (RFC 9309). Eine Änderung wirkt also nicht sofort, und eine sehr große Datei wird nicht zwangsläufig vollständig gelesen.
# Alle Aufrufer: Suchergebnisse, Warenkorb und Parameterfluten ausschließen
User-agent: *
Disallow: /suche
Disallow: /warenkorb
Disallow: /checkout
Disallow: /*?sort=
Disallow: /*?p=
Allow: /
# Einzelner Sammler mit bekannter Kennung: vollständiger Ausschluss
User-agent: <Kennung-des-Sammlers>
Disallow: /
Sitemap: https://www.example.invalid/sitemap.xmlFür Inhalte, die zum Training von Modellen ausgelesen werden, kommt eine zweite Ebene hinzu. Nach deutschem Recht ist Text und Data Mining an rechtmäßig zugänglichen Werken grundsätzlich zulässig, aber vorbehaltlich einer Erklärung des Rechteinhabers - und dieser Vorbehalt wirkt bei online zugänglichen Werken nur in maschinenlesbarer Form (§ 44b UrhG). Wie sich ein solcher Vorbehalt praktisch setzen lässt, steht ausführlich im Beitrag zum TDM-Vorbehalt; wer KI-Funktionen umgekehrt im eigenen Haus betreiben will, findet den Rahmen dafür unter KI-Funktionen ohne Datenabfluss.
Nutzungen nach Absatz 2 Satz 1 sind nur zulässig, wenn der Rechtsinhaber sich diese nicht vorbehalten hat. Ein Nutzungsvorbehalt bei online zugänglichen Werken ist nur dann wirksam, wenn er in maschinenlesbarer Form erfolgt.
§ 44b Absatz 3 Urheberrechtsgesetz
Was die robots.txt ausdrücklich nicht ist, steht im Standard selbst: Sie ersetzt keine Sicherheitsmaßnahme, und das Auflisten von Pfaden macht diese Pfade öffentlich auffindbar (RFC 9309, Abschnitt 3). Ein Administrationsbereich gehört deshalb hinter eine Anmeldung, nicht in eine Ausschlussliste. Wer beides verwechselt, veröffentlicht eine Wegbeschreibung zu genau den Pfaden, die er verbergen wollte.
Stufe 2: Frequenz begrenzen statt sperren
Die wirksamste Stufe im Alltag ist kein Ausschluss, sondern eine Obergrenze. Wer eine Frequenz je Adresse und je Pfadgruppe festlegt, lässt normale Nutzung unberührt und bremst genau das, was ein Sammler braucht: Tempo. Der Statuscode dafür ist seit 2012 standardisiert - 429 zeigt an, dass in einem gegebenen Zeitraum zu viele Anfragen gestellt wurden, und die Antwort darf einen Retry-After-Kopf mitgeben, der sagt, wie lange zu warten ist (RFC 6585).
# Zwei Zonen: Katalog großzügig, Suche und Warenkorb eng
limit_req_zone $binary_remote_addr zone=katalog:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=suche:10m rate=10r/m;
limit_req_status 429;
server {
location /produkt/ {
limit_req zone=katalog burst=20 nodelay;
add_header Retry-After 60 always;
}
location /suche {
limit_req zone=suche burst=5 nodelay;
add_header Retry-After 120 always;
}
}Drei Punkte aus dem Standard, die in der Praxis oft fehlen. Erstens dürfen Antworten mit 429 nicht zwischengespeichert werden - liefert ein vorgelagerter Cache sie doch aus, sperrt er unbeteiligte Besucher aus (RFC 6585). Zweitens sollte die Antwort erklären, worum es geht, und ein Retry-After mitgeben; ohne diese Angabe versucht ein ehrlicher Aufrufer es sofort wieder. Drittens ist niemand verpflichtet, überhaupt mit 429 zu antworten: Bei sehr vielen Anfragen aus einer Quelle kostet jede Antwort selbst Ressourcen, weshalb der Standard ausdrücklich auch das Schließen der Verbindung als angemessen nennt (RFC 6585, Abschnitt 7.2).
Stufe 3: Geschäftslogik schützen
Frequenzgrenzen helfen gegen Maße, nicht gegen Absicht. Gegen Warenkorb-Blockade und Schnellkauf wirkt nur die Logik selbst: Wie viele offene Warenkörbe eine Sitzung haben darf, wie lange eine Reservierung hält, wie viele Anmeldeversuche je Konto und je Adresse zulässig sind, ob die Bestandsanzeige eine exakte Stückzahl nennt oder nur eine Spanne. Dieselbe Logik schützt auch die Schnittstellen, über die ein Headless-Aufbau seine Daten liefert - dazu passt der Beitrag zur Absicherung der Store API. Wie sich das Verhalten unter Last verhält, klärt man vorher und nicht am Aktionstag; die Vorgehensweise steht im Beitrag zu Lasttest und Notfallplan.
- Reservierungsdauer im Warenkorb begrenzen und ablaufende Reservierungen automatisch freigeben.
- Obergrenze für offene Warenkörbe und für Positionen je Warenkorb setzen, gestaffelt nach Warengruppe.
- Anmeldeversuche je Konto und je Herkunftsadresse getrennt zählen und beide Zähler begrenzen.
- Bestandsanzeige bei knapper Ware auf eine Spanne umstellen, statt die exakte Stückzahl zu veröffentlichen.
- Schnittstellen mit eigenem Zugangsschlüssel, eigener Frequenzgrenze und eigener Protokollierung versehen.
- Checkout-Schritte serverseitig prüfen, statt sich auf die Reihenfolge im Browser zu verlassen.
Stufe 4: Die Messung sauber halten
Die letzte Stufe kostet am wenigsten und wird am häufigsten vergessen: Bot-Verkehr gehört getrennt ausgewiesen, nicht gelöscht. Wer ihn herausfiltert, verliert das Frühwarnsignal; wer ihn mitzählt, trifft Entscheidungen auf verschobenen Zahlen. Sinnvoll ist ein eigenes Segment mit eigener Zeitreihe, damit sichtbar bleibt, wann eine neue Quelle auftaucht. Für die Sichtbarkeit in Suchmaschinen zählt ohnehin ein anderer Blick auf dieselben Daten - was davon in die Suchmaschinenoptimierung gehört, ist die Frage, welche Seiten ein Crawler tatsächlich erreicht und wie oft.
Der rechtliche Rahmen in Deutschland
Ein systematisch abgezogener Katalog ist mehr als ein Ärgernis. Das Urheberrechtsgesetz räumt dem Datenbankhersteller das ausschließliche Recht ein, die Datenbank insgesamt oder einen nach Art oder Umfang wesentlichen Teil zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben; der wiederholten und systematischen Nutzung unwesentlicher Teile stellt das Gesetz die Nutzung eines wesentlichen Teils gleich, sofern sie einer normalen Auswertung zuwiderläuft oder die berechtigten Interessen unzumutbar beeinträchtigt (§ 87b UrhG). Ob ein konkreter Katalog diese Schwelle erreicht, ist eine Frage des Einzelfalls und gehört in die anwaltliche Prüfung; dieser Beitrag ersetzt sie nicht. Für die technische Seite lässt sich die Beratung davon trennen.
Umgekehrt stellt sich die Frage, ob die Auswertung des eigenen Protokolls zulässig ist, wenn dort IP-Adressen stehen. Die Datenschutz-Grundverordnung nennt die Verarbeitung personenbezogener Daten in dem Maße ein berechtigtes Interesse, wie sie für die Gewährleistung der Netz- und Informationssicherheit unbedingt notwendig und verhältnismäßig ist, und führt die Abwehr gezielter Serverüberlastung ausdrücklich als Beispiel an (Erwägungsgrund 49 DSGVO). In der Praxis heißt das: Zweck festhalten, Speicherdauer begrenzen, Zugriff auf die Protokolle einschränken und den Vorgang in das Verarbeitungsverzeichnis aufnehmen.
Was das im Betrieb heißt
Messen
Zugriffsprotokolle mit ausreichender Aufbewahrung, ein wiederkehrender Auswertungslauf und eine Ausgabe, die jemand liest. Ohne diesen Schritt ist jede weitere Maßnahme eine Vermutung.
Einsortieren
Bestätigte Suchmaschinen auf eine Ausnahmeliste, bekannte Sammler in eine eigene Gruppe, alles Übrige nach Verhalten bewerten. Die Kennung allein entscheidet nichts.
Drosseln
Frequenzgrenzen je Pfadgruppe statt einer globalen Regel, 429 mit Retry-After statt stiller Verbindungsabbrüche, Ausnahmen für Zahlungs- und Versandschnittstellen.
Nachhalten
Eine Zeitreihe je Segment zeigt, wann eine neue Quelle auftaucht und ob eine Maßnahme gewirkt hat. Ohne Vorher-Wert bleibt die Wirkung eine Behauptung.
Der teuerste Weg beginnt mit einer Sperrliste. Sie erzeugt Aufwand, sperrt Kundschaft aus und verfehlt getarnte Zugriffe, weil diese die Kennung wechseln. Der günstige Weg beginnt mit einer Messung, die zwei Wochen läuft und danach beantwortet, welcher Anteil des Verkehrs automatisiert ist, woher er kommt und was er abruft. Erst darauf folgen Grenzwerte - und die erste Grenze wird erfahrungsgemäß großzügiger gesetzt, als es sich richtig anfühlt, und dann anhand der Messung nachgezogen.
Die Verkehrsanteile stammen aus dem Bad Bot Report 2026 von Thales (Auswertung des vollen Jahres 2025) und aus dem Bad Bot Report 2025 von Imperva für das Jahr 2024. Die Einordnung der Angriffsarten folgt der OWASP-Systematik Automated Threats to Web Applications (OAT-005, OAT-011, OAT-016, OAT-021). Die technischen Festlegungen stehen in RFC 9309 (Robots Exclusion Protocol) und RFC 6585 (Statuscode 429). Die rechtlichen Aussagen beruhen auf § 87b und § 44b Urheberrechtsgesetz sowie Erwägungsgrund 49 der Datenschutz-Grundverordnung; das Verfahren zur Bestätigung von Suchmaschinen-Zugriffen ist in der Dokumentation von Google Search Central beschrieben. Alle Angaben wurden am 5. September 2026 an der Quelle geprüft.
Dafür gibt es keine belastbare öffentliche Zahl. Die verbreiteten Werte - 53 Prozent des gesamten Verkehrs automatisiert, davon 40 Prozentpunkte als schädlich eingestuft (Thales Bad Bot Report 2026) - beschreiben einen weltweiten Durchschnitt über alle Branchen hinweg, nicht den deutschen Handel. Der eigene Anteil lässt sich typischerweise binnen zwei Wochen aus dem Zugriffsprotokoll bestimmen, und die Spannweite zwischen einzelnen Shops ist erfahrungsgemäß groß. Wie die Protokolle dafür vorgehalten werden, gehört zur Frage des Hostings.
In der Regel nicht. Die robots.txt ist eine Ansage an Aufrufer, die sich freiwillig daran halten; der Standard selbst hält fest, dass sie keine gültige Sicherheitsmaßnahme ersetzt und aufgelistete Pfade öffentlich auffindbar macht (RFC 9309). Sie ist trotzdem der richtige erste Schritt, weil sie erwünschte Crawler steuert und die Grundlage für einen maschinenlesbaren Nutzungsvorbehalt bildet. Gegen Aufrufer, die sie ignorieren, wirken erst Frequenzgrenzen und Schutz in der Geschäftslogik.
Das kann vorkommen, und zwar typischerweise dort, wo viele Menschen hinter einer Adresse sitzen: Firmennetze, Mobilfunk, Hochschulen, Datenschutz-Weiterleitungen. Deshalb wird die Grenze je Pfadgruppe gesetzt statt global, großzügig begonnen und anhand der Messung nachgezogen. Wichtig ist die richtige Antwort: 429 mit einem Retry-After-Kopf, damit ein ehrlicher Aufrufer weiß, wann er es erneut versuchen kann (RFC 6585). Ein stiller Verbindungsabbruch sieht für den Kunden wie ein Ausfall aus.
Nicht an der Kennung - die ist frei wählbar. Belastbar ist die doppelte Auflösung: erst eine Rückwärtsauflösung der zugreifenden Adresse, dann eine Vorwärtsauflösung des dabei gefundenen Namens, und beide Ergebnisse müssen übereinstimmen. Für Google sind die zugelassenen Namensräume googlebot.com, google.com und googleusercontent.com (Google Search Central). Für den laufenden Betrieb lässt sich diese Prüfung in die Auswertung einbauen, statt sie von Hand zu fahren - das ist ein kleiner Baustein in der Programmierung.
Die Datenschutz-Grundverordnung sieht die Verarbeitung personenbezogener Daten in dem Maße als berechtigtes Interesse an, wie sie für die Netz- und Informationssicherheit unbedingt notwendig und verhältnismäßig ist, und nennt die Abwehr gezielter Serverüberlastung ausdrücklich als Beispiel (Erwägungsgrund 49 DSGVO). In der Praxis heißt das: Zweck festhalten, Speicherdauer begrenzen, Zugriff einschränken, Eintrag im Verarbeitungsverzeichnis. Die Bewertung des Einzelfalls gehört in die rechtliche Prüfung; dieser Beitrag ersetzt sie nicht.
Das hängt davon ab, wie weit die vier Stufen bereits vorhanden sind. Messung und robots.txt sind typischerweise eine Frage von Stunden, Frequenzgrenzen von einem Tag, der Schutz der Geschäftslogik dagegen von der Bauart des Shops - Warenkorb, Reservierung und Checkout müssen dafür angefasst werden. Sinnvoll ist es, in dieser Reihenfolge vorzugehen und nach jeder Stufe erneut zu messen, statt alles gleichzeitig zu ändern. Für eine Einschätzung des eigenen Falls reicht ein kurzes Gespräch, siehe Kontakt.