Web-Crawler-Benchmark 2026: Von der Indexierung zur Agentic Intelligence
Wir haben vier Crawling-APIs auf drei Domains mit unterschiedlichem Schwierigkeitsgrad (amazon.com, entrepreneur.com, theregister.com) bei drei maximalen Tiefen (5, 10, 20) und einem Limit von 1.000 Seiten verglichen und dabei die Crawling-Abdeckung, die Ausführungszeit, die Linkfindung, die Markdown-Linkqualität und die Genauigkeit der Titelextraktion gemessen.
Wenn Sie Folgendes anstreben:
- Wandeln Sie Webseiten in strukturierte Daten um – mehr dazu in unserem Leitfaden zum Web Scraping .
- Durchforsten Sie ganze Websites, lesen Sie weiter.
Webcrawler-Benchmark
Sie können unsere Benchmark-Methodik nachlesen.
Durchschnittlich gecrawlte Seiten im Vergleich zu den Kosten pro 1.000 Seiten
Durchsuchte Seiten über verschiedene Domains hinweg nach maximaler Tiefe
Der Bot Firecrawl durchsuchte auf theregister.com unabhängig von der maximalen Suchtiefe konstant etwa 100 Seiten, auf entrepreneur.com über alle Suchtiefen hinweg ungefähr 90 Seiten und auf amazon.com nur etwa 30 Seiten, vermutlich aufgrund des strengen Bot-Schutzes von Amazon. Bemerkenswerterweise hatte eine Erhöhung der maximalen Suchtiefe praktisch keinen Einfluss auf die Anzahl der Seiten, die Firecrawl auf den verschiedenen Domains durchsuchen konnte.
Apify zeigte die konstanteste Leistung und erreichte das maximale Crawling-Limit von 1.000 Seiten auf jeder Domain und in jeder Tiefenebene ohne erkennbare Schwierigkeiten, selbst auf stark geschützten Seiten wie Amazon.
Cloudflare zeigte in den verschiedenen Tests ein uneinheitliches Verhalten:
- Auf theregister.com wurden bei einer maximalen Suchtiefe von 5 nur 100 Seiten durchsucht, bei einer maximalen Suchtiefe von 20 hingegen fast 1000 Seiten.
- Wie bereits in früheren Tests festgestellt, crawlt Cloudflare gelegentlich nur eine Seite und bricht den Vorgang dann vollständig ab. Wir haben bestätigt, dass es sich nicht um ein Caching-Problem handelt (der Cache war deaktiviert) und haben Wartezeiten zwischen den Durchläufen von bis zu einer Minute getestet, das Verhalten blieb jedoch bestehen. Bei maximaler Suchtiefe von 10 Seiten auf theregister.com trat genau dieses Problem auf: Cloudflare crawlt nur eine Seite, bevor der Crawlvorgang abbricht.
- Auf entrepreneur.com durchsuchte der Prozess Cloudflare 780 Seiten in Tiefe 5, steigerte die Anzahl auf 885 in Tiefe 10, fiel dann aber in Tiefe 20 rapide auf nur noch 172 Seiten ab. Dieser Rückgang könnte damit zusammenhängen, dass der Crawl-Scheduler von Cloudflare tiefere Linkketten herabstuft oder ein Timeout verursacht. Alternativ könnte er eine interne Begrenzung der Parallelität widerspiegeln, die dazu führt, dass der Crawl-Vorgang vorzeitig beendet wird, wenn die Crawl-Front bei höheren Tiefen zu groß wird.
- Auf amazon.com hat Cloudflare 905 Seiten in einer Tiefe von 5 gecrawlt, aber die Zahl sank stetig mit zunehmender maximaler Tiefe und fiel auf 809 in einer Tiefe von 10 und 795 in einer Tiefe von 20, was darauf hindeutet, dass tiefere Crawl-Konfigurationen dazu führen können, dass Cloudflare mehr Zeit mit dem Link-Discovery-Overhead als mit dem eigentlichen Seitenabruf verbringt.
Nimble erreichte oder näherte sich dem Limit von 1.000 Seiten auf theregister.com in allen Crawling-Tiefen (1.000 / 1.000 / 999). Auf entrepreneur.com wurden 1.000 Seiten in Tiefe 5 gecrawlt, jedoch traten bei höheren Tiefen leichte Einbrüche auf (896 in Tiefe 10, 983 in Tiefe 20), möglicherweise weil das 7-Stunden-Timeout vor Abschluss des vollständigen Crawlings in tieferen Ebenen erreicht wurde. Alle Läufe von Nimble endeten mit einem Timeout. Amazon erwies sich als schwieriger.
- Bei einer Tiefe von 5 wurden nur 319 Seiten gefunden, bei einer Tiefe von 10 sprang die Zahl auf 988 Seiten, fiel dann aber bei einer Tiefe von 20 wieder auf 906 Seiten ab.
- Diese Inkonsistenz spiegelt wahrscheinlich die Kombination aus Amazons Bot-Schutzmechanismen und den Timeout-Beschränkungen von Nimble wider, wobei tiefere Crawls länger für die Verarbeitung jeder Seite benötigen und dabei möglicherweise auf mehr Herausforderungen durch die Bot-Abwehr stoßen.
Ausführungszeit über alle Domänen hinweg nach maximaler Tiefe
Firecrawl war der schnellste Provider über alle Domains hinweg und schloss die Crawls in unter 5 Minuten ab, typischerweise zwischen 75 und 265 Sekunden. Diese Geschwindigkeit geht jedoch auf Kosten der Abdeckung, da Firecrawl auch die wenigsten Seiten gecrawlt hat. Im Wesentlichen ist der Crawling-Vorgang nur deshalb schnell, weil er frühzeitig abgebrochen wird.
Die Abfrage von Apify dauerte auf theregister.com unabhängig von der Seitentiefe etwa 2.200–2.400 Sekunden (ca. 40 Minuten). Auf entrepreneur.com und amazon.com waren die Ausführungszeiten mit 8.300–15.900 Sekunden (2–4 Stunden) deutlich länger, was auf die größeren und komplexeren Seitenstrukturen zurückzuführen ist. Trotz der längeren Abfragezeiten erreichte Apify stets das Limit von 1.000 Seiten und erwies sich somit als die zuverlässigste Abfrage hinsichtlich des Verhältnisses von Abdeckung zu Zeit.
Cloudflare zeigte ein Zeitverhalten, das die inkonsistenten Crawl-Zählungen widerspiegelt:
- Auf theregister.com wurde der Crawl in einer Tiefe von 10 Seiten in nur einer Sekunde abgeschlossen, da nur eine Seite gecrawlt wurde, bevor der Vorgang abgebrochen wurde.
- Auf entrepreneur.com war der Crawlvorgang bei einer Suchtiefe von 20 Seiten in 10 Sekunden abgeschlossen, nachdem nur 172 Seiten gecrawlt worden waren.
- Wenn Cloudflare einen kompletten Kriechgang durchführt, liegen die Zeiten zwischen 3.500 und 25.200 Sekunden.
- Mit zunehmender maximaler Tiefe scheint der Crawler von Cloudflare die Suche nach tieferliegenden Seiten gegenüber der Suche nach breiteren Seiten zu priorisieren. Er crawlt zwar weniger Seiten, ist aber schneller fertig. Auf amazon.com sank die Ausführungszeit von 25.200 Sekunden (Timeout) bei Tiefe 5 auf nur noch 5.660 Sekunden bei Tiefe 20, während die Anzahl der gecrawlten Seiten von 905 auf 795 zurückging. Dies deutet darauf hin, dass der Crawler von Cloudflare seine Strategie bei größeren Tiefen anpasst und weniger Zeit mit der Suche nach tieferliegenden Seiten verbringt, sondern sich stattdessen auf die Suche nach tieferliegenden Seiten konzentriert.
Nimble erreichte bei jedem Durchlauf über alle Domains und Suchtiefen hinweg das 7-Stunden-Timeout (25.200 Sekunden). Dies ist bemerkenswert, da Nimble in unseren vorherigen Schnelltests mit maximaler Suchtiefe 1 den Vorgang ohne Timeout abschloss. Im vollständigen Benchmark mit Suchtiefen von 5–20 und einem Seitenlimit von 1.000 Seiten lief der Crawler stets bis zum Erreichen des Timeouts. Trotzdem konnte Nimble in den meisten Fällen eine hohe Anzahl an Seiten crawlen (ca. 900–1.000 auf theregister.com und entrepreneur.com). Das bedeutet, dass der Crawler während der gesamten 7 Stunden aktiv war, aber nie ein Abschlusssignal gab.
Linktext-Füllrate anbieterübergreifend nach maximaler Tiefe
Um die Qualität der Markdown-Ausgabe zu beurteilen, haben wir den Anteil der Links im Markdown jedes Anbieters gemessen, die Ankertext (den anklickbaren Textteil eines Links) enthalten. Fehlender Ankertext (z. B. [](/about) statt [About Us](/about)) bedeutet, dass der Crawler die Linkbezeichnung nicht extrahieren konnte.
- Nimble : 100% über alle Tiefen hinweg
- Cloudflare : 91-94%
- Firecrawl : 90%
- Apify : 77-78% , ungefähr bei jedem fünften Link fehlt der Ankertext.
Die Crawltiefe hatte nur einen minimalen Einfluss auf die Füllraten der einzelnen Anbieter. Dies lässt vermuten, dass es sich eher um eine Eigenschaft der Parsing-Engine des jeweiligen Anbieters als um eine Einstellung der Crawltiefe handelt.
Linktext-Füllrate anbieterübergreifend nach Domäne
Die Betrachtung der Füllraten über verschiedene Domains hinweg zeigt, wie die Komplexität der Website die Qualität der Link-Extraktion jedes Anbieters beeinflusst.
- Nimble wurde in allen Bereichen zu 100 % aufrechterhalten.
- Apify wies die größte Streuung auf: 89 % auf amazon.com, aber nur noch 66 % auf entrepreneur.com. Das bedeutet, dass bei einem Drittel der Links auf dieser Seite der Ankertext fehlte. Dies deutet darauf hin, dass Apify größere Schwierigkeiten mit inhaltsreichen Websites mit komplexen Navigationsstrukturen hat.
- Firecrawl erzielte die besten Ergebnisse auf theregister.com (98%), fiel aber auf entrepreneur.com auf 81% zurück, was einem ähnlichen Muster wie bei Apify entspricht.
- Cloudflare war nach Nimble am konstantesten und lag unabhängig von der Domäne zwischen 89 und 94 %.
Entrepreneur.com erwies sich als die schwierigste Domain für die Linktextextraktion; sowohl Apify (66%) als auch Firecrawl (81%) erzielten dort ihre niedrigsten Werte, wahrscheinlich aufgrund der starken Verwendung verschachtelter Navigationsmenüs und dynamischer Inhaltselemente auf der Website, die sich nicht so einfach sauber in Markdown konvertieren lassen.
Gesamtzahl der Links in der Markdown-Ausgabe über alle Domains hinweg nach maximaler Tiefe
Die Anzahl der Links variierte zwischen den Anbietern durchweg stark (74–97 %), was darauf hindeutet, dass die Anbieter sehr unterschiedliche Anzahlen von Links von denselben Seiten extrahieren. Um diese Diskrepanz genauer zu analysieren, haben wir die Gesamtzahl der Markdown-Links pro Anbieter ermittelt.
- Apify lieferte insgesamt die meisten Links, insbesondere auf amazon.com mit über 420.000 Links in der fünften Linktiefe (ca. 423 pro Seite). Auf entrepreneur.com stabilisierte sich die Anzahl unabhängig von der Linktiefe bei etwa 63.000. Die Ergebnisse umfassen neben den Links im Seiteninhalt auch Anzeigen-Tracker und Tracking-Pixel.
- Cloudflare erreichte auf entrepreneur.com bei einer Suchtiefe von 10 einen Höchstwert von 303.000, fiel aber bei einer Suchtiefe von 20 auf 53.000 zurück. Auf derselben Startseite von entrepreneur.com extrahierte Cloudflare 434 Links im Vergleich zu Apify mit 143 Links, wobei vollständige Navigationsmenüs und Untermenüs erfasst wurden.
- Firecrawl lieferte über alle Konfigurationen hinweg konstant 5-9K Links zurück, was durch die geringe Seitenzahl begrenzt war.
- Nimble lieferte insgesamt 3.000 bis 40.000 Links, im Durchschnitt 5 bis 28 Links pro Seite, verglichen mit 60 bis 420 bei anderen Anbietern. Auf der Startseite von entrepreneur.com lieferte Nimble 13 Links, im Gegensatz zu 434 bei Cloudflare, wobei sich die Links auf die Hauptartikelüberschriften beschränkten. Die 100%ige Füllrate spiegelt wider, dass alle enthaltenen Links Ankertext enthielten, und bedeutet nicht, dass die Linkabdeckung umfassend ist. Nimble gibt keine Standard-Markdown-Links aus. Die Zählung umfasst auch maskierte HTML-Links, die im Markdown-Output enthalten sind.
Aktueller Preis für Titel bei verschiedenen Anbietern
Die Titelähnlichkeit zwischen den Anbietern wies über alle Tests und Domains hinweg eine Abweichung von unter 1 % auf. Dies bestätigt, dass die Anbieter bei der Titelextraktion stets dasselbe Ergebnis liefern. Die Trefferquote für Titel lag ebenfalls über alle maximalen Crawling-Tiefen hinweg zwischen 98 und 100 %, was zeigt, dass die Crawling-Tiefe keinen signifikanten Einfluss auf die Titelextraktion hat.
Bei einer Aufschlüsselung nach Domänen zeigten sich einige Unterschiede:
Auf entrepreneur.com und theregister.com erreichten die meisten Anbieter Titelanzeigeraten von 99–100 %. Nur bei Amazon.com zeigten sich signifikante Unterschiede: Firecrawl fiel auf 93 % und Nimble auf 95,9 %, während Apify weiterhin 99,6 % erreichte. Dies deckt sich mit Amazons strengerem Bot-Schutz, der Seitenantworten blockieren oder verfälschen kann, wodurch einige Anbieter Seiten ohne extrahierbare Titel ausliefern.
Was ist ein Webcrawler?
Ein Webcrawler, manchmal auch „Spider“ oder „Agent“ genannt, ist ein Bot, der das Internet durchsucht, um Inhalte zu indexieren.
Crawler haben sich über Suchmaschinen hinaus entwickelt und dienen nun als agentenbasierte Datenschicht. Sie fungieren als Augen für autonome KI-Agenten wie Claude Code und OpenAI Operator und unterstützen diese bei Echtzeitaufgaben wie Wettbewerbsanalysen und mehrstufigen Transaktionen.
Was macht ein Webcrawler?
Das Web-Crawling wurde in drei Modi unterteilt, die jeweils für ein anderes Crawler-Ziel konzipiert wurden.
- Discovery-Modus (traditionell): Suchmaschinen-Bots wie Googlebot durchsuchen URLs zur Indexierung und helfen Nutzern so, Ergebnisse über Suchmaschinen zu finden.
- Abrufmodus (RAG): KI-Bots wie ChatGPT-User oder PerplexityBot rufen in Echtzeit spezifische Seiten ab, um Benutzeranfragen zu beantworten. Sie verwenden Markdown anstelle von HTML, um die Token-Beschränkungen des KI-Modells einzuhalten.
- Agentenmodus (aktionsorientiert): Dieser neue Crawler-Typ kann ab 2026 mehr als nur Inhalte lesen. Mithilfe des Model Context Protocol (MCP) können diese Bots mit Websites interagieren, um Flüge zu buchen oder Softwarebefehle auszuführen.
Früher verwendeten Crawler Selektoren wie XPath oder CSS, um Daten zu extrahieren. Die KI-basierte Datenextraktion ist mittlerweile Standard.
Tools wie Firecrawl und Crawl4AI verwenden natürlichsprachliche Anweisungen, um Daten zu finden. Anstatt für jedes Element Regeln zu schreiben, können Entwickler dem Crawler einfach sagen: „Extrahiere den Produktpreis“, und die KI findet den richtigen Wert, selbst wenn sich der Website-Code ändert.
Webcrawler selbst entwickeln oder kaufen im Zeitalter der KI
1. Bauen Sie Ihren eigenen Crawler
Ideal zum Schutz zentraler geistiger Eigentumsrechte und zur Ermöglichung umfassender Anpassungen. Die Entwicklung erfordert nun die Erstellung einer proprietären Agentenschicht und nicht mehr nur das Schreiben einfacher Scrapy-Skripte.
- Wann Sie selbst entwickeln sollten: Wählen Sie diesen Ansatz, wenn Ihr Crawler einen einzigartigen Wettbewerbsvorteil bietet. Entwickeln Sie ihn beispielsweise selbst, wenn Sie eine spezialisierte Suchmaschine entwickeln oder die vollständige Kontrolle über sensible oder regulierte Daten benötigen.
- Das Toolset: Sie müssen nicht mehr bei Null anfangen. Entwickler nutzen jetzt das Model Context Protocol (MCP), um internen KI-Agenten die Interaktion mit dem Web zu ermöglichen.
2. Verwendung von Web-Crawling-Tools und APIs
Managed Tools haben sich von einfachen Scrapern zu autonomen Agenten weiterentwickelt.
- Wartungsfreie Datenextraktion: Moderne Tools wie Kadoa und Firecrawl nutzen selbstheilende KI. Sie geben die benötigten Daten, z. B. den „Produktpreis“, an, anstatt deren Position im Code festzulegen. Ändert sich das Website-Layout, passt sich das Tool automatisch an.
- Compliance als Dienstleistung: Viele Anbieter bieten integrierte Compliance mit dem EU-KI-Gesetz an. Sie verwalten die erforderlichen Audit-Logs und Urheberrechts-Opt-out-Prüfungen, deren eigenständige Implementierung schwierig ist.
- Schnelle Wertschöpfung: Mit dem Kauf einer Plattform können Sie Ihr Projekt innerhalb weniger Wochen von der Konzeption bis zur Produktion bringen.
Abbildung 5: Eine Erklärung zur Funktionsweise einer URL-Grenze.
Sind Webcrawler legal?
Web-Crawling ist grundsätzlich legal , doch je nachdem, wie und was genau gecrawlt wird, kann man schnell in rechtliche Schwierigkeiten geraten. Vier Hauptkriterien bestimmen, ob Crawling (und das damit üblicherweise verbundene Scraping) legal ist:
1. Öffentlich vs. privat: Nur Daten crawlen, die ohne Konto öffentlich zugänglich sind.
2. Persönliche Informationen: Vermeiden Sie die Angabe personenbezogener Daten (Namen, E-Mail-Adressen und Anschriften), es sei denn, Sie verfügen über eine rechtliche Grundlage dafür.
3. Serverzustand: Verwenden Sie Ratenbegrenzungen, um eine Verlangsamung des Servers zu vermeiden; vermeiden Sie DDoS-Angriffe auf eine Website.
4. Urheberrecht : Artikel und Bilder sind urheberrechtlich geschützt, Fakten (Preise, Daten) jedoch nicht.
Worin besteht der Unterschied zwischen Web-Crawling und Web-Scraping?
Web Scraping bezeichnet den Einsatz von Webcrawlern, um den gesamten Inhalt einer bestimmten Webseite zu erfassen und zu speichern. Anders ausgedrückt: Web Scraping ist ein spezieller Anwendungsfall des Web Crawlings, um einen gezielten Datensatz zu erstellen, beispielsweise um alle Finanznachrichten für die Investitionsanalyse abzurufen oder nach bestimmten Firmennamen zu suchen.
Traditionell extrahierte ein Web-Scraper Daten von einer Webseite, nachdem ein Webcrawler alle Elemente erfasst und indexiert hatte. Heutzutage werden die Begriffe Scraping und Crawling jedoch synonym verwendet, wobei Crawler eher Suchmaschinen-Crawler bezeichnet. Da neben Suchmaschinen auch andere Unternehmen Webdaten nutzen, hat sich der Begriff Web-Scraper zunehmend vom Begriff Web-Crawler abgelöst.
Welche Herausforderungen birgt das Web-Crawling?
1. Aktualität der Datenbank
Die Inhalte von Websites werden regelmäßig aktualisiert. Dynamische Webseiten ändern beispielsweise ihren Inhalt basierend auf den Aktivitäten und dem Verhalten der Besucher. Das bedeutet, dass der Quellcode der Website nach dem Crawlen nicht mehr unverändert bleibt. Um dem Nutzer die aktuellsten Informationen bereitzustellen, muss der Webcrawler diese Webseiten häufiger neu crawlen.
2. Krabbelfallen
Websites nutzen verschiedene Techniken, wie beispielsweise Crawlerfallen, um Webcrawler am Zugriff auf und dem Crawlen bestimmter Webseiten zu hindern. Eine Crawlerfalle, auch Spinnenfalle genannt, veranlasst einen Webcrawler zu einer unendlichen Anzahl von Anfragen und führt zu einer Endlosschleife. Websites können Crawlerfallen auch unbeabsichtigt erzeugen. In jedem Fall gerät ein Crawler, sobald er auf eine solche Falle stößt, in eine Art Endlosschleife, die seine Ressourcen verschwendet.
3. Netzwerkbandbreite
Das Herunterladen einer großen Anzahl irrelevanter Webseiten, die Verwendung eines verteilten Webcrawlers oder das erneute Crawlen vieler Webseiten führen allesamt zu einer hohen Auslastung der Netzwerkkapazität.
4. Doppelte Seiten
Webcrawler durchsuchen zwar größtenteils alle doppelten Inhalte im Web, indexieren aber nur eine Version einer Seite. Doppelte Inhalte erschweren es Suchmaschinen-Bots, die zu indexierende und zu rankende Version zu bestimmen. Wenn der Bot Google eine Gruppe identischer Webseiten in den Suchergebnissen findet, indexiert er nur eine dieser Seiten und zeigt sie als Antwort auf die Suchanfrage eines Nutzers an.
Die 3 besten Praktiken für Web-Crawling
1. Höflichkeit/Kriechgeschwindigkeit
Websites legen eine Crawling-Rate fest, um die Anzahl der Anfragen von Webcrawlern zu begrenzen. Die Crawling-Rate gibt an, wie viele Anfragen ein Webcrawler innerhalb eines bestimmten Zeitraums an Ihre Website senden darf (z. B. 100 Anfragen pro Stunde). Dadurch können Website-Betreiber die Bandbreite ihrer Webserver schonen und eine Serverüberlastung vermeiden. Ein Webcrawler muss sich an das Crawling-Limit der Zielwebsite halten.
2. Robots.txt-Konformität
Eine robots.txt-Datei ist eine Textdatei im Stammverzeichnis einer Website, die Crawlern mitteilt, auf welche Seiten sie zugreifen dürfen und auf welche nicht. Es handelt sich um einen freiwilligen Standard; konforme Bots respektieren ihn, er verhindert den Zugriff jedoch nicht vollständig. Die Einhaltung der robots.txt-Datei einer Website gilt als Best Practice, und in vielen Ländern kann deren Missachtung rechtliche oder Reputationsrisiken bergen.
3. IP-Rotation
Websites setzen verschiedene Anti-Scraping-Techniken wie CAPTCHAs ein, um den Crawler-Traffic zu kontrollieren und Web-Scraping-Aktivitäten einzudämmen. Browser-Fingerprinting ist beispielsweise eine Tracking-Technik, mit der Websites Informationen über Besucher sammeln, etwa zur Sitzungsdauer oder zu Seitenaufrufen.
Diese Methode ermöglicht es Website-Betreibern, „nicht-menschlichen Datenverkehr“ zu erkennen und die IP-Adresse des Bots zu blockieren. Um eine Erkennung zu vermeiden, können Sie rotierende Proxys , wie z. B. Residential Proxys, in Ihren Webcrawler integrieren .
Benchmark-Methodik für Webcrawler
Wir haben vier Crawling-APIs (Apify, Nimble, Cloudflare, Firecrawl) auf drei Domains mit unterschiedlichem Schwierigkeitsgrad getestet: amazon.com (starker Bot-Schutz), entrepreneur.com (Website mit komplexen Inhalten) und theregister.com (Nachrichtenseite).
Gemeinsame Konfiguration
Alle Anbieter erhielten identische Grundeinstellungen, um einen fairen Vergleich zu gewährleisten:
- Sitemap: Deaktiviert, Anbieter müssen Seiten ausschließlich über HTML-Links finden.
- Externe Links: Deaktiviert, Crawler bleiben innerhalb der Zieldomäne.
- Subdomains: Aktiviert, Subdomain-Seiten werden verfolgt (z. B. india.entrepreneur.com)
- JavaScript-Rendering: Aktiviert, alle Anbieter verwenden einen Headless-Browser
- Cache: Deaktiviert
- Seitenlimit: 1.000 Seiten pro Druckdurchlauf
- Zeitüberschreitung: 7 Stunden (25.200 Sekunden)
- Ratenbegrenzungsbehandlung: 20 Sekunden Wartezeit mit bis zu 3 Wiederholungsversuchen bei HTTP 429
Jeder Provider wurde in drei maximalen Tiefen (5, 10, 20) über alle drei Domänen hinweg getestet, insgesamt wurden 36 Crawl-Läufe durchgeführt. Die Provider wurden sequenziell (nicht parallel) getestet, jede Kombination wurde einmal ausgeführt und der Crawl-Status jede Sekunde abgefragt.
Apify wurde mit dem Website-Content-Crawler-Aktor konfiguriert, der Playwright/Firefox als Headless-Browser nutzte. Der Zugriff auf Subdomains wurde über Glob-Muster gesteuert, und der integrierte Proxy von Apify wurde für alle Anfragen verwendet.
Die Adressen Nimble, Cloudflare und Firecrawl wurden mithilfe ihrer jeweiligen REST-APIs und den oben beschriebenen gemeinsamen Einstellungen konfiguriert. Über die standardisierten Parameter hinaus wurden keine weiteren anbieterspezifischen Konfigurationen angewendet.
Für Cloudflare nutzten wir den Workers Paid-Tarif. Die angegebenen Kosten entsprechen den Ausgaben für das Crawlen von 1.000 Seiten im Rahmen dieses Tarifs. Cloudflare berechnet die Kosten anhand der Browser-Rendering-Zeit und nicht anhand der Seitenanzahl.
Für Firecrawl wurde der Hobby-Tarif genutzt. Die angegebenen Kosten sind der anteilige Betrag für 1.000 Credits aus dem in diesem Tarif enthaltenen Guthaben. Die effektiven Kosten pro Seite variieren je nach Tarifstufe und ob zusätzliche Credit-Pakete erworben wurden.
Kommentare 1
Teilen Sie Ihre Gedanken
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.
Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.