Apify-Alternativen für Web Scraping in großem Umfang (über 1 Mio. Seiten)

Bei einer Million Seiten ist der Crawler selbst selten der Kostentreiber. Es sind Proxy-Bandbreite, fehlgeschlagene Retries und Browser-Rendering. Wenn Sie Apify-Alternativen bewerten, reicht ein Vergleich der Listenpreise deshalb nicht aus: Entscheidend ist, wie jedes Werkzeug in der Praxis mit diesen Kosten umgeht.

Ein Wechsel von Apify auf eine andere Plattform allein macht das Scraping nicht automatisch günstiger. Ein wirksamerer erster Schritt ist es, die Seiten herauszutrennen, die wirklich einen Browser brauchen. Wenn eine API oder eine einfache HTTP-Anfrage die benötigten Daten schon liefert, greifen Sie darauf zurück. Nur Aufgaben mit JavaScript-Rendering, Klicks zur Paginierung, Formularübermittlung oder angemeldeter Sitzung müssen über einen Browser laufen.

Sobald Sie die Arbeitslast so aufteilen, wird viel klarer, welches Werkzeug zu welcher Aufgabe passt. Apify, Firecrawl oder ein selbst gehosteter Crawler eignen sich für große Mengen öffentlicher, direkt zugänglicher Daten. Wenn der Workflow die Schritte erreicht, die wirklich von Browserzustand und Interaktion abhängen, kann ego (lite) übernehmen.

Der Grund: Bei diesen Aufgaben geht es nicht mehr nur darum, eine Seite abzurufen. Der Agent muss mit gerendertem Inhalt, dem aktuellen Browserzustand und der Interaktion mit der Seite arbeiten, und je nachdem, was die Seite zurückliefert, kann sich die nächste Aktion ändern. ego (lite) läuft direkt in einem echten Browser, sodass der Agent die aktuelle Seite auslesen, die Interaktion fortsetzen und Ihnen die Kontrolle ganz selbstverständlich zurückgeben kann, wenn ein Schritt menschliches Urteilsvermögen oder eine manuelle Übernahme erfordert.

Bei groß angelegten Projekten ist der bessere Plan also meist nicht, ein einziges Werkzeug zu finden, das den gesamten Apify-Workflow ersetzt. Vielmehr gilt es, je Aufgabenart den passenden Ausführungsmodus zu wählen: die Teile, die eine API oder ein HTTP-Aufruf erledigen kann, einfach halten, das Massen-Crawling öffentlicher Daten einem spezialisierten Crawler überlassen und ego (lite) für die Schritte nutzen, die wirklich von einer Browserumgebung und Interaktion abhängen. So bleiben die Kosten unter Kontrolle, und Sie zahlen keine Browser-Laufzeit für Aufgaben, die nie einen Browser gebraucht hätten.

Was kostet ein Crawl über eine Million Seiten auf Apify?

Nach den Zahlen unten etwa 430 $ bis 1.300 $, und mehr als 80 % davon sind Proxy-Bandbreite und nicht das Crawling.

Die Tarife hinter dieser Rechnung stehen auf Apifys Preisseite.

Wie Compute Units gezählt werden, steht in Apifys Dokumentation zu Nutzung und Ressourcen.

Diese Schätzung basiert auf Apifys veröffentlichten Tarifen, nicht auf einer Rechnung oder einem Angebot. Sie geht von einer Million Ziel-URLs aus, einem HTTP-Durchlauf im Cheerio-Stil für die tragende Mehrheit davon, Browser-Rendering für etwa 100.000 Seiten, die wirklich JavaScript benötigen, und Residential-Proxys für den gesamten Lauf.

Eine Unterscheidung ist bei dieser Größenordnung wichtiger als alle anderen. Anfragevolumen ist nicht Seitenvolumen. Wenn 85 % Ihrer Anfragen beim ersten Versuch erfolgreich sind, sind eine Million Zielseiten nach Retries eher 1,15 bis 1,3 Millionen Anfragen. Sie zahlen für die Anfragen und für deren Bandbreite, auch für die, die leer zurückkommen.

Unser Kostenmodell, Position für Position.

Lesen Sie das als Rechenübung auf Basis veröffentlichter Preise. Wir legen Apifys Tarife auf eine definierte Arbeitslast um, und die Annahmen zur Arbeitslast sind angegeben, damit Sie Ihre eigenen einsetzen können.

Zwei Zahlen in dieser Tabelle verdienen einen zweiten Blick, denn hier gehen Budgets tatsächlich schief.

Die erste ist die 1024MB-Position. Neue Apify-Nutzer nehmen routinemäßig an, dass mehr Speicher mehr kostet. In CU-Begriffen stimmt das nicht: Ein Job, der doppelt so viel Speicher braucht, ist in der halben Zeit fertig, und abgerechnet wird das Produkt aus beidem. Speicher ist ein Scheduling-Regler, kein Kostenhebel.

