Web-Scraping-Preise: Pro GB, pro Seite oder pro Request?

Niemand verkauft Web Scraping in derselben Einheit

Bright Data bepreist seinen Web Unlocker pro tausend Requests. Oxylabs berechnet Web Unblocker pro Gigabyte. Firecrawl verlangt ein Credit pro Seite. Zyte rechnet pro tausend erfolgreicher Responses ab, aufgeteilt auf fünf Schwierigkeitsstufen. Apify stellt Compute Units in Rechnung, was einem Gigabyte RAM für eine Stunde entspricht.

Fünf Anbieter, fünf Einheiten. Keine davon lässt sich in eine andere umrechnen, ohne einen Wert, den du selbst messen musst. Und keiner von ihnen veröffentlicht diese Zahl, weil sie von deinem Traffic abhängt und nicht von ihrem Produkt.

Wir haben alle fünf Preisseiten am 8. September 2026 analysiert. Hier ist, was dort steht, und was die Mathematik daraus macht.

Schneller Vergleich

Zwei Dinge fallen in dieser Tabelle sofort auf.

Zytes eigene Liste spannt einen Faktor von 124x auf. Derselbe Anbieter, dieselbe Einheit, dieselbe Zeile auf derselben Rechnung: Eine einfache, über HTTP abgerufene Seite kostet 0,13 $ pro Tausend, eine komplexe, im Browser gerenderte Seite 16,08 $. Wer „pro tausend Requests“ als vergleichbaren Wert angibt, nennt nur ein Ende einer extrem breiten Spanne.

Und Bright Data wechselt die Einheiten mitten im eigenen Katalog. Web Unlocker wird pro Request verkauft. Browser API wird pro Gigabyte verkauft. Das ist keine Nachlässigkeit. Es ist ein klares Indiz, und der Rest dieses Beitrags erklärt, was es bedeutet.

Was man für ein Gigabyte wirklich bekommt

Die Zahl, die über jede Umrechnung entscheidet, ist die durchschnittliche Seitengröße. Und die öffentlichen Daten dazu sind ernüchternd.

Der Web Almanac 2025 des HTTP Archive beziffert die mediane mobile Startseite beim Crawl im Juli 2025 auf 2.559 KB, ein Anstieg von 8,4 % innerhalb eines Jahres. Schlüsselt man diese Medianskoseite nach Inhaltstyp auf, erhält man 911 KB Bilder, 632 KB JavaScript, 122 KB Fonts und 77 KB CSS.

Und 22 KB HTML.

Diese letzte Zahl ist die entscheidende, denn das HTML-Dokument ist meist das Einzige, was du parst. Auf der medianen Seite macht es 0,86 % der Bytes aus, die ein vollständiges Browser-Rendering herunterlädt. Die anderen 99 % sind Ballast, für dessen Transfer du bezahlt hast.

Rechne das auf den 8-GB-Tarif von Oxylabs zu 9,40 $/GB um:

• Wenn du nur HTML mit 22 KB pro Seite abrufst, entspricht ein Gigabyte etwa 45.000 Seiten. Das sind rund 0,21 $ pro 1.000 Seiten.
• Beim Rendern der gesamten Seite mit 2.559 KB entspricht ein Gigabyte etwa 390 Seiten. Das sind rund 24 $ pro 1.000 Seiten.

Gleicher Tarif. Gleicher angegebener Preis. Ein Unterschied um den Faktor 116, der allein durch eine Einstellung in deinem eigenen Code entsteht.

Vergleiche das nun mit Firecrawl. Bei 83 $ für 100.000 Credits im Jahrestarif und einem Credit pro Seite zahlst du 0,83 $ pro 1.000 Seiten, egal ob die Seite 20 KB oder 4 MB wiegt. Gegenüber dem reinen HTML-Abruf ist die Abrechnung pro Gigabyte etwa viermal günstiger. Gegenüber dem vollständigen Rendern ist sie etwa 29-mal teurer.

Der Schnittpunkt liegt bei knapp 100 Kilobyte

Rechnet man das durch, treffen sich beide Abrechnungsmodelle bei einer bestimmten Seitengröße. 0,00083 $ pro Seite bei Firecrawl geteilt durch 9,40 $ pro Gigabyte bei Oxylabs ergibt 88 KB. Wählst du Firecrawl auf Monatsbasis statt jährlich (99,50 $ für dieselben 100.000 Credits), verschiebt sich der Schnittpunkt auf 106 KB. Unterhalb dieser Spanne gewinnt die Abrechnung pro Gigabyte. Darüber gewinnt der feste Preis pro Seite, und der Abstand wächst schnell, da die Seitengröße nach oben offen ist.

Das ist der interessante Teil: Oxylabs veröffentlicht seine eigene Umrechnung, ohne sie als solche zu kennzeichnen. Die kostenlose Testversion von Web Unblocker wird als "1GB (up to 10k results)" beschrieben. Das sind 100 KB pro Ergebnis, genau in der Spanne, die wir gerade aus den Preislisten zweier anderer Anbieter berechnet haben. Deren eigene Kalkulation geht davon aus, dass du Dokumente abrufst und keine Galerien renderst.

