20 Prozent aller „OK“-Webantworten, die eine KI erhält, sind nicht in Ordnung

Meine jüngsten Experimente mit KI-gestütztem Web-Scraping haben mir deutlich vor Augen geführt, wie sehr das Web zunehmend abgeschottet wird. Der Auslöser für diesen Rückzug ist natürlich das rasante Wachstum des KI-Web-Scrapings, dessen unermüdlicher Bedarf an neuen Daten dazu führen kann, dass Domains offline gehen.

Das ist für Domains ein guter Anlass, das zu tun, was viele von ihnen schon lange wollten: ihre Inhalte nur angemeldeten Nutzern zugänglich zu machen (wobei Googlebot in der Regel freie Bahn hat). Facebook schloss die schrittweise Einführung dieser Richtlinie im Jahr 2023 ab, und Twitter/X tat es im selben Jahr. Reddit wird sie noch im Laufe dieses Monats einführen.

Auf diese Weise wird es für die Domain etwas einfacher, die länderspezifischen Vorschriften zur Durchsetzung von Altersbeschränkungen einzuhalten, da der Nutzer bereits registriert ist. Noch wichtiger ist, dass die Daten des Nutzers gespeichert, für lokale Analysen ausgewertet und – sofern die lokale Gesetzgebung dies zulässt – an Datenhändler und KI-Unternehmen verkauft werden können.

Andernorts sind Maßnahmen, die gezielt der Abwehr von Bots (statt der Registrierung von Nutzern) dienen, laut Cloudflare im Jahresvergleich um mehr als 58 % gestiegen; und all diese zunehmenden Bot-Aktivitäten veranlassen Websites naturgemäß dazu, genauer zu prüfen, VPN- und Proxy-Adressen möglicherweise ebenso wie jeglichem „bösartigen“ Datenverkehr den Zugang zu verweigern.

Aus eigener Erfahrung kann ich sagen, dass ich immer häufiger auf „blockierende“ Antworten oder Prüfungen stoße – so sehr, dass ich eine Website womöglich sogar verlasse, sobald sie damit beginnt, solche Inhalte zu laden. Da CAPTCHA-Wände nachweislich dazu führen, dass Nutzer und potenzielle Kunden abgeschreckt werden, kann man sich vorstellen, welcher Druck Domainbetreiber dazu bewegt, sie trotz dieses Nachteils einzusetzen.

Ein CAPTCHA von archive.is, einer der vielen Websites, die Prüfungen eingeführt haben – häufig als Reaktion auf eine übermäßige Zahl automatisierter (statt menschlicher) Anfragen.

All diese neuen und verstärkten Hürden sind teilweise logistischer Natur (weil nicht alle Domains dem Ansturm standhalten können), dienen aber oft auch als eine Art Verhandlungstaktik: Man will herausfinden, ob KI-Unternehmen bereit sind, für all die Daten, nach denen sie sich so sehr sehnen und die so lange kostenlos verfügbar waren, nun eine individuelle oder gemeinschaftliche Vergütung anzubieten.

Da KI-Crawler in großem Maßstab arbeiten müssen, verwenden sie unter dem Framework Playwright häufig „headless“ Chrome-Instanzen. Bei immer mehr Domains erhält man damit heutzutage eine 403-Fehlermeldung („verboten“) (das heißt: Der Host erkennt den automatisierten Datenverkehr und weist ihn ab):

Eine lokale Installation von changedetection.io versucht, eine Website regelmäßig abzufragen. Die Website akzeptiert jedoch den vom Framework verwendeten erkannten Browser nicht und antwortet mit dem Statuscode 403 („Forbidden“).

Erwünscht ist die Client-Antwort „200“ („OK“) – selbst wenn man dafür einem Netzwerk aus Residential-Proxys einen Haufen Geld zahlen und zusätzlich eine Reihe unterschiedlicher heimlicher Tricks anwenden muss, um sie zu erhalten.

Nichts ist besser als die Antwort 200 – das heißt, es gibt keinen Client-Antwortcode mit einem stärkeren positiven Signal. Sie ist auch nicht mehrdeutig: Sie bedeutet nie „fast in Ordnung“, „später in Ordnung“ oder „immer mehr in Ordnung“, sondern „in Ordnung!“. Wenn etwas nicht in Ordnung ist, lautet die Antwort nicht 200.

Hallo! Verschwinde!

Diese mangelnde Differenzierung könnte laut einer neuen Studie jedoch dazu führen, dass KI-Datensätze, statistische Schätzungen und die Meldung eines „guten“ Status erheblich verzerrt werden, obwohl dies nicht der Fall ist.

Die Studie* schätzt, dass rund ein Fünftel der Antworten der Kategorie 200 überhaupt keine brauchbaren Seiteninhalte enthält, sondern leere Website-Gerüste, CAPTCHA-Prüfungen, Zugangsbeschränkungen oder Ersatzseiten ausliefert.

In der Studie heißt es:

„20,9 % der Seiten, die ein statischer Client mit dem Status 200 erhält, enthalten nicht den Hauptinhalt der Seite: App-Gerüste, Bot-Prüfungen, Sperrseiten, Fehler- und Platzhalterseiten sowie unvollständige Inhalte.“

In dieser Hinsicht scheitern ungeduldige automatisierte Systeme an ihrer eigenen Beschränktheit: Die Antwort „200“ darf mit einem erfolgreichen Abruf gleichgesetzt werden, selbst wenn der Abruf lediglich eine CAPTCHA-Wand, eine Bezahlschranke oder ein anderes Hindernis liefert.

Die Studie beschreibt sieben Arten von Inhalten, die häufig eine Antwort 200 problematisch machen:

Die sieben Inhaltskategorien, die bei einer Antwort 200 alles andere als „in Ordnung“ sind. Quelle

Für die Studie wurden über drei Tage hinweg 10.307 Webadressen mit einem einfachen Web-Abrufprogramm und einem Browser getestet, der JavaScript ausführen kann. Die Antworten wurden anhand der abgerufenen Inhalte klassifiziert, nicht anhand ihrer HTTP-Statuscodes.

Die größten Kategorien „unbrauchbarer“ 202-Antworten waren leere Website-Gerüste sowie Fehler- oder Ersatzseiten, auf die zusammen mehr als zwei Drittel der Fehlschläge entfielen.

Bei leeren Website-Gerüsten kann es vorkommen, dass eine Website zwar ihre Menüs und Navigation anzeigt, den angeforderten Artikel oder die Produktliste jedoch leer lässt. Im zweiten Fall kann statt der angeforderten Inhalte eine themenfremde Seite oder die Startseite erscheinen. Beide Fälle können dennoch denselben HTTP-Statuscode 200 erhalten wie ein erfolgreicher Abruf mit brauchbaren und nützlichen Inhalten.

Als Abhilfe empfiehlt die Studie, dass Web-Abrufprogramme melden, was tatsächlich abgerufen wurde, statt sich auf HTTP-Statuscodes zu verlassen. Einfache Prüfungen auf ungewöhnlich kurze Seiten, verdächtige Weiterleitungen und Inhalte, die nicht existierenden Seiten ähneln, könnten die meisten Fehlschläge erkennen.

Aufwendigere Browser-Tools könnten dann nur eingesetzt werden, wenn eine Seite offenbar nicht korrekt geladen wurde. Außerdem könnten KI-Auswertungen prüfen, ob zitierte Quellen die erwarteten Informationen tatsächlich enthalten, statt anzunehmen, dass eine HTTP-200-Antwort bedeutet, der Inhalt sei erfolgreich abgerufen worden.

Der Autor der neuen Arbeit merkt zudem an, dass sich mit „einfachen Heuristiken“ rund 86 % der unbrauchbaren Antworten mühelos erkennen lassen, indem grundlegende Prüfungen zur Seitenlänge, zu Weiterleitungen und zu Ähnlichkeiten mit nicht existierenden Seiten vorgenommen werden:

Vergleich von Strategien für den Web-Abruf: Das Rendern ausschließlich als verdächtig eingestufter Seiten erschloss etwas mehr brauchbare Inhalte (81,4 %) als das Rendern aller Seiten (80,3 %), während sich die durchschnittliche Abrufzeit von 20,6 auf 5,8 Sekunden pro Seite verringerte. 

Warum gibt es so viele fehlerhafte 200-Antworten?

In Entwickler-Communitys wurde im Laufe der Jahre bisweilen darüber diskutiert, ob der 202-Fehler („Accepted“ – „Anfrage angenommen, aber noch nicht abgeschlossen“; „Anfrage angenommen, aber noch nicht abgeschlossen“) solche „fehlgeschlagenen“ Anfragen mit Status 200 eindeutig kennzeichnen könnte. Tatsächlich kann 202 jedoch nicht alle in der neuen Studie beschriebenen Fälle abdecken, und es gibt keinen bestehenden Statuscode, der das könnte.

Obwohl die Studie diesem Thema nicht ausführlich nachgeht, könnte der Grund dafür, dass Domaininhaber 200-Fehler zulassen, in künftigen verwandten Arbeiten näher untersucht werden.

Ein Grund könnte sein, dass alles, was keinen Status 200 hat, im Grunde eine Art Fehlerseite oder Hindernis darstellt, darunter der häufigste Fall: 404-Fehler („nicht gefunden“) – bei denen die gesuchten Inhalte schlicht fehlen. Manche glauben, dass eine übermäßige Zahl solcher Fehler zu SEO-Abstrafungen (und vermutlich auch zu GEO-Abstrafungen) führt, doch Google bestreitet das.

Tatsächlich betrachtet Google fehlerhafte 200-Antworten als „Soft-404-Fehler“. Offensichtlich dürften sie als problematischer gelten als gewöhnliche 404-Fehler, da es sich im Grunde um „irreführende“ Ergebnisse handelt – ob absichtlich oder nicht.