Die zweite ist die Proxy-Position. Beachten Sie, dass die Plattform hier buchstäblich nicht der dominierende Kostenfaktor sein kann: Bei 0,20 $ bis 0,13 $ pro CU je nach Stufe müssten Sie über 2.000 Compute Units verbrennen, um eine einzige moderate Bandbreitenrechnung zu erreichen.

Wenn Ihr Crawl teuer ist, zahlen Sie für Bandbreite, nicht für Orchestrierung.

Wie rechnet Apifys Compute-Unit-Modell tatsächlich ab?

Eine Compute Unit ist 1GB Speicher, der eine Stunde lang gehalten wird, gemessen in Sekundengranularität, und sie ist die einzige Einheit, gegen die die Plattform Crawling abrechnet.

Speicher mal Dauer. Ein Lauf, der eine Stunde lang 1024MB hält, verbraucht genau eine CU. Derselbe Lauf mit 4096MB für fünfzehn Minuten verbraucht ebenfalls eine CU. Deshalb bewegt sich die CU-Spalte in unserem Modell so wenig, wenn Sie die Worker-Größen ändern: Die Arbeit bleibt die Arbeit.

Ein paar Eigenschaften des Modells sollten Sie verinnerlichen:

1. Cheerio ist keine kleine Optimierung. Apifys eigene Empfehlung nennt einen HTTP-Durchlauf im Cheerio-Stil bis zu 20-mal schneller als denselben Job im Browser. Dieser Faktor ist es, der 170 CU für eine Million Seiten in Reichweite hält.
2. Die Parallelität, nicht die Worker-Größe, bestimmt Ihre Wandzeit. Die Limits pro Tarif reichen von 25 gleichzeitigen Runs im Free-Tarif bis 256 im Business-Tarif, mit kombinierten Speicherobergrenzen von 16.384MB, 65.536MB, 262.144MB und 524.288MB über diese Stufen hinweg. Bei 32 gleichzeitigen Aufgaben und rund 3.200 Seiten pro Minute sind eine Million Seiten etwa 5,2 Stunden.
3. Manche Actors haben harte Speicheruntergrenzen. Ein Browser-Actor läuft nicht unter 1024MB, und der Google-Maps-Scraper braucht 4096MB oder mehr. 4096MB ist der pragmatische Standard, wenn Sie lieber nicht pro Actor optimieren möchten.
4. Credits lassen sich nicht übertragen. Ungenutzte monatliche Credits verfallen. Wenn Ihr Crawling stoßweise läuft, ein riesiger Lauf pro Quartal statt eines stetigen Tropfens, zahlen Sie für Kapazität, die Sie nicht genutzt haben.

Nichts davon spricht gegen Apify. Es ist eine der wenigen Plattformen, deren Stückkosten Sie anhand veröffentlichter Dokumentation nachvollziehen können, und das CU-Modell ist wirklich ehrlich: Es rechnet Arbeit ab, nicht Zeilen. Das Problem ist, was es nicht enthält.

Proxys. Rendering-lastige Actors. Speicher, der weiter anwächst, während ein Dataset einfach daliegt. Das sind die Positionen, die entscheiden, ob ein Crawl über eine Million Seiten hunderte oder tausende kostet, und es sind dieselben Positionen bei jeder Apify-Alternative, die Sie in Betracht ziehen.

Welche sind die wichtigsten Apify-Alternativen für Scraping in großem Umfang?

Es gibt vier Arten von Alternativen, und nur eine davon hat dieselbe Preisform wie Apify.

Die meisten Listen mit Apify-Alternativen sind in Wahrheit Listen anderer Tools, die Websites scrapen, und das ist eine andere Frage. Wenn Ihr Crawl teuer statt undurchführbar ist, ist die relevante Achse nicht die Features, sondern wofür jeder Anbieter Ihnen Geld berechnet. Preis pro Compute-Stunde, Preis pro Credit, Preis pro Gigabyte Proxy-Traffic und Preis pro Operator-Stunde verhalten sich alle unterschiedlich, wenn das Volumen wächst.

