Scrapy wird oft vorschnell in die Schublade „kommt mit modernen Websites nicht klar“ gesteckt, nur weil es kein JavaScript ausführt. Genau da liegt aber der Denkfehler. Dass die Seite nicht gerendert wird, ist kein Defizit, sondern das eigentliche Konzept — und sobald man es in der Praxis erlebt, fühlt es sich auch nicht mehr wie eine fehlende Funktion an.
Ich habe mir das in nur einem Durchlauf selbst bewiesen. Ich baute eine mit JavaScript gerenderte Katalog-Testseite, ließ Scrapy die Seite abrufen, die ein Browser anzeigen würde, und bekam 0 Produktkarten zurück. Danach richtete ich denselben Spider auf den JSON-Endpunkt, den die Seite im Hintergrund still und heimlich aufrief — und erhielt 8/8 Elemente, sauber extrahiert. Dasselbe Tool, dieselbe Session, zwei komplett unterschiedliche Ergebnisse — und genau um diese Lücke zwischen den beiden Zahlen geht es in diesem Testbericht.
Was Scrapy tatsächlich ist — und was nicht
Scrapy ist ein Python-Framework zum Crawlen von Websites und zum Extrahieren strukturierter Daten. So beschreiben es die Maintainer auch selbst in den Überblicksdokumenten — und nach der Nutzung kann ich sagen: Das stimmt, ohne Marketing-Sprech. Das Projekt ist alt und etabliert genug, um für Python-Entwickler die naheliegende Antwort zu sein, wenn es um ernsthafte Webdatenextraktion geht. Auch das Repository bestätigt diesen Eindruck: rund 62.981 GitHub-Sterne zum 07.07.2026 (scrapy/scrapy), dazu 11.773 Forks und 590 offene Issues am selben Tag. Lizenz: BSD-3-Clause, Python 3.10 oder neuer. Die Version, die ich getestet habe, war 2.17.0 — sie erschien sogar am Morgen meiner Tests, also kein Sternchen wegen einer veralteten Version.
Hier liegt die Trennlinie, die Scrapy von neueren AI-Crawlern unterscheidet: Scrapy arbeitet standardmäßig nur per HTTP. Kein Browser. Keine Rendering-Engine. Es lädt HTML über das Netz herunter, übergibt es an einen Parser und extrahiert Felder per CSS-Selektoren oder XPath. Das als Einschränkung zu bezeichnen, trifft nur die halbe Wahrheit und verfehlt den eigentlichen Designgedanken. Die Grundidee von Scrapy ist nämlich, dass es meist der falsche Weg ist, für einen Standard-Job erst einmal Chrome headless hochzufahren. Der klügere Weg ist, die Datenanfrage zu finden, die die Seite ohnehin schon ausführt — und genau diese direkt anzusprechen.
Und das ist nicht meine persönliche Auslegung, sondern die offizielle Haltung. In den Dokumenten zu dynamischen Inhalten steht es ausdrücklich: Zuerst die zugrunde liegende Datenanfrage identifizieren und nachbauen; ein Headless-Browser ist nur die Ausweichlösung, wenn sich diese Anfrage nicht praktikabel reproduzieren lässt. Die meisten Scraper öffnen zuerst den Browser und denken nie an die API. Scrapy dreht dieses Standardverhalten um.
Wichtige Funktionen — und die Designentscheidung dahinter
Unter der Haube besteht Scrapy aus mehreren Bausteinen, die alle von derselben Annahme ausgehen: Du bist Entwickler und willst Kontrolle, nicht einen Ein-Klick-Zauberer.
Spiders. Man schreibt eine Klasse, gibt Start-URLs an und definiert einen parse-Callback, der Items erzeugt oder weiteren Links folgt. Das ist mehr Schreibarbeit als bei einem No-Code-Extractor — die Extraktionslogik liegt komplett bei dir — dafür entscheidest du exakt, was erfasst wird und wohin der Crawl als Nächstes geht.
Selektoren. Das Parsen basiert auf parsel, darunter arbeitet lxml. CSS und XPath sind beide vollwertig integriert, nicht nur nachträglich angeflanscht. Der lxml-Unterbau sorgt dafür, dass die Auswahl schnell bleibt und der Code eher nach Absicht als nach String-Gefrickel aussieht.
Feed-Exports. Richtest du einen Spider auf eine Datei, serialisiert Scrapy die Daten ohne weitere Verkabelung nach JSON, JSON Lines, CSV oder XML. In meinem Lauf schrieb ein Spider für einen statischen Katalog sowohl JSON als auch CSV — ganz ohne eine einzige Export-Zeile von mir. Die Feed-Export-Funktion ist also echt und funktioniert genau so, wie beschrieben.
AutoThrottle und Crawl-Kontrollen. Anfragen werden asynchron über Twisted geplant, und du bekommst Concurrency-Limits, Download-Verzögerungen, Tiefenbegrenzungen, AutoThrottle für adaptive Ratenbegrenzung sowie robots.txt-Beachtung. Das sind die Schutzmechanismen, die einen breiten Crawl davor bewahren, zur Serverkeule zu werden.
HTTP-only — noch einmal als Vorteil formuliert. Kein Browser bedeutet wenig Speicherverbrauch, hohen Durchsatz und keine Rendering-Engine, die mitlaufen muss — vorausgesetzt, die gewünschten Daten sind per normalem HTTP erreichbar. Und das sind sie viel häufiger, als die Browser-first-Fraktion annimmt.
Einrichtung: der Dependency-Stack, den niemand in Screenshots zeigt
Die Installation war unspektakulär — und bei einem Framework dieser Größe ist genau das erwähnenswert. pip install Scrapy==2.17.0 lief in einer frischen virtuellen Umgebung auf macOS arm64 sauber durch, mit binären Wheels und ohne Kompilierungsdrama. Nichts Spektakuläres zu berichten — und genau das ist der Punkt.
Interessant ist eher, was dabei alles mitkam. scrapy version -v zeigte Scrapy 2.17.0 auf Basis von lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 und cryptography 49.0.0, ergänzt durch parsel, cssselect und tldextract. Das ist ein echter Fußabdruck — praktisch ein ganzes Crawling-Framework als Abhängigkeitsstapel, nicht bloß ein einzelner HTML-Parser. Auf meinem Rechner existierten für alles passende Wheels, daher verlief die Installation problemlos. Auf anderen Systemen warnen die offiziellen Dokus jedoch weiterhin vor plattformspezifischen Reibungen; historisch sind vor allem cryptography und Twisted die Stellen, an denen es klemmen kann. Wenn du also auf einer ungewöhnlichen Plattform arbeitest, solltest du dafür Zeit einplanen. Hier lief alles glatt — aber die Größe des Installationspakets sollte man trotzdem kennen, bevor man sich festlegt. Du holst dir eben ein Framework ins Haus, und ein Framework bringt auch das entsprechende Gewicht mit.
Praxistest: Was funktioniert hat
Nach der Installation lief der statische Pfad einwandfrei. Vollständige Trefferquote, nichts verloren.
| Test | Ergebnis | Laufzeit |
|---|---|---|
| Lokaler statischer Katalog + Pagination | 12/12 Produkte | 0,557 s |
| CSV-Export für statischen Katalog | 12 Zeilen geschrieben | (derselbe Lauf) |
| Artikel-Extraktion | Titel + 3/3 Textabsätze | 0,416 s |
| Crawl-Graph, DEPTH_LIMIT=2 | 11 Seiten auf Tiefe 0/1/2 | 0,904 s |
| Lokale 500-Seite | Status 500 erfasst, kein Absturz | 0,424 s |
| Books to Scrape (öffentlich) | 20 Produkte | 2,053 s |
| Quotes to Scrape Spider (öffentlich) | 12 Zitat-Elemente | 3,465 s |
Der Spider für den statischen Katalog arbeitete sich von Seite eins zu Seite zwei durch die Pagination und erfasste 12/12 erwartete Datensätze. Danach schrieb er sie im selben Durchlauf als JSON und CSV heraus. Besonders interessant ist die Artikel-Testseite. Scrapy versuchte nicht, die Seite automatisch in sauberes Markdown umzuwandeln — stattdessen konnte ich gezielt article-Felder per Selektor ansprechen und Navigation sowie Footer-Inhalte separat auslagern. So erhielt ich 3/3 Hauptabsätze, während der Boilerplate-Text sauber getrennt blieb, statt im Ergebnis zu landen. Genau das ist der Tausch: Du schreibst die Selektoren selbst, bekommst dafür aber exakt das, was du angefordert hast — und nichts Zusätzliches.
Auch die Crawl-Kontrolle überzeugte im kleinen Maßstab. Mit DEPTH_LIMIT=2, einer kurzen Download-Verzögerung, domänenweiter Concurrency-Begrenzung und aktivem robots.txt-Schutz erfasste der Crawl-Graph 11 Seiten auf den Tiefen 0, 1 und 2, und die Tiefenlogik funktionierte korrekt. Ebenso unspektakulär war das Fehlerhandling. Die absichtlich erzeugte 500-Seite wurde als strukturierter Datensatz mit Status 500 über handle_httpstatus_list zurückgegeben — kein Exception-Fehler, kein abgebrochener Run. Scrapy behandelt Fehlerstatus also als etwas, das man in der Spider-Logik verarbeitet, statt als Überraschung, die den Crawl zu Fall bringt.
Praxistest: die JavaScript-Grenze und die Tür daneben
Jetzt kommen wir zu dem Ergebnis, um das sich dieser Testbericht dreht.
Ich ließ Scrabys HTTP-Fetcher auf eine JavaScript-gerenderte Katalogseite los. Er lud den Quell-HTML-Code herunter, fand 0 .product-card-Knoten und machte weiter — weil er das Script nie ausgeführt hat, das diese Karten überhaupt erst erzeugen würde. Die öffentliche Quotes to Scrape JS page erzielte dasselbe Ergebnis: 0 gerenderte Quote-Knoten. Würde man den Test hier beenden, käme man schnell zu dem Schluss, Scrapy sei für alles Unbrauchbare aus diesem Jahrzehnt ungeeignet.
Aber man sollte dort nicht aufhören. Der JS-Katalog wurde im Hintergrund ganz normal von einer JSON-API befüllt — genau so, wie es bei den meisten dieser Seiten der Fall ist. Ich richtete denselben Scrapy-Spider auf diesen Endpunkt und bekam 8/8 Produkte in 0,416 s zurück — kein Browser, kein Rendering, nur eine Anfrage an die URL, die die Seite ohnehin schon aufrief, und das Parsen der zurückgegebenen JSON-Daten.
Dieser direkte Vergleich zeigt im Kleinen die Philosophie „Anfrage nachbauen statt Seite rendern“. Die gerenderte Seite war nur Kulisse; die eigentlichen Daten lagen die ganze Zeit hinter einer API. Genau dorthin lenkt Scrapy dich — weg vom teuren Headless-Browser, der nur zusieht, wie sich die Seite selbst zusammenbaut. Das ist schneller, schlanker und bricht seltener, denn ein API-Vertrag ist stabiler als ein Haufen clientseitiger DOM-Logik. Der Haken: Das ist Handarbeit. Du musst den Network-Tab öffnen, die Anfrage finden und Header sowie Parameter selbst nachbilden. Scrapy entdeckt die API nicht für dich — es macht nur das Ansprechen trivial, sobald du sie gefunden hast.
Zwei Grenzen, klar benannt. Wenn es tatsächlich keine zugrunde liegende Anfrage gibt, die man reproduzieren könnte — also wenn die Daten rein clientseitig gerendert werden und im Hintergrund keine API existiert — braucht Scrapy eine Headless-Browser-Integration, die du selbst anbinden musst. Diesen Pfad habe ich hier nicht getestet. Und alles oben lief nur mit kleinen Testdaten und öffentlichen Demo-Seiten. Ich habe keinen Crawl über 100 bis 1.000 Seiten gefahren, deshalb mache ich hier keine Aussagen zu Speicherverbrauch, Durchsatz oder Retry-Verhalten im großen Stil. Der asynchrone Kern und die Crawl-Kontrollen sind zwar starke Hinweise, aber Hinweise sind noch keine Messwerte.
Vor- und Nachteile
Vorteile:
- HTTP-only-Design ist schnell und leichtgewichtig — 12/12 statische Treffer in etwa einer halben Sekunde, 8/8 aus einer JSON-API in 0,416 s, ganz ohne Browser-Overhead.
- Der Ansatz „Anfrage nachbauen“ funktioniert tatsächlich: Eine JS-Seite, die 0 Elemente lieferte, gab über ihre API alle 8 Items frei.
- CSS- und XPath-Selektoren auf
lxml-Basis halten den Extraktionscode lesbar und schnell. - Feed-Exports nach JSON/CSV/XML ohne zusätzliches Export-Setup.
- Explizites Fehlerhandling — eine 500 wird als Status zurückgegeben, nicht als Absturz.
- Ausgereifte Crawl-Kontrollen: Concurrency, Verzögerungen, Tiefenbegrenzung, AutoThrottle, robots.txt.
- Permissive BSD-3-Clause-Lizenz; saubere Installation auf einem aktuellen System.
Nachteile:
- Rendert JavaScript nicht per Design — auf clientseitig gerenderten Seiten erscheinen zunächst 0 Knoten, bis man die API selbst findet.
- Das Finden der zugrunde liegenden Anfrage ist Handarbeit; Scrapy zeigt dir den Endpunkt nicht von selbst.
- Großer Dependency-Stack (
Twisted,lxml,cryptography,pyOpenSSL,parsel,tldextract) — hier lief es glatt, aber auf ungewöhnlichen Plattformen ist das historisch eine Reibungsquelle. - Mehr Code als bei No-Code- oder Auto-Extraction-Tools; Spiders müssen geschrieben und gepflegt werden.
- Mein Test deckte kleine Fixtures und Demo-Seiten ab, keinen Großcrawl — Zuverlässigkeit im großen Maßstab ist in diesem Durchlauf also nicht bewiesen.
Für wen es gedacht ist — und wer besser weiterzieht
Scrapy ist für Entwickler, die Kontrolle auf Code-Ebene wollen und in Anfragen denken, nicht in Seiten. Wenn deine erste Reaktion auf eine langsame JavaScript-Seite lautet: „Hier steckt irgendwo eine API dahinter“, dann ist das genau der Anwendungsfall, für den das Tool gebaut wurde. Es belohnt Menschen, die Selektoren schreiben, den Network-Tab lesen und ihre Extraktionslogik vollständig selbst verantworten können. Für statische Websites, paginierte Kataloge und alles, was auf einem auffindbaren JSON-Endpunkt basiert, ist es schnell und präzise.
Gehe lieber weiter — oder kombiniere es mit etwas anderem — wenn du keine Lust hast, Spider-Code zu schreiben und zu pflegen, oder wenn deine Zielseiten Daten nur clientseitig rendern, ohne reproduzierbare Anfrage, und du nicht selbst einen Headless-Browser anbinden möchtest. Und falls der Traum darin bestand, einfach nur eine URL in ein Tool zu stecken und sauberen strukturierten Output zu bekommen, ohne Extraktionsregeln zu schreiben: Das war nie Scrabys Aufgabe, und es hat nie so getan, als wäre es das.
Alternativen und wo Thunderbit einzuordnen ist
Thunderbit für Webdatenextraktion ausprobieren
Man sollte zuerst wissen, worauf man sich einlässt: ein kostenloses Open-Source-Framework, das du selbst betreibst und wartest. Du besitzt die Spiders, den Dependency-Stack und die Arbeit, auf jeder Website die jeweilige Datenanfrage zu finden. Dafür zahlst du pro Request nichts, behältst alles intern und hast maximale Kontrolle. Für viele Teams ist das die richtige Entscheidung — und dieser Testbericht soll niemanden davon abbringen.
Der eigentliche Kompromiss liegt im Problem von Rendering und Seitenänderungen, und Scrabys Antwort darauf lautet: Du löst es. Du findest die API, reproduzierst die Anfrage und baust für den Fall ohne API selbst einen Browser ein. Ein verwaltetes AI-Scraping-API nimmt dir diese Schicht dagegen ab. In diese Rolle fällt Thunderbit für technisch orientierte Leser — ein AI-Scraping-API plus MCP-Server plus CLI, nicht die Browser-Erweiterung, die Sales- und Ops-Teams nutzen. POST /distill wandelt eine Seite in sauberes, LLM-taugliches Markdown um; POST /extract liefert strukturiertes JSON auf Basis eines von dir definierten Schemas; beide übernehmen JavaScript-Rendering, Anti-Bot-Schutz und dynamische Inhalte serverseitig — einschließlich der clientseitig gerenderten Fälle, bei denen Scrapy dich zu einem Browser greifen lässt. Für KI-Agenten und Coding-Assistenten gibt es einen MCP-Server, inklusive kostenfreiem thunderbit_suggest_fields, mit dem du eine Seite erst einmal scopen kannst, bevor Kosten entstehen. Und für Terminal, CI oder Cron steht eine CLI über npx @thunderbit/thunderbit-cli bereit.
Der Unterschied liegt nicht in der Qualität, sondern in der Zuständigkeit. Scrapy ist ein explizites Engineering-Framework: Du pflegst Spider, Pipeline und JS-Strategie selbst und bekommst dafür volle Kontrolle ohne Kosten pro Aufruf. Der Thunderbit-Stack gibt die Render- und Extraktionsschicht als Managed Service ab, sodass du nicht mehr im Network-Tab nach Spuren suchen musst und stattdessen pro Call zahlst. Klein, code-first und mit Freude daran, jeden Schritt selbst zu besitzen? Dann passt Scrabys Kontrolle besser. Du willst über hundert Websites skalieren und für jede Anfrage nicht von Hand dieselbe Arbeit leisten? Dann nimmt dir der Managed-Ansatz genau diese gesamte Arbeit ab.
Weitere Benchmarks aus dem Umfeld findest du hier: der vollständige Vergleich Open-Source-basierter Scraper, die Colly-Review zum browserlosen Go-Crawler und die Scrapling-Review zu adaptiven Selektoren.
Fazit
Sollte man Scrapy verwenden? Ja — wenn du Entwickler bist, Kontrolle willst und die Grundidee teilst: Nicht die Seite rendern, sondern die Anfrage dahinter finden. Im Test hat genau diese Philosophie so funktioniert, wie sie verspricht. Ein JavaScript-Katalog lieferte dem HTTP-Fetcher 0 Karten; die dahinterliegende JSON-API gab dem gleichen Spider alle 8 Items frei. Die statische Extraktion traf 12/12, die Artikel-Selektoren hielten 3/3 Absätze frei von Boilerplate, der Crawl-Graph respektierte seine Tiefenbegrenzung über 11 Seiten hinweg, und eine 500 wurde als behandelter Status statt als Absturz zurückgegeben.
Man sollte die Aussagen aber richtig einordnen. Scrapy rendert kein JavaScript, und es findet die API nicht für dich — diesen Reflex musst du selbst mitbringen. Der Dependency-Stack ist der eines vollwertigen Frameworks und kann auf ungewöhnlichen Plattformen Probleme machen, auch wenn hier alles sauber lief. Und ich habe Testdaten und Demo-Seiten geprüft, keinen Crawl über tausend Seiten. Die Skalierbarkeit ist also vielversprechend, aber in diesem Durchlauf nicht bewiesen. Innerhalb dieser Grenzen ist Scrapy das Werkzeug, das eine leise radikale Idee am konsequentesten umsetzt: Der schnellste Weg durch eine Webseite führt oft gar nicht durch die Webseite selbst.
Thunderbit für Webdatenextraktion ausprobieren Get Started Free
FAQs
Kann Scrapy JavaScript-gerenderte Seiten auslesen?
Mit dem Standard-HTTP-Fetcher nicht — auf einer JS-Testseite und der öffentlichen Quotes-JS-Seite kamen jeweils 0 Knoten zurück, weil Scrapy HTML herunterlädt, ohne einen Browser auszuführen. Der vorgesehene Weg ist, die zugrunde liegende Datenanfrage zu finden und direkt anzusprechen; in meinem Test lieferte die JSON-API hinter einem JS-Katalog alle 8 Elemente. Wenn es keine reproduzierbare Anfrage gibt, musst du einen Headless-Browser selbst anbinden.
Was bedeutet „die Anfrage reproduzieren“ eigentlich?
Die meisten dynamischen Seiten laden ihre Daten im Hintergrund von einer JSON-API und rendern sie dann clientseitig. Statt einen Browser zu starten und dabei zuzusehen, öffnest du den Network-Tab, findest diesen API-Call und richtest Scrapy direkt darauf aus. Das ist schneller und stabiler als Rendering — ein API-Vertrag bricht seltener als ein DOM — aber es ist Handarbeit, und Scrapy zeigt dir den Endpunkt nicht von selbst.
Ist Scrapy schwer zu installieren?
Bei mir war es unkompliziert — pip install Scrapy==2.17.0 lief in einer frischen venv auf macOS mit binären Wheels ohne Kompilierungsfehler durch. Allerdings bringt es einen recht großen Stack mit (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), und die offiziellen Dokus warnen auf manchen Systemen weiterhin vor plattformspezifischen Abhängigkeiten. Auf ungewöhnlichen Setups solltest du also etwas Puffer einplanen.
Welche Ausgabeformate unterstützt Scrapy?
Feed-Exports unterstützen ab Werk JSON, JSON Lines, CSV und XML — du richtest den Spider auf eine Datei, und die Items werden ohne zusätzlichen Code serialisiert. In meinem Lauf erzeugte ein Spider in einem Durchgang sowohl JSON als auch CSV. Wichtig: Scrapy exportiert die Felder, die du ausgewählt hast; es bereinigt eine Seite nicht automatisch zu Markdown.
Ist Scrapy für kommerzielle Nutzung kostenlos?
Ja, BSD-3-Clause ist sehr permissiv und kommerziell freundlich. Prüfe wie immer die aktuelle Lizenz im Repository, bevor du darauf aufbaust, und achte auf verantwortungsvolle User-Agent-, Proxy- und Rate-Limit-Einstellungen — Fähigkeiten sind keine Erlaubnis.