Wenn du nach Datenvolumen zahlst und einen Browser steuerst, ist dein größter Hebel nicht der Anbieter. Es ist das Blockieren von Bildern und Schriftarten vor dem Laden der Seite, denn auf der medianen Seite macht das 1.033 der 2.559 KB aus. Wir sagen dir das lieber direkt, statt so zu tun, als würde das Logo auf der Rechnung die Kosten bestimmen.

Zwei ehrliche Einschränkungen. Das sind Medianwerte über das gesamte Web, und deine Zielseiten sind nicht das gesamte Web (E-Commerce- und Reiseseiten sind schwerer, JSON-Endpoints deutlich leichter). Zudem kann eine gerenderte Seite mit blockierten Medien weit unter dem Median liegen, was den Schnittpunkt zu deinen Gunsten verschiebt, ohne dass sich etwas auf der Preisseite ändert. Die gleiche Rechnung entscheidet, wann sich ein LLM-Extraktionsschritt nicht mehr rentiert: Der Einheitspreis ist nie die interessante Zahl, sondern der Preis pro behaltenem Datensatz.

Was als abrechenbar gilt, ist eine zweite Dimension

Die Einheit ist die eine Frage. Was die Abrechnung auslöst, ist eine andere, die man leicht übersieht.

Bright Data wirbt bei Web Unlocker mit "pay only for success". Zyte berechnet "per 1,000 successful responses". Firecrawl verbraucht einen Credit pro API-Request, je nach Endpoint. Bei der Abrechnung pro Gigabyte gibt es überhaupt keine Erfolgsbedingung: Die Bytes wurden übertragen, also zahlst du, und eine Challenge-Seite, die du verwirfst, ist eine Seite, die du gekauft hast.

Das ist wichtiger, als es klingt, denn eine Challenge oder ein Interstitial liefert meist einen HTTP 200 Statuscode mit. Wenn deine Definition von Erfolg nur der Statuscode ist, stimmen deine Retry-Logik und deine Rechnung nicht mit deinem Datensatz überein. Wir haben über diese Diskrepanz in Validate Rules Now Decide What Counts as Success geschrieben, und genau diese Bruchlinie verwandelt eine partielle Blockierung in eine unbemerkte Lücke in einer Zeitreihe.

Wer welche Abrechnungseinheit wählen sollte

Zahle pro Gigabyte, wenn du Dokumente nur abrufst statt sie zu rendern, und deine Ziele textbasiert sind: Suchergebnisse, JSON-Endpoints, Kategorieseiten, Sitemaps. Bei 20 bis 50 KB pro Seite ist die Abrechnung nach Bytes das günstigste Modell am Markt, und nichts kommt dem nahe.

Zahle pro Seite oder pro Request, wenn du renderst, medienlastige Ziele hast oder das Seitengewicht über einen Long-Tail an Websites schlicht nicht vorhersagen kannst. Du zahlst bei kleinen Seiten einen Aufpreis, um dir eine Obergrenze für große Seiten zu sichern. Bei Render-Workloads ist diese Obergrenze viel wert.

Zahle pro Tier, wie es Zyte anbietet, wenn dein Zielseiten-Mix stabil ist und du weißt, in welche Stufe jede Website fällt. Das Modell geht ehrlich mit dem um, was andere wegrechnen: Schwierige Seiten kosten mehr beim Scraping. Für Ziel-Listen, die sich wöchentlich ändern, passt es weniger gut.

Kaufe Compute Units, wenn du lange Crawls mit eigenem Code auf der Plattform ausführst. Dieser Zähler berechnet die Rechenleistung, nicht die Datenmenge. Er belohnt schnelle Parser und straft langsame ab. Es ist das einzige Modell in dieser Liste, bei dem sich Code-Optimierung direkt auf der Rechnung bemerkbar macht.

Keine dieser Einheiten ist ein Trick. Jede ist eine Wette darauf, wie typischer Traffic aussieht, kalkuliert von Anbietern, die ihre eigene Kundenbasis kennen. Der Fehler liegt nicht in der Wahl der falschen Einheit. Er liegt darin, zwei Angebote mit unterschiedlichen Einheiten zu vergleichen und den niedrigeren Betrag für die Entscheidung zu halten.

Die Preise steigen, auch ohne Preiserhöhung

Bevor du ein Angebot annimmst, auch von uns, miss zwei Kennzahlen aus einer Woche deines eigenen Traffics: Bytes pro Request und der Anteil der Requests, die brauchbare Daten geliefert haben. Jedes Angebot in diesem Beitrag lässt sich sauber umrechnen, sobald du diese beiden Werte hast, und keines ohne sie.

Beobachte dann, was im nächsten Jahr passiert. Die durchschnittliche Startseite ist in zwölf Monaten um 7,8 % gewachsen, und der Trend zeigt nur in eine Richtung. Wenn deine Rechnung nach Bytes abgerechnet wird, ist das eine jährliche Preiserhöhung, die niemand ankündigen muss, auf einem Posten, den niemand verhandelt hat.

Bei FourA geben wir die Kosten jedes Calls direkt in der Response zurück. Du liest die Umrechnung also fortlaufend ab, statt sie am Monatsende aus einer Rechnung zu rekonstruieren. Das sagt dir nicht, welche Einheit du kaufen sollst. Aber es zeigt dir genau, was du pro behaltener Seite ausgibst, und um genau diese Zahl dreht sich die gesamte Diskussion.