1. Firecrawl. Credit-basierte Scraping-API mit LLM-fähiger Ausgabe. Ein Scrape ist ein Credit, und jedes optionale Ausgabeformat kostet mehr: Der JSON-Modus kostet +4, Frage- oder Highlight-Extraktion +4 pro Format, PII-Redaktion +4. Die Stufen reichen von 0 $, 20 $, 106 $, 424 $ und 762 $ für 1.000, 5.000, 100.000, 500.000 und 1.000.000 Credits pro Monat.
2. ZenRows. Managed Fetching mit JS-Rendering und Proxy-Rotation. Die Credits reichen von 5.000 in der 16-$-Stufe bis 5 Millionen in der 456-$-Stufe, mit Parallelität von 5 bis 200 und individuell darüber. JavaScript-Rendering vervielfacht die Credit-Kosten um den Faktor 10, der kombinierte JS-plus-Proxy-Modus um 25. Fehlgeschlagene und wiederholte Anfragen werden nicht abgerechnet.
3. ScraperAPI. Credit-basiertes Fetching mit einer geradlinigen Parallelitätsleiter, von 20 in der 49-$-Stufe bis über 500 am oberen Ende, mit 100.000 bis 10,5 Millionen Credits.
4. Bright Data und Oxylabs. Proxy-first-Anbieter, die auch verwaltete Scraper verkaufen. Oxylabs listet SERP-Preise von 0,50 $ bis 1,35 $ pro Unit-Sequence und Residential-Bandbreite von 3 $/GB bis herunter zu 2 $/GB bei Volumen. Bright Datas Web-Scraper-Seite stützt sich auf die Behauptung unbegrenzter Parallelität, ohne Preise zu veröffentlichen. Das ist eine Behauptung, die wir nicht prüfen können, und deshalb wiederholen wir sie nicht als Tatsache.
5. Selbst gehostete Crawler. Eine Scrapy- oder Playwright-Pipeline auf Ihrer eigenen Infrastruktur. Überhaupt keine Gebühr pro Seite oder pro CU, und Ihre Proxy-Rechnung bleibt Ihre Proxy-Rechnung. Der Preis dafür ist, dass Warteschlangenverwaltung, Retries, Scheduling und Monitoring dauerhaft Ihr Problem werden.
6. Agentengesteuerte Browser. Das ist der Weg, an dem wir arbeiten, lesen Sie ihn also mit diesem Hintergrund. ego (lite) ist ein Chromium-Browser, der Ihre bestehenden Logins und Erweiterungen übernimmt, und ein Coding-Agent steuert ihn über den ego-browser Skill in einem eigenen isolierten Space. Dorthin geht ein Workflow, wenn statische Anfragen nicht mehr ausreichen: ein Anmeldeschritt, eine Ansicht, die nur unter JavaScript rendert, eine hinter einem Klick versteckte Paginierung, ein Filter, der ein Formular ist, ein Code, den Sie aus einem Posteingang ablesen müssen. Er ist kostenlos und läuft heute auf macOS, Windows und Linux stehen auf der Roadmap. Es gibt keinen Preis pro Seite, den man gegen Apifys Rate stellen könnte, die Frage ist also nicht, was pro Seite billiger ist. Sondern ob Ihr Workflow überhaupt eine Sitzung braucht.

Warum dominiert die Proxy-Bandbreite die Rechnung?

Weil es die einzige Position ist, die mit der Größe der Seiten skaliert, die Sie herunterladen, und nicht mit der Menge an Arbeit, die Sie leisten.

Wie dieser Weg bei einer gleichwertigen Browser-Aufgabe abschneidet, ist ego (lite) vs. Playwright der direkte Vergleich.

Wie Sie eine angemeldete Sitzung über mehrere Läufe hinweg am Leben halten, steht in persistenten Browser-Sitzungen über Agent-Läufe hinweg.

Compute skaliert mit der CPU-Zeit. Parallelität skaliert mit der Tarifstufe. Bandbreite skaliert mit dem Internet. Ein Megabyte HTML bleibt ein Megabyte, ob es nun eine Millisekunde oder eine Sekunde gebraucht hat, und Residential-Proxy-Traffic wird pro Gigabyte abgerechnet: 8 $/GB bei Apify, 3 $/GB bis herunter zu 2 $/GB bei Volumen bei Oxylabs.

Bei 50KB komprimiertem HTML pro Seite sind eine Million Seiten etwa 50GB. Das sind 400 $ zu Apifys gelistetem Tarif, bevor Sie Retries mitzählen, und es wird schlimmer, je schwieriger das Ziel ist: Bot-geschützte Seiten sind schwerer, brauchen oft mehrere Anfragen zur Auflösung und können bis zu dreimal so viele Ressourcen verbrauchen wie eine freundliche Seite.

Hier ist der unangenehme Teil. Der größte Teil dieser Bandbreite ist verschwendet, und das wissen Sie bereits. Eine Produktlistenseite mag 400KB aus HTML, CSS, JavaScript, Schriften und Tracking-Pixeln sein, damit Sie einen Preis und einen Lagerstatus lesen können, während das eigentliche Signal vielleicht 2KB groß ist. Sie zahlen Residential-Tarife, um die Verpackung zu transportieren.

Drei Hebel reduzieren das, und sie sind mehr wert als jeder Anbieterwechsel. Beschränken Sie den Crawl auf die Seiten, die die Daten tragen, statt jedem Link zu folgen. Rufen Sie strukturierte Endpunkte ab, wo eine Seite sie anbietet, denn JSON-Antworten sind nur ein Bruchteil des gerenderten Seitengewichts. Und rendern Sie nur dort, wo Rendering nötig ist, was in unserem Modell 100.000 von einer Million Seiten sind.

Wie schneiden die Apify-Alternativen im Vergleich ab?

Nach veröffentlichten Tarifen liegt die Spanne zwischen dem günstigsten und dem teuersten Weg bei etwa dem Zehnfachen, und nichts davon kommt vom Crawling selbst.

Lesen Sie jede Zeile auf zwei Dinge hin: wofür der Anbieter Geld berechnet und was er Sie nicht tun lässt. Ein Preis ohne Obergrenze ist Marketing. Eine Obergrenze ohne Preis ist ein Vertriebsanruf.