Zitierdrift

Wenn das alles nach Haarspalterei klingt, sollte man den Petabyte-Umfang der Daten bedenken, die routinemäßig für das Training von KI gesammelt werden (oder gesammelt werden sollen). Wenn ein volles Fünftel dieser Daten unzuverlässig oder offen irreführend ist, lassen sich die nachgelagerten Folgen kaum als eine Art „Kollateralungenauigkeit“ abtun. Solche falschen Antworten könnten vielmehr die Verteilung in Datensätzen und die Ergebnisse des Trainings von KI-Modellen erheblich und nachteilig beeinflussen.

Ein bemerkenswertes Problem im Zusammenhang mit fehlerhaften 200-Antworten ist beispielsweise die „Zitierdrift“: Dabei wird eine von einer KI generierte Antwort nicht mehr durch die Webseite gestützt, die ursprünglich als Beleg zitiert wurde. Das kann etwa daran liegen, dass sich die Seite geändert hat, der relevante Text entfernt wurde oder der Link inzwischen an eine andere Stelle führt.

Die neue Studie ergab, dass die scheinbare Zitierdrift von 5,8 % auf 21,9 % anstieg, wenn alle HTTP-200-Antworten als erfolgreiche Abrufe gewertet wurden – unabhängig davon, was sie enthielten.

Das bedeutet, dass fälschlicherweise der Eindruck entstehen könnte, eine Quelle habe sich geändert, sei verschwunden oder stütze eine von einer KI generierte Behauptung nicht mehr – nur weil anstelle des ursprünglichen Materials ein CAPTCHA, eine leere Seite oder ein anderes Hindernis abgerufen wurde.

Behaupten Sie einfach, es sei so!

Das Problem zeigte sich auch bei Tests mit absichtlich nicht existierenden Webadressen. Wenn zufällige, erfundene Pfade bei Websites angefragt wurden, gaben 13,1 % der antwortenden Websites den Status 200 („OK“) zurück, obwohl die angeforderten Seiten nicht existierten^†.

„13,1 % der Websites, die auf die Abfrage mit zufälligen Pfaden antworteten, gaben den Status 200 zurück (S1 10,5 %, S2 13,3 %, S3 17,3 %, S4 13,7 %, S5 13,1 %). Jede dieser Antworten ist definitionsgemäß ein Soft-404-Fehler, aber nicht jede weist darauf hin.“

„Bei einer explorativen Aufschlüsselung der 172 Soft-404-Antworten stufte die annotierende Person 98 als Fehler- oder Ersatzseite, 32 als leere Hülle und 28 als Inhalte ein: Eine an einem zufälligen Pfad ausgelieferte Startseite oder Auflistung wirkt wie eine normale Seite.“

Fazit

Würde das Problem auf einer höheren Ebene erkannt, könnte die IANA möglicherweise einen neuen und besser geeigneten HTTP-Statuscode einführen, etwa [X] („Anfrage erfolgreich, aber der angeforderte Inhalt wurde nicht ausgeliefert“). Das würde zwar tatsächlich beschreiben, was passiert, würde aber naturgemäß ein unwahrscheinliches Maß an Einblick in die Transaktion aufseiten des Hosts voraussetzen.

Ähnliche Codes gibt es bereits, doch keiner passt wirklich: 451 („Aus rechtlichen Gründen nicht verfügbar“) ist mehrdeutig und ziemlich beunruhigend (!); 206 („Teilinhalt“) ist technisch passend, aber für unvollständige Daten (Abrufe) vorgesehen; und der überraschenderweise tatsächlich existierende Code 203 („Nicht autoritative Informationen“), der 1997 eingeführt wurde, ist für den vorliegenden Anwendungsfall nur von nebensächlicher Bedeutung.

Der naheliegendste Kandidat ist vielleicht tatsächlich der wenig intuitiv benannte Code 103 („Frühe Hinweise“), der anzeigt, dass noch nicht alle Ressourcen der URL geladen sind (auch wenn dies eindeutig eine grobe Fehlinterpretation der eigentlichen Bedeutung des Codes wäre).

* Mit dem Titel „Wenn 200 OK keine Antwort ist: Stille Abruffehler bei der agentenbasierten Erfassung von Webinhalten.“ Bitte beachten Sie, dass die Arbeit offenbar in erster Linie maschinenlesbar verfasst ist, möglicherweise damit eine KI sie abfragen kann, und auch an sich nicht leicht zu lesen ist.

^† Ich entschuldige mich für das mechanistisch klingende Zitat, aber wie oben erwähnt ist die gesamte Arbeit auf diese Weise verfasst, damit sie „maschinenlesbar“ statt für Menschen verständlich ist, auch wenn sie nicht ganz im JSON-Format vorliegt.

Erstmals veröffentlicht am Mittwoch, 4. November 2026