Was kostet es, 2026 eine Million Seiten zu scrapen?
DIY-Proxys, Rechenleistung und Entwicklerzeit gegen pauschal 299 $ für 1.000.000 Credits: die echten Kosten für eine Million Seiten, geprüft im August 2026.

„Was kostet es, eine Million Seiten zu scrapen” klingt nach einer einzigen Zahl. Ist es nicht. Es sind mindestens drei Zahlen (Bandbreite, Rechenleistung, Entwicklerzeit), die niemand zusammenzählt, bis die Rechnung des Hobby-Proxy-Plans neben der AWS-Rechnung liegt.
Hier die ehrliche Aufschlüsselung für beide Wege, DIY und API, bei 1.000.000 Seiten im Monat.
Der DIY-Weg: was tatsächlich auf der Rechnung landet
Bandbreite. Scraping in echter Größenordnung bedeutet residentielle oder mobile Proxys, weil Rechenzentrums-IPs auf allem, was Wert auf Schutz legt, schnell geblockt werden. Zwei aktuelle Pay-as-you-go-Preise, geprüft im August 2026: Bright Data listet residentielle Proxys ab 4,00 $/GB Pay-as-you-go (ein Rabattpreis auf einen Listenpreis von 8,00 $/GB), und Oxylabs listet residentielle Proxys ab 6,00 $/GB Pay-as-you-go.
Eine reine HTML-Seite, ohne Bilder oder Skripte, liegt je nach Website bei etwa 50-150 KB. Bei angenommenen 100 KB Durchschnitt für 1.000.000 statische Seiten sind das rund 100 GB, also zwischen 400 und 600 Dollar allein an Proxy-Bandbreite, bevor auch nur eine Zeile Parsing-Code läuft.
Wenn die Seiten einen echten Browser brauchen (JS-gerenderter Inhalt, Infinite Scroll, Inhalt hinter einer SPA), lädt eine Headless-Session das komplette Seitengewicht herunter, Skripte und Assets inklusive, nicht nur das HTML. Das liegt regelmäßig bei 1-3 MB pro Seite. Bei 1.000.000 Seiten sind das 1-3 TB, also grob 4.000-18.000 Dollar an Proxy-Bandbreite bei denselben Preisen. Das ist die Zahl, die überrascht: JS-Rendering addiert sich nicht zur Rechnung, es multipliziert sie, weil die Einheit jetzt das ganze Seitengewicht ist statt nur das HTML.
Rechenleistung. Statische Abrufe sind günstig parallel auszuführen: eine bescheidene Worker-Flotte, die 1.000.000 einfache HTTP-Requests im Monat abarbeitet, liegt in der Größenordnung von 50-200 Dollar Cloud-Rechenleistung. Headless-Chrome-Instanzen sind ein anderes Tier: jede belegt für die Sekunden des Renderns echten Speicher und CPU, also liegt eine Flotte für 1.000.000 JS-gerenderte Seiten im Monat realistischer bei 500-2.000 Dollar, abhängig davon, wie aggressiv du Browser-Kontexte bündeln und wiederverwenden kannst.
Entwicklerzeit. Das ist die Zeile, die niemand in die Tabelle schreibt, und die nie auf null geht. Anti-Bot-Maßnahmen ändern sich, Selektoren driften bei einem Website-Redesign, und Proxy-Pools brauchen Monitoring für die Sperrrate. Selbst konservative 10-15 Stunden Entwicklerzeit im Monat zu 75-150 Dollar/Stunde sind 750-2.250 Dollar, und diese Schätzung geht davon aus, dass nichts so schlimm kaputtgeht, dass ein Wochenende draufgeht.
Zusammengerechnet landet ein statischer 1.000.000-Seiten-Job DIY bei etwa 1.200-3.000 Dollar im Monat, wenn Bandbreite, Rechenleistung und Wartung ehrlich mitgezählt werden. Ein JS-gerenderter Job landet eher bei 5.000-20.000 Dollar, wobei die Bandbreite den größten Teil des Schadens anrichtet.
Der API-Weg: eine Zahl, keine Wartungszeile
Bei FastAF kostet /scrape 1 Credit für eine statische Seite, 5 Credits mit dynamic=true (JS-Rendering), 10 mit premium=true (residentielles/Anti-Bot-Netzwerk) und 25 mit beidem.
1.000.000 statische Seiten = 1.000.000 Credits = das Pro-Paket, pauschal 299 $ für 1.000.000 Credits, 5 gleichzeitige Requests. Das ist die ganze Rechnung. Keine Proxy-Rechnung, keine Headless-Browser-Flotte zu dimensionieren, kein Bereitschaftsdienst, wenn eine Website ihr Markup ändert.
1.000.000 Seiten mit JS-Rendering (dynamic=true) = 5.000.000 Credits. Das sind ein Business-Paket (3.000.000 Credits, 799 $) plus zwei Pro-Pakete (598 $), 1.397 $ zum Listenpreis, oder ein darauf zugeschnittenes Volumenangebot (das fragst du am besten direkt an, statt Pakete zu stapeln).
| Szenario | Benötigte Credits | FastAF-Kosten | DIY-Schätzung (Bandbreite + Rechenleistung + Zeit) |
|---|---|---|---|
| 1 Mio. Seiten, statisch | 1.000.000 | 299 $ (Pro) | ~1.200-3.000 $/Monat |
| 1 Mio. Seiten, JS-Rendering | 5.000.000 | ~1.397 $ (Business + 2x Pro) oder individuell | ~5.000-20.000 $/Monat |
import requests
API_KEY = "faf_live_..."
def scrape(url, dynamic=False, premium=False):
resp = requests.get(
"https://api.fastaf.co/v1/scrape",
params={"url": url, "dynamic": str(dynamic).lower(), "premium": str(premium).lower()},
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=60,
)
resp.raise_for_status()
return resp.text
page = scrape("https://example.com/product/123", dynamic=True)
print(page[:500])
Der Teil, der die Rechnung in beide Richtungen verändert
Fehlgeschlagene Requests sind der Punkt, den jeder Vergleich oben stillschweigend ausklammert, und das sollte er nicht. Bei FastAF werden Credits reserviert, wenn ein Request startet, und zurückgegeben, wenn er ohne Ergebnis zurückkommt: ein geblockter Versuch kostet dich nichts. Wenn du die DIY-Zahlen oben durchrechnest und deine Sperrrate bei einem harten Ziel bei 15-20 % liegt, sind die effektiven Bandbreiten- und Rechenkosten pro nutzbarer Seite 15-20 % höher als der Listenpreis, und das noch bevor die Entwicklerzeit für die Fehlersuche eingerechnet ist.
Kurz zusammengefasst
Für statische Seiten in echtem Volumen ist DIY ein paar hundert Dollar an Proxys plus ein Wartungsjob, der nie ganz verschwindet; der API-Weg ist ein Pro-Paket zu pauschal 299 $, ohne irgendetwas zu warten. Bei JS-gerenderten Seiten wird die Lücke in beide Richtungen deutlich größer, weil Seitengewicht (DIY) und Credit-Kosten (API) beide gemeinsam skalieren. Rechne deine eigenen Zahlen zu Seitengewicht und Volumen durch dieselbe Rechnung, bevor du dich für einen Weg entscheidest: die Preise zeigen die vollständige Credit-Tabelle, und das kostenlose Kontingent gibt dir 500 Credits ohne Kreditkarte, um es zuerst an deinen echten Seiten zu testen.