Bad Bots blocken oder nicht?

Mirlo

Lt. Junior Grade
Registriert
Feb. 2025
Beiträge
500
Weils derzeit mit dem "KI-Firmen kaufen antiquarische Bücher fürs KI-Trainig" wieder einmal die Runde macht:

Wie siehst du das mit dem Blocken von Bad Bots? Es gibt für sowohl als auch Argumente. Ja/Nein?

Mir war es lange Zeit egal. Jetzt nicht mehr. Dabei habe ich etwas interessantes herausgefunden:

ChatGPT:
Ich greife nicht direkt wie ein Browser auf jede Website zu. Für Webanfragen nutze ich einen Such- und Abrufdienst, der Suchergebnisse und zwischengespeicherte Inhalte bereitstellt.

Bei einer Suche nach example.de liefert der Abrufdienst keinen Treffer für die Domain selbst, sondern nur andere Inhalte mit ähnlichem Namen (example.in, example.ai). Es gibt daher keinen Datensatz für example.de, den ich auslesen könnte.

Der von mir verwendete Such-/Abrufdienst kann Ergebnisse fehlen lassen oder anders priorisieren.

Das bedeutet also, dass der Wandel von Suchmaschinen hin zu KI Chatbots auch bedeutet, dass Content herausgefiltert wird. Dadurch sind Websites gar nicht mehr auffindbar. Stattdessen werden alternativ andere Websites vorgeschlagen. Während bisherige Suchmaschinen alles indexierten und in den Suchergebnissen listeten, "priorisiert" KI für den Menschen vor. Viele wollen das sogar so. Sie wollen auf jede ihrer Fragen nur eine mögliche Antwort. Alles andere wird ausgeblendet und existiere nicht.
 
Was indiziert werden soll nicht blocken und blocken, was nicht indiziert werden soll
 
Mirlo schrieb:
Das ist irreführend bis falsch, wie LLM-Output es häufig ist.

a) Trainingsdaten werden gar nicht "live" vom LLM geholt, sondern von einem anderen Crawler und dann eben für das Training des LLM benutzt. Das LLM selbst "weiß" von dem Prozess aber gar nichts.

b) Live-Anfragen ("Chat") kann vom Anbieter so konfiguriert werden, dass keine Websuche erlaubt wird. Dann zitiert das LLM "aus dem Gedächtnis" (= etwas verwaschene Trainingsdaten; daher kommen die Halluzinationen).

c) Während des Chats kann die Websuche auch sozusagen virtuell angeschaltet sein. Will das LLM auf die Suche zugreifen, wird die aber nicht tatsächlich ausgeführt, sondern nur aus einer großen anbieterseitigen Datenbank "irgendwie" beantwortet. Günstig für den Anbieter zu implementieren und schnell. Zweifelhafte Ergebnisse. Vermutlich das, was oben von ChatGPT größtenteils gemeint ist.

d) Es wird dem LLM tatsächlich Live-Websuche erlaubt (bei z.B. Claude Code sind das die "WebRequest"-Ausgaben). Die passieren dann auf Anbieterseite (unzuverlässig da einfach zu blocken) oder auf Client-Seite (bei Claude Code zum Beispiel).

Ob man als eigener Web-Anbieter blocken soll oder nicht, muss man selbst wissen oder (bei einem Forum) die Benutzer fragen, ob sie es wollen. Hat nunmal Vor- und Nachteile.
 
  • Gefällt mir
Reaktionen: Drahminedum
Ergänzend zu dem was @GrumpyCat geschrieben hat: viele Besitzer von grösseren Foren haben gar keine Wahl mehr als zu blocken, wenn sonst zehntausende (!) Bots gleichzeitig das Forum beackern.
 
Auf der anderen Seite können die Modelle auch echte live Anfragen starten. Sie verwenden dann aber oft die APIs - bekommen das JSON und nicht HTML.
Das passiert wen du ihm sagst er soll recherchieren oder "googeln". Welche Informationen der Bot woher bekommt ist tatsächlich ziemlich unterschiedlich.
 
