Alle paar Monate stellt jemand in unserem Team in Slack dieselbe Frage: „Sollen wir dafür einfach einen Scrapy-Spider schreiben?“ Und jedes Mal hängt meine Antwort komplett davon ab, wer fragt und was genau erreicht werden soll. Damit ist im Grunde schon der ganze Artikel gesagt — aber ich verdiene mein Gehalt ja nicht dafür, die Pointe vorwegzunehmen, also erkläre ich es jetzt ordentlich.
Ich arbeite seit fast einem Jahrzehnt in SaaS und Automation — zuerst bei Automation Anywhere, wo ich gesehen habe, wie Unternehmen alles automatisieren, außer dem Teil, bei dem trotzdem noch jemand Daten von einer Website kopieren und einfügen musste, und jetzt bei Thunderbit, wo genau dieses „Copy & Paste von Websites“ das Problem ist, das wir aus der Welt schaffen wollen. Scrapy wiederum treibt seit Jahren still und zuverlässig die Datenpipelines des Internets an, lange bevor „agentic AI“ ein Begriff war, den man beim Abendessen fallen ließ. Die beiden zu vergleichen heißt nicht wirklich Thunderbit vs Scrapy im Sinne von „wer gewinnt?“. Es ist eher wie ein Schweizer Taschenmesser mit einer voll ausgestatteten Werkstatt zu vergleichen — beide liefern am Ende ein Stück zugeschnittenes Metall, aber der Weg dahin, der nötige Skill und das Chaos danach sind völlig unterschiedlich.
Kurze Antwort
Wenn du nur die Kurzfassung willst, bevor ich ins Detail gehe: Thunderbit ist ein verwalteter, agentischer Web Scraper — du zeigst auf eine Seite, klickst einmal, und das Tool erkennt die Struktur für dich, egal ob du im Browser, in der Web App, über die Open API, den MCP Server oder die CLI arbeitest. Scrapy ist ein ausgereiftes Open-Source-Python-Framework — du schreibst den Spider, definierst die Selektoren, baust die Pipeline und verantwortest jede Zeile Code, die mit deinen Daten zu tun hat.
Keines der beiden Tools ist in einem universellen Sinn „besser“. Sie sind für unterschiedliche Menschen und unterschiedliche Probleme gebaut — und ehrlich gesagt ist genau das der Grund, warum ich diesen Beitrag sauber aufziehen wollte, statt alles auf ein einziges Urteil zu verkürzen.
Auf einen Blick
Hier ist die Tabelle, die ich mir beim ersten Suchen gewünscht hätte. Jeder „Thunderbit vs Scrapy“-Artikel, den ich gefunden habe, steckte die beiden Tools entweder in einen größeren Scrapy-vs-BeautifulSoup-Vergleich oder lieferte nur ein dünnes, kaum hilfreiches Verzeichnis-Widget. Also haben wir das echte Ding gebaut.
Was ist Thunderbit?
Thunderbit entstand aus einer ziemlich nervigen Beobachtung: Die meisten Menschen, die Daten aus dem Web brauchen, sind keine Entwickler — und die meisten Tools zum Web Scraping tun so, als wären sie es. Genau diese Lücke ist im Grunde der Grund, warum es uns gibt.
Der Kern-Workflow im Browser ist im besten Sinne absichtlich unspektakulär. Du öffnest die Seite mit den gewünschten Daten, klickst auf One Click Extract, und der Agent übernimmt ab da — er liest die Seite, erkennt, was sich extrahieren lässt (Produktlisten, Stellenanzeigen, Kontaktdaten, was auch immer sichtbar ist) und bereitet die Felder automatisch vor. Es gibt einen Run Now-Button, wenn du sofort loslegen willst; wenn du aber einfach in Ruhe deinen Kaffee trinkst, startet die Extraktion ohnehin von selbst. Keine Selektoren, kein Schema-Gebastel, keine „Inspect Element“-Archäologie.
Über den One-Click-Browser-Workflow hinaus erstreckt sich Thunderbit noch über weitere Oberflächen, je nachdem, was du baust:
- Die Chrome Extension ist für den Fall gedacht: „Ich schaue mir diese Seite gerade an und will genau diese Daten haben.“
- Die Web App deckt cloudbasierte und wiederkehrende Datenerfassung für Business-User ab, die keinen Code anfassen wollen.
- Die Open API stellt Distill- und strukturierte Extract-Endpunkte für Backend- und Anwendungs-Workflows bereit.
- Der MCP Server erlaubt es KI-Agenten in Claude, Cursor oder Windsurf, Thunderbit direkt als Tool aufzurufen.
- Die CLI ist für Entwickler und Coding-Agenten gedacht, die im Terminal arbeiten.
Thunderbit kann auf kompatiblen Seiten auch Pagination und Subpage-Anreicherung übernehmen, und Felder lassen sich mit Anweisungen in Alltagssprache statt mit Regex verfeinern. All das heißt nicht, dass es auf jeder Website der Welt perfekt funktioniert — dazu komme ich gleich noch ganz offen — aber es ist so gebaut, dass ein Sales-Operations-Mitarbeiter oder ein Immobilienanalyst niemals einen Code-Editor öffnen muss.
Was ist Scrapy im Jahr 2026?
Scrapy ist kein verstaubtes Altwerkzeug. Die offizielle Scrapy-Seite nennt Version 2.17.0 als aktuelle stabile Version, und das Projekt wird weiterhin aktiv gepflegt — die neueste Veröffentlichung brachte sogar HTTP/2- und SOCKS-Proxy-Support in den Download-Handler-Pfad. Das ist also keine Geschichte von „KI hat das alte Framework verdrängt“. Scrapy lebt sehr wohl noch — und ist, ganz ehrlich, immer noch richtig gut in dem, was es tut.
Im Kern ist Scrapy ein Python-Framework, das auf einer asynchronen Crawling-Engine basiert. Du schreibst eine Spider-Klasse, definierst Start-URLs (oder eine Start-Methode), und Scrapy schickt Requests los, deren Callback-Funktionen die Antwort verarbeiten. Danach wählst du Daten mit CSS- oder XPath-Selektoren aus (oder ganz klassisch per Regex, wenn du magst), packst sie in Items und jagst sie durch Pipelines für Bereinigung, Validierung und Speicherung. Die offizielle Übersichts-Dokumentation erklärt diesen Ablauf Schritt für Schritt — und das ist tatsächlich ein sehr elegantes System, sobald man es verstanden hat.
Der Preis für diese Lerninvestition ist echte Kontrolle: Cookies und Sessions, Authentifizierungsabläufe, Caching, robots.txt-Beachtung, Crawl-Tiefenlimits und AutoThrottle, damit dein IP nicht von einem verärgerten Server-Admin geblockt wird. Dazu kommt ein riesiges Middleware- und Extension-Ökosystem — Proxy-Rotation, eigene Download-Handler, Monitoring-Hooks und neuerdings auch Add-ons für Playwright-basiertes Rendering sowie sogar KI-Coding-Agent-Tools, die dir Spider-Boilerplate erzeugen.
Ein wichtiger Punkt zur Einordnung: Die Core-Engine von Scrapy ist ein HTTP-Crawler, kein Browser. JavaScript rendert Scrapy nicht von selbst. Wenn du das brauchst, greifst du zu scrapy-playwright, einer Selenium-ähnlichen Middleware oder einem externen Rendering-Dienst. Das ist nicht zwingend ein Nachteil — es ist eine bewusste Designentscheidung, die das Framework schlank und schnell hält — aber es bedeutet eben auch, dass „eine JS-lastige Website verarbeiten“ kein Standardverhalten ist, sondern eine Projektentscheidung.
Der Kernunterschied: Verwalteter agentischer Workflow vs. Code-eigenes Framework
Zeit bis zum ersten Datensatz
Ich werde hier keine Stoppuhrzahlen erfinden — ich habe schon zu viele Artikel gesehen, die behaupten, Scrapy habe eine „steile Lernkurve“, ohne jemals zu zeigen, wie sie zu diesem Urteil gekommen sind. Zählen wir also einfach die tatsächlichen Schritte.
Scrapy-Weg, zum Beispiel für eine Produktliste:
- Python-virtuelle Umgebung einrichten und Scrapy installieren.
- Einen Spider aus einer Vorlage generieren.
- Den HTML-Code der Seite prüfen und für jedes Feld XPath-/CSS-Selektoren schreiben.
- Eine Item-Pipeline für Bereinigung und Export konfigurieren.
- Spider ausführen, Selektorfehler debuggen, erneut ausführen.
Thunderbit-Weg für dieselbe Aufgabe:
- Die Seite im Browser öffnen.
- One Click Extract klicken.
- Der Agent erkennt die extrahierbaren Felder und startet automatisch (oder du klickst auf Run Now).
Das sind fünf Schritte mit Python-Setup gegenüber drei Schritten ohne jegliche Umgebungsinstallation. Ich behaupte nicht, dass die reine Schrittzahl alles ist — Scrapys fünf Schritte geben dir deutlich mehr Kontrolle darüber, was genau passiert — aber wenn das Ziel schlicht lautet: „Diese Tabelle heute noch in eine Tabelle oder ein Spreadsheet bekommen“, dann ist genau dieser Unterschied die ganze Geschichte.
Kontrolle und Erweiterbarkeit
Hier spielt Scrapy seine Stärke aus, und ich würde dir einen Bärendienst erweisen, wenn ich so täte, als wäre das anders. Weil du den Quellcode kontrollierst, kannst du wirklich alles bauen: eigenes Retry-Verhalten, ungewöhnliche Pagination-Logiken, mehrstufige Authentifizierungsabläufe, die Anbindung an dein bestehendes Data Warehouse — was auch immer deine Architektur verlangt. Thunderbits agentischer Ansatz optimiert auf „strukturierte Daten schnell ohne Code“, was per Definition bedeutet, dass das System Entscheidungen für dich trifft, statt dir jeden Hebel offenzulegen. Für 80 % der Business-Extraktionsaufgaben ist dieser Tausch fantastisch. Für die restlichen 20 % — die wirklich seltsame, maßgeschneiderte Crawling-Logik — brauchst du ein Framework, das du nach Belieben verbiegen kannst.
Wartung und operative Verantwortung
Spiders gehen kaputt. Das ist kein Angriff auf Scrapy — jeder Scraper, egal ob agentisch oder handgeschrieben, ist der Website ausgeliefert, auf die er zeigt. Aber wenn ein Scrapy-Spider bricht, weil eine Website ihr HTML-Layout umgebaut hat, muss jemand im Team das bemerken, analysieren und reparieren. Das ist echter Entwicklungsaufwand, jedes einzelne Mal.
Thunderbits KI-gestützte Extraktion kann sich an manche Layoutänderungen automatisch anpassen, weil sie die Seitenstruktur interpretiert, statt nur einem hart codierten Selektorpfad zu folgen. Trotzdem will ich ehrlich sein: Das ist keine Immunität. Genügend drastische Strukturänderungen können das System weiterhin aus dem Tritt bringen. Der Unterschied liegt eher darin, wer die Anpassung übernimmt — ein Algorithmus mit Best-Effort-Schätzung oder ein Entwickler, der um 23 Uhr XPath von Hand neu schreibt.
Praxisnahe Szenarien
Einmalige Verzeichnis- oder Produkttabelle
Wenn du von einer einzelnen Seite oder einer kleinen Seitenliste eine Tabelle mit Restaurant-Einträgen, Produktpreisen oder Veranstaltungsdetails brauchst, ist ein Scrapy-Projekt ehrlich gesagt überdimensioniert — du würdest einen Spider schreiben, den du genau einmal benutzt und danach nie wieder anfasst. Das ist ganz klar Thunderbits Terrain als Browser-Erweiterung: öffnen, klicken, extrahieren, nach Google Sheets exportieren, fertig.
Großer Custom-Crawl mit Business-Regeln
Stell dir nun vor, du musst 50.000 Produktseiten über ein Dutzend Domains crawlen, eine eigene Deduplizierungslogik anwenden und alles in ein proprietäres Preismodell einspeisen. Das ist genau Scrapys Spielwiese. Die Pipeline-Architektur, die Concurrency-Steuerung, das Middleware-Ökosystem — all das existiert genau für Jobs in dieser Größenordnung mit so viel individueller Logik.
Dynamische, stark JavaScript-lastige Website
Beide Tools brauchen hier Hilfe, nur eben unterschiedliche. Scrapy braucht eine explizite Rendering-Integration wie scrapy-playwright, die man zusätzlich einklinkt — inklusive weiterer Abhängigkeiten und laufendem Wartungsaufwand. Thunderbits Browser-Erweiterung arbeitet mit der bereits im Browser gerenderten Seite — auch mit einigen unterstützten eingeloggten Sitzungen — und umgeht damit einen Großteil des Setups. Aber ich will klar sagen: Keiner der beiden Ansätze ist ein garantierter Sieg gegen aggressive Anti-Bot-Systeme oder ungewöhnliche Dynamikmuster. Wer dir etwas anderes erzählt, verkauft dir etwas.
KI-Agenten- oder Anwendungsintegration
Wenn du in Claude oder Cursor einen KI-Agent-Workflow baust und dieser im Rahmen seiner Schlussfolgerung Live-Webdaten abrufen soll, ist eine eigene Scrapy-Integration nicht gerade wenig Arbeit. Thunderbits MCP Server ist genau dafür gemacht — er stellt Extraktion als Tool bereit, das dein Agent direkt aufrufen kann.
Genauigkeit, Skalierung und Wartung
Scrapys Genauigkeit ist im besten Sinne deterministisch — ein sauber geschriebener Selektor zieht jedes Mal exakt das Feld, das du ihm gesagt hast, bis sich das zugrunde liegende HTML ändert. Diese Vorhersagbarkeit ist in Produktionspipelines enorm wertvoll, wenn du genau wissen musst, warum etwas schiefgelaufen ist.
Thunderbits agentische Erkennung funktioniert anders. Sie interpretiert die Seite so, wie ein Mensch sie ansehen würde, und entscheidet, was wahrscheinlich Preis, Titel oder Beschreibung ist. Das ist für Geschwindigkeit und Flexibilität unglaublich nützlich, aber es ist ein anderes Genauigkeitsmodell — eher „meistens richtig, gelegentlich braucht es einen kleinen Schubs“ als „immer exakt das, was der Selektor sagt“. Ich sage dir lieber offen, wie dieser Tausch aussieht, als so zu tun, als wäre KI-gestützte Extraktion fehlerfrei.
Beim reinen Durchsatz ist Scrapys asynchrone Engine darauf ausgelegt, riesige Mengen an Requests effizient durchzuschieben — das gehört wirklich zu ihrer DNA. Thunderbit ist eher für gezielte Jobs mit mittlerem Volumen optimiert, bei denen schnell ein sauberes strukturiertes Ergebnis wichtiger ist als das nächtliche Crawlen von einer Million Seiten. Wenn du einen wirklich massiven Crawl planst, solltest du dir die aktuellen Planlimits anschauen, bevor du annimmst, dass eines der Tools in jeder Hinsicht so skaliert, wie du es brauchst.
Noch ein Punkt, der für beide gilt: autorisierte Nutzung ist entscheidend. Ganz gleich, welches Tool du nimmst — robots.txt, Website-Nutzungsbedingungen und geltendes Recht zu respektieren ist nicht optional, sondern gehört zu einem verantwortungsvollen Einsatz einfach dazu.
Preis, Lizenz und Gesamtkosten
Hier tappen viele ständig in dieselbe Falle: „kostenlos“ und „ohne Kosten“ gleichzusetzen. Scrapy hat keine Lizenzgebühr — es ist Open Source, Punkt. Aber kostenlose Software braucht trotzdem eine Laufzeitumgebung, und die kostet Geld: Hosting, Proxy-Dienste bei größerem Volumen, Browser-Automation-Tools für JavaScript-Rendering, Monitoring, damit du merkst, wenn ein Spider still und leise stirbt, und — das ist der große Posten — Entwicklerzeit zum Bauen, Testen und Reparieren.
Thunderbit basiert auf einem Abo-/Credit-Modell, und ich verweise dich lieber auf die offizielle Preisseite, statt hier irgendeine Zahl zu nennen, weil sich Preisstrukturen ändern können und ich möchte, dass du die aktuellen Konditionen direkt siehst. Was dieses Abo dir kauft, ist vor allem der Wegfall eines Großteils von Setup- und Wartungsaufwand — zumindest für unterstützte Workflows.
Die eigentliche Frage lautet nicht: „Was ist auf dem Papier günstiger?“ Sondern: „Welche Währung hat dein Team mehr zur Verfügung — Entwicklerstunden oder ein Softwarebudget?“ Ein Data-Engineering-Team mit fünf Leuten und freien Kapazitäten findet Scrapy möglicherweise insgesamt günstiger, wenn man vorhandene Skills mitrechnet. Ein dreiköpfiges Operations-Team ohne Inhouse-Entwickler wird feststellen, dass das „kostenlose“ Framework in Wahrheit Contractor-Rechnungen und drei Wochen Verzögerung kostet, bevor die erste Datenzeile überhaupt sichtbar ist.
Wer sollte sich für Thunderbit entscheiden?
Thunderbit ist besonders sinnvoll, wenn du ein nicht-technischer Anwender bist — im Sales, Marketing, E-Commerce, in der Immobilienbranche oder im Recruiting — und jetzt strukturierte Daten brauchst, ohne dafür erst ein Engineering-Ticket aufzumachen. Es passt auch gut zu Entwicklern, die programmgesteuerten Zugriff wollen, aber die Extraktionslogik nicht selbst von Grund auf bauen möchten, denn die Open API und die CLI übernehmen diese Ebene für dich. Wenn deine Workflows Lead-Generierung, E-Commerce-Monitoring oder LinkedIn-Datenextraktion für Recruiting-Recherche beinhalten, ist das in der Regel der schnellere Weg.
Wer sollte sich für Scrapy entscheiden?
Scrapy ist die richtige Wahl, wenn du Python-Entwickler im Team hast, eine Crawling-Infrastruktur aufbaust, die über Jahre laufen soll, und volle Kontrolle über Request-Logik, Retry-Verhalten und Datenpipelines brauchst. Es ist auch die bessere Option, wenn Compliance- oder Architekturvorgaben verlangen, dass der Code komplett dir gehört — auditierbar, selbst gehostet und ohne externe Abhängigkeit.
Können Teams beides nutzen?
Viele Teams tun genau das, und ich halte das nicht für eine Ausweichantwort. Entwickler können langlebige, hochskalierbare Scrapy-Spiders für die Crawling-Infrastruktur betreiben, die dauerhaft bestehen muss, während der Rest der Organisation Thunderbit für Ad-hoc-Recherchen, einmalige Datenabzüge und explorative Arbeiten nutzt, die keinen kompletten Engineering-Sprint rechtfertigen. Eine offizielle Integration zwischen den beiden Tools gibt es nicht — das will ich klar sagen — aber operativ steht dir nichts im Weg, beide parallel einzusetzen, je nachdem, welches Tool für welchen Job besser passt.
Fazit
Wenn ich das auf eine einzige Bauchfrage verdichten müsste: Optimierst du eher auf Kontrolle oder auf Geschwindigkeit? Scrapy gibt dir totale Kontrolle, kostet dafür aber Einrichtungszeit und laufende Wartung. Thunderbit gibt dir Geschwindigkeit und Zugänglichkeit, verlangt dafür aber einen Teil der Flexibilität. Keines von beiden ist objektiv die einzig richtige Antwort — es hängt davon ab, ob die Person, die scrapen soll, Python beherrscht oder ihre Sales-Pipeline kennt. Mehr dazu, wie KI-basierte Extraktion im Vergleich zu klassischen Methoden abschneidet, findest du in unserer Einordnung zu AI Web Scraping und Web Scraping ohne Code, die das Thema über diesen direkten Vergleich hinaus breiter beleuchten.
FAQ
Ist Scrapy kostenlos? Das Scrapy-Framework selbst ist Open Source und hat laut der offiziellen Scrapy-Seite keine Lizenzgebühr. Deine tatsächlichen Kosten entstehen durch Hosting, Proxies, Rendering-Tools, falls du JavaScript-Unterstützung brauchst, und Entwicklerzeit für Aufbau und Wartung der Spiders.
Kann Scrapy JavaScript von sich aus rendern? Nein. Scrapys Kern ist ein HTTP-Crawler, kein Browser, daher führt es JavaScript nicht von Haus aus aus. Teams ergänzen bei JS-lastigen Seiten typischerweise scrapy-playwright oder eine Selenium-ähnliche Middleware, wie in der offiziellen Scrapy-Dokumentation beschrieben.
Unterstützt Thunderbit API- und MCP-Zugriff? Ja. Thunderbit bietet eine Open API mit Distill- und strukturierten Extract-Endpunkten für programmgesteuerte Nutzung sowie einen MCP Server, über den KI-Agenten in Tools wie Claude und Cursor Thunderbit direkt aufrufen können.
Was ist für Business-User schneller? Thunderbit, ganz klar. Der Browser-Workflow One Click Extract startet die Extraktion automatisch nach der Analyse der Seite, ganz ohne Selektoren oder Schema-Setup — also ein deutlich kürzerer Weg als Python zu installieren und einen Spider zu schreiben.
Was eignet sich besser für stark angepasste Crawls? Scrapy. Sein Middleware-System, die Pipeline-Architektur und der vollständige Zugriff auf den Quellcode geben Entwicklern die Kontrolle, die sie für sehr spezifische Crawling-Logik, groß angelegte geplante Jobs und maßgeschneiderte Datenpipelines brauchen, die ein agentisches Tool nicht ersetzen soll.
