Web-Crawler-Benchmark, um Websites an KI zu verfüttern

Wir haben vier Crawl-APIs über drei Domains mit unterschiedlichem Schwierigkeitsgrad auf drei maximalen Tiefenstufen (5, 10, 20) mit einem 1.000-Seiten-Limit getestet und dabei Crawl-Abdeckung, Ausführungszeit, Link-Erkennung, Markdown-Link-Qualität und Titelextraktionsgenauigkeit gemessen.

Wenn Sie Folgendes erreichen möchten:

• Um Webseiten in strukturierte Daten umzuwandeln, lesen Sie unseren Leitfaden zu Web Scraping.
• Um ganze Websites zu crawlen, lesen Sie weiter.

Webcrawler-Benchmark

Sie können unsere Benchmark-Methodik.

Durchschnittlich gecrawlte Seiten vs. Kosten pro 1.000 Seiten

Gecrawlte Seiten nach Domains und maximaler Tiefe

Firecrawl crawlte konstant rund 100 Seiten auf theregister.com, unabhängig von der maximalen Tiefe, etwa 90 Seiten auf entrepreneur.com über alle Tiefenstufen hinweg und nur rund 30 Seiten auf amazon.com, wahrscheinlich aufgrund von Amazons aggressivem Bot-Schutz. Bemerkenswert ist, dass eine zunehmende maximale Tiefe praktisch keinen Einfluss auf die Anzahl der Seiten hatte, die Firecrawl auf einer der Domains crawlen konnte.

Apify zeigte die konstanteste Leistung und erreichte das maximale Crawl-Limit von 1.000 Seiten auf jeder Domain und jeder Tiefenstufe ohne erkennbare Schwierigkeiten, selbst auf stark geschützten Websites wie Amazon.

Cloudflare zeigte in den Tests uneinheitliches Verhalten:

• Auf theregister.com bei maximaler Tiefe 5 crawlte es nur 100 Seiten, aber bei maximaler Tiefe 20 erreichte es fast 1.000 Seiten.
• Wie wir in früheren Tests beobachtet haben, crawlte Cloudflare gelegentlich nur 1 Seite und beendet dann den Auftrag vollständig. Wir haben bestätigt, dass dies kein Caching-Problem ist (der Cache war deaktiviert), und haben mit Wartezeiten zwischen den Läufen von bis zu 1 Minute getestet, aber das Verhalten blieb bestehen. Bei maximaler Tiefe 10 auf theregister.com trat genau dieses Problem auf: Cloudflare crawlte nur 1 Seite, bevor es stoppte.
• Auf entrepreneur.com crawlte Cloudflare 780 Seiten bei Tiefe 5, steigerte sich auf 885 bei Tiefe 10, fiel dann aber stark auf nur 172 Seiten bei Tiefe 20. Dieser Rückgang könnte mit Cloudflares Crawl-Scheduler zusammenhängen, der tiefere Link-Ketten herabstuft oder mit Timeouts belegt, oder er könnte ein internes Nebenläufigkeitslimit widerspiegeln, das den Auftrag vorzeitig beendet, wenn die Crawl-Frontier bei größeren Tiefen zu stark wächst.
• Auf amazon.com crawlte Cloudflare 905 Seiten bei Tiefe 5, aber die Zahl ging mit zunehmender maximaler Tiefe stetig zurück und fiel auf 809 bei Tiefe 10 und 795 bei Tiefe 20, was darauf hindeutet, dass tiefere Crawl-Konfigurationen dazu führen können, dass Cloudflare mehr Zeit für den Overhead der Link-Erkennung aufwendet als für den tatsächlichen Seitenabruf.

Nimble erreichte oder näherte sich dem 1.000-Seiten-Limit auf theregister.com über alle Tiefenstufen (1.000 / 1.000 / 999). Auf entrepreneur.com crawlte es bei Tiefe 5 1.000 Seiten, zeigte aber bei höheren Tiefen leichte Rückgänge (896 bei Tiefe 10, 983 bei Tiefe 20), möglicherweise weil das 7-Stunden-Timeout erreicht wurde, bevor der vollständige Crawl in tieferen Ebenen abgeschlossen war; alle Nimble-Läufe endeten mit einem Timeout-Status. Amazon erwies sich als schwieriger:

• Bei Tiefe 5 schaffte es nur 319 Seiten, aber bei Tiefe 10 sprang es auf 988 Seiten und fiel dann bei Tiefe 20 auf 906.
• Diese Inkonsistenz spiegelt wahrscheinlich die Kombination aus Amazons Bot-Schutzmechanismen und Nimbles Timeout-Einschränkungen wider, wobei tiefere Crawls länger brauchen, um jede Seite zu verarbeiten, und unterwegs auf mehr Anti-Bot-Herausforderungen stoßen können.

Ausführungszeit nach Domains und maximaler Tiefe

Firecrawl war der schnellste Anbieter über alle Domains hinweg und schloss Crawls in unter 5 Minuten ab, typischerweise zwischen 75 und 265 Sekunden. Diese Geschwindigkeit geht zulasten der Abdeckung, da Firecrawl auch die wenigsten Seiten crawlte. Im Wesentlichen ist es schnell fertig, weil es früh stoppt.

Apify benötigte auf theregister.com unabhängig von der Tiefe rund 2.200 bis 2.400 Sekunden (~40 Minuten). Auf entrepreneur.com und amazon.com waren die Ausführungszeiten mit 8.300 bis 15.900 Sekunden (2–4 Stunden) deutlich länger, was die größeren und komplexeren Website-Strukturen widerspiegelt. Trotz der längeren Zeiten erreichte Apify durchgängig das 1.000-Seiten-Limit und war damit im Verhältnis von Abdeckung zu Zeit am zuverlässigsten.

Cloudflare zeigte Zeitwerte, die seine uneinheitlichen Crawl-Zahlen widerspiegeln:

• Auf theregister.com bei Tiefe 10 wurde der Lauf in nur 1 Sekunde abgeschlossen, weil nur 1 Seite gecrawlt wurde, bevor der Lauf stoppte.
• Auf entrepreneur.com bei Tiefe 20 endete der Lauf in 10 Sekunden, nachdem nur 172 Seiten gecrawlt wurden.
• Wenn Cloudflare einen vollständigen Crawl abschließt, liegen die Zeiten zwischen 3.500 und 25.200 Sekunden.
• Mit zunehmender maximaler Tiefe scheint Cloudflare das Erreichen tieferer Seiten gegenüber der Breite zu priorisieren: Es werden weniger Seiten gecrawlt, aber schneller abgeschlossen. Auf amazon.com sank die Ausführungszeit von 25.200 Sekunden (Timeout) bei Tiefe 5 auf nur 5.660 Sekunden bei Tiefe 20, während auch die Zahl der gecrawlten Seiten von 905 auf 795 zurückging. Dies deutet darauf hin, dass der Crawler von Cloudflare seine Strategie in höheren Tiefen ändert und weniger Zeit für die breite Erkennung, aber mehr für die tiefe Durchquerung aufwendet.

Nimble erreichte bei jedem einzelnen Lauf über alle Domains und Tiefenstufen hinweg das 7-Stunden-Timeout (25.200 Sekunden). Das ist bemerkenswert, weil Nimble in unseren früheren Schnelltests mit maximaler Tiefe 1 ohne Timeout abgeschlossen hatte. Im vollständigen Benchmark mit Tiefen von 5 bis 20 und einem 1.000-Seiten-Limit lief es durchgängig bis zum Erreichen des Timeouts. Trotzdem schaffte es Nimble in den meisten Fällen, eine hohe Zahl von Seiten zu crawlen (~900–1.000 auf theregister.com und entrepreneur.com), was bedeutet, dass es während der gesamten 7 Stunden aktiv crawlt, aber einfach nie den Abschluss signalisiert.

Linktext-Füllrate nach Anbietern und maximaler Tiefe

Um die Qualität der Markdown-Ausgabe zu bewerten, haben wir gemessen, wie viel Prozent der Links im Markdown jedes Anbieters Ankertext enthalten, also den klickbaren Textteil eines Links. Ein fehlender Ankertext (z. B. [](/about) statt [About Us](/about)) bedeutet, dass der Crawler das Label des Links nicht extract konnte.

• Nimble: 100 % über alle Tiefen
• Cloudflare: 91-94 %
• Firecrawl: 90 %
• Apify: 77-78 %, bei etwa 1 von 5 Links fehlt der Ankertext.

Die Crawl-Tiefe hatte bei allen Anbietern nur minimalen Einfluss auf die Füllraten, was darauf hindeutet, dass dies eine Eigenschaft der Parsing-Engine jedes Anbieters ist und nicht eine Crawl-Einstellung.

Linktext-Füllrate nach Anbietern und Domain

Ein Blick auf die Füllraten über verschiedene Domains zeigt, wie sich die Komplexität einer Website auf die Qualität der Link-Extraktion jedes Anbieters auswirkt.

• Nimble hielt über alle Domains hinweg 100 %.
• Apify zeigte die größte Schwankung: 89 % auf amazon.com, fiel aber auf entrepreneur.com auf 66 %, was bedeutet, dass bei einem Drittel seiner Links auf dieser Website der Ankertext fehlte. Dies deutet darauf hin, dass Apify mit inhaltsreichen Websites mit komplexen Navigationsstrukturen mehr Probleme hat.
• Firecrawl schnitt auf theregister.com am besten ab (98 %), fiel aber auf entrepreneur.com auf 81 % zurück und folgte damit einem ähnlichen Muster wie Apify.
• Cloudflare war nach Nimble am konstantesten und blieb unabhängig von der Domain zwischen 89 und 94 %.

Entrepreneur.com erwies sich als die schwierigste Domain für die Linktext-Extraktion; sowohl Apify (66 %) als auch Firecrawl (81 %) erzielten dort ihre niedrigsten Werte, wahrscheinlich aufgrund der starken Nutzung verschachtelter Navigationsmenüs und dynamischer Inhaltselemente, die sich schwerer sauber in Markdown konvertieren lassen.

Gesamtzahl der Links in der Markdown-Ausgabe nach Domains und maximaler Tiefe

Die Varianz der Linkanzahl zwischen den Anbietern war durchgängig hoch (74-97 %), was darauf hindeutet, dass die Anbieter aus denselben Seiten sehr unterschiedlich viele Links extract. Um ein detaillierteres Bild dieser Diskrepanz zu erhalten, haben wir die Gesamtzahl der Markdown-Links pro Anbieter gemessen.

• Apify lieferte insgesamt die meisten Links zurück, insbesondere auf amazon.com mit über 420K Links bei Tiefe 5 (~423 pro Seite). Auf entrepreneur.com stabilisierte es sich unabhängig von der Tiefe bei rund 63K. Seine Ausgabe enthält neben Links zu Seiteninhalten auch Anzeigen-Tracker und Tracking-Pixel.
• Cloudflare erreichte auf entrepreneur.com bei Tiefe 10 einen Spitzenwert von 303K, fiel aber bei Tiefe 20 auf 53K. Auf derselben Homepage von entrepreneur.com extrahierte Cloudflare 434 Links, verglichen mit Apifys 143, und erfasste vollständige Navigationsmenüs und Untermenüs.
• Firecrawl lieferte über alle Konfigurationen hinweg konstant 5-9K Links, begrenzt durch seine niedrige Seitenzahl.
• Nimble lieferte insgesamt 3-40K Links zurück, durchschnittlich 5-28 Links pro Seite, verglichen mit 60-420 bei anderen Anbietern. Auf der Homepage von entrepreneur.com gab Nimble 13 Links zurück, gegenüber Cloudflares 434, beschränkt auf die Hauptüberschriften der Artikel. Die Füllrate von 100 % spiegelt wider, dass alle enthaltenen Links Ankertext hatten, und weist nicht auf eine umfassende Linkabdeckung hin. Nimble gibt keine Standard-Markdown-Links aus. Die Anzahl umfasst escaped HTML-Links, die in der Markdown-Ausgabe gefunden wurden.

Titelpräsenzrate nach Anbietern

Die Titelähnlichkeit zwischen den Anbietern wies über alle Tests und Domains hinweg eine Abweichung von weniger als 1 % auf, was bestätigt, dass die Anbieter, wenn sie einen Titel extract, durchgängig dasselbe Ergebnis liefern. Die Titelpräsenzrate blieb über alle maximalen Tiefenstufen hinweg ebenfalls zwischen 98 und 100 %, was zeigt, dass die Crawl-Tiefe keinen bedeutsamen Einfluss auf die Titelextraktion hat.

Bei einer Aufschlüsselung nach Domain ergaben sich einige Unterschiede:

Auf entrepreneur.com und theregister.com erreichten die meisten Anbieter Titelpräsenzraten von 99-100 %. Amazon.com war die einzige Domain, auf der bedeutsame Unterschiede auftraten: Firecrawl fiel auf 93 % und Nimble auf 95,9 %, während Apify 99,6 % hielt. Dies steht im Einklang mit dem stärkeren Bot-Schutz von Amazon, der Seitenantworten blockieren oder verzerren kann, sodass einige Anbieter Seiten ohne extrahierbaren Titel zurückgeben.

Merkmale der besten Web-Crawler-APIs

Decodo bietet Crawling über /crawl, einen Endpoint seiner Web Data API. Alle Web Data API-Endpoints laufen unter einer API und einem API-Key. Ein /crawl-Auftrag sammelt bis zu 10.000 Seiten und gibt jede Seite als Markdown oder HTML zurück.

• Nutzer legen die maximale Tiefe fest, filtern Pfade mit regulären Ausdrücken und halten den Crawl auf einem Host, seinen Subdomains oder allen Domains.
• Der Crawler verwendet die Sitemap, Seitenlinks oder beides und fordert Seiten aus einem gewählten Land und einer gewählten Spracheinstellung an.
• Eine maximale Dauer stoppt den Auftrag und behält die bis dahin gesammelten Seiten.
• Eine Seite, die ohne JavaScript fehlschlägt, erhält einen weiteren Versuch mit JavaScript-Rendering.

Der /map-Endpoint listet bis zu 147.000 URLs von einer Seite und der Top-Level-Sitemap der Website auf, ohne Inhalte abzurufen, sodass ein Crawl nur ausgewählte Pfade ansteuern kann. Der free-Plan umfasst 10.000 Anfragen pro Monat ohne Kreditkarte.

Apify crawlt Websites über Website Content Crawler, einen Actor auf der Apify-Plattform. Standardmäßig ruft es statische Seiten über einfaches HTTP ab und wechselt für Seiten, die JavaScript benötigen, zu einem Headless-Browser. Nutzer können es auch im Nur-Browser- oder Nur-HTTP-Modus ausführen.

• Nutzer legen Start-URLs, maximale Tiefe, maximale Seitenzahl und URL-Muster zum Ein- oder Ausschließen fest und können Sitemaps für die Erkennung hinzufügen.
• Ein „Geändert seit“-Datum beschränkt erneute Crawls auf geänderte Seiten.
• Ein CSS-Selektor entfernt Navigation, Header und Footer vor der Konvertierung.
• Der Crawler gibt Text, Markdown, HTML und Screenshots zurück und kann verlinkte PDF-, Word- und Excel-Dateien herunterladen.

Apify verbindet die Ausgabe mit LangChain, LlamaIndex, Pinecone und Qdrant und bietet den Crawler als MCP-Tool an.

Cloudflare bietet einen /crawl-Endpoint in seinem Browser-Rendering-Dienst an. Ein Auftrag umfasst bis zu 100.000 Seiten und läuft bis zu sieben Tage; die Ergebnisse bleiben 14 Tage lang verfügbar.

• Der Crawler findet Seiten über Sitemaps, Seitenlinks oder beides und filtert URLs mit Wildcard-Mustern.
• Standardmäßig rendert er Seiten in einem Headless-Browser und kann stattdessen einfaches HTML ohne JavaScript abrufen.
• Die Ausgabe erfolgt als HTML, Markdown oder JSON.

Der Crawler beachtet robots.txt, einschließlich crawl-delay, und identifiziert sich mit einem festen User-Agent. Cloudflare gibt an, dass es CAPTCHAs oder Bot-Schutz nicht umgeht.

Firecrawls /crawl-Endpoint entdeckt und scrapet die Unterseiten einer Start-URL und gibt für jede Seite Markdown, HTML oder JSON zurück.

• Nutzer legen ein Seitenlimit, eine Erkennungstiefe und Regex-Pfadfilter fest.
• Der Crawl kann auf übergeordnete Pfade, Subdomains oder einen Hop externer Links ausgeweitet werden.
• Der Crawler kombiniert die Sitemap mit Seitenlinks oder verwendet nur eine der beiden Quellen.
• Ein prompt-Parameter verwandelt eine Anweisung in normaler Sprache in Crawl-Einstellungen.

Die Ergebnisse kommen per Polling, über Webhook-Ereignisse pro Seite oder über einen SDK-Watcher und bleiben 24 Stunden lang verfügbar.

Nimble Crawl führt jeden Crawl als Hintergrundauftrag mit bis zu 10.000 Seiten und 20 Link-Hops aus und gibt für jede Seite HTML oder Markdown zurück.

• Nutzer filtern Pfade mit regulären Ausdrücken und wählen, ob Subdomains gefolgt werden soll.
• Der Crawler verwendet die Sitemap, Seitenlinks oder beides als Quelle.
• URLs, die sich nur in Query-Parametern unterscheiden, können als eine Seite zählen.
• Jeder Crawl kann aus einem gewählten Land und einer gewählten Spracheinstellung ausgeführt werden.

Ein Statusaufruf meldet, wie viele Seiten ausstehend, abgeschlossen oder fehlgeschlagen sind, und der Inhalt jeder Seite stammt aus einem eigenen Ergebnisaufruf. Callbacks werden beim Start des Crawls, für jede Seite und am Ende ausgelöst.

Methodik des Webcrawler-Benchmarks

Wir testeten vier Crawl-APIs (Apify, Nimble, Cloudflare, Firecrawl) auf drei Domains mit unterschiedlichem Schwierigkeitsgrad: amazon.com (starker Bot-Schutz), entrepreneur.com (komplexe Inhalts-Website) und theregister.com (Nachrichten-Website).

Gemeinsame Konfiguration

Alle Anbieter erhielten identische Kerneinstellungen, um einen fairen Vergleich zu gewährleisten:

• Sitemap: Deaktiviert, Anbieter müssen Seiten ausschließlich über HTML-Links entdecken
• Externe Links: Deaktiviert, Crawler bleiben innerhalb der Zieldomain
• Subdomains: Aktiviert, Subdomain-Seiten werden gefolgt (z. B. india.entrepreneur.com)
• JavaScript-Rendering: Aktiviert, alle Anbieter verwenden einen Headless-Browser
• Cache: Deaktiviert
• Seitenlimit: 1.000 Seiten pro Lauf
• Timeout: 7 Stunden (25.200 Sekunden)
• Umgang mit Rate-Limits: 20-sekündige Wartezeit mit bis zu 3 Wiederholungen bei HTTP 429

Jeder Anbieter wurde auf allen drei Domains bei drei maximalen Tiefenstufen getestet (5, 10, 20), insgesamt 36 Crawl-Läufe. Die Anbieter wurden nacheinander getestet (nicht parallel), jede Kombination wurde einmal ausgeführt, und der Crawl-Status wurde jede Sekunde abgefragt.

Apify wurde mit dem website-content-crawler-Actor konfiguriert und verwendete Playwright/Firefox als Headless-Browser. Der Subdomain-Zugriff wurde über Glob-Muster gesteuert, und Apifys integrierter Proxy wurde für alle Anfragen verwendet.

Nimble, Cloudflare und Firecrawl wurden über ihre jeweiligen REST-APIs mit den oben beschriebenen gemeinsamen Einstellungen konfiguriert. Über die standardisierten Parameter hinaus wurden keine zusätzlichen anbieterspezifischen Konfigurationen angewendet.

Für Cloudflare verwendeten wir den Workers-Paid-Plan. Die angegebenen Kosten spiegeln wider, was wir für das Crawlen von 1.000 Seiten im Rahmen dieses Plans ausgegeben haben. Cloudflare rechnet auf Basis der Browser-Rendering-Zeit ab und nicht nach Seitenzahl.

Für Firecrawl verwendeten wir den Hobby-Plan. Die angegebenen Kosten entsprechen dem anteiligen Betrag für 1.000 Credits aus den in diesem Plan enthaltenen Credits. Die effektiven Kosten pro Seite variieren je nach Plantarif und danach, ob zusätzliche Credit-Pakete erworben werden.

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Web-Crawler-Benchmark, um Websites an KI zu verfüttern}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Abgerufen am 7. April 2026}
}

Änderungsprotokoll

9 Aktualisierungen

Alle9Allgemein8Methodik1

202620242023

1. 7. Apr

   Die Abschnitte zu Branchentrends, Crawler-Typen und Web-Crawling-Beispielen wurden entfernt.

2. 6. Apr

   Benchmark von vier Crawl-APIs über drei Domains und drei Tiefenstufen mit Diagrammen zu Abdeckung, Geschwindigkeit, Links und Titeln hinzugefügt.

3. 6. Apr

   Ein Methodikabschnitt hinzugefügt, der das Crawl-Setup für vier Anbieter, drei Domains und drei Tiefenstufen beschreibt.

4. 25. Feb

   Ein Abschnitt, Sind Web-Crawler legal?, wurde dem Artikel hinzugefügt.

5. 11. Feb

   Der Abschnitt „Was ist ein Web-Crawler?“ wurde mit neuen Trends und Betriebsmodi aktualisiert.

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple.

Cems Arbeit bei AIMultiple wurde von führenden globalen Publikationen wie Business Insider, Forbes, Morning Brew und Washington Post, von globalen Unternehmen wie Deloitte und HPE, von NGOs wie dem World Economic Forum und von supranationalen Organisationen wie der European Commission zitiert. [1], [2], [3], [4], [5]

Im Laufe seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen bei ihren Technologieentscheidungen bei McKinsey & Company und Altman Solon über mehr als ein Jahrzehnt. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung.

Er leitete Technologiestrategie und -beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Außerdem verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von 0 einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung erreichte. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.

Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er absolvierte die Bogazici University als Computeringenieur und hat einen MBA von der Columbia Business School.

Vollständiges Profil anzeigen

Technisch geprüft von

Nazlı Şipi

KI-Forscherin

Folgen auf

Nazlı ist Datenanalystin bei AIMultiple. Sie verfügt über frühere Erfahrung in der Datenanalyse in verschiedenen Branchen, wo sie daran arbeitete, komplexe Datasets in umsetzbare Erkenntnisse umzuwandeln.

Vollständiges Profil anzeigen

Kommentare 1

Teilen Sie Ihre Gedanken

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten

Aggeliki

Jan 12, 2022 at 16:15

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.

Antworten