Jedes Scraping-Dashboard hat eine Erfolgsquote, und fast jedes zählt dasselbe: Antworten mit einem HTTP 200. Es ist eine Zahl, die sich leicht erheben lässt und die sich beruhigend berichten lässt. Sie ist auch die irreführendste Zahl in der Web-Datenerhebung, denn ein 200 bedeutet nur, dass ein Server etwas zurückgeschickt hat. Es sagt nichts darüber aus, ob dieses Etwas die angeforderte Seite war.
Die Lücke zwischen diesen beiden Dingen ist die stille Fehlerquote: der Anteil “erfolgreicher” Anfragen, die den falschen Inhalt zurückgeliefert haben. Es ist der Fehler, den man in den Logs nicht sieht, und er landet in den Daten und sieht dabei aus wie gute Daten.
Wie groß ist sie also? Die ehrliche Antwort lautet, dass niemand sie veröffentlicht hat. Dieses Fehlen erweist sich als die interessanteste Erkenntnis, und der Rest dieses Beitrags behandelt, warum es dazu kommt, was die nahegelegenen Messungen tatsächlich zeigen und wie man die eigene Quote misst.
Die wichtigsten Erkenntnisse
- Keine veröffentlichte Studie misst, welcher Anteil der HTTP-200-Antworten im gesamten Web den falschen Inhalt trägt. Die jüngste große Studie zur Bot-Blockierung hält schriftlich fest, dass Inhaltsverschlechterung innerhalb von 200-Antworten außerhalb ihres Untersuchungsbereichs lag.
- Blockierung ist verbreitet und schlecht gekennzeichnet. Eine Studie zu Common Crawl fand mindestens 1,68% der Seiten, die den Crawler explizit ablehnten, mit einer inkonsistenten und sogar fehlerhaften Verwendung von Statuscodes.
- Blockseiten kommen tatsächlich als 200er an. Bei einer Messung aus Kuba im Jahr 2023 taten dies 32 der 395 Domains, die eine Blockseite auslieferten, mit einem 200-Status.
- Große Studien zur Link-Verrottung zählen weiche 404-Seiten als lebendig, weil das Prüfen von Inhalten weit schwerer ist als das Prüfen von Statuscodes.
- Die eigene stille Fehlerquote lässt sich messen, aber nur durch die Validierung von Inhalten, nicht von Status.
Was als stiller Fehler gilt
Ein stiller Fehler ist jede Antwort, die Erfolg meldet und nicht das enthält, was ein echter Besucher erhalten hätte. Die häufigen Formen:
| Form | Was man erhält | Warum es als Erfolg durchgeht |
|---|---|---|
| Blockseite als 200 ausgeliefert | Eine Ablehnungsmeldung dort, wo die Seite sein sollte | Der Status sagt OK |
| Challenge oder Zwischenseite | Ein CAPTCHA oder eine “Ihr Browser wird überprüft”-Seite | Oft ein 200, manchmal ein Fehlercode |
| Weiches 404 | Eine generische Seite oder Startseite für Inhalte, die nicht mehr existieren | Der Server liefert 200 statt 404 |
| Leere Hülle | HTML ohne Inhalt, weil sich die Seite erst in JavaScript aufbaut | Ein vollständiges, gültiges Dokument |
| Consent- oder Bezahlschranke | Ein Consent-Bildschirm vor dem Inhalt | Die Seite hat geladen; der Inhalt nicht |
| Falsche Variante | Die Seite, der Preis oder die Sprache eines anderen Landes | Eine völlig echte Seite, nur nicht die gemeinte |
Jede dieser Formen wird geparst, gespeichert und aggregiert wie gute Daten. Keine löst einen Fehleralarm aus.
Die Zahl, die niemand gemessen hat
Forscher, die Bot-Blockierung und Web-Verfall untersuchen, sind dieser Frage wiederholt ausgewichen, und mehrere sagen dies auch ausdrücklich.
Die jüngste große Studie, “Detecting Bot Detection” von Gundelach, Mühlhauser und Herrmann (Universität Bamberg, Juni 2026), scannte die Tranco-Top-10.000-Seiten zwischen dem 27. Februar und 2. März 2026 unter mehreren Browser-Konfigurationen. Ihr Abschnitt zu den Einschränkungen ist unmissverständlich: “content degradation within HTTP 200 responses is outside our observational scope.” Die Autoren untersuchten zudem 81 Web-Messstudien und stellten fest, dass “only 5% of papers explicitly quantify bot detection or blocking rates, and 83% omit any discussion” davon.
Sie befinden sich in guter Gesellschaft. Die PAM-2025-Studie zu Common-Crawl-Ablehnungen arbeitete mit Nicht-200-Antworten. Die globale Geo-Blocking-Studie von 2018 stellte fest, dass eine Seite laden könnte, während “the login button has disappeared, or that some content is not available”, und überließ diese “more nuanced changes in content” künftiger Arbeit. Das Pew Research Center behandelte in seiner Link-Verrottungsstudie von 2024 “ambiguous situations in which we could not guarantee that the content exists, like soft 404 pages” als zugänglich. Die April-2026-Studie des Internet Archive zum toten Web “relied on HTTP status codes and did not look into the contents of the pages to check for any soft-404s.”
All dies ist keine Nachlässigkeit. Die Klassifizierung von Statuscodes skaliert auf Millionen von Seiten; zu beurteilen, ob Inhalt korrekt ist, erfordert Wissen darüber, wie korrekt für jede Seite aussieht. Genau deshalb ist die stille Fehlerquote im Web-Maßstab ungemessen, und genau deshalb ist sie für die eigenen Ziele messbar, wo man tatsächlich weiß, wie korrekt aussieht.
Was die nahegelegenen Messungen zeigen
Keine einzelne Zahl beantwortet die Frage, aber mehrere Messungen grenzen sie ein.
| Befund | Quelle | Gemessen |
|---|---|---|
| Headless Chromium wurde bei 15,2% der Top-Seiten soft-geblockt, gegenüber 6,8% bis 7,2% bei anderen Browser-Setups; 81,9% der soft-geblockten Seiten wurden Bot-Erkennung zugeschrieben | Gundelach, Mühlhauser und Herrmann, arXiv, Juni 2026 | Feb. bis März 2026 |
| Mindestens 1,68% der Seiten lehnten Common Crawl explizit ab, mit inkonsistenten und sogar fehlerhaften Statuscodes; 80% der ablehnenden Domains blockierten jede Anfrage | Ansar, Sperotto und Holz, PAM 2025 | Common-Crawl-Snapshot, Ende 2023 |
| 32 von 395 Domains, die kubanischen Nutzern Blockseiten auslieferten, verwendeten einen 200-Status | Ablove et al., USENIX Security 2024 | Mai 2023 |
| Automatisierte Crawls verpassten 45% der Fingerprinting-Websites, auf die echte Nutzer stießen, teilweise weil sie die Bot-Erkennung nicht überwinden konnten | Annamalai, Bilogrevic und De Cristofaro, WWW 2025 | 30 Nutzer über 10 Wochen |
| Cookie-Schranken bei 0,6% von 45.000 Seiten, und bei 8,5% der deutschen Top-1.000 | Rasaii, Gosain und Gasser, IMC 2023 | 2023 |
| 7,35% der Webserver lieferten 200 für ein unbekanntes Dokument statt 404 | Prieto Álvarez, Álvarez Díaz und Cacheda Seijo, 2014 | Vor 2014 |
| Weiche 404er machten mehr als 15% der toten Links aus | Bar-Yossef, Broder, Kumar und Tomkins, WWW 2004 | Vor 2004 |
Die ersten beiden Zeilen beschreiben durch Fehlercodes sichtbare Blockierung, also den Teil, der leicht zu erkennen ist. Die dritte zeigt, dass der andere Teil existiert: Etwa jede zwölfte Blockseite in dieser Studie kam als Erfolg verkleidet an. Die Zahlen zu weichen 404ern sind alt, und sie sind die jüngsten, die veröffentlicht wurden.
Was es nachgelagert kostet
Das klarste Bild stiller Fehler in einem realen Datensatz stammt aus offiziellen Statistiken. Als das UK Office for National Statistics Preisindizes aus per Web-Scraping erhobenen Supermarktdaten pilotierte, berichtete das Update vom Mai 2016, dass “the total percentage of products that were classified as anomalous or misclassifications after this validation step was 25%” und Preise “from 3.4 million to 2.5 million” entfernt wurden. Fehlende Daten, so wurde ergänzt, “were mainly caused by retailers making structural changes to their websites.”
Diese 25% sind keine Fehlerquote auf HTTP-Ebene. Der Großteil davon waren Produkte, die in die falsche Kategorie gescrapt wurden, sowie Ausreißerpreise. Genau das ist der Punkt: Jeder dieser Datensätze kam aus einer erfolgreichen Anfrage zurück, und ein Viertel davon war unbrauchbar. Es brauchte einen Validierungsschritt, aufgebaut von einem Statistikamt, um sie zu finden.
Warum Statuscodes dieses Signal nicht tragen können
Es wäre praktisch, wenn Server Ablehnungen ehrlich melden würden. Die Beweislage zeigt, dass sie es nicht konsistent tun. Die Common-Crawl-Studie fand Ablehnungen, die durch eine inkonsistente und sogar fehlerhafte Verwendung von HTTP-Statuscodes signalisiert wurden. Die Kuba-Studie fand Blockierungen verteilt über DNS-Fehler, Timeouts, 403er, eine Handvoll des eigens dafür vorgesehenen 451-Codes, und 200er.
Manche Infrastruktur hilft tatsächlich. Cloudflare setzt für alle seine Challenge-Seitentypen einen cf-mitigated: challenge-Antwort-Header, was ein weit verlässlicheres Signal ist als der Statuscode. Darauf sollte geprüft werden. Aber ein Header eines einzelnen Anbieters ist kein Web-Standard, und die meisten stillen Fehler tragen überhaupt kein Kennzeichen.
Die eigene stille Fehlerquote messen
Die Definition ist einfach: von den Antworten, die das eigene System als erfolgreich gezählt hat, der Anteil, der die Inhaltsvalidierung nicht bestanden hat. Die eigentliche Arbeit steckt in der Validierung.
- Datensätze validieren, nicht Antworten. Festlegen, welche Felder jeder Datensatz eines Seitentyps enthalten muss, und jedes 200 als fehlgeschlagen werten, das diese nicht liefert.
- Größe mit dem Normalwert des Seitentyps vergleichen. Eine Produktseite, die plötzlich nur ein Fünftel ihrer üblichen Größe hat, ist selten eine Produktseite.
- Nach Block- und Challenge-Kennzeichen suchen, einschließlich Headern wie
cf-mitigated, und Formulierungen, die die Zielseiten tatsächlich verwenden. - Kanarienvögel einsetzen. Seiten abrufen, deren korrekten Inhalt man unabhängig kennt, über denselben Pfad wie in der Produktion, und vergleichen.
- Festhalten, von wo aus abgerufen wurde. Eine falsche Länder-Variante ist nur erkennbar, wenn der Beobachtungspunkt protokolliert wurde, was das Argument von dem Vantage-Point-Standard ist.
- Stichproben für menschliche Überprüfung. Ein paar Dutzend Antworten pro Woche, von einer Person gelesen, deckt Fehlerarten auf, die keine Regel vorhergesehen hat.
Ein erster Klassifikator kann sehr klein sein:
BLOCK_MARKERS = ("captcha", "access denied", "unusual traffic", "verify you are human")
REQUIRED_FIELDS = ("title", "price")
def classify(resp, record, baseline_bytes):
"""Label one response. Anything but "ok" on a 200 is a silent failure."""
if resp.headers.get("cf-mitigated") == "challenge":
return "challenge"
if resp.status_code != 200:
return "http_error"
if not record and any(m in resp.text.lower() for m in BLOCK_MARKERS):
return "block_page"
if len(resp.content) < 0.2 * baseline_bytes:
return "too_small"
if not record or any(record.get(f) in (None, "") for f in REQUIRED_FIELDS):
return "missing_fields"
return "ok"Das Ergebnis pro Ziel und Seitentyp berichten, direkt neben der bereits vorhandenen Erfolgsquote. Wenn die beiden auseinanderlaufen, lügt die Erfolgsquote. Steigende Soft-Blocks bei einer Seite sind auch eines der frühesten Anzeichen dafür, dass sie sich gegen den eigenen Crawler wendet, wofür ein Target-Health-Score gedacht ist. Die umfassenderen Kennzahlen finden sich unter Monitoring einer Web-Scraping-Pipeline.
Wo Tooling hilft, und wo es nicht kann
Verwaltete Datenerhebung entfernt manche stillen Fehler, bevor sie überhaupt ankommen. Shifters Web Scraping API wiederholt fehlgeschlagene Abrufe, CAPTCHAs und vorübergehende Zielfehler automatisch, bis zu dreimal mit unterschiedlichen Proxys, und berechnet nur erfolgreiche Anfragen. JavaScript-Rendering beseitigt das Problem leerer Hüllen bei Seiten, die sich erst im Browser aufbauen, und extract_rules liefert benannte Felder zurück, wodurch ein fehlendes Feld leicht zu erkennen ist.
Was keine Erhebungsschicht leisten kann, ist zu wissen, dass eine völlig wohlgeformte Seite den falschen Preis oder den falschen Länderkatalog enthält. Nur man selbst weiß, wie korrekt für die eigenen Daten aussieht. Inhaltsvalidierung gehört in die eigene Pipeline, unabhängig davon, wie die Seiten abgerufen wurden.
Fazit
Ein 200 ist eine Behauptung eines Servers, keine Garantie über den Inhalt. Blockseiten, Challenges, weiche 404er, leere Hüllen, Consent-Schranken und falsche Varianten kommen alle als Erfolg verkleidet an, und veröffentlichte Forschung hat aus nachvollziehbaren praktischen Gründen fast alles über Web-Blockierung gemessen, außer genau das.
Die Konsequenz ist, dass die einzige stille Fehlerquote, die man je haben wird, die ist, die man selbst misst. Jeden Datensatz validieren, Kanarienvögel pflegen, deren Antworten bekannt sind, und das Ergebnis auf dasselbe Dashboard stellen wie die Erfolgsquote. Der Unterschied zwischen den beiden Zahlen ist der Teil des Datensatzes, dem man derzeit nicht trauen kann.
Quellen und Referenzen
- Gundelach, Mühlhauser und Herrmann, Detecting Bot Detection: Prevalence, Techniques, and Implications for Web Measurement Research, arXiv, 12. Juni 2026. Scans 27. Februar bis 2. März 2026.
- Ansar, Sperotto und Holz, Web Crawl Refusals: Insights From Common Crawl, PAM 2025, 7. März 2025.
- Ablove et al., Digital Discrimination of Users in Sanctioned States: The Case of the Cuba Embargo, USENIX Security 2024. Gemessen im Mai 2023.
- McDonald et al., 403 Forbidden: A Global View of CDN Geoblocking, ACM IMC 2018.
- Annamalai, Bilogrevic und De Cristofaro, Beyond the Crawl: Unmasking Browser Fingerprinting in Real User Interactions, WWW 2025.
- Rasaii, Gosain und Gasser, Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web, ACM IMC 2023.
- Prieto Álvarez, Álvarez Díaz und Cacheda Seijo, Soft-404 Pages, a Crawling Problem, Journal of Digital Information Management, 2014.
- Bar-Yossef, Broder, Kumar und Tomkins, Sic Transit Gloria Telae: Towards an Understanding of the Web’s Decay, WWW 2004.
- Pew Research Center, When Online Content Disappears: methodology, 17. Mai 2024.
- Sawood Alam, Internet Archive, Gone but Not Forgotten: Recovering the Dead Web, 23. April 2026.
- Office for National Statistics, Research indices using web scraped data: May 2016 update, 23. Mai 2016.
- Cloudflare, Detect a Challenge Page response.
- Shifter, Web Scraping API errors and limits.