Eine Scraping-Pipeline kommt selten mit einem einzigen Produkt aus. Sie ruft Seiten über eine API ab, rendert einen Teil davon im Browser, stellt große Aktualisierungen über einen Crawler in die Queue und legt die Ergebnisse in einem Speicher ab. Hat jeder dieser Bausteine seine eigene Preisliste und sein eigenes Guthaben, heißt die Frage nach den Kosten eines Workflows: vier Rechnungen miteinander abgleichen.
Crawlbase rechnet all das über ein einziges Credit-Guthaben und eine gestaffelte Preistabelle ab. Die Crawling API, der Enterprise Crawler, Smart AI Proxy, Cloud Storage sowie die Aufrufe über den Crawlbase Web MCP Server greifen auf denselben Pool zu, und Sie entscheiden, ob Sie nach Verbrauch zahlen (Pay-as-you-go) oder ein monatliches Kontingent abonnieren. Dieser Beitrag erklärt, wie die Preistabelle funktioniert, was ein Request tatsächlich kostet und wie Sie die Ausgaben im Griff behalten, wenn ein Workload wächst.
- Ein Guthaben heißt nicht, dass jeder Request genau einen Credit kostet. Schwierigere Sites, JavaScript-Rendering und gespeicherte Seiten verbrauchen mehr.
- Die Preistabelle ist gestaffelt wie Steuerstufen: Wer eine Schwelle überschreitet, zahlt für alles Weitere einen niedrigeren Preis, nie rückwirkend für das Bisherige.
- Ein Abonnement kauft ein monatliches Kontingent zu einem niedrigeren effektiven Preis. Overage, also Verbrauch über das Kontingent hinaus, läuft (sofern aktiviert) auf der Staffel weiter, statt wieder beim Höchstpreis zu beginnen.
- Sie zahlen für erfolgreiche Requests. Blockierungen und Fehler auf Seiten von Crawlbase sind kostenlos; ein echter 404 der Site ist dagegen eine gelieferte Antwort.
- Prüfen Sie die Stufe einer Site im Playground, bevor Sie skalieren, und nicht erst auf der ersten Rechnung.
So funktioniert die gestaffelte Preistabelle
Die Preistabelle funktioniert wie die Stufen der Einkommensteuer. Der erste Teil Ihres monatlichen Verbrauchs wird zum ersten Preis abgerechnet, der nächste Teil zum zweiten und so weiter. Wer eine Schwelle überschreitet, zahlt für den folgenden Verbrauch weniger; was bereits verbraucht wurde, wird nie neu bepreist. Die Pay-as-you-go-Preise für erfolgreiche Standard-Requests lauten:
| Monatliche Volumenstufe | Preis pro 1,000 erfolgreiche Standard-Requests |
|---|---|
| Erste 1,000 | $3.00 |
| Nächste 10,000 | $2.00 |
| Nächste 100,000 | $0.60 |
| Nächste 1 Million | $0.50 |
| Nächste 10 Millionen | $0.10 |
| Nächste 100 Millionen | $0.05 |
| Nächste 1 Milliarde | $0.04 |
| Darüber hinaus | $0.02 |
Über alle Stufen gerechnet kosten 100,000 erfolgreiche Standard-Requests $76.40, also etwa $0.76 pro 1,000. Eine Million kostet $527.50, etwa $0.53 pro 1,000, und zehn Millionen kosten $1,471.90, etwa $0.15 pro 1,000:
100,000 standard requests first 1,000 x $3.00 / 1,000 = $3.00 next 10,000 x $2.00 / 1,000 = $20.00 next 89,000 x $0.60 / 1,000 = $53.40 total = $76.40
Diese Zahlen gelten für Standard-Requests. Requests an schwierigere Sites oder mit JavaScript-Rendering tragen einen Multiplikator, daher reicht die reine Anzahl der Requests nicht, um einen gemischten Workload zu prognostizieren. Der Preisrechner übernimmt die Rechnung für Standard-, mittlere und komplexe Sites, jeweils mit oder ohne JavaScript.
Was ein Request kostet
Ein erfolgreicher Request an eine Standard-Site verbraucht einen Credit. Der Preis für alles andere ergibt sich aus drei Regeln: der Schwierigkeitsstufe der Site, ob die Seite einen echten Browser braucht und ob Sie das Ergebnis speichern.
| Request oder Vorgang | Credits |
|---|---|
| Standard-Site, erfolgreicher Request | 1 |
| Mittlere Site | 1.5 |
| Komplexe Site | 2 |
| Stark geschützte Sites | Höhere Stufen, bis zu 20 |
| JavaScript-Rendering | 2x die Stufe der Site |
| Screenshot | Abgerechnet wie ein JavaScript-Request: 2 auf einer Standard-Site |
| Speichern der Seite in Cloud Storage | +0.5 pro gespeicherter Seite, 30 Tage aufbewahrt |
Die Stufe wird der Domain automatisch zugewiesen; Sie wählen sie nicht selbst. JavaScript-Rendering verdoppelt die jeweilige Stufe: Ein gerenderter Request an eine Standard-Site kostet 2 Credits, an eine mittlere Site 3. Ein Screenshot braucht einen echten Browser und wird deshalb wie ein gerenderter Request abgerechnet: 2 Credits auf einer Standard-Site, mehr auf schwierigeren. Das Speichern einer Seite kostet beim Speichern einen halben Credit zusätzlich, und gespeicherte Seiten werden 30 Tage aufbewahrt.
Die Stufe einer Site vor dem Skalieren prüfen
Raten müssen Sie nicht. Öffnen Sie den Playground in der Konsole und geben Sie eine Ziel-URL ein: Er zeigt die Domain, ihre Stufe, den Multiplikator und die Credits, die ein erfolgreicher Request verbraucht. Für https://www.amazon.com/dp/1098145356 zeigt er amazon.com · Moderate · 1.5x.
Die Schätzung passt sich an, wenn Sie die Optionen ändern. Ist Store result aktiviert (die Standardeinstellung), zeigt das Amazon-Beispiel 2 Credits: 1.5 für den Request plus 0.5 für das Speichern. Schalten Sie das Speichern ab, sind es 1.5; schalten Sie JavaScript ein, verdoppelt sich der Request-Anteil auf 3. Der Screenshot-Modus aktiviert JavaScript automatisch, weil ein Screenshot einen Browser braucht. Run request schickt einen Live-Test ab, und Copy as cURL liefert Ihnen denselben Aufruf zur Wiederverwendung im eigenen Code. Verteilt sich ein Workload auf mehrere Domains, ist die Prüfung jeder einzelnen hier der schnellste Weg, nicht länger jede Site so zu behandeln, als koste sie gleich viel.
Pay-as-you-go oder Abonnement
Beide Varianten nutzen dasselbe Guthaben und dieselben Produkte. Der Unterschied liegt darin, wie Sie es finanzieren.
Pay-as-you-go kommt ohne Monatsgebühr aus. Abgerechnet wird monatlich und nachträglich für Ihren erfolgreichen Verbrauch, zu den oben genannten gestaffelten Preisen. Das passt zu Tests, gelegentlichen Jobs und Workloads, deren Volumen schwer vorherzusagen ist.
Ein Abonnement kauft ein monatliches Credit-Kontingent zu einem niedrigeren effektiven Preis:
| Plan | Credits pro Monat | Monatspreis |
|---|---|---|
| Starter | 200,000 | $99 |
| Scale 500K | 500,000 | $199 |
| Scale 1M | 1,000,000 | $349 |
| Growth | 2,000,000 | $599 |
Das Kontingent wird mit jedem monatlichen Abrechnungszyklus zurückgesetzt, und bei jährlicher Abrechnung gibt es einen Rabatt. Die Preisseite zeigt stets die aktuellen Pläne. Abonnements eignen sich für gleichmäßige Workloads wie tägliche Katalog-Aktualisierungen oder kontinuierliches Preis-Monitoring. Für sehr große oder spezielle Workloads decken Enterprise-Konditionen individuelles Volumen, Durchsatz- und SLA-Zusagen sowie die Rechnungsstellung ab.
Wenn das Kontingent aufgebraucht ist
Ist Pay-as-you-go-Overage aktiviert, laufen Requests weiter, nachdem das monatliche Kontingent aufgebraucht ist. Zuerst wird das Kontingent verbraucht, der Verbrauch danach wird als Overage abgerechnet. Die Staffel beginnt nicht von vorn: Hat Ihr Plan-Verbrauch Sie bereits über die ersten Stufen hinausgetragen, setzt Overage dort an, wo Sie angekommen sind, und nicht bei $3 pro 1,000.
Ist Overage deaktiviert, pausieren Requests, sobald das Kontingent verbraucht ist, und laufen weiter, wenn der Plan verlängert wird. Zusätzlich zu beiden Einstellungen können Sie Ausgabenlimits setzen: eines für das Konto in Dollar und eines pro Workspace in Credits. Ist ein Limit erreicht, werden keine neuen Requests mehr ausgeführt.
Welche Einstellung die richtige ist, ist eine Produktentscheidung, keine Abrechnungsfrage. Ein Live-Bestandsfeed legt vielleicht Wert auf Kontinuität und erlaubt Overage; ein Research-Batch mit festem Budget bevorzugt eher einen harten Stopp. Entscheiden Sie, bevor der Workload sein Kontingent erreicht, statt es an einer pausierten Pipeline zu bemerken.
Ein Guthaben für alle Produkte, eine gestaffelte Preistabelle und Abrechnung nur für erfolgreiche Requests. Starten Sie mit kostenlosen Credits, bis zu 5,000 beim Abschluss des Onboardings, ganz ohne Kreditkarte.
Ein Guthaben für alle Produkte
| Produkt | Rolle in der Pipeline |
|---|---|
| Crawling API | Seiten als HTML, JSON oder Markdown abrufen, gerendert, wenn sie einen Browser brauchen |
| Enterprise Crawler | Große URL-Batches in die Queue stellen und Ergebnisse asynchron empfangen |
| Smart AI Proxy | Traffic Ihres eigenen HTTP-Clients über verwaltete Proxys und Anti-Bot-Handling leiten |
| Cloud Storage | Abgerufene Seiten 30 Tage aufbewahren und ohne erneutes Crawlen wieder auslesen |
| Crawlbase Web MCP Server | KI-Agenten Tools für Crawling, Markdown und Screenshots geben |
Eine Pipeline für Produktdaten könnte Seiten über die Crawling API abrufen, nächtliche Aktualisierungen über den Enterprise Crawler anstoßen und ausgewählte Seiten in Cloud Storage aufbewahren. Alle drei verbrauchen aus demselben Guthaben, jedes nach seiner eigenen Regel. Der Web MCP Server selbst ist kostenlos; die API-Requests, die er auslöst, kosten so viel, als würden Sie die API direkt aufrufen. Konten, die noch ein Legacy-Paket für Smart AI Proxy haben, werden weiter über dieses Paket abgerechnet, bis sie auf einen Plan wechseln.
Ein gemeinsamer Pool erspart es nicht, den Verbrauch pro Workload zu verfolgen, aber Sie behalten ein einziges Guthaben im Blick statt eines vorausbezahlten Budgets pro Integration.
Was abgerechnet wird
Sie zahlen für erfolgreiche Requests. Ein Request wird abgerechnet, wenn Crawlbase eine verwertbare Antwort der Site erhalten hat: die Seite selbst, eine verfolgte Weiterleitung oder einen echten 404 oder 410, denn „diese Seite existiert nicht mehr“ ist eine echte Antwort. Blockierungen wie 403 und 429, Timeouts und Fehler auf Seiten von Crawlbase werden nicht abgerechnet.
Dadurch wird die Arbeit mit unzuverlässigen Zielen günstiger, denn fehlgeschlagene Versuche landen nicht auf der Rechnung. Kostenlos im umfassenden Sinn sind Fehlschläge damit aber nicht: Sie verbrauchen weiterhin Concurrency und Zeit. Setzen Sie vernünftige Timeouts und Retry-Limits und behalten Sie die Erfolgsquote im Blick, denn erfolgsbasierte Abrechnung reduziert verschwendete Ausgaben, ersetzt aber kein gutes Request-Management.
Einen Monat schätzen, bevor Sie skalieren
- Erfolgreiches Volumen schätzen für jeden Workload, nicht die Anzahl der URLs in der Queue.
- Nach Stufe und Rendering aufteilen, wobei der Playground die Stufe jeder Domain liefert.
- Zusatzkosten einrechnen, vor allem Screenshots und Seiten, die Sie in Cloud Storage aufbewahren.
- Pay-as-you-go mit einem Abonnement vergleichen, dann über Overage und Ausgabenlimits entscheiden.
Der Rechner berücksichtigt die Staffel und die gängigen Multiplikatoren. Vergleichen Sie nach den ersten Produktivläufen die Schätzung mit den tatsächlich verbrauchten Credits und justieren Sie nach. Hintergründe dazu, warum Crawlbase pro erfolgreichem Request abrechnet, finden Sie unter Crawlbase-Preise erklärt.
Fazit
Der eigentliche Nutzen von einem Guthaben und einer Preistabelle liegt nicht darin, dass jeder Workload bei denselben Stückkosten landet. Er liegt darin, dass sich Kosten über ein System mit mehreren beweglichen Teilen hinweg nachvollziehen lassen: die Stufe jeder Site prüfen, Rendering und Speicherung einrechnen, die Zahlungsweise wählen und vorab festlegen, was passiert, wenn das Kontingent aufgebraucht ist.
Vergleichen Sie die Pläne und rechnen Sie selbst nach, direkt auf der Preisseite, oder erstellen Sie ein kostenloses Konto und testen Sie Ihre eigenen Ziel-Sites, bevor Sie sich auf etwas festlegen.
Häufig gestellte Fragen (FAQs)
Kostet jeder Request gleich viele Credits?
Nein. Ein erfolgreicher Request an eine Standard-Site kostet einen Credit. Schwierigere Sites tragen einen Multiplikator von 1.5 bis 20, JavaScript-Rendering verdoppelt die Stufe der Site, ein Screenshot wird wie ein gerenderter Request abgerechnet, und das Speichern einer Seite kostet einen halben Credit zusätzlich.
Werden fehlgeschlagene oder blockierte Requests berechnet?
Nein. Blockierungen wie 403 und 429, Timeouts und Fehler auf Seiten von Crawlbase werden nicht abgerechnet. Ein Request wird abgerechnet, wenn er eine verwertbare Antwort der Site liefert, und dazu gehört auch ein echter 404 oder 410 für eine Seite, die nicht mehr existiert.
Wenn mein Abonnement aufgebraucht und Overage aktiviert ist, beginnt die Abrechnung dann wieder in der obersten Stufe?
Nein. Overage setzt in der Stufe fort, die Ihr Verbrauch bereits erreicht hat, statt wieder beim Höchstpreis zu beginnen. Ist Overage deaktiviert, pausieren Requests bis zur Verlängerung des Plans, und die Kontingente werden mit jedem monatlichen Abrechnungszyklus zurückgesetzt.
Kann ich dieselben Credits für verschiedene Produkte nutzen?
Ja. Die Crawling API, der Enterprise Crawler, Smart AI Proxy, Cloud Storage und die API-Aufrufe über den Crawlbase Web MCP Server verbrauchen alle aus demselben Guthaben, jedes nach seiner eigenen Regel. Konten, die noch ein Legacy-Paket für Smart AI Proxy nutzen, rechnen diesen Traffic über das Paket ab.
Wie lange bewahrt Cloud Storage eine Seite auf?
Dreißig Tage. Das Speichern einer Seite kostet beim abrufenden Request einen halben Credit zusätzlich, das erneute Auslesen ist kostenlos.
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.