Ein Scraper, der einmal funktioniert, hat genau eines bewiesen: dass ein Request, über einen Exit, zu einem Zeitpunkt, mit Inhalt zurückkam. Er sagt nichts darüber, wie oft dieses Ziel antwortet, wie lange es dauert, was eine Seite kostet, ob ein Browser überhaupt etwas tut oder um welche URL-Formen der Site sich die Fehlschläge häufen. Das sind die Zahlen, die entscheiden, ob eine Pipeline es wert ist, gebaut zu werden, und sie werden meist erst entdeckt, wenn die Pipeline schon existiert.
Das Crawlbase Web Scraping Cookbook veröffentlicht sie vorab. Es gibt eine Seite pro Site, und jede Seite wird an echtem Crawlbase-Traffic gemessen, bevor irgendetwas geschrieben wird: Erfolgsrate, mediane Antwortzeit, Credit-Preis, wie viel des erfolgreichen Traffics einen Browser genutzt hat, welche Länder-Route die erfolgreichen Calls gesetzt haben, welche URL-Muster die Erfolge ausmachen und was die Fehlschläge tatsächlich waren. Aktuell umfasst es 17.739 gemessene Sites und 356 Rezepte, auf Basis der Zahlen von August 2026, monatlich aktualisiert.
- Eine Erfolgsrate allein ist kein Profil. Zwei Sites mit 98 % können sich um das 20-Fache in der Latenz und um das 20-Fache im Preis unterscheiden.
- Browser-Rendering ist eine Messgröße, kein Standard. Bei vier der sechs Sites unten gewinnt der Normal token, und ein Browser bringt nichts.
- Country-Routing ist eine Frage derselben Art. Es verschiebt Trustpilot um vier Punkte und bringt bei den anderen überhaupt nichts.
- Fehlerklassen sind Handlungsanweisungen. Ein 429 heißt: Calls drosseln, ein 403 heißt: den Exit korrigieren, ein 5xx heißt: warten.
- Die Zahlen beschreiben ein gemessenes Zeitfenster, keine Garantie, und werden deshalb jeden Monat neu ausgewiesen.
Was ein Rezept misst
Jede Seite entsteht aus beobachtetem Traffic zu dieser Site, nicht aus einem Testlauf, der für die Seite durchgeführt wurde. Gemessen wird das, womit eine Pipeline tatsächlich planen muss.
| Messgröße | Was sie beantwortet | Was sie verändert |
|---|---|---|
| Erfolgsrate | Wie oft Calls an diese Site mit Inhalt zurückkommen | Retry-Budget und ob das Ziel eine Pipeline wert ist |
| Mediane Antwortzeit | Wie lange ein typischer Call dauert | Parallelität, Scheduling, Client-Timeouts |
| Credit-Preis | Was eine Seite kostet, nach Domain-Komplexität, verdoppelt bei einem JavaScript-Fetch | Stückkosten vor der Skalierung, nicht danach |
| Browser-Anteil | Wie viel des erfolgreichen Traffics den JavaScript token genutzt hat | Ob Rendering nötig oder nur teuer ist |
| Land | Welchen Exit die erfolgreichen Calls genutzt haben | Ob sich country=XX lohnt |
| URL-Muster | In welchen Seitenformen sich die Erfolge konzentrieren | Was zuerst implementiert und validiert wird |
| Fehlerklassen | Was die Site geantwortet hat, als sie abgelehnt hat | Retry-Logik, die zur Ablehnung passt |
Ein Detail der Erfolgszählung sollte klar benannt werden, weil es die Bedeutung der Rate verändert. Eine Site, die 200 mit einer Blockseite oder einer Consent-Wall beantwortet, hat keinen Inhalt zurückgegeben, deshalb zählt das Cookbook das als Fehlschlag und nicht als Erfolg. Bei Google ist diese Klasse mit 33,8 % die größte einzelne Fehlergruppe.
Sechs Sites, sechs verschiedene Profile
Am schnellsten sieht man, warum eine einzelne Zahl nicht reicht, wenn man sechs echte Rezepte nebeneinanderlegt. Alle Zahlen unten sind die Messungen von August 2026, die auf der jeweiligen Seite veröffentlicht sind; Muster und Fehlschläge stammen aus dem Request-Log seit dem 14. August 2026.
Google: schnell, günstig genug, kein Browser
Das google.com-Rezept misst 97,0 % Erfolg, eine mediane Antwortzeit von 1,9 Sekunden, und 2 Credits pro Seite. Calls mit dem Normal token sind zu 96,9 % erfolgreich und tragen 99,8 % des Traffics, ein Browser ist hier also reiner Kostenfaktor. Suchseiten dominieren: /search macht 98,3 % der erfolgreichen Requests aus, und 6,3 % der Calls fordern den google-serp Scraper an, um strukturiertes JSON statt HTML zu erhalten. Die Fehlschläge verteilen sich fast gleichmäßig auf Block- oder Consent-Seiten, die mit 200 beantwortet wurden (33,8 %), und Requests, die innerhalb des Timeouts nie geantwortet haben (33,5 %); Rate Limits liegen bei 23,5 %.
LinkedIn: zuverlässig, langsam und teuer
Das linkedin.com-Rezept misst 98,0 % Erfolg, eine mediane Antwortzeit von 14,7 Sekunden, und 20 Credits pro Seite, die Preisstufe Extreme II. Calls mit dem Normal token sind zu 99,9 % erfolgreich und machen 96,0 % des Traffics aus. Die Erfolge konzentrieren sich auf Job-Seiten (41,5 %), Unternehmensseiten (27,3 %) und Profile (18,5 %). Die Fehlschläge dominiert der eigene Ablehnungsstatus der Site, 999, mit 58,5 %, dazu 591 Antworten mit 27,1 %.
LinkedIn ist das klarste Argument dafür, das ganze Profil zu lesen. Nach der Erfolgsrate beurteilt ist es die zweitzuverlässigste Site dieser Gruppe. Nach den Kosten pro Seite beurteilt ist es das Zwanzigfache von Target, und nach der Latenz beurteilt das Neunfache von Google.
Allegro: nahezu perfekt und ohne Eile
Das allegro.pl-Rezept misst 99,7 % Erfolg, eine mediane Antwortzeit von 16,5 Sekunden, und 2 Credits pro Seite. Der gesamte erfolgreiche Traffic nutzt den Normal token. Produktseiten unter /produkt/{slug} machen 77,3 % der Erfolge aus. Angeführt werden die Fehlschläge von Timeouts (44,3 %), dann 403 Ablehnungen (36,9 %) und 400 Antworten (12,8 %).
Target: günstig und schnell, aber mit Rate Limits
Das target.com-Rezept misst 96,4 % Erfolg, eine mediane Antwortzeit von 1,6 Sekunden, und 1 Credit pro Seite. Calls mit dem Normal token sind zu 97,7 % erfolgreich und tragen 97,2 % des Traffics, und zwei Produkt-URL-Formen decken zusammen 99,3 % der Erfolge ab. Interessant ist das Fehlerprofil: 48,1 % sind 429 Rate Limits, gefolgt von 403 mit 32,4 % und Timeouts mit 13,3 %. Günstig und schnell, aber die Site wehrt sich gegen das Tempo, und das ist eher ein Scheduling- als ein Konfigurationsproblem.
Trustpilot: hier zählen Rendering und Land gleichermaßen
Das trustpilot.com-Rezept misst 90,9 % Erfolg, eine mediane Antwortzeit von 32,0 Sekunden, und 1 Credit pro Seite, 2 Credits mit dem JavaScript token, den dieses Rezept braucht. Das ist die Site der Gruppe, bei der die Konfiguration sowohl das Ergebnis als auch die Rechnung verändert. Calls mit dem JavaScript token erreichen 94,0 % gegenüber 29,5 % beim Normal token, und 94,0 % der Calls nutzen ihn. Auch das Country-Routing verschiebt das Ergebnis: 46,2 % der erfolgreichen Calls setzen den US-Exit und erreichen 92,4 %, gegenüber 88,2 % ohne gesetztes Land. Reviews unter /review/{slug} machen 97,5 % der Erfolge aus. Angeführt werden die Fehlschläge von 403 mit 45,9 %.
Das ist der Call, den das Rezept empfiehlt, und der, den man übernehmen sollte, weil er beide Entscheidungen zugleich trägt:
curl "https://api.crawlbase.com/?token=YOUR_JS_TOKEN&country=US&url=https%3A%2F%2Fwww.trustpilot.com%2Freview%2Fsd.se"
QQ.com: fast perfekt, und trotzdem braucht es den Browser
Das qq.com-Rezept misst 99,9 % Erfolg, eine mediane Antwortzeit von 6,1 Sekunden, und 1 Credit pro Seite, 2 Credits mit dem JavaScript token, den dieses Rezept braucht. Es ist die zuverlässigste Site dieser Gruppe und braucht trotzdem Rendering: Calls mit dem JavaScript token erreichen 100 % gegenüber 86,8 % beim Normal token, und 98,9 % der Calls nutzen ihn. Tag-Seiten machen 99,8 % der Erfolge aus. Die meisten Fehlschläge sind 5xx-Antworten der Site selbst, zusammen 72,4 %.
QQ.com und Trustpilot machen denselben Punkt von zwei Seiten. Die Erfolgsrate an der Oberfläche sagt nicht, ob ein Browser nötig ist, denn sie spiegelt bereits wider, dass die Aufrufer einen nutzen.
Die sechs im Vergleich
| Site | Erfolg | Mediane Antwort | Preis | Browser | Land | Das Profil |
|---|---|---|---|---|---|---|
| google.com | 97,0 % | 1,9 s | 2 Credits | Nein | Keines | Schnell und einfach |
| linkedin.com | 98,0 % | 14,7 s | 20 Credits | Nein | Keines | Zuverlässig, langsam, teuer |
| allegro.pl | 99,7 % | 16,5 s | 2 Credits | Nein | Keines | Zuverlässig, aber langsam |
| target.com | 96,4 % | 1,6 s | 1 Credit | Nein | Keines | Günstig, schnell, mit Rate Limits |
| trustpilot.com | 90,9 % | 32,0 s | 2 Credits mit JS | Ja | US hilft | Die Konfiguration entscheidet |
| qq.com | 99,9 % | 6,1 s | 2 Credits mit JS | Ja | Keines | Zuverlässig, rendering-abhängig |
Ein Rezept lesen, bevor der Scraper geschrieben wird
Der praktische Nutzen des Profils liegt darin, dass es die Rateschleife am Anfang einer Integration entfernt, in der der meiste Aufwand verloren geht.
Mit der Konfiguration starten, die bereits gewinnt
Jedes Rezept nennt den Token und das Land, die der erfolgreiche Traffic genutzt hat, damit der erste Call ein informierter ist und kein Testballon. Für eine Site mit Normal token wie Google ist das die gesamte Konfiguration:
from crawlbase import CrawlingAPI api = CrawlingAPI({'token': 'YOUR_TOKEN'}) r = api.get('https://www.google.com/search') html = r['body']
Einen Browser nur dort hinzufügen, wo die Messung es verlangt
Rendering ist der häufigste Reflex und die häufigste Verschwendung. Google, LinkedIn, Allegro und Target werden im beobachteten Traffic alle mit dem Normal token bedient, ein Browser fügt dort also einem Call, der bereits funktioniert hat, Kosten und Latenz hinzu. Trustpilot und QQ.com sind der umgekehrte Fall: Dort ist Rendering der Unterschied zwischen 94,0 % und 29,5 % beziehungsweise zwischen 100 % und 86,8 %. Bei der Crawling API kannst du es auf zwei Wegen anfordern: Call mit dem JavaScript token, oder Call mit dem Normal token und zusätzlich javascript=true, was vor dem Crawl auf deinen JavaScript-Key umschaltet, sodass ein Key alles abdeckt. Mit Smart AI Proxy ist der Schalter javascript=true im Header CrawlbaseAPI-Parameters zu setzen. Beide Wege werden als JavaScript-Request abgerechnet, und daher stammt der verdoppelte Credit-Preis bei diesen beiden Sites.
Die Fehlerklasse den Retry bestimmen lassen
Die Aufschlüsselung der Fehlschläge zahlt sich nach dem Start aus, weil jede Klasse eine andere Reaktion verlangt. Einen 429 sofort zu wiederholen, reproduziert ihn. Einen 403 ohne Wechsel des Exits zu wiederholen, reproduziert ihn ebenfalls.
- 429 bedeutet, dass die Site dein Tempo drosselt. Strecke die Calls zeitlich oder übergib sie dem Crawler, der das Tempo für dich regelt. Die Hälfte der Fehlschläge von Target entfällt darauf.
- 403 bedeutet, dass der Exit abgelehnt wird. Setze das Land, das die erfolgreichen Calls nutzen, und wiederhole einmal; eine zweite Ablehnung bedeutet meist, dass die URL selbst geschützt ist.
- 5xx bedeutet, dass die Site versagt und nicht der Fetch. Warten und später erneut versuchen. Bei QQ.com sind das fast drei Viertel aller Fehlschläge.
- Timeouts bedeuten, dass die Seite innerhalb des Limits nicht fertig wurde. Halte dein Client-Timeout über der medianen Antwortzeit der Site, genau deshalb veröffentlicht das Rezept sie.
- Ein 200 mit einer Block- oder Consent-Seite ist ein Fehlschlag im Gewand eines Erfolgsstatus. Er wird nicht abgerechnet und ist der Grund, den Inhalt statt des Status zu prüfen.
Die Rezepte werden darauf gemessen: ein Endpoint, Browser-Rendering und Anti-Bot-Handling innerhalb des Fetch, und cb_status sagt dir, ob die Seite zurückgekommen ist. Fehlgeschlagene Requests werden nicht abgerechnet. Starte kostenlos mit bis zu 5.000 Requests, ohne Karte.
Vom Rezept zur Pipeline
Das Profil passt in die frühe Phase eines Builds, in der sich Unbekannte am günstigsten beseitigen lassen.
Für ein Team, das Infrastruktur auswählt, statt den Fetch zu schreiben, beantworten dieselben Zahlen eine andere Frage. Zuverlässigkeit, Latenz und Preis sind Eigenschaften des jeweiligen Ziels, nicht der Plattform, deshalb ist „Könnt ihr diese Site scrapen“ weniger nützlich als „Was kostet diese Site, wie langsam ist sie, und was tut sie, wenn sie ablehnt“. Die sechs Sites oben reichen von 1 bis 20 Credits pro Seite und von 1,6 bis 32,0 Sekunden, auf einer Plattform. Die Kostenmodellierung beginnt beim Preis des Ziels:
100,000 pages x 1 credit = 100,000 credits (target.com) 100,000 pages x 20 credits = 2,000,000 credits (linkedin.com)
Der Preisrechner rechnet diese Credits in einen Monatsbetrag um. Entscheidend ist, dass der Multiplikator bekannt sein kann, bevor die Pipeline existiert, und nicht erst nach der ersten Rechnung.
Was die Zahlen nicht behaupten
Ein Rezept beschreibt gemessenen Traffic für ein angegebenes Zeitfenster. Es ist kein Versprechen für morgen und keine Behauptung, dass sich jede Seite der Site wie die Seiten in der Stichprobe verhält. Sites ändern ihren Schutz, rotieren Infrastruktur und justieren Rate Limits neu, deshalb trägt jede Seite den Monat ihrer Messung und ein Datum des letzten Tests, und deshalb wird der gesamte Satz monatlich aktualisiert, statt altern gelassen zu werden. Wenn eine Site nicht mehr antwortet, wird ihr Rezept entfernt, statt als Dokumentation von etwas erhalten zu bleiben, das nicht mehr funktioniert.
Die Muster und Fehlerklassen stammen aus dem Request-Log seit dem 14. August 2026, sie beschreiben also die Seitenformen, die Crawlbase-Accounts tatsächlich abrufen. Eine URL-Form, die niemand anfragt, taucht nicht auf, auch wenn die Site sie ausliefert.
Fazit
Die meisten Scraping-Entscheidungen werden zweimal getroffen: einmal aus einer Annahme heraus und noch einmal, nachdem der Traffic zeigt, was die Site wirklich tut. Das Cookbook zieht die zweite Fassung nach vorn. Bevor du einen Extractor schreibst, siehst du, wie oft das Ziel antwortet, wie lange es dauert, was eine Seite kostet, ob der Browser überhaupt etwas tut, welchen Exit die erfolgreichen Calls nutzen, welche URL-Formen die Erfolge tragen und worin die Ablehnungen bestanden.
Finde dein Ziel im Cookbook, starte mit dem Call, den die Messungen stützen, und erstelle ein kostenloses Konto und teste ihn mit deiner eigenen Last.
Häufig gestellte Fragen (FAQs)
Woher stammen die Zahlen im Cookbook?
Aus dem Crawlbase-Traffic zu dieser Site: jeder Request aus jedem Account im angegebenen Monat für die Erfolgsrate und das Request-Log seit dem 14. August 2026 für Muster, Länder und Fehlerklassen. Es sind Messungen beobachteten Traffics für dieses Zeitfenster, keine Garantien für künftige Leistung, und nirgendwo in den Daten wird ein Kunde oder Account identifiziert.
Bedeutet „Browser nötig“, dass ich selbst einen Browser betreiben muss?
Nein. Es bedeutet, dass das Ziel JavaScript-Rendering braucht, und Crawlbase übernimmt das Rendering. Bei der Crawling API und dem Crawler verlangst du es entweder über den JavaScript token oder über deinen Normal token plus javascript=true, was vor dem Crawl die Keys wechselt; mit Smart AI Proxy gibst du javascript=true im Header CrawlbaseAPI-Parameters an. Beides zählt abrechnungstechnisch als JavaScript-Request.
Kann ich vor dem Bauen abschätzen, was ein Ziel kosten wird?
Ja, und das ist im Wesentlichen der Sinn. Das Rezept veröffentlicht den Credit-Preis für eine Seite dieser Site, festgelegt durch ihre Domain-Komplexität, Seiten mal Preis ergibt also die Credit-Zahl, und der Rechner rechnet sie um. Achte dabei auf die Browser-Spalte: Eine Site, die Rendering braucht, wird mit dem verdoppelten JavaScript-Wert abgerechnet, deshalb kosten Trustpilot und QQ.com 2 Credits pro Seite statt 1. Der tatsächliche Verbrauch hängt weiterhin von deiner Konfiguration ab und davon, durch welches Produkt du den Traffic schickst.
Warum wird eine 200-Antwort manchmal als Fehlschlag gezählt?
Weil eine Blockseite oder eine Consent-Wall, die mit einem 200 ausgeliefert wird, nicht der Inhalt ist, den du angefragt hast. Sie als Erfolg zu zählen, würde jede Rate der Site aufblähen und die häufigste Art verbergen, wie moderne Ziele ablehnen. Abgerechnet werden diese Antworten ebenfalls nicht.
Wie oft wird ein Rezept aktualisiert?
Monatlich. Jede Seite nennt den Monat hinter ihren Messungen und das Datum des letzten Tests, damit ein veraltetes Profil sichtbar und nicht stillschweigend vorhanden ist. Rezepte für Sites, die nicht mehr antworten, werden entfernt statt stehen gelassen.
Crawlen Sie jede Website im großen Maßstab, ohne gegen die Infrastruktur zu kämpfen.
Crawlbase übernimmt Proxys, Fingerprints und CAPTCHAs, damit Ihr Team Datenpipelines ausliefert, statt Crawl-Infrastruktur zu pflegen. 1.000 Anfragen kostenlos, keine Karte erforderlich.