Jeder Leitfaden zu „Scrapy vs. Selenium“ im Internet sagt im Grunde dasselbe: Scrapy ist schneller, Selenium kann JavaScript, such dir einfach etwas aus. Die Richtung stimmt oft, aber pauschale Aussagen wie „X Seiten pro Minute“ haben in der Praxis selten Bestand. Der echte Durchsatz hängt vom Zielsystem, vom Netzwerk, von der Parallelität, vom Browser-Lebenszyklus, von Wartezeiten und von Anti-Bot-Schutzmechanismen ab.
Dieser Leitfaden vergleicht die Architekturen und betrieblichen Abwägungen, die in der Praxis wirklich zählen. Außerdem geht es um Punkte, die viele Vergleiche auslassen: wie Browser-Automatisierung das Ressourcenmodell verändert, warum selektives Rendern oft besser ist als reines Browser-Crawling und wann eine verwaltete Extraktions-API die bessere Wahl ist als eines der beiden Frameworks.
Kurzfazit: Scrapy vs. Selenium im Jahr 2026
Die Kurzversion: Scrapy gewinnt bei Geschwindigkeit, Skalierung und Ressourceneffizienz, sobald es um serverseitig gerenderte Inhalte geht. Selenium ist die richtige Wahl, wenn du einen echten Browser brauchst, der sich auch wie ein echter Browser verhält — klicken, tippen, auf die Animation eines Modals warten. Keines der beiden Tools kommt von Haus aus gut mit modernen Anti-Bot-Schutzmaßnahmen zurecht, und Playwright hat still und leise die meisten Anwendungsfälle übernommen, für die man früher Selenium genommen hat.
Hier ist die Entscheidungslogik, die ich selbst verwende:
| Deine Situation | Nimm |
|---|---|
| Statische oder serverseitig gerenderte Seiten, hohe Datenmenge | Scrapy |
| JS-lastige SPA mit Logins, Klicks, mehrstufigen Abläufen | Selenium oder Playwright |
| Gemischte Website – größtenteils statisch, einige Bereiche nur per JS | Scrapy-Playwright-Hybrid |
| Bekannte URLs, du brauchst nur strukturierte Daten und möglichst wenig Wartung | KI-Extraktions-API (Thunderbit und ähnliche) |
Stand Mitte 2026 ist Scrapy 2.17.0 verfügbar, Selenium 4 erweitert weiterhin die Unterstützung für WebDriver BiDi, und scrapy-playwright bietet einen gepflegten Weg, ausgewählte Scrapy-Anfragen über einen Browser laufen zu lassen. Behalte diese Entscheidungsmatrix im Kopf — der Rest des Artikels erklärt, warum sie funktioniert.
Was sind Scrapy und Selenium eigentlich — und warum wird darüber immer noch gestritten?
Scrapy mit Selenium zu vergleichen ist ein bisschen so, als würde man einen Lieferwagen mit einem Pkw vergleichen. Beide bringen etwas von A nach B, aber das eine wurde für effizientes Transportieren großer Mengen gebaut, während das andere für jemanden gedacht ist, der aktiv mit der Straße interagieren muss. Die Debatte hält sich, weil beide Tools zum Scrapen verwendet werden können — sie sind nur für unterschiedliche Aufgaben gemacht, und viele Teams greifen erst einmal zum falschen Werkzeug.
Scrapy: Die asynchrone Crawling-Engine
Scrapy ist ein reines Python-Framework, das auf Twisted und dessen ereignisgesteuertem, nicht blockierendem I/O-Modell basiert. Es ist kein Browser — war es nie — es sendet einfach HTTP-Anfragen und parst das HTML, das zurückkommt. Genau das ist der Punkt. Weil es nicht darauf warten muss, dass ein Browser etwas rendert, kann es Dutzende Anfragen parallel absetzen, ohne zu blockieren.
Out of the box bringt Scrapy Spiders, Item Pipelines, Feed-Exporter, Retry-Middleware und Ratenbegrenzung mit. Das ist kein Framework, bei dem du alles selbst zusammenbauen musst — viele Produktionsanforderungen sind bereits abgedeckt. Die Architekturdokumentation von Scrapy beschreibt Engine, Scheduler, Downloader und Item Pipeline als separate, austauschbare Komponenten. Genau deshalb ist das Framework so langlebig: Du kannst Funktionen ergänzen, ohne den Kern neu zu schreiben.
Der Haken: Kein Browser bedeutet keine JavaScript-Ausführung. Wenn deine Daten erst per clientseitigem Fetch geladen werden, nachdem die Seite gerendert wurde, sieht Scrapy davon nichts. Es liest nur die anfängliche HTML-Antwort, Punkt.
Selenium: Der Browser, den du programmieren kannst
Selenium steuert echte Browser — Chrome, Firefox, Edge — über das W3C-WebDriver-Protokoll. Das ist der standardisierte Ansatz, der Selenium browser- und sprachunabhängig macht statt zu einem Chrome-spezifischen Trick. Selenium rendert JavaScript, führt AJAX-Aufrufe aus und kann klicken, scrollen und tippen genau wie ein Mensch.
Damit ist Selenium die passende Wahl für alles, was Interaktion erfordert: mehrstufige Logins, Assistenten, endloses Scrollen, Dropdowns, die API-Aufrufe auslösen. Aber jede dieser Browsersitzungen ist schwergewichtig. Die eigene Grid-Sizing-Anleitung von Selenium empfiehlt für die Planung grob 1 GB RAM pro Browsersitzung — und das noch bevor du die CPU-Last durch das eigentliche Rendern berücksichtigst.
Ein Detail, das viele regelmäßig stolpern lässt: „Seite geladen“ heißt nicht, dass die UI bereit ist. In der Selenium-Dokumentation wird sogar davon abgeraten, implizite und explizite Wartezeiten zu mischen, weil Timeouts dann schnell unberechenbar werden. Wenn dein Selenium-Skript instabil ist, liegt es meistens genau daran.
Scrapy vs. Selenium: Performance ohne erfundene Universalzahlen
Ein belastbarer Benchmark muss die Zielseiten, den Cache-Zustand, die Netzwerkbedingungen, die Parallelität, die Wiederverwendung des Browsers, die Wartebedingungen und den vollständigen Code offenlegen. Ohne diesen Kontext ist eine Zahl wie „Seiten pro Minute“ eher Marketing als Beweis. Der architektonische Vergleich ist trotzdem hilfreich:
| Arbeitslast-Merkmal | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| Serverseitig gerendertes HTML | Direkter HTTP-Pfad | Voller Browser-Pfad | Direkter Pfad über Scrapy |
| JavaScript-gerenderte Inhalte | Zusätzlicher Renderer nötig | Native Browser-Ausführung | Selektives Browser-Rendering |
| Parallelitätsmodell | Asynchroner Request-Scheduler | Browser-Sitzungen durch deinen Code oder Grid verwaltet | Scrapy-Scheduler plus Browser-Kontexte |
| Ressourcenprofil | Kein Browser-Rendering-Overhead | CPU- und Speicher-Overhead des Browsers | Browserkosten nur für markierte Anfragen |
| Beste Messgröße | Elemente pro Minute bei sicherer Fehlerrate | Abgeschlossene Abläufe pro Minute bei sicherer Fehlerrate | Statistische und gerenderte Anfragen getrennt messen |
Die Standard-Einstellung für parallele Anfragen in Scrapy ist eine Obergrenze, kein garantiertes Durchsatzniveau. Die tatsächliche Geschwindigkeit wird von Latenz, Limits pro Domain, Drosselung, Wiederholungen, Antwortgröße, Parsing-Aufwand und der akzeptablen Anfragerate des Zielsystems bestimmt. Selenium kann eine Browsersitzung wiederverwenden und ist daher nicht grundsätzlich auf einen neuen Browser pro Seite beschränkt. Trotzdem rendert und betreibt jede aktive Sitzung eine Browserumgebung.
Das Hybridmodell ist attraktiv, weil es normale Anfragen über Scrapy per HTTP abwickelt und nur Seiten, die gerendert werden müssen, an den Browser schickt. Das reduziert in vielen Fällen die Browserlast, ist aber nicht automatisch schneller: Miss statische und gerenderte Pfade getrennt, berücksichtige Fehlerraten und Retries und tune die Parallelität sowohl mit Blick auf die Sicherheit des Zielsystems als auch auf den verfügbaren Speicher.
Die Kernunterschiede, die deine Entscheidung prägen
Geschwindigkeit ist nicht die einzige Variable. Sobald das Ganze in der Produktion läuft, spielen einige praktische Faktoren eine genauso große Rolle.
JavaScript-Rendering und dynamische Inhalte
Scrapy allein sieht nichts, was clientseitig gerendert wird. Selenium sieht alles, weil es ein echter Browser ist. Der Mittelweg — Scrapy-Splash (älter, mit Lua skriptbar) und scrapy-playwright (modern, empfohlen) — ermöglicht selektives JS-Rendering innerhalb des Scrapy-Crawls, statt für jede Anfrage gleich auf einen vollständigen Browser zu setzen. Wenn 80–90 % deiner Zielseiten statisches HTML sind und nur ein kleiner Teil JS braucht, ist selektives Rendering die naheliegende Architektur. Alles über den Browser laufen zu lassen, nur weil einige Seiten es brauchen, ist reine Rechenverschwendung.
Skalierbarkeit und Parallelität
Scrapy von 1.000 auf 1.000.000 Seiten zu skalieren ist vor allem eine Frage der Bereitstellung — mehr parallele Anfragen, vielleicht verteilte Worker mit Redis. Selenium zu skalieren heißt, linear mehr Browserinstanzen hinzuzufügen, was wiederum linear mehr RAM und CPU bedeutet. Am Ende verwaltest du eine Browser-Farm mit Selenium Grid und musst dich mit Abstürzen und Recovery beschäftigen. Nicht dass Selenium nicht skalieren könnte — es bedeutet nur, dass Skalierung hier ein Infrastrukturprojekt ist, keine reine Konfiguration.
Daten-Pipelines und Export
Die Item Pipeline von Scrapy übernimmt Validierung, Deduplizierung und Export nach JSON, CSV oder in eine Datenbank als integrierte Funktion. Selenium bietet dir davon nichts — Serialisierung und Speicherung musst du komplett selbst schreiben. Wenn Datenqualität und Anbindung an Folgeprozesse wichtig sind (und das sollten sie), verschafft dir Scrapy hier einen echten Vorsprung.
Wartung und langfristige Zuverlässigkeit
Mir ist ein Muster aufgefallen: Scrapy-Spiders altern meist recht ordentlich, weil die Middleware-Architektur eine gewisse Struktur erzwingt. Selenium-Skripte werden schnell fragil — Browser-Updates brechen Treiber, Timing-Probleme führen zu instabilen Läufen, und jede DOM-Änderung bedeutet neue Selektoren. Ich habe Entwickler in Foren schon ganz offen sagen sehen, ein Selenium-basierter Scraper „sei vermutlich nicht die beste Wahl für etwas, das wir an einen Kunden verkaufen wollen“. Und ehrlich gesagt: Diese Intuition stimmt, wenn das Projekt länger als ein paar Monate unverändert überleben soll.
Anti-Bot-Realitätscheck: Wie sich die Tools gegen die Schutzmechanismen von 2026 schlagen
Das ist der Teil, den viele Vergleiche einfach übergehen — und genau der entscheidet in der Praxis, ob dein Scraper überhaupt funktioniert. Weder Scrapy noch Selenium wurden mit moderner Anti-Bot-Infrastruktur im Hinterkopf gebaut. So zu tun, als wäre das anders, führt in der Produktion nur zu unangenehmen Überraschungen.
| Schutzebene | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS-Rendering | ❌ Middleware nötig | ✅ | ✅ | ✅ Integriert |
| TLS-Fingerprinting | ⚠️ Erkennbar | ⚠️ Erkennbar | ⚠️ Besser, aber nicht gelöst | ✅ Abgedeckt |
| CAPTCHA-Lösung | ❌ Manuell | ❌ Manuell | ❌ Manuell | ✅ Integriert |
| Rotation bei Ratenlimits | ⚠️ Eigene Proxys nötig | ⚠️ Eigene Proxys nötig | ⚠️ Eigene Proxys nötig | ✅ Verwaltet |
Scrapy fällt bei Browser-Fingerprint-Prüfungen sofort auf, weil es gar kein Browser-Fingerprint ist — es ist einfach ein HTTP-Client, und viele Anti-Bot-Anbieter stufen Traffic als verdächtig ein, wenn er nicht wie echter Browser-Traffic aussieht. Selenium besteht einfache JS-Checks, weil es tatsächlich ein Browser ist, ist aber über Signale wie navigator.webdriver erkennbar — ein standardisiertes Flag, das bei Automatisierung auf true steht. Patches wie undetected-chromedriver versuchen, das zu verschleiern, aber sie spielen gegen Erkennungsanbieter, die ihre Signaturen regelmäßig aktualisieren.
Das Stealth-Wettrüsten (und warum DIY fragil ist)
Die unbequeme Wahrheit über Anti-Detection-Patches: Sie sind ein Wartungslaufband, keine echte Lösung. undetected-chromedriver und playwright-stealth funktionieren, bis Cloudflare Turnstile oder DataDome ein Update ausrollt, das genau die verwendete Technik erkennt. Dann wird wieder gepatcht. Ich habe Teams beobachtet, die mehr Engineering-Zeit in den Erhalt ihrer Stealth-Schicht steckten als in den eigentlichen Scraper.
Auch Ratenbegrenzung verdient einen eigenen Hinweis. Wenn ein Server 429 Too Many Requests zurückgibt, ist der Retry-After-Header eher ein Hinweis als eine Vorschrift — viele Websites senden ihn gar nicht, und manche drosseln über ganz andere Signale. Scrapy's AutoThrottle hilft, indem es die Verzögerung anhand der beobachteten Latenz anpasst, aber das ist reaktiv, nicht präventiv.
Genau hier zahlt sich eine verwaltete Extraktions-API aus — denn dann ist das Anti-Bot-Handling das Problem eines anderen und nicht deins. Dazu später mehr.
Der Playwright-Faktor: Warum „Scrapy vs. Selenium“ nicht mehr das ganze Bild ist
Wer das Ganze nur als Zweikampf zwischen zwei Tools darstellt, übersieht, was sich in den letzten Jahren in der Scraping-Community tatsächlich verändert hat. In Entwicklerforen liest man ständig Varianten von „Ich bin von Selenium zu Playwright gewechselt und war ziemlich zufrieden damit“ — trotzdem wird Playwright in den meisten Vergleichen, wenn überhaupt, nur am Rand erwähnt.
Playwright, von Microsoft entwickelt, steuert Chromium, Firefox und WebKit über eine einzige API. Sein Actionability-Modell wartet darauf, dass Elemente sichtbar, stabil und wirklich interaktionsfähig sind, bevor eine Aktion ausgeführt wird — das reduziert viele Timing-Probleme, die Selenium-Skripte plagen. Außerdem verwaltet es Browser-Kontexte effizienter, sodass du isolierte Sitzungen aufbauen kannst, ohne jedes Mal einen komplett neuen Browser starten zu müssen.
Wann Playwright Selenium komplett ersetzt
Für Scraping — nicht für Browser-Tests mit bestehender Selenium-Infrastruktur — ist Playwright 2026 oft schlicht das bessere Werkzeug. Schnellere Kontext-Erstellung, geringerer Ressourcenverbrauch pro Seite, native Async-Unterstützung und integrierte Netzwerk-Interzeption. Wenn du ein Scraping-Projekt von Grund auf neu startest und keine vorhandene Selenium-Test-Suite bewahren musst, gibt es wenig Grund, zuerst zu Selenium zu greifen.
Die Ausnahme: Wenn dein Team bereits Selenium-Testinfrastruktur hat oder du sehr spezifische Browser-Profile anpassen musst, die Playwright nicht so sauber unterstützt, bleibt Selenium weiterhin relevant.
Wie scrapy-playwright funktioniert
scrapy-playwright ist ein Download-Handler für Scrapy, der nur Anfragen mit meta={"playwright": True} durch einen echten Browser schickt — alles andere bleibt auf Scrapys schnellem, asynchronem HTTP-Pfad. Hier ein vereinfachter Spider, der einen paginierten Katalog crawlt, in dem Produktkarten clientseitig per JS gerendert werden:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Nur die Seiten, die wirklich gerendert werden müssen, laufen über den Browser. Genau das ist der Punkt des Hybridansatzes — du bezahlst nicht für jede einzelne Anfrage den Browser-Aufpreis, sondern nur dort, wo er tatsächlich nötig ist.
Scrapy-Splash vs. Scrapy-Playwright: Welches Middleware-Setup ist sinnvoll?
Scrapy-Splash erfordert einen separaten Splash-Docker-Dienst und Lua-Skripte für Interaktionen — das funktioniert, ist aber schwergewichtiger und älter. scrapy-playwright integriert sich direkt in Scrapys asynchrone Event-Schleife, unterstützt alle drei großen Browser-Engines und verarbeitet komplexe Interaktionen, ohne dass eine zweite Skriptsprache drangeklebt werden muss. Wenn du 2026 ein neues Projekt startest, gibt es praktisch keinen Grund mehr, Splash zu wählen.
Eine produktionsreife Hybridarchitektur
Die meisten Artikel sagen nur: „Du kannst Scrapy und Selenium kombinieren“ — und lassen es dabei. Das ist noch keine Architektur. Das ist ein Vorschlag. So sieht ein echtes Produktions-Setup aus.
Der Ablauf: Ein Scrapy-Scheduler leitet Anfragen über einen URL-Router, der prüft, ob eine Seite statisch oder dynamisch ist. Statische Anfragen laufen direkt über Scrapys Standard-Downloader. Dynamische Anfragen werden markiert und an die Playwright-Middleware weitergeleitet, die einen Pool von Browser-Kontexten verwaltet. Beide Wege laufen anschließend wieder in dieselbe Item Pipeline für Validierung, Deduplizierung und Export — egal ob die Daten aus rohem HTML oder aus einem gerenderten DOM stammen, sie landen am Ende im selben JSON-, CSV- oder Datenbank-Output.
Ein paar Hinweise für den Produktiveinsatz: Containerisiere das Ganze mit Docker, damit die Playwright-Browser-Binaries überall konsistent ausgeliefert werden, begrenze parallele Playwright-Kontexte anhand des verfügbaren RAM (ich würde auf einer typischen 4-GB-Maschine nicht über 8–10 Kontexte gehen) und lasse geplante Jobs über Cron oder eine CI/CD-Pipeline laufen, statt einen Prozess einfach dauerhaft laufen zu lassen.
Dieses Setup gibt dir maximale Kontrolle. Es bedeutet aber auch, dass du dich selbst um Browser-Binary-Updates, Bugs im Kontext-Lifecycle (nicht geschlossene Seiten können einen Crawl blockieren), Proxy-Rotation und alle Anti-Bot-Patches kümmern musst, die du vielleicht nachrüsten willst. Das ist eine echte Engineering-Verpflichtung, und das sollte man offen sagen, bevor man sich darauf einlässt.
Für Teams, die strukturierte Ausgaben wollen, ohne diese Infrastruktur selbst zu betreiben, geht Thunderbits CLI das Problem etwas anders an:
thunderbit batch extract --schema schema.json --file urls.txt
Dasselbe strukturierte JSON-Format. Kein Spider-Code, kein Browser-Pool, keine Anti-Bot-Logik, die du selbst warten musst. Dafür tauschst du einen Teil der Anpassbarkeit gegen schnellere Produktionsreife ein — das ist ein legitimer Kompromiss, kein pauschales Upgrade, und hängt komplett davon ab, wie viel Kontrolle dein Projekt wirklich braucht.
Der „Framework überspringen“-Pfad: Wann eine KI-Scraping-API besser ist als beide
Irgendwann merkt ein Entwickler, dass er eigentlich gar kein Crawling-Framework braucht. Er braucht strukturierte Daten von 500 bekannten URLs, und dafür einen Spider, einen Browser-Pool und eine Anti-Bot-Schicht zu bauen, fühlt sich wie Overkill an — weil es meistens auch einer ist.
Diese Lücke will Thunderbit schließen, und gleich vorweg: Das ist kein Ersatz für Scrapy bei komplexen, rekursiven Crawls mit eigener Logik. Es ist ein anderes Werkzeug für ein anderes, enger umrissenes Problem.
Open API: POST /extract nimmt ein JSON-Schema entgegen und liefert strukturierte Daten, die genau dazu passen — kein rohes HTML, kein Markdown-Wust, den du erst selbst parsen musst. POST /distill macht das Gegenteil und gibt sauberes Markdown zurück, das sich direkt in eine RAG-Pipeline oder ein LLM einspeisen lässt. Der verwaltete Dienst unterstützt JavaScript-Rendering und Anti-Bot-Handling, sodass du diese Infrastruktur nicht selbst managen musst. Der aktuelle Leitfaden zu Distill vs. Extract nennt 1 Credit pro Distill-Seite und 20 pro Extract-Seite; prüfe vor der Budgetplanung die Live-Dokumentation, da sich Produktbedingungen ändern können.
MCP-Server: Für KI-Agenten wie Claude oder Cursor stellt Thunderbits MCP-Server Distillation, strukturierte Extraktion, Feldvorschläge und Batch-Jobs als Werkzeuge bereit. So kann ein Agent während einer Aufgabe frische Webdaten abrufen, ohne seine Umgebung zu verlassen.
CLI: Die dokumentierte Thunderbit CLI unterstützt Befehle wie thunderbit extract <url> --schema schema.json und fügt sich nahtlos in Terminal-Workflows und geplante Jobs ein. Du kannst distilliertes Markdown auch direkt in ein anderes Tool pipen, wenn du schnelle Einmalrecherchen machen willst.
Wenn du lieber ganz ohne Code arbeiten möchtest, deckt die Thunderbit Chrome Extension denselben Bereich per Klick-Oberfläche ab — besonders interessant, wenn in deinem Team auch Nicht-Entwickler Daten brauchen, ohne ein Terminal zu öffnen. Ich habe außerdem mehr zum Thema AI Web Scraping und Web Scraping ohne Programmierung geschrieben, falls du das Gesamtbild willst.
Sei ehrlich zu dir selbst, in welchem Lager du bist: Scrapy ist weiterhin die richtige Wahl für komplexe Multi-Site-Crawls mit eigener Logik und rekursivem Link-Following. Selenium oder Playwright für interaktionslastige Abläufe. Aber „Ich brauche strukturierte Daten aus diesen bekannten URLs“ ist ein engeres Problem, als eines der beiden Tools eigentlich lösen sollte — und eine API kann Spider-Code, Anti-Bot-Logik und die laufende Wartung deiner eigenen Infrastruktur tatsächlich überflüssig machen.
Scrapy vs. Selenium vs. Playwright vs. KI-API: Direktvergleich
| Funktion | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Sprachunterstützung | Nur Python | Python, Java, C#, JS, Ruby | Python | REST (jede Sprache) |
| JS-Rendering | Nein (Middleware nötig) | Ja | Ja | Ja, integriert |
| Async/Parallelität | Native, hoch | Pro Instanz begrenzt | Native über Scrapy | Verwaltet serverseitig |
| Anti-Bot-Handling | Selbst bauen | Selbst bauen | Teilweise | Integriert |
| Datenpipeline/Export | Eingebaut | Selbst bauen | Eingebaut | Strukturierte JSON-Ausgabe |
| Einrichtungsaufwand | Mittel | Niedrig zum Start, hoch bei Skalierung | Mittel bis hoch | Minimal |
| Wartungsaufwand | Niedrig bis mittel | Hoch | Mittel | Nahezu null |
| Am besten für | Hochvolumige statische Crawls | Interaktionslastige Abläufe | Gemischte statische/dynamische Seiten | Bekannte URLs, strukturierte Ausgabe |
Wenn du über diese vier Optionen hinaus weitere Scraper-Tools vergleichst, lohnt sich auch ein Blick darauf, wie sich Instant Data Scraper Alternativen und die besten KI-Web-Scraper einordnen — der Markt ist inzwischen dicht, und nicht jedes Tool löst dasselbe Problem.
Rechtliche und ethische Hinweise für Web Scraping im Jahr 2026
Ich halte es hier kurz, weil es nicht der Schwerpunkt des Artikels ist, aber es ist wichtig. Scrapy kann mit der Einstellung ROBOTSTXT_OBEY dafür sorgen, dass dein Spider die robots.txt-Regeln respektiert — gute Praxis, wobei man wissen sollte, dass das Robots Exclusion Protocol selbst ausdrücklich sagt, dass diese Regeln keine rechtliche Zugriffsberechtigung darstellen. Selenium und Playwright haben überhaupt keine eingebaute robots.txt-Konformität — das liegt vollständig bei dir. Unabhängig vom Tool solltest du vor dem Scraping und der Weiterverwendung von Daten die Nutzungsbedingungen der Website und das geltende Recht in deiner Jurisdiktion prüfen; „öffentlich sichtbar“ ist nicht automatisch überall eine rechtliche Freigabe.
Das richtige Tool für dein Scraping-Projekt 2026 auswählen
Die Entscheidung läuft im Kern auf vier Fragen hinaus: Welche Art von Inhalt ist es, wie groß ist der Umfang, wie viel Interaktion brauchst du und wie viel laufende Wartung willst du dir tatsächlich aufhalsen? Statische Seiten in echtem Umfang: Scrapy. JS-lastige Seiten mit echter Interaktion: Selenium oder Playwright. Eine Mischung aus beidem: das Hybridmodell. Bekannte URLs, strukturierte Ausgabe, möglichst wenig Pflege: Eine API wie Thunderbit spart dir wahrscheinlich mehr Zeit, als sie kostet.
„Scrapy vs. Selenium“ war nie wirklich die ganze Frage — es war nur lange die einzige verfügbare Denkschablone. Playwright hat den Mittelweg verändert, und KI-Extraktions-APIs haben eine völlig neue Option für alle geschaffen, die gemerkt haben, dass sie gerade Infrastruktur bauen statt ein Geschäftsproblem zu lösen. Es lohnt sich, die kostenlose Stufe vorab zu testen — suggest-fields ist kostenlos und Distill kostet nur einen Credit. So kannst du prüfen, ob der API-Ansatz passt, bevor du auch nur eine Zeile Spider-Code schreibst.
FAQs
Ist Scrapy schneller als Selenium beim Web Scraping? Nach meiner Erfahrung: Ja — auf statischen Seiten oft um Größenordnungen, weil Scrapy dank asynchroner Architektur den Browser-Overhead komplett umgeht. Der Abstand wird kleiner, wenn Scrapy für JS-lastige Seiten über Playwright-Middleware läuft, aber bei gemischten Workloads liegt Scrapy insgesamt meist trotzdem vorn, weil nicht-JS-Seiten im schnellen Pfad bleiben.
Kann Scrapy JavaScript-gerenderte Seiten verarbeiten?
Nicht allein — Scrapy sieht nur die anfängliche HTML-Antwort. Mit scrapy-playwright oder dem älteren Scrapy-Splash als Middleware kannst du gezielt einzelne Anfragen über einen echten Browser rendern lassen, während der Rest des Crawls auf Scrapys nativer, schnellerer Strecke bleibt.
Wann sollte ich Selenium statt Scrapy verwenden? Wenn du vollständige Browser-Interaktion brauchst — mehrstufige Logins, durch Assistenten klicken, Formulare ausfüllen — und die Seitenanzahl eher moderat als riesig ist. Es ist auch die vernünftige Wahl, wenn du bereits eine Selenium-basierte Testinfrastruktur hast, die du fürs Scraping wiederverwenden willst.
Ist Playwright 2026 besser als Selenium für Scraping? Für Scraping im engeren Sinn meistens ja — Playwright bietet oft bessere Performance, eingebautes Auto-Wait und einen geringeren Ressourcenbedarf pro Browser-Kontext. Selenium hat weiterhin Vorteile für Teams, die etablierte plattformübergreifende Test-Suites betreiben, die Playwright nicht ersetzen sollte.
Was ist eine KI-Scraping-API und wann ersetzt sie Scrapy oder Selenium? Eine KI-Scraping-API wie Thunderbits Open API übernimmt JavaScript-Rendering, Anti-Bot-Abwehr und Datenerfassung serverseitig und liefert strukturierte JSON-Daten zurück, die einem von dir definierten Schema entsprechen. Sie ist die richtige Wahl, wenn du bekannte URLs hast und strukturierte Ausgabe brauchst, ohne eigene Crawl-Infrastruktur aufzubauen oder zu warten — sie ersetzt Scrapy aber nicht bei komplexen, rekursiven Crawls mit eigener Logik.
Mehr erfahren