Die Sache mit dem Blocken kann auch daneben gehen, indem Humans ausgesperrt werden, oder anders gesehen, die eigene Website so gesehen offline genommen wird.

Es gibt aber Firmen, die sowohl Cable/DSL/Cellular als auch Serverdienste anbieten, auf denen Bots gehostet werden (können), die wiederum nicht als Bots zu erkennen sind. Es gibt zwar exakte (Pay-) Datenbanken, mittels denen zwischen beiden unterschieden werden kann, aber die sind teuer, oder die Firmen unterscheiden ihre IPs absichtlich nicht zwischen beidem. Hier ist die Frage, wie konsequent sollte geblockt werden? Die eine Seite sagt: Entweder ihr gebt eure Bots zu erkennen, oder ihr werdet komplett geblockt, womit eure IPs nichts mehr wert sind und keiner mehr bei euch einen Vertrag über Cable/DSL/Cellular abschließt. Die andere Seite sagt: Aber ich bin zu klein, als das ich durch mein Blocken irgendetwas erreichen könnte. Stattdessen wird meine Seite deswegen möglicherweise upgerankt, oder wie seit KI komplett rausgerankt.

Das Blocken können sich - mal wieder - nur die Großen leisten. Die Kleinen bleiben - mal wieder - auf der Strecke. Einen Zusammenhalt zwischen den Kleinen gibt es nicht, der eine Schwarm-Wirkung haben könnte: Entweder Bots erkennbar machen, oder komplett blocken. Konsequent.

Dazu muss beachtet werden: Dass Bots nicht erkennbar werden, hat seinen Grund darin, dass Betrüger-Websites den Bots anderen Content als den Humans auslieferten. Die sind an der Misére schuld.

Diejenigen Websites, die bei der DSGVO ihre Schotten dicht gemacht hatten, also Content nur nach LogIn, sind jetzt im Vorteil. Die blocken Bots bereits seitdem. So gesehen ist es also vernünftig Bots konsequent zu blocken. Wenn es auch Humans erwischt, dann sollen sie sich einen anderen Provider suchen, bei dem keine Bad Bots gehostet werden (können). Bots erkennbar machen, oder ihr werdet geblockt.
 
Drahminedum schrieb:
Ergänzend zu dem was @GrumpyCat geschrieben hat: viele Besitzer von grösseren Foren haben gar keine Wahl mehr als zu blocken, wenn sonst zehntausende (!) Bots gleichzeitig das Forum beackern.
Ich betreibe eine größere Plattform und nein, das ist mit ein paar Kniffen kein Problem. Durchdrehende Crawler hat es schon immer gegeben (z.B. hat Bing früher gerne tausende Zugriffe pro Minute gemacht).

Ganz einfach: Priorität haben eingeloggte Benutzer, dann anonyme Zugriffe auf aktuelle Inhalte (alles sowieso im Cache), und alles andere nur, wenn die Server-Last es zulässt.

Das natürlich zusätzlich zum üblichen Crawling-Schutz (Rate Limiting für alle), weil auch eingeloggte Benutzer häufiger Unsinn machen (z.B. wollen hier die Leute ständig einen Komplettabzug der Seite machen unter ihrem Login, was auch grundsätzlich nicht verboten ist, aber bitte nicht mit 5000 Requests pro Minute).
 
  • Gefällt mir
Reaktionen: madmax2010
Oder man schaltet etwas wie https://anubis.techaro.lol/ vor. Ganz einfach gesagt, challenges die der Client berechnen muss um auf die Seite zu kommen.

Klar gibt es Crawler die auch diese Challenges berechnen, aber wenn dann soll es sie Rechenleistung kosten :)
 
Zuletzt bearbeitet:
Anubis ist bestenfalls eine Notlösung, schon alleine weil z.B. auch Google geblockt wird, es auch menschliche Benutzer nervt und Zeit und Energie verschwendet. Bei dem Community-Ding bei mir würden mit Anubis auch haufenweise Integrationen mit anderen Webseiten kaputtgehen.

Letztendlich müssen die jeweiligen Softwares (also Foren/Wikis/...) früher oder später die entsprechenden Features selbst mitbringen. Ist doch lächerlich, dass die allermeiste Software z.B. die Last auf dem Server überhaupt nicht beachtet und auch stumpf alle Anfragen gleich priorisiert, egal ob offensichtlicher Bot oder langjähriger authentifizierter Benutzer.
 
Zuletzt bearbeitet:
GrumpyCat schrieb:
Anubis ist bestenfalls eine Notlösung, schon alleine weil z.B. auch Google geblockt wird, es auch menschliche Benutzer nervt und Zeit und Energie verschwendet
Die Integrationen, Google Analytics und co. müssen natürlich konfiguriert werden. Ist alles machbar.
Denke jedoch nicht das es die Enduser gross stört, sie müssen ja nicht damit interagieren, sie sehen es nur kurz, solange der Token nicht abgelaufen ist.

Mit einem Loadbalancer noch prüfen ob ein User eingeloggt ist und Anzahl Requests limitieren (http 429, 5 request pro Sekunde) und man ist schon mal besser abgesichert. Ich persönlich würde lieber einen zusärzlichen Service davor schalten anstatt dies direkt z.B. in der Forensoftware zu packen.

Wenn ich ein Hoster wählen müsste, würde ich nach genau solchen Kriterien suchen und wenns wichtig ist dazu buchen.
 
GrumpyCat schrieb:
Letztendlich müssen die jeweiligen Softwares (also Foren/Wikis/...) früher oder später die entsprechenden Features selbst mitbringen
Die meisten weigern sich beharrlich und argumentieren, das wäre Aufgabe des Serverbetreibers.
 
dasBaum_CH schrieb:
Google Analytics und co. müssen natürlich konfiguriert werden.
Oder halt rauswerfen statt die Besucher ans Messer (Google) zu liefern.
Ich check den Sinn solcher Tools eh nicht. All das was an on-Site-Daten gesammelt werden kann, hat man doch als Serverbetreiber sowieso. Wozu also noch einen externen Dienst einbinden?
 
  • Gefällt mir
Reaktionen: dasBaum_CH und Drahminedum
Drahminedum schrieb:
Die meisten weigern sich beharrlich und argumentieren, das wäre Aufgabe des Serverbetreibers.
Nur die eigentliche Software kann die Priorisierung sinnvoll vornehmen. Der Admin oder auch nur der Webserver an sich kann ja nicht wissen, welche Verbindung wie wichtig ist.

Manche Software ist von sich aus halbwegs sinnvoll gestaltet (z.B. sind bei MediaWiki alle URLs ohne Query Parameter schnell zu erzeugen; die mit Parametern irgendwie "speziell" und für Crawler unwichtig); manche eher nicht (z.B. die meiste Forensoftware, die ist meistens eher schlecht programmiert).
 
Drahminedum schrieb:
Die meisten weigern sich beharrlich und argumentieren, das wäre Aufgabe des Serverbetreibers.
Ich war auch lange Zeit dieser Ansicht und hatte sehr lange damit gehadert Bots komplett zu blocken und hatte sie nur nicht getrackt. Nachdem mir bekannt wurde, dass Bots zwar meinen Content crawlen und diesen fürs KI-Training, aber nicht für Antworten an KI-User verwenden, war die Entscheidung gefallen, Bots komplett zu blocken. Durch das Blocken von Bots beim Tracking war schon einiges an Code dafür vorhanden. Allerdings muss beim kompletten Blocken zwischen Good Bot und Bad Bot unterschieden werden, was beim Tracking nicht notwendig ist.

dasBaum_CH schrieb:
Ganz einfach gesagt, challenges die der Client berechnen muss um auf die Seite zu kommen.
Das hatte ich auch getestet, mit simplen Buttons-Klick like Cookie-Consent. Umso mehr Buttons geklickt werden müssen, umso weniger Websitebesuche. Einer ist zu wenig, drei sind zu viel. Die Humans springen bei zuvielen Buttons ab. Aber einige Bots können Buttons klicken. Das ist also keine Lösung.

Es gibt ab und an immer wieder Berichte, dass Bots die neuesten Captchas knacken können.

:::

Die User von Tracking-Software - ob eigene oder von der Stange - sind am Blocken von Bots interessiert. Sie wollen nur Humans tracken. Es ist dabei der Unterschied zu beachten, dass beim kompletten Blocken zwischen Good Bot und Bad Bot unterschieden werden muss. Es gibt Listen von Good Bots im Internet. Da kann sich jeder selbst aussuchen, was er nicht blocken will. Google, Bing, Yandex, Baidu ... SEO, Security, Services, ...

Die Big 5 Cloud Anbieter bieten ihre IP/CIDR als Listen an. Diese können zu MaxMind Datenbanken (mmdb) konvertiert und genutzt werden.

Per IP- oder CIDR-Listen blocken ist ansonsten eher unpraktisch. Es gibt Anbieter von IP to ISP und IP to ASN Datenbanken. Damit kann per ISP/ASN Name (Firmenname) geblockt werden. Leider sind die qualitativ besseren Datenbanken Pay.

Es bräuchte eine gesetzliche Regelung, dass Bots als solche erkennbar sein müssen. Betreiber von nicht erkennbaren Bots mit Strafen belegen. Dann wäre die Sache eindeutig. Aber es gibt auch Zweifel daran, ob das eine gute Lösung wäre.
Ergänzung ()

dasBaum_CH schrieb:
Wenn ich ein Hoster wählen müsste, würde ich nach genau solchen Kriterien suchen und wenns wichtig ist dazu buchen.
Da begibst du dich in eine Abhängigkeit zum Hoster. Die bessere Lösung ist, die Bots per PHP zu blocken. Da kannst du den Hoster wechseln wann du willst.

Wichtig beim komplett blocken ist: Die Bots müssen exakt 0 kb Content als Antwort bekommen. Jede andere Antwort ist für sie Futter. Wenn Informationen gesendet werden, dann ein HTTP Statuscode 451.
451Unavailable For Legal ReasonsDieser Statuscode soll darauf hinweisen, dass die angeforderte Ressource aufgrund von gesetzlichen Bestimmungen (Copyrighteinschränkungen, Zensur etc., eventuell beschränkt auf ein bestimmtes Land) nicht verfügbar ist.
Er wurde im Juni 2012 von Google-Mitarbeiter Tim Bray bei der IETF eingereicht und gilt seit dem 17. Dezember 2015 als angenommen. Bray schlug die Nummer 451 in Anspielung auf Ray Bradburys Roman Fahrenheit 451 vor und fügte einen Dank an den Autor an.
 
Zuletzt bearbeitet:
Mirlo schrieb:
Das hatte ich auch getestet, mit simplen Buttons-Klick like Cookie-Consent. Umso mehr Buttons geklickt werden müssen, umso weniger Websitebesuche.
Passiert automatisch. Musst nichts klicken oder manuell eingeben. Einem Endanwender fällt das gar nicht mal so stark auf. Ziel ist es auch unter anderem den Crawler unnötige Rechenleistung zu stehlen.

Im HTTP Header kann man ja auch authorisierte User erkennen und grössere rate-limiten setzen.
Bisschen HAProxy mit lua script, anubis und webserver access logs immer im Blick haben. Alles mit opensource tools und selfhosted realisierbar (wenn es nichts, ausser die eigene Zeit, kosten darf).
 
Zurück
Oben