Webcrawler-Benchmark, um Websites an KI zu verfüttern
Wir haben vier Crawl-APIs über drei Domänen mit unterschiedlichem Schwierigkeitsgrad auf drei maximalen Tiefenstufen (5, 10, 20) mit einem Limit von 1.000 Seiten getestet und dabei Crawl-Abdeckung, Ausführungszeit, Link-Erkennung, Markdown-Link-Qualität und Genauigkeit der Titel-Extraktion gemessen.
Wenn Sie Folgendes beabsichtigen:
- Um Webseiten in strukturierte Daten umzuwandeln, lesen Sie unseren Leitfaden zu Web-Scraping.
- Ganze Websites crawlen, lesen Sie weiter.
Webcrawler-Benchmark
Sie können unsere Benchmark-Methodik lesen.
Durchschnittlich gecrawlte Seiten vs. Kosten pro 1.000 Seiten
Gecrawlte Seiten über Domänen nach maximaler Tiefe
Firecrawl crawlt durchgehend etwa 100 Seiten auf theregister.com unabhängig von der maximalen Tiefe, ungefähr 90 Seiten auf entrepreneur.com über alle Tiefenstufen hinweg und nur etwa 30 Seiten auf amazon.com, wahrscheinlich aufgrund des aggressiven Bot-Schutzes von Amazon. Bemerkenswert ist, dass eine Erhöhung der maximalen Tiefe praktisch keinen Einfluss auf die Anzahl der Seiten hatte, die Firecrawl in irgendeiner Domäne crawlen konnte.
Apify zeigte die konstanteste Leistung und erreichte das maximale Crawl-Limit von 1.000 Seiten auf jeder Domäne und in jeder Tiefenstufe ohne erkennbare Schwierigkeiten, selbst auf stark geschützten Websites wie Amazon.
Cloudflare zeigte bei den Tests uneinheitliches Verhalten:
- Auf theregister.com bei maximaler Tiefe 5 crawlt er nur 100 Seiten, aber bei maximaler Tiefe 20 erreichte er fast 1.000 Seiten.
- Wie wir in früheren Tests beobachtet haben, crawlt Cloudflare gelegentlich nur 1 Seite und beendet dann den Auftrag vollständig. Wir haben bestätigt, dass dies kein Cache-Problem ist (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 crawlt nur 1 Seite, bevor er stoppte.
- Auf entrepreneur.com crawlt Cloudflare 780 Seiten bei Tiefe 5, steigerte sich auf 885 bei Tiefe 10, fiel dann aber stark auf nur 172 Seiten bei Tiefe 20 ab. Dieser Rückgang könnte mit dem Crawl-Scheduler von Cloudflare zusammenhängen, der tiefere Link-Ketten herabstuft oder zeitlich begrenzt, oder er könnte eine interne Nebenläufigkeitsgrenze widerspiegeln, die dazu führt, dass der Auftrag vorzeitig beendet wird, wenn die Crawl-Front bei höheren Tiefen zu groß wird.
- Auf amazon.com crawlt Cloudflare 905 Seiten bei Tiefe 5, aber die Zahl ging stetig zurück, als die maximale Tiefe zunahm, und fiel auf 809 bei Tiefe 10 und 795 bei Tiefe 20, was darauf hindeutet, dass tiefere Crawl-Konfigurationen Cloudflare dazu veranlassen könnten, mehr Zeit für den Overhead der Link-Erkennung als für das tatsächliche Abrufen von Seiten aufzuwenden.
Nimble erreichte oder näherte sich dem Limit von 1.000 Seiten auf theregister.com über alle Tiefenstufen (1.000 / 1.000 / 999). Auf entrepreneur.com crawlt er 1.000 Seiten bei Tiefe 5, zeigte jedoch bei höheren Tiefen leichte Rückgänge (896 bei Tiefe 10, 983 bei Tiefe 20), möglicherweise weil bei tieferen Ebenen das 7-Stunden-Timeout erreicht wurde, bevor der vollständige Crawl abgeschlossen werden konnte; alle Läufe von Nimble endeten mit einem Timeout-Status. Amazon erwies sich als schwieriger:
- Bei Tiefe 5 schaffte er nur 319 Seiten, aber bei Tiefe 10 sprang er auf 988 Seiten, um dann bei Tiefe 20 auf 906 abzufallen
- Diese Inkonsistenz spiegelt wahrscheinlich die Kombination aus Amazons Bot-Schutzmechanismen und den Timeout-Einschränkungen von Nimble wider, wobei tiefere Crawls länger brauchen, um jede Seite zu verarbeiten, und unterwegs möglicherweise auf mehr Anti-Bot-Herausforderungen stoßen
Ausführungszeit über Domänen nach maximaler Tiefe
Firecrawl war der schnellste Anbieter über alle Domänen hinweg und schloss Crawls in unter 5 Minuten ab, typischerweise zwischen 75 und 265 Sekunden. Diese Geschwindigkeit geht auf Kosten der Abdeckung, da Firecrawl auch die wenigsten Seiten crawlt. Im Wesentlichen ist es schnell fertig, weil es früh aufhört.
Apify benötigte etwa 2.200 bis 2.400 Sekunden (~40 Minuten) auf theregister.com, unabhängig von der Tiefe. 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 durchgehend das Limit von 1.000 Seiten und war damit in Bezug auf das Verhältnis von Abdeckung zu Zeit am zuverlässigsten.
Cloudflare zeigte Zeiten, die seine inkonsistenten Crawl-Zahlen widerspiegeln:
- Auf theregister.com bei Tiefe 10 wurde der Crawl in nur 1 Sekunde abgeschlossen, weil nur 1 Seite gecrawlt wurde, bevor gestoppt wurde.
- Auf entrepreneur.com bei Tiefe 20 wurde er nach dem Crawlen von nur 172 Seiten in 10 Sekunden abgeschlossen.
- 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 crawlt weniger Seiten, schließt aber schneller ab. 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 die gecrawlten Seiten ebenfalls von 905 auf 795 zurückgingen. Dies deutet darauf hin, dass der Crawler von Cloudflare seine Strategie bei höheren Tiefen ändert und weniger Zeit für die breite Entdeckung und mehr für die tiefe Durchquerung aufwendet.
Nimble erreichte bei jedem einzelnen Lauf über alle Domänen und Tiefenstufen das 7-Stunden-Timeout (25.200 Sekunden). Dies ist bemerkenswert, da in unseren früheren Schnelltests mit maximaler Tiefe 1 Nimble ohne Timeout abgeschlossen wurde. Im vollständigen Benchmark mit Tiefen von 5 bis 20 und einem Limit von 1.000 Seiten lief er konsequent, bis das Timeout erreicht wurde. Trotzdem schaffte es Nimble in den meisten Fällen, eine hohe Anzahl von Seiten zu crawlen (~900 bis 1.000 auf theregister.com und entrepreneur.com), was bedeutet, dass er während der gesamten 7 Stunden aktiv crawlt, aber einfach nie einen Abschluss signalisiert.
Linktext-Füllrate über Anbieter nach 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, den klickbaren Textteil eines Links. Fehlender Ankertext (z. B. [](/about) statt [About Us](/about)) bedeutet, dass der Crawler das Label des Links nicht extrahieren konnte.
- Nimble: 100 % über alle Tiefen
- Cloudflare: 91 bis 94 %
- Firecrawl: 90 %
- Apify: 77 bis 78 %, ungefähr 1 von 5 Links ohne Ankertext
Die Crawl-Tiefe hatte bei allen Anbietern nur minimale Auswirkungen auf die Füllraten, was darauf hindeutet, dass dies eine Eigenschaft der Parsing-Engine jedes Anbieters und keine Crawl-Einstellung ist.
Linktext-Füllrate über Anbieter nach Domäne
Ein Blick auf die Füllraten über verschiedene Domänen zeigt, wie sich die Komplexität der Website auf die Qualität der Link-Extraktion jedes Anbieters auswirkt.
- Nimble hielt 100 % über alle Domänen.
- Apify zeigte die größte Variation: 89 % auf amazon.com, aber ein Rückgang auf 66 % auf entrepreneur.com, was bedeutet, dass ein Drittel der Links auf dieser Website ohne Ankertext war. Dies deutet darauf hin, dass Apify mehr mit inhaltslastigen Websites zu kämpfen hat, die komplexe Navigationsstrukturen aufweisen.
- Firecrawl schnitt auf theregister.com am besten ab (98 %), fiel aber auf entrepreneur.com auf 81 % ab, was einem ähnlichen Muster wie bei Apify folgt.
- Cloudflare war nach Nimble am konstantesten und blieb unabhängig von der Domäne zwischen 89 und 94 %.
Entrepreneur.com erwies sich als die schwierigste Domäne für die Linktext-Extraktion; sowohl Apify (66 %) als auch Firecrawl (81 %) hatten 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 über Domänen nach maximaler Tiefe
Die Varianz der Linkanzahl zwischen den Anbietern war durchgehend hoch (74 bis 97 %), was darauf hindeutet, dass die Anbieter sehr unterschiedliche Anzahlen von Links aus denselben Seiten extrahieren. Um einen detaillierteren Einblick in diese Diskrepanz zu erhalten, haben wir die Gesamtzahl der Markdown-Links pro Anbieter gemessen.
- Apify lieferte insgesamt die meisten Links, insbesondere auf amazon.com mit über 420K Links bei Tiefe 5 (~423 pro Seite). Auf entrepreneur.com stabilisierte sich die Zahl unabhängig von der Tiefe bei etwa 63K. Die Ausgabe enthält neben den Links zu Seiteninhalten auch Werbe-Tracker und Tracking-Pixel.
- Cloudflare erreichte auf entrepreneur.com bei Tiefe 10 einen Höchststand von 303K Links, fiel aber bei Tiefe 20 auf 53K ab. Auf derselben Homepage von entrepreneur.com extrahierte Cloudflare 434 Links im Vergleich zu 143 von Apify und erfasste dabei vollständige Navigationsmenüs und Untermenüs.
- Firecrawl lieferte durchgehend 5 bis 9K Links über alle Konfigurationen hinweg, begrenzt durch die geringe Seitenzahl.
- Nimble lieferte insgesamt 3 bis 40K Links, durchschnittlich 5 bis 28 Links pro Seite, verglichen mit 60 bis 420 bei anderen Anbietern. Auf der Homepage von entrepreneur.com lieferte Nimble 13 Links gegenüber 434 von Cloudflare, beschränkt auf die Hauptüberschriften der Artikel. Seine Füllrate von 100 % spiegelt wider, dass alle aufgenommenen Links Ankertext enthielten, und ist kein Hinweis auf eine umfassende Link-Abdeckung. Nimble gibt keine standardmäßigen Markdown-Links aus. Die Zahl umfasst auch HTML-Links, die innerhalb der Markdown-Ausgabe gefunden wurden.
Titel-Vorhandenseinsrate über Anbieter
Die Titelähnlichkeit zwischen den Anbietern zeigte über alle Tests und Domänen hinweg eine Abweichung von weniger als 1 %, was bestätigt, dass die Anbieter, wenn sie einen Titel extrahieren, durchgehend dasselbe Ergebnis liefern. Die Rate der vorhandenen Titel blieb ebenfalls über alle maximalen Tiefenstufen zwischen 98 und 100 %, was zeigt, dass die Crawl-Tiefe keinen nennenswerten Einfluss auf die Titel-Extraktion hat.
Bei der Aufschlüsselung nach Domäne zeigten sich einige Unterschiede:
Auf entrepreneur.com und theregister.com erreichten die meisten Anbieter Raten von 99 bis 100 % für vorhandene Titel. Amazon.com war die einzige Domäne, in der nennenswerte 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 extrahierbare Titel zurückgeben.
Was ist ein Webcrawler?
Ein Webcrawler, manchmal als „Spider“ oder „Agent“ bezeichnet, ist ein Bot, der das Internet durchsucht, um Inhalte zu indexieren.
Crawler haben sich über Suchmaschinen hinaus entwickelt und dienen nun als agentische Datenschicht. Sie fungieren als die Augen für autonome KI-Agenten wie Claude Code und OpenAI Operator und unterstützen bei Echtzeitaufgaben wie Wettbewerbsforschung und mehrstufigen Transaktionen.
Was macht ein Webcrawler?
Webcrawling wurde in drei Modi unterteilt, die jeweils für ein unterschiedliches Crawler-Ziel konzipiert sind.
- Discovery-Modus (traditionell): Suchmaschinen-Bots wie Googlebot crawlen URLs zum Indexieren und helfen Menschen, Ergebnisse über Suchmaschinen zu finden.
- Abrufmodus (RAG): KI-Bots wie ChatGPT-User oder PerplexityBot rufen bestimmte Seiten in Echtzeit ab, um Benutzer-Prompts zu beantworten. Sie verwenden Markdown anstelle von HTML, um die Token-Limits des KI-Modells einzuhalten.
- Agentischer Modus (handlungsorientiert): Dieser neue Crawler-Typ im Jahr 2026 tut mehr als nur Inhalte zu lesen. Mithilfe des Model Context Protocol (MCP) können diese Bots mit Websites interagieren, um Flüge zu buchen oder Software-Befehle auszuführen.
In der Vergangenheit verwendeten Crawler Selektoren wie XPath oder CSS, um Daten zu extrahieren. KI-native Extraktion ist zur Norm geworden.
Tools wie Firecrawl und Crawl4AI verwenden Anweisungen in natürlicher Sprache, um Daten zu finden. Anstatt Regeln für jedes Element zu schreiben, können Entwickler dem Crawler sagen: „Extrahiere den Produktpreis“, und die KI findet den richtigen Wert, selbst wenn sich der Code der Website ändert.
Webcrawler bauen vs. kaufen im KI-Zeitalter
1. Einen eigenen Crawler bauen
Ideal zum Schutz des geistigen Kerneigentums und zur Ermöglichung tiefgreifender Anpassung. Das Bauen erfordert heute die Entwicklung einer proprietären Agentenschicht und nicht nur das Schreiben einfacher Scrapy-Skripte.
- Wann bauen: Wählen Sie diesen Ansatz, wenn Ihr Crawler einen einzigartigen Wettbewerbsvorteil bietet. Bauen Sie beispielsweise Ihren eigenen, wenn Sie eine spezialisierte Suchmaschine entwickeln oder 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 Webcrawling-Tools und APIs
Verwaltete Tools haben sich von einfachen Scrapern zu autonomen Agenten weiterentwickelt.
- Wartungsfreie Extraktion: Moderne Tools wie Kadoa und Firecrawl nutzen selbstheilende KI. Sie geben die benötigten Daten an, etwa „Produktpreis“, und nicht deren Position im Code. Wenn sich das Website-Layout ändert, passt sich das Tool automatisch an.
- Compliance als Service: Viele Anbieter bieten integrierte Compliance mit dem EU KI Act. Sie verwalten erforderliche Audit-Protokolle und Copyright-Opt-out-Prüfungen, die unabhängig nur schwer zu implementieren sind.
- Schneller Nutzen: Der Kauf einer Plattform kann Ihr Projekt innerhalb von Wochen vom Konzept zur Produktion bringen.
Sind Webcrawler legal?
Im Allgemeinen ist Webcrawling legal, aber je nachdem, wie und was Sie crawlen, könnten Sie schnell in eine rechtliche Zwickmühle geraten. Vier Hauptpfeiler bestimmen, ob das Crawling (und das typischerweise folgende Scraping) legal ist:
1. Öffentlich vs. privat: Crawlen Sie nur Daten, die ohne Konto öffentlich zugänglich sind.
2. Personenbezogene Daten: Halten Sie sich von PII (Namen, E-Mails und Adressen) fern, es sei denn, Sie haben eine Rechtsgrundlage.
3. Server-Gesundheit: Verwenden Sie Ratenbegrenzungen, um den Server nicht zu verlangsamen; vermeiden Sie „DDOSing“ einer Website.
4. Urheberrecht: Artikel und Bilder sind urheberrechtlich geschützt, Fakten (Preise, Daten) jedoch nicht.
Was ist der Unterschied zwischen Webcrawling und Web-Scraping?
Web-Scraping ist die Verwendung von Webcrawlern, um alle Inhalte einer Zielwebseite zu scannen und zu speichern. Mit anderen Worten: Web-Scraping ist ein spezifischer Anwendungsfall des Webcrawlings, um einen gezielten Datensatz zu erstellen, etwa das Abrufen aller Finanznachrichten für die Investitionsanalyse und die Suche nach bestimmten Firmennamen.
Traditionell extrahierte ein Web-Scraper Daten aus der indexierten Webseite, nachdem ein Webcrawler alle Elemente der Webseite gecrawlt und indexiert hatte. Heutzutage werden die Begriffe Scraping und Crawling jedoch austauschbar verwendet, mit dem Unterschied, dass sich „Crawler“ eher auf Suchmaschinen-Crawler bezieht. Als auch andere Unternehmen als Suchmaschinen begannen, Webdaten zu nutzen, begann der Begriff „Web-Scraper“ den Begriff „Web-Crawler“ zu verdrängen.
Als bevorzugte Quelle hinzufügenWas sind die Herausforderungen des Webcrawlings?
1. Aktualität der Datenbank
Der Inhalt von Websites wird regelmäßig aktualisiert. Dynamische Webseiten ändern ihren Inhalt beispielsweise basierend auf den Aktivitäten und Verhaltensweisen der Besucher. Das bedeutet, dass der Quellcode der Website nach dem Crawlen nicht mehr derselbe ist. Um dem Benutzer die aktuellsten Informationen bereitzustellen, muss der Webcrawler diese Webseiten häufiger erneut crawlen.
2. Crawler-Fallen
Websites setzen verschiedene Techniken ein, etwa Crawler-Fallen, um Webcrawler daran zu hindern, auf bestimmte Webseiten zuzugreifen und sie zu crawlen. Eine Crawler-Falle oder Spider-Falle führt dazu, dass ein Webcrawler unendlich viele Anfragen stellt und in einem Teufelskreis des Crawlens gefangen wird. Websites können Crawler-Fallen auch unbeabsichtigt erzeugen. In jedem Fall gerät ein Crawler, wenn er auf eine Crawler-Falle trifft, in eine Art Endlosschleife, die Ressourcen des Crawlers verschwendet.
3. Netzwerkbandbreite
Das Herunterladen einer großen Anzahl irrelevanter Webseiten, der Einsatz eines verteilten Webcrawlers oder das erneute Crawlen vieler Webseiten führt alles zu einem hohen Verbrauch an Netzwerkkapazität.
4. Doppelte Seiten
Webcrawler-Bots crawlen größtenteils alle doppelten Inhalte im Web; es wird jedoch nur eine Version einer Seite indexiert. Doppelter Inhalt macht es für Suchmaschinen-Bots schwierig zu bestimmen, welche Version des doppelten Inhalts indexiert und gerankt werden soll. Wenn Googlebot eine Gruppe identischer Webseiten in den Suchergebnissen entdeckt, indexiert es nur eine dieser Seiten und wählt sie aus, um sie als Antwort auf die Suchanfrage eines Benutzers anzuzeigen.
Die 3 besten Praktiken für Webcrawling
1. Höflichkeit/Crawl-Rate
Websites legen eine Crawl-Rate fest, um die Anzahl der Anfragen von Webcrawler-Bots zu begrenzen. Die Crawl-Rate gibt an, wie viele Anfragen ein Webcrawler in einem bestimmten Zeitintervall an Ihre Website stellen kann (z. B. 100 Anfragen pro Stunde). Sie ermöglicht es Website-Betreibern, die Bandbreite ihrer Webserver zu schützen und eine Überlastung des Servers zu reduzieren. Ein Webcrawler muss das Crawl-Limit der Zielwebsite einhalten.
2. Robots.txt-Compliance
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, d. h. konforme Bots respektieren sie, aber sie verhindert den Zugriff technisch nicht. Das Befolgen der robots.txt einer Website gilt als Best Practice, und in vielen Rechtsordnungen kann deren Missachtung rechtliche oder rufschädigende Risiken mit sich bringen.
3. IP-Rotation
Websites setzen verschiedene Anti-Scraping-Techniken wie CAPTCHAs ein, um den Crawler-Verkehr zu steuern und Web-Scraping-Aktivitäten zu reduzieren. Beispielsweise ist Browser-Fingerprinting eine Tracking-Technik, mit der Websites Informationen über Besucher sammeln, etwa Sitzungsdauer oder Seitenaufrufe.
Diese Methode ermöglicht es Website-Betreibern, „nicht-menschlichen Verkehr“ zu erkennen und die IP-Adresse des Bots zu blockieren. Um einer Erkennung zu entgehen, können Sie rotierende Proxys, wie Residential Proxys, in Ihren Webcrawler integrieren.
Methodik des Webcrawler-Benchmarks
Wir haben vier Crawl-APIs (Apify, Nimble, Cloudflare, Firecrawl) auf drei Domänen mit unterschiedlichem Schwierigkeitsgrad getestet: amazon.com (starker Bot-Schutz), entrepreneur.com (komplexe Inhaltsseite) und theregister.com (Nachrichtenseite).
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 Zieldomäne
- 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)
- Behandlung von Ratenlimits: 20-Sekunden-Wartezeit mit bis zu 3 Wiederholungen bei HTTP 429
Jeder Anbieter wurde auf drei maximalen Tiefenstufen (5, 10, 20) über alle drei Domänen getestet, insgesamt 36 Crawl-Läufe. Die Anbieter wurden sequenziell (nicht parallel) getestet, jede Kombination wurde einmal ausgeführt, und der Crawl-Status wurde jede Sekunde abgefragt.
Apify wurde mit dem Website-Content-Crawler-Actor unter Verwendung von Playwright/Firefox als Headless-Browser konfiguriert. Der Zugriff auf Subdomains wurde über Glob-Muster gesteuert, und der integrierte Proxy von Apify 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 haben wir den Workers-Paid-Plan verwendet. Die angegebenen Kosten spiegeln wider, was wir ausgegeben haben, um unter diesem Plan 1.000 Seiten zu crawlen. Cloudflare berechnet die Kosten auf Basis der Browser-Rendering-Zeit und nicht der Seitenzahl.
Für Firecrawl haben wir den Hobby-Plan verwendet. Die angegebenen Kosten sind der anteilige Betrag für 1.000 Credits aus den in diesem Plan enthaltenen Credits. Die effektiven Kosten pro Seite variieren je nach Planstufe und 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 = {{Webcrawler-Benchmark, um Websites an KI zu verfüttern}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/web-crawler}},
note = {AIMultiple. Abgerufen am 11. August 2026}
}Änderungsprotokoll
9 Aktualisierungen- 2026
Die Abschnitte zu Branchentrends, Crawler-Typen und Web-Crawling-Beispielen wurden entfernt.
Benchmark von vier Crawl-APIs über drei Domains und drei Tiefenstufen mit Diagrammen zu Abdeckung, Geschwindigkeit, Links und Titeln hinzugefügt.
Ein Methodikabschnitt hinzugefügt, der das Crawl-Setup für vier Anbieter, drei Domains und drei Tiefenstufen beschreibt.
Ein Abschnitt, Sind Web-Crawler legal?, wurde dem Artikel hinzugefügt.
Der Abschnitt „Was ist ein Web-Crawler?“ wurde mit neuen Trends und Betriebsmodi aktualisiert.
- 2024
Das Jahr im Abschnitt „Die besten Web-Crawler“ wurde aktualisiert.
- 2023
Eine Kurzzusammenfassung der besten Web-Crawler von 2023 wurde dem Vorwort hinzugefügt.
Der Abschnitt „Warum ist Web-Crawling wichtig?“ wurde entfernt.
Die Einleitung wurde um eine Definition von Webcrawler und Web Scraping erweitert.
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.
Kommentare 1
Teilen Sie Ihre Gedanken
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.
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.