Die Firecrawl-Zeile wird am häufigsten falsch gelesen, daher lohnt es sich, sie auszubuchstabieren. Eine Million Credits klingt nach einer Million Seiten, und bei einem reinen Scrape stimmt das. Fügen Sie JSON-Extraktion hinzu, haben Sie fünf Credits pro Seite ausgegeben, dieselben 749 $ decken also 200.000 Seiten ab. Das ist kein Preistrick. Es sind echte Kosten für echte Arbeit, und es bedeutet, dass die Zahl, mit der Sie budgetieren, nicht die Zahl auf der Tarifkarte ist.

Firecrawls eigene Dokumentation ist ungewöhnlich offen über die andere Einschränkung: Ihr eigentlicher Engpass werden gleichzeitige Browser sein. Der Free-Tarif beginnt bei zwei, Hobby bei fünf, Standard bei 25, Growth bei 50, Scale bei über 100. Bei 100 gleichzeitigen Seiten und großzügigen zwei Sekunden pro Seite sind das etwa 50 Seiten pro Sekunde, also rund 5,6 Stunden für eine Million. Es funktioniert, aber Sie können sich mit Credits allein nicht daran vorbeikaufen.

Firecrawls Parallelitätsstufen stammen aus der eigenen Preisseite.

Für den Vergleich der Scraping-Bibliotheken hinter dieser Wahl siehe Playwright vs. Puppeteer für Web Scraping.

ZenRows löst eine andere Variante desselben Problems, indem Retries kostenlos werden. Nicht für fehlgeschlagene oder wiederholte Anfragen abgerechnet zu werden, ist ein echter Vorteil bei feindlichen Zielen, und so etwas sollten Sie prüfen, bevor Sie annehmen, dass ein günstigerer Listenpreis gewinnt.

Welche Kriterien entscheiden über eine Apify-Alternative?

Vier Zahlen entscheiden darüber, und drei davon sind Eigenschaften Ihrer Arbeitslast und nicht eines Anbieters.

Feature-Matrizen sind in dieser Größenordnung meist Rauschen, weil jeder Anbieter dieselbe Kernaufgabe erledigt. Was sie unterscheidet, ist, wie sich ihre Abrechnung verhält, wenn Ihr Crawl um eine Größenordnung wächst, und ob die Obergrenze, die sie setzen, vor oder nach diesem Wachstum erreicht wird.

Beachten Sie, wie wenig in dieser Tabelle um Features geht. Die Anbieter, die um die Suchanfrage Apify alternatives konkurrieren, konkurrieren meist über dieselbe Checkliste: Proxy-Pools, JS-Rendering, CAPTCHA-Behandlung, Integrationen. Diese Checklisten konvergieren tendenziell. Die Form der Abrechnung konvergiert nicht, und sie entscheidet über Ihre Rechnung.

Wie wählen Sie eine Apify-Alternative aus?

Bringen Sie Ihre Antwort mit Ihrem Rendering-Anteil und Ihrem Autorisierungsstatus in Einklang, und die Auswahlliste schrumpft auf eine Zeile.

1. Statisches HTML, öffentlich, über eine Million Seiten. Bleiben Sie auf einer CU-abgerechneten Plattform oder hosten Sie selbst, und stecken Sie Ihre Energie in Proxy-Tarife und die Reduzierung des Seitengewichts. Ein Wechsel zwischen Plattformen spart bei diesem Rendering-Anteil einstellige Prozentbeträge.
2. Überwiegend statisch, mit einer hartnäckigen gerenderten Minderheit. Teilen Sie den Crawl. Günstige Abrufe für die Mehrheit, einen Rendering-Pfad für den Rest. Das ist die Entscheidung mit der höchsten Rendite überhaupt, und sie kostet nichts.
3. Durchgehend JavaScript-lastig, öffentliche Daten. Credit-basierte APIs verdienen ihren Aufpreis hier, wenn sie die Extraktion für Sie übernehmen, denn Sie kaufen dann Token und strukturierte Ausgabe statt nur Bytes. Planen Sie die Format-Multiplikatoren ein, bevor Sie eine Stufe wählen.
4. Feindliche Ziele und häufige Blockierungen. Kalkulieren Sie Retries, nicht Anfragen. Ein Anbieter, der Fehler nicht abrechnet, kann bei höherem Listenpreis günstiger sein.
5. Hinter einem Login oder einem internen Dashboard. Hören Sie auf, Crawler-Preise zu vergleichen. Das ist autorisierte, sitzungsabhängige Arbeit, und sie läuft in einem Browser, der die Sitzung bereits hält, und genau dafür ist ego (lite) gedacht. Lesen Sie unsere Ausführungen zu Scraping hinter Login-Schranken für die Mechanik, und machen Sie klar, dass kein Tool hier die Zugriffskontrollen einer Website umgeht.
6. Ein paar hundert Seiten, oft aktualisiert. Nichts davon trifft zu. Sie sind nicht in der Größenordnung, in der Kostenmodelle interessant werden, und ein No-Code-Tool ist wahrscheinlich die richtige Wahl. Unser Leitfaden zu KI-Tools für Web Scraping behandelt die No-Code-, API- und agent-browser-Wege mit genau diesem Umfang.

Wenn Sie eher gehostete Browser-Infrastruktur als speziell Crawler abwägen, gilt dieselbe Logik eine Ebene tiefer: Headless-Browser versus echter Browser ist die Entscheidung, die bestimmt, ob Ihre Kosten pro Seite überhaupt vom Rendering dominiert werden.

Wann lohnt es sich, ego (lite) in den Workflow aufzunehmen?

Eine statische Anfrage reicht an fünf konkreten Punkten nicht mehr aus: eine Anmeldung, eine Ansicht, die nur unter JavaScript rendert, eine Paginierung hinter einem Klick, ein Filter, der eigentlich ein Formular ist, und ein Verifizierungsschritt.

Diese fünf lohnt es sich zu benennen, weil ein Abruf sie nicht aus eigener Kraft überwindet. curl liefert die Login-Seite zurück und meldet 200. Das HTML kommt an, und die Zeilen sind nicht darin. Seite zwei existiert, aber erst nach einem Klick, der innerhalb einer Anfrage nie stattfindet. Die Daten, die Sie wollen, liegen hinter einem Formular statt hinter einem Query-String. Das Konto verlangt einen Code aus einem Posteingang, den Sie in einem anderen Tab geöffnet haben.

Wenn das passiert, ist die Lösung kein größerer Crawler. Sondern derselbe Workflow in einem Browser, der die Sitzung bereits mitbringt.

Damit das nicht Theorie bleibt, haben wir eine Aufgabe auf beiden Wegen ausgeführt und die Belege behalten. Die Aufgabe: die ersten drei nicht gesponserten Fischöl-Einträge aus einer Amazon-Suche ziehen, mit Name, Marke, Preis, Bewertung, Anzahl der Rezensionen und Größe. Ein Durchlauf über ego (lite), ein Durchlauf über reines HTTP mit einem Skript. Beide liefen am selben Tag auf derselben Maschine, und beide Läufe sind unten zu sehen.

Der Weg über den Browser, Schritt für Schritt

Der Browser-Durchlauf besteht aus vier Teilen: die Eingaben, die Sie übergeben, die Schritte, die der Agent ausführt, was passiert, wenn er auf etwas stößt, das er nicht allein entscheiden sollte, und wie Sie das Ergebnis prüfen. Hier ist jeder davon anhand einer echten Produktsuche.

1. Eingaben. Die Such-URL, ein bereits angemeldetes Amazon-Konto und ein Satz, der die zu sammelnden Felder beschreibt. ego (lite) ist Chromium und übernimmt Ihre bestehenden Logins, Erweiterungen und den Verlauf, es gibt also keinen Cookie-Export-Schritt und keine Zugangsdaten, die irgendwo eingefügt werden müssten. Der ego-browser Skill ist an den Browser gebunden und wird zusammen mit ego (lite) installiert, und Sie aktivieren ihn, indem Sie /ego-browser in das Chat-Feld des Agenten eingeben.

1. Zentrale Schritte. Der Agent öffnet einen eigenen Space, ein separates Fenster mit blauem Leuchten, damit er nicht die Tabs steuert, die Sie gerade nutzen. Darin navigiert der Agent, erstellt Snapshots der Seite, um ihre Struktur zu lesen, und erfasst, was er findet. Diese Snapshots lesen verschachtelte iframes, und genau dort scheitert renderingabhängige Extraktion meist.

3. Wiederherstellung bei Fehlern. Wenn der Lauf auf eine Anmeldung, einen Verifizierungscode oder etwas anderes stößt, das er nicht allein entscheiden sollte, hält er an und holt Sie in seinen Space, statt zu raten. Das dokumentierte Verhalten gilt auch am riskanteren Ende: Eine Jobbewerbung wartet auf Ihre Bestätigung vor dem endgültigen Absenden, und ein Buchungsvorgang läuft bis zur Zahlungsseite und hält dort an. Ein Crawler, der auf eine Login-Schranke trifft, protokolliert ein 200 und macht weiter. Dieser fragt nach.
4. Ergebnisprüfung. Prüfen Sie die gesammelten Zeilen gegen die Seite, auf der der Agent tatsächlich war, nicht gegen die URL, die Sie ihm übergeben haben. Der Snapshot, mit dem der Agent gearbeitet hat, ist der Beleg. Hier ist die einzige echte Anomalie des Laufs aufgetaucht, und so etwas existiert nur auf einer gerenderten Seite.

Dieselbe Aufgabe stattdessen über reines HTTP

Hier ist die ehrliche andere Hälfte, denn das interessante Ergebnis ist nicht, dass HTTP gescheitert ist. Sondern wo es Probleme hatte und was es gekostet hat, es zum Laufen zu bringen.

Der HTTP-Durchlauf erledigte dieselbe Aufgabe mit einem Skript und ohne Browser. Am Ende kam er ans Ziel. Das Log ist ein Protokoll davon, wie viel Transportarbeit zwischen beidem stand.

Eine gechallengte Anfrage ist ein harter Stopp. Aber die meisten 503er hier waren keine Challenges, und die beiden auseinanderzuhalten erforderte ein Experiment.

Den Transport neu zu schreiben war die Mitte des Problems, nicht sein Ende. Der Extraktor musste danach zweimal anhand derselben Seite korrigiert werden.

Beide Durchläufe erreichten also die drei Produkte. Der Unterschied liegt darin, was jeder investieren musste, um dorthin zu kommen. Der Browser-Lauf öffnete einen Space, las Seiten und endete mit einem Screenshot für jeden gemeldeten Wert. Der HTTP-Lauf schrieb sechs Skripte, tauschte wegen eines Fingerprint-Konflikts seinen HTTP-Client, fügte eine Retry-Schicht hinzu, korrigierte einen Bug bei der Sponsoring-Erkennung, korrigierte einen Währungs-Bug und endete mit einem Bericht, der einräumte, für das erste Produkt keine Ausgabe zu haben.

Das ist der Teil, den ein Kostenmodell pro Seite übersieht. Keiner der Ansätze ist falsch, und die Token- und Wandzeit-Zähler in diesen Screenshots liegen nah genug beieinander, dass Geschwindigkeit allein die Frage nicht entscheidet. Was sie trennt, ist, wohin die Zeit geht. Ein Weg verbringt sie damit, eine Seite zu lesen. Der andere verbringt sie damit, die Maschinerie zu bauen und zu debuggen, die das Lesen einer Seite ersetzt.

Bei drei Produkten ist diese Maschinerie der gesamte Aufwand, und sie rechnet sich nicht. Bei hunderttausend Seiten läuft derselbe Code einen Tag lang unbeaufsichtigt, und die Rechnung kippt vollständig.

Wann Sie ego (lite) überhaupt nicht brauchen

Reines HTTP deckt mehr von dieser Arbeit ab, als die Werkzeugdebatte vermuten lässt. Wenn die Seite ihre Daten im HTML zurückgibt, rufen Sie sie ab. Wenn die Website eine API veröffentlicht, nutzen Sie die API, denn sie ist der beabsichtigte Zugangsweg und übersteht Redesigns, die Selektoren brechen. Und wenn ein großer öffentlicher Crawl die ganze Aufgabe ist, ohne einen Schritt, der eine Sitzung braucht, schlägt eine gehostete Plattform oder eine credit-basierte API einen lokalen Browser beim Durchsatz.

Lesen Sie den Amazon-Fall auch in der richtigen Größenordnung. Er ist kein Beweis dafür, dass HTTP kaputt ist, denn HTTP erreichte die Daten. Und er ist kein Beweis dafür, dass der Browser schnell war, denn der Browser-Lauf dauerte ebenfalls über zwanzig Minuten und sein eigener Bericht verzeichnet einen Fehler. Was er zeigt, ist, wohin die Arbeit auf jeder Seite ging. Das einzige echte Problem des Browser-Wegs war das der Website, nicht das des Tools. Die Probleme des HTTP-Wegs waren alle seine eigenen.

Einen Browser zu einem Workflow hinzuzufügen, der keinen braucht, ist der häufigste Weg, einen Scraping-Job langsamer und teurer zu machen, als er sein müsste. Prüfen Sie zuerst den günstigen Weg, und halten Sie fest, was er kostet, wenn das Ziel eine Sitzung braucht.

Lohnt sich ein selbst gehosteter Crawler noch?

Oft ja, und der Grund ist Arithmetik und nicht Handwerkskunst: Bei Volumen zahlen Sie für eine Warteschlange und einen Scheduler, und beides sind Massenware.

Scrapy und Playwright sind kostenlos, gut dokumentiert und langweilig in der Art, wie Produktionsinfrastruktur sein sollte. Wenn Ihr Crawl ein wiederkehrender Job gegen stabile Ziele ist, entfernt eine selbst gehostete Pipeline die Plattformgebühr vollständig und lässt Ihnen die Serverkosten und die Proxy-Rechnung, die Sie ohnehin zahlen würden.

Das ehrliche Gegengewicht ist, dass die Plattformgebühr etwas Reales kauft. Retry-Logik, die fünf verschiedene Fehlermodi abdeckt. Ein Scheduler, der nicht driftet. Speicher, Logging und die Möglichkeit, ein Dataset erneut auszuführen, ohne die Produktion anzufassen. Teams unterschätzen konsequent, was das in Engineering-Stunden kostet, weil die Stunden im Kalender einer Person auftauchen und nicht auf einer Rechnung.

Eine grobe Regel: Hosten Sie selbst, wenn der Crawl wiederkehrend und die Ziele stabil sind. Mieten Sie, wenn der Crawl explorativ ist oder wenn die Seite, die Sie crawlen, alle paar Wochen ihre Form ändert. Die Plattformgebühr ist überwiegend eine Change-Management-Gebühr.

Wo geraten all diese Optionen an ihre Grenzen?

Drei Stellen, und sie sind es, die ein sauberes Kostenmodell in eine Kostenüberschreitung verwandeln.

Die erste ist, dass die Marketingaussagen jedes Anbieters seiner Dokumentation davonlaufen, und die Lücke ist genau dort am größten, wo Sie Präzision brauchen. Bright Datas Web-Scraper-Seite nennt unbegrenzte Parallelität und veröffentlicht auf derselben Seite keine Preise. Das ist keine Lüge, die wir widerlegen können; es ist eine Behauptung, die wir nicht prüfen können, und das ist etwas anderes und Nützlicheres zu wissen. Behandeln Sie jede Formulierung mit unbegrenzt, Enterprise-Grade oder unendlich als Anlass, die Zahl zu suchen, und wenn die Zahl nicht veröffentlicht ist, nehmen Sie an, dass die Obergrenze existiert und verhandelt wird.

Die zweite ist der Bot-Schutz, der weniger ein Feature ist, das Sie kaufen, als eine Bedingung, unter der Sie arbeiten. Effizienzgewinne durch einen schnelleren Abrufweg verdampfen, wenn jede Anfrage eine Residential-IP, eine warme Sitzung und ein Retry-Budget braucht. Unser Modell erreicht 1.300 $ nicht, weil ein Anbieter abzockt, sondern weil härtere Ziele schwerere Seiten und mehr verschwendete Anfragen bedeuten.

Die dritte ist die, die niemand in eine Vergleichstabelle schreibt: Das ist Infrastruktur für öffentliche Daten, und sie so zu nutzen liegt in Ihrer Verantwortung. Nutzungsbedingungen, robots-Direktiven, personenbezogene Daten unter DSGVO oder CCPA und der Unterschied zwischen den öffentlichen Seiten einer Website und den privaten Informationen ihrer Nutzer sind alles Fragen, die unabhängig davon sind, welches Tool Sie wählen. Ein billiger Crawler macht einen unzulässigen Crawl nicht zulässig. Wir sind keine Anwälte und das ist keine Rechtsberatung, aber der günstigste Crawl ist der, den Ihre Organisation tatsächlich verteidigen kann.

FAQ

Was ist die günstigste Apify-Alternative für eine Million Seiten?

Nach veröffentlichten Tarifen eine selbst gehostete Scrapy-Pipeline mit günstigen Proxys, weil es überhaupt keine Plattformgebühr gibt. Unter den verwalteten Optionen schlägt eine CU-abgerechnete Plattform mit HTTP-Durchlauf die credit-basierten APIs beim reinen Volumen. Aber die ehrliche Antwort ist, dass die Plattformwahl die kleinere Hälfte der Rechnung ist: Bei 8 $/GB Residential-Traffic kosten eine Million Seiten à 50KB etwa 400 $ an Bandbreite, egal wer sie abruft.

Ist Firecrawl ein guter Ersatz für Apify?

Für LLM-fähiges Markdown und strukturierte Extraktion ja: Es ist einfacher zu kalkulieren, und die Ausgabe spart Ihnen eine Parsing-Schicht. Für einen reinen Abruf von einer Million Seiten wird die Parallelitätsgrenze zur Einschränkung, bevor es das Credit-Guthaben wird. Der Free-Tarif erlaubt zwei gleichzeitige Browser, die Scale-Stufe über 100, der Durchsatz wird also vom Tarif begrenzt und nicht von den Ausgaben.

Rechnet Apify fehlgeschlagene Anfragen ab?

Ja, indirekt. Compute Units fallen für die Laufzeit an, unabhängig davon, was die Anfrage zurückgegeben hat, und Proxy-Bandbreite wird für die Übertragung verbraucht. Eine wiederholte Anfrage wird zweimal abgerechnet, ohne dass der erste Versuch etwas vorzuweisen hätte.

Warum sind Apify-Alternativen im großen Maßstab oft teurer?

In Plattform-Begriffen sind sie das meist nicht. Sie wirken teuer, weil Credit-Multiplikatoren sich nicht sauber auf Seiten abbilden lassen: Ein Scrape ist ein Credit, aber der JSON-Modus ist fünf, und JavaScript-Rendering kann bei einem proxy-basierten Anbieter zehn- oder fünfundzwanzigmal so viel sein wie ein einfacher Abruf. Multiplizieren Sie den Listenpreis mit dem Multiplikator, den Sie tatsächlich brauchen, und die Lücke schließt sich oder kehrt sich um.

Brauche ich Browser-Rendering für eine Million Seiten?

Fast nie für alle. Eine Arbeitsannahme ist, dass 90 % der Seiten als statisches HTML lesbar sind und 10 % JavaScript brauchen, weshalb unser Modell 100.000 Seiten rendert und den Rest abruft. Messen Sie Ihren Anteil an einer Stichprobe von 1.000 Seiten, bevor Sie budgetieren, denn er bewegt die Kosten stärker als jede Anbieterwahl.

Was ist mit Bright Data und Oxylabs als Apify-Alternativen?

Sie sind am stärksten, wenn die Proxys das Problem sind. Oxylabs listet Residential-Bandbreite von 3 $/GB bis herunter zu 2 $/GB bei Volumen, was deutlich unter Apifys 8 $/GB liegt, und SERP-Preise von 0,50 $ bis 1,35 $ pro Unit-Sequence. Bright Data veröffentlicht auf seiner Web-Scraper-Seite keine Preise und stützt sich auf eine Behauptung unbegrenzter Parallelität, die wir nicht prüfen konnten. Behandeln Sie das also als Angebot, das Sie anfordern sollten, und nicht als Tatsache, mit der Sie planen.

Die hier genannten Tarife für Residential-Bandbreite stehen auf Oxylabs' Preisseite.

Bright Datas Tarife, die auf der Scraper-Seite keine Preise pro GB veröffentlichen, beginnen auf seiner Preisseite.

Kann ich Apify durch ego (lite) ersetzen?

Sie decken unterschiedliche Schritte ab, es liest sich also weniger wie ein Ersatz und mehr wie eine Übergabe. Apify führt gehostete Crawls bei Volumen aus. ego (lite) ist ein kostenloser macOS-Browser, den ein Coding-Agent über eine Sitzung steuert, in der Sie bereits angemeldet sind, und Sie greifen darauf zurück, wenn ein Schritt einen Login, eine gerenderte Ansicht, einen Klick durch die Paginierung, ein Formular oder einen Verifizierungscode braucht. Wenn Ihre Aufgabe ein großer öffentlicher Crawl ist und darin nichts eine Sitzung braucht, brauchen Sie ego (lite) überhaupt nicht in der Pipeline.

Wie schätze ich die Proxy-Bandbreite vor einem Crawl?

Rufen Sie 1.000 repräsentative URLs ab, messen Sie die komprimierten Antwortgrößen und multiplizieren Sie. Dann addieren Sie den Retry-Faktor: Bei 85 % Erfolg beim ersten Versuch sind eine Million Ziele 1,15 bis 1,3 Millionen Anfragen. Budgetieren Sie die höhere Zahl, denn das Seitengewicht steigt mit dem Bot-Schutz.

Ist Apify bei diesem Volumen noch die richtige Wahl?

Manchmal ja. Sein CU-Modell ist transparent, es rechnet Arbeit statt Zeilen ab, und sein Actor-Ökosystem erspart eine Menge Glue-Code. Wenn Ihr Crawl ein paar hunderttausend Seiten umfasst und Ihre Proxys von einem günstigeren Anbieter kommen, ist die Plattform nicht Ihr Problem. Der Grund zu wechseln hat meist mit verfallenden Credits zu tun, mit tarifgebundener Parallelität, die erreicht wird, bevor Sie bereit sind, oder mit Bandbreitentarifen, die Sie anderswo unterbieten können.

Was bricht bei einer Million Seiten zuerst?

Das Budget, nicht die Technologie. Parallelitätsgrenzen und Retry-Abrechnung sind dokumentiert und vorhersehbar. Was Teams überrascht, ist die Bandbreitenrechnung, die Annahme darüber, wie viele Seiten Rendering brauchen, und wie viel vom Crawl sich als Seiten entpuppt, die niemand haben wollte. Korrigieren Sie den Umfang, bevor Sie den Anbieter korrigieren.

Die meisten Vergleiche von Apify-Alternativen beantworten eine Frage zu Features. Die Frage, die bei einer Million Seiten Geld kostet, betrifft die Form der Abrechnung, und sie hat drei Teile: Wofür multipliziert der Anbieter, wo liegt seine Obergrenze, und wer zahlt für eine fehlgeschlagene Anfrage?

Apify beantwortet diese Fragen gut. Seine Compute Unit ist eine saubere Arbeitseinheit, und sie rechnet Ihnen das Durchsuchen von Seiten ab, statt Zeilen zu zählen. Was sie nicht kontrolliert, ist der Teil der Rechnung, den Sie tatsächlich anstarren werden: Residential-Bandbreite zu 8 $/GB, auf Seiten, deren Bytes größtenteils Beiwerk sind.

Der nützliche Schritt ist also nicht, die Plattform zu wechseln. Er besteht darin, den Crawl auf die Seiten zu beschneiden, die die Daten tragen, die statische Mehrheit mit etwas abzurufen, das 20-mal günstiger ist als ein Browser, und die 10 % zu rendern, die es brauchen. Tun Sie das, und der Anbietervergleich wird zur Rundungsentscheidung.

Die Teile, die ein Crawler nicht erreicht, die eingeloggten Seiten und internen Tools sind die Stelle, an der der Crawl aufhört und eine Sitzung beginnt. ego (lite) führt denselben Workflow aus, mit dem Login bereits angehängt, und hält an, um Sie zu fragen, wenn ein Schritt einen Menschen braucht. Und wenn ein einfacher Abruf die Zeilen bereits liefert, ist das die ganze Antwort. Lassen Sie den Browser draußen.

Wir sind in diesen ersten Crawl über eine Million Seiten mit der Erwartung gegangen, die Plattform sei der teure Teil. Geantwortet hat stattdessen die Bandbreite.