Laut dem 2025 State of Open Source Report haben 96 % der Unternehmen im vergangenen Jahr ihren Open-Source-Einsatz erhöht oder zumindest beibehalten — und „keine Lizenzkosten“ ist weiterhin der häufigste Grund dafür. Doch es gibt etwas, das Ihnen niemand sagt, wenn Sie sich bei GitHub einen Scraper schnappen: „Open Source“ und „sicher für den Einsatz in einem kommerziellen Produkt“ sind nicht dasselbe.
Ich habe in diesem Jahr einen guten Teil meiner Zeit damit verbracht, die üblichen Verdächtigen zu durchforsten — Scrapy, Playwright, Puppeteer sowie neuere, KI-native Crawler wie Crawl4AI und ScrapeGraphAI — und das Kriterium, das für eine Geschäftsentscheidung wirklich zählt, taucht in typischen „beste Scraper“-Listen fast nie auf: der Lizenztyp. Die meisten Ranglisten sortieren nach GitHub-Stars. Ich sortiere danach, was passiert, wenn Ihr Legal-Team fragt: „Moment mal, ist das AGPL?“ Diese Liste ordnet 12 Tools zuerst nach Passung zur Kategorie ein (Parser, Browser-Automatisierung, KI-native Scraper, Crawl-Frameworks, No-Code-Erweiterungen) und erst danach nach Lizenz, weil Entscheidungen in der Praxis genau in dieser Reihenfolge fallen.
Warum der Lizenztyp der erste Filter für jeden Open-Source-Web-Scraper ist
„Open Source“ bedeutet nicht automatisch „Sie dürfen damit machen, was Sie wollen“. Die Open Source Definition verbietet ausdrücklich, die kommerzielle Nutzung auszuschließen — deshalb erlaubt jedes Tool auf dieser Liste auch geschäftliche Nutzung. Aber wie Sie es nutzen dürfen und welche Pflichten beim Ausliefern entstehen, hängt vollständig von der jeweiligen Lizenz ab.
Permissive Lizenzen — MIT, BSD-3-Clause, Apache-2.0 — erlauben fast alles, solange der Urheberrechtsvermerk erhalten bleibt. Apache-2.0 geht noch einen Schritt weiter und enthält eine ausdrückliche Patentlizenz, was Juristen meist am liebsten sehen. Keine dieser drei Lizenzen verpflichtet Sie, Ihren eigenen Quellcode offenzulegen.
Copyleft-Lizenzen sind eine andere Sache. AGPL-3.0 ist die Lizenz, bei der viele stolpern — und genau unter ihr steht auch Firecrawls selbst gehosteter Kern (die SDKs sind MIT, aber die eigentliche Scraping-Engine ist AGPL). Nach Abschnitt 13 der AGPL-3.0 müssen Sie, wenn Sie das betroffene Programm verändern und Nutzern diese modifizierte Version über ein Netzwerk zugänglich machen, den entsprechenden Quellcode anbieten. Das ist nicht automatisch der Auslöser dafür, dass „die ganze SaaS open source wird“, wie es in Foren manchmal vereinfacht dargestellt wird — die Pflicht bezieht sich konkret auf ein verändertes betroffenenes Programm, das für den Fernzugriff bereitgestellt wird. Trotzdem ist das eine echte Rechtsfrage, die vor dem Aufbau eines Closed-Source-Produkts darauf juristisch geklärt werden sollte, statt sie in einem Stack-Overflow-Thread zu verhandeln.
Dann gibt es noch die etwas nebulöse Kategorie „Open Core“. Web Scraper, die Chrome-Erweiterung, hat auf GitHub historisch ein LGPL-3.0-Repository — allerdings stammt der letzte Code-Commit dort aus dem Jahr 2017, und es gibt keine verifizierbare Zuordnung zwischen diesem alten Quellcode und der Erweiterung, die aktuell im Chrome Web Store liegt (Version 1.111.13 zum Zeitpunkt dieses Artikels). Die ehrliche Einordnung: Die lokale Erweiterung ist kostenlos, die Cloud-Stufe mit Zeitplanung und Proxy-Rotation ist ein separates proprietäres Produkt, und wenn man das gesamte Angebot als „Open Source“ bezeichnet, verwischt man genau diese Trennung.
So haben wir diese 12 besten Open-Source-Web-Scraper-Tools verglichen
Ich habe jedes Tool anhand von sieben Kriterien bewertet: Lizenztyp und Hürden für die kommerzielle Nutzung, Sprache/Runtime, native Unterstützung für JavaScript-Rendering (im Vergleich zu einer Plugin-Kombination), Lernkurve, versteckte Kosten für Rechenleistung oder Proxies, Signale für die Community-Gesundheit (offene Issues, Release-Takt, letzter Commit) und den besten Anwendungsfall.
Die Liste ist nach Kategorien gegliedert — statische Parser, Browser-Automatisierungs-Frameworks, KI-native Scraper, Crawl-Frameworks und schließlich die eine No-Code-Browser-Erweiterung — statt rein nach Star-Zahl sortiert. Das ist Absicht. Beautiful Soup und Scrapy lösen völlig unterschiedliche Probleme, auch wenn beide extrem beliebt sind; sie auf derselben Skala zu ranken hilft bei der Tool-Auswahl nicht wirklich weiter.
| Kriterium | Was ich geprüft habe |
|---|---|
| Lizenz und Eignung für kommerzielle Nutzung | Exakte Repo-Lizenz, Anforderungen an Attribution, Copyleft-/Netzwerk-Klauseln |
| Runtime und Team-Fit | Python, Node/TypeScript, Java oder mehrere Sprachen |
| JS-Rendering | Nativ im Browser, per Plugin-Kopplung oder gar nicht |
| Framework-Umfang | Nur Parser, Browser-Treiber, vollständige Crawl-Pipeline oder Managed Product |
| Community-Gesundheit | GitHub-Stars, Datum der letzten Release, offene Issues, letzter Push |
| Versteckte Kosten | Browser-Speicherverbrauch, Proxy-Bedarf, Abhängigkeit von Modell-APIs, Wartungsaufwand |
| Bester Fit | Konkrete Übereinstimmung mit Team und Aufgabe, gestützt durch dokumentierte Fähigkeiten oder Issues |
Ein ehrlicher Hinweis zu den Zahlen zur Community-Gesundheit: Die maßgebliche Entwicklung von Beautiful Soup findet auf Launchpad statt, nicht auf GitHub. Deshalb ist seine GitHub-Starzahl (ein inoffizieller Mirror mit 223 Stars, zuletzt 2022 aktualisiert) nicht direkt mit den anderen 10 Tools vergleichbar. Das weise ich unten ausdrücklich aus, statt so zu tun, als passe es nahtlos in dieselbe Tabelle.
Die beste Open-Source-Parsing-Library für statische Websites: BeautifulSoup
BeautifulSoup ist eine Python-Bibliothek zum Navigieren und Durchsuchen von HTML-/XML-Parsebäumen. Sie lädt keine Seiten, führt kein JavaScript aus und verwaltet keine Crawl-Queues — sie nimmt einfach Markup, das Sie bereits haben, und lässt Sie es mit einer benutzerfreundlichen API durchsuchen. Genau diese enge Ausrichtung ist der Sinn der Sache: Das ist das Tool für den Moment, in dem Sie das HTML schon besitzen und nur noch Daten daraus ziehen müssen.
- Lizenz: MIT — permissiv, keine Pflichten außer dem Beibehalten des Hinweises
- Lernkurve: wirklich anfängerfreundlich; das Objektmodell ist fehlertolerant
- JS-Rendering: nativ keines — kombinieren Sie es mit etwas, das zunächst gerendertes HTML abruft
- Bekannte Einschränkung: Die offizielle Dokumentation räumt ein, dass es „nie so schnell sein wird wie die Parser darunter“, und unterschiedliche Parser-Backends (lxml vs. html5lib vs. html.parser) können bei fehlerhaftem HTML spürbar unterschiedliche Bäume erzeugen
Am besten geeignet für: schnelle interne Skripte und einmalige Extraktionen aus statischem oder bereits abgerufenem HTML — nicht für Skalierung und nicht für stark JavaScript-lastige Websites.
Das beste Open-Source-Browser-Automatisierungs-Framework für Legacy-Cross-Browser-Tests: Selenium
Selenium ist der älteste Name auf dieser Liste. Ursprünglich wurde es für Browser-Tests entwickelt und wird seitdem von einem großen Teil der Scraping-Welt zweckentfremdet. Sein Markenzeichen ist nicht Geschwindigkeit, sondern Reichweite. Die offiziellen Selenium-4-Bindings gibt es für Java, Python, C#, Ruby und JavaScript, und es steuert Chrome, Edge, Firefox und Safari über den W3C-WebDriver-Standard.
- Lizenz: Apache-2.0
- GitHub-Gesundheit: 34.366 Stars, 98 offene Issues, 12 stabile Releases im letzten Jahr (aktuell: 4.47.0)
- JS-Rendering: nativ, über den echten Browser
- Dokumentierte Reibungspunkte: Die eigene Dokumentation bezeichnet Synchronisierung als „eine der häufigsten Herausforderungen“ — die Dokumentenbereitschaft bedeutet nicht automatisch, dass per JS hinzugefügte Elemente auch schon verfügbar sind, und ein dynamisches DOM-Refresh löst
StaleElementReferenceExceptionaus
Am besten geeignet für: Teams, die Multi-Browser- oder Multi-Language-Abdeckung brauchen oder Selenium ohnehin für QA nutzen und die vorhandenen Skills auch fürs Scraping wiederverwenden wollen.
Das beste Open-Source-Browser-Automatisierungs-Framework für moderne, stark JavaScript-lastige Websites: Playwright
Playwright, von Microsoft gepflegt, ist die moderne Antwort auf „Selenium wirkt langsam und umständlich“. Es automatisiert Chromium, Firefox und WebKit nativ und prüft mit Actionability-Checks automatisch, ob Elemente wirklich bereit sind — sichtbar, stabil und aktiviert — bevor es mit ihnen interagiert. Allein dieses Auto-Wait-Verhalten erspart viele der manuellen WebDriverWait-Boilerplate, die Selenium-Nutzer sonst von Hand schreiben.
Die Nuance, die in jedem Forum-Thread „Scrapy vs. Playwright vs. Selenium“ untergeht: Scrapy rendert JavaScript von sich aus überhaupt nicht. Dafür braucht es ein separates Plugin — scrapy-playwright —, das für Browser-Rendering nachgerüstet wird. Playwright und Puppeteer rendern nativ, weil Rendering das Produkt ist.
- Lizenz: Apache-2.0
- GitHub-Gesundheit: 94.443 Stars, 15 stabile Releases im letzten Jahr (aktuell: 1.62.1)
- Versteckte Kosten: Schon die Browser-Binaries selbst liegen bei ungefähr 281 MB für Chromium, 187 MB für Firefox und 180 MB für WebKit — und mit dem Breaking Change in Version 1.38 wurden automatische Browser-Downloads gestoppt, daher ist ein festes Version-Pinning im Docker-Image wichtig
Am besten geeignet für: Teams, die React-/Vue-Single-Page-Apps scrapen und zuverlässiges Cross-Browser-Verhalten brauchen, ohne eigene Wait-Logik zu bauen.
Das beste Open-Source-Browser-Automatisierungstool für Chrome-zentrierte Projekte: Puppeteer
Puppeteer, Googles eigene Automatisierungsbibliothek, ist von Grund auf für Chrome ausgelegt — mit tiefer Integration in das Chrome DevTools Protocol, eingebauter Screenshot- und PDF-Erzeugung und mehr. Eine veraltete Annahme sollte man hier korrigieren: Aktuelles Puppeteer unterstützt offiziell auch Firefox Stable, daher ist „nur Chrome“ nicht mehr ganz korrekt, auch wenn Chrome weiterhin der Hauptanwendungsfall bleibt.
- Lizenz: Apache-2.0
- GitHub-Gesundheit: 95.458 Stars, 249 offene Issues — deutlich mehr offene Issues als bei Playwright, was man bei der Bewertung von Reaktionsgeschwindigkeit berücksichtigen sollte
- Anti-Bot-Realität: Puppeteer Issue #7006 dokumentiert, dass eine völlig normale Navigation von einer Cloudflare-Challenge getroffen wurde — das Rendern einer Seite macht Sie also nicht unsichtbar für Anti-Bot-Systeme, Punkt.
Am besten geeignet für: Node.js-Teams, die sich auf Chrome standardisiert haben, besonders wenn Scraping mit PDF- oder Screenshot-Erzeugung kombiniert werden soll.
Der beste KI-native Open-Source-Scraper für LLM- und RAG-Pipelines: Crawl4AI
Crawl4AI läuft intern auf Playwright und ist darauf ausgelegt, sauberes Markdown für LLM- und RAG-Pipelines auszugeben, statt rohes HTML-Chaos zu liefern. Es unterstützt sowohl einen „clean Markdown“-Modus als auch einen „Fit Markdown“-Modus, der auf Kontextfenster optimiert ist, plus optionales LLM-Extrahieren, falls Sie das möchten — CSS/XPath und BM25-Filterung funktionieren auch ganz ohne Modell-API.
Ein Punkt, den man präzise nennen sollte: GitHub kennzeichnet das Repo als Apache-2.0, aber die tatsächliche Lizenzdatei ergänzt für öffentliche Nutzung und Distribution eine verpflichtende Attribution. Das ist nicht das Standard-Apache-2.0, sondern Apache-2.0 plus eine projektspezifische Bedingung — lesen sollte man deshalb die tatsächliche Lizenzdatei und nicht nur das Badge in der GitHub-Seitenleiste.
- GitHub-Gesundheit: 77.959 Stars, neueste Release v0.9.2 (Juli 2026)
- Ressourcenbedarf: Die Self-Hosting-Anleitung empfiehlt mindestens 4 GB RAM, die dem Container zur Verfügung stehen
- Dokumentierte Instabilität: Im Changelog zu v0.9.0 wurden Breaking Changes an den Standardwerten für die Docker-Server-Authentifizierung und verschobene Module vermerkt — das ist ein sich schnell entwickelndes Ziel, Versionen also pinnen
Am besten geeignet für: Python-Teams, die frische Webdaten in LLM-Agenten oder RAG-Pipelines einspeisen und die Browser-Infrastruktur selbst betreiben können.
Der beste KI-native Open-Source-Scraper für Self-Hosted-Deployments (mit Lizenz-Haken): Firecrawl
Der selbst gehostete Kern von Firecrawl macht die AGPL-Diskussion sehr konkret. Es ist ein API-first-Crawler, der Markdown, HTML, Screenshots und strukturierte Daten zurückgibt — also wirklich leistungsfähig, aufgebaut auf Fetch und Playwright. Aber der Feinschliff, den viele mit „Firecrawl“ verbinden — das verwaltete Anti-Bot-Handling, die Proxy-Rotation, die Fire-engine-Stealth-Schicht — gehört zu Firecrawl Cloud und nicht zum selbst gehosteten Repo. In der eigenen Self-Hosting-Dokumentation von Firecrawl steht ausdrücklich, dass Fire-engine und fortgeschrittenes Anti-Bot-Verhalten im Standard-Self-Hosted-Stack nicht enthalten sind und Screenshots/Seitenaktionen diese Komponente voraussetzen.
- Lizenz: im Kern AGPL-3.0-or-later, SDKs unter MIT
- GitHub-Gesundheit: 166.527 Stars — für diese Kategorie wirklich enorm
- Setup-Realität: Self-Hosting bedeutet das Bereitstellen von Redis, RabbitMQ, PostgreSQL und optional FoundationDB — das ist ein Multi-Service-Betrieb, kein einzelner Container
Am besten geeignet für: interne Tools oder Open-Source-Projekte, die mit der Source-Offer-Pflicht von AGPL leben können. Überlegen Sie gut, bevor Sie ohne juristische Prüfung ein Closed-Source-Kommerzprodukt direkt auf dem selbst gehosteten Kern aufbauen.
Der beste KI-native Open-Source-Scraper für sprachbasierte Extraktion: ScrapeGraphAI
ScrapeGraphAI lässt Sie in natürlicher Sprache beschreiben, was Sie wollen, statt Selektoren zu schreiben — es handelt sich um eine graphbasierte Pipeline, in der LLM-Aufrufe die Feldzuordnung übernehmen. Die MIT-lizenzierte Bibliothek nutzt Ihre eigene Infrastruktur: Ihren LLM-API-Schlüssel (oder alternativ ein lokales Ollama-Modell, wenn Sie lieber ohne Token-Kosten auskommen wollen) und Ihre konfigurierte Playwright-Instanz.
Der Haken, den man klar benennen sollte: „Open Source“ heißt hier nicht automatisch „keine laufenden Kosten“. Jede Extraktion verbraucht Tokens bei dem Modell, das Sie angebunden haben. Und promptgesteuerte Extraktion hat einen speziellen Fehlermodus, den selector-basierte Tools nicht haben: Ein offenes Issue berichtet, dass die Pipeline alle Schritte erfolgreich durchläuft, aber für Daten, die sichtbar auf der Seite vorhanden waren, leere bzw. NA-Felder zurückgibt — ein stilles Scheitern, das deterministische CSS-/XPath-Extraktion so nicht erzeugt.
- Lizenz: MIT
- GitHub-Gesundheit: 29.447 Stars, aktuelle stabile Version v2.1.6
Am besten geeignet für: unregelmäßige, einmalige Extraktionsaufgaben, bei denen die Flexibilität von Prompts den Modellpreis und den Validierungsaufwand rechtfertigt.
Der beste leichte Open-Source-Scraper ohne Modellabhängigkeit: AutoScraper
AutoScraper verzichtet komplett auf LLMs. Sie geben eine URL und einen Beispielwert an, den Sie extrahieren möchten; das Tool leitet daraus Strukturregeln von der Seite ab und wendet sie auf ähnliche Seiten an. Kein Modell-API-Key, keine Token-Rechnung — intern läuft einfach requests plus BeautifulSoup.
Vorsicht bei dem Label „eingestellt“, das manche Foren-Threads diesem Tool anhängen. Das stimmt nicht: Mitte 2025 gab es tatsächlich neue Commits, und der letzte Push im Repo war im Juli 2026. Die veröffentlichte Version, die Leser tatsächlich mit pip install einspielen würden, ist allerdings weiterhin v1.1.14 aus dem Jahr 2022. „Langsame Release-Frequenz“ ist die faire Beschreibung — „totes Projekt“ nicht.
- Lizenz: MIT
- GitHub-Gesundheit: 7.844 Stars
- Klare Grenze: kein natives JS-Rendering — es ruft
requests.get()auf und parst schlicht das zurückgegebene HTML, mehr nicht
Am besten geeignet für: kleine, wiederkehrende Extraktionsaufgaben auf strukturell stabilen statischen Seiten, bei denen gelegentliches Nachtrainieren nach einem Redesign okay ist.
Das beste Open-Source-Crawl-Framework für große Python-Projekte: Scrapy
Scrapy ist das produktionsreife Python-Crawl-Framework — Engine, Scheduler, Downloader, Item-Pipelines, alles dabei. Wenn Beautiful Soup ein Skalpell ist, dann ist Scrapy der komplette OP-Saal: asynchrones Networking, domainbezogene Parallelitätssteuerung, AutoThrottle und Exporter, die direkt nach CSV, JSON, JSON Lines, XML oder in den Cloud-Speicher schreiben.
Die bereits erwähnte Nuance ist hier wichtig genug, um sie zu wiederholen, denn sie ist die größte Quelle für Verwirrung bei Scrapy: Scrapy hat kein natives JavaScript-Rendering. Die eigene Dokumentation von Scrapy empfiehlt, zuerst den zugrunde liegenden Daten-Request zu finden und nachzubilden — weil das meist schneller und vollständiger ist als ein ganzer Browser-Render — und scrapy-playwright nur für Fälle zu verwenden, in denen ein Browser wirklich unvermeidbar ist.
- Lizenz: BSD-3-Clause
- GitHub-Gesundheit: 63.830 Stars, 304 offene Issues, 9 stabile Releases im letzten Jahr (aktuell: 2.17.0)
- Rate-Limit-Lücke: Eine offene Verbesserungsidee weist darauf hin, dass AutoThrottle auf Basis der Latenz und nicht anhand von HTTP-429-Antworten regelt — backoff, der auf Response-Signale reagiert, müssen Sie selbst bauen
Am besten geeignet für: großskaliges Crawlen statischer Websites, bei dem strukturierte Pipelines und flexible Exporte wichtiger sind als JavaScript-Rendering.
Das beste Open-Source-Crawl-Framework für Node.js-Produktionssysteme: Crawlee
Crawlee vom Apify-Team ist das nächstliegende Node-/TypeScript-Pendant zu Scrapy — nur dass JavaScript-Rendering hier nicht nachträglich angeflanscht wird, sondern von Anfang an eingebaut ist: über Crawler-Klassen auf Basis von Playwright und Puppeteer, die unter einer gemeinsamen Queue-, Storage- und Proxy-Rotation-Schicht laufen.
- Lizenz: Apache-2.0
- GitHub-Gesundheit: 25.364 Stars, 8 stabile Releases im letzten Jahr (aktuell: 3.18.1)
- Smarter Detailpunkt: Das
AutoscaledPoolpasst die Parallelität dynamisch an, basierend auf CPU-, Speicher- und Event-Loop-Last in Echtzeit — und die Dokumentation warnt ausdrücklich davor, die Mindestparallelität zu hoch einzustellen, weil sonst der gesamte Crawl abstürzen kann
Am besten geeignet für: Node.js-/TypeScript-Teams, die produktionsreifes Queue-Management und JavaScript-Rendering wollen, ohne Scrapy-ähnliche Bausteine selbst zusammenstecken zu müssen.
Das beste Open-Source-Crawl-Framework für Enterprise-Java-Indexierung: Apache Nutch
Apache Nutch ist der Ausreißer auf dieser Liste — ein Java-Crawler für großskalige Web-Indexierung, der typischerweise in Solr, Elasticsearch oder OpenSearch einspeist. Das ist nicht das Tool, mit dem Sie Produktpreise von der Konkurrenzseite ziehen; es ist das Tool, nach dem Enterprise-Suchteams greifen, wenn sie die Crawl-Schicht unter einem Suchindex aufbauen.
- Lizenz: Apache-2.0
- GitHub-Gesundheit: nur 3.276 Stars, aber zuletzt im August 2026 gepusht — die niedrige Star-Zahl spiegelt eine spezialisierte Nische wider, nicht Vernachlässigung
- JS-Verarbeitung: erfordert das separate
protocol-selenium-Plugin; ein JIRA-Ticket dokumentiert einen HTTPS-Proxy-Fehler genau in diesem Plugin-Pfad
Am besten geeignet für: Teams, die bereits Java-/Hadoop-Infrastruktur betreiben und Enterprise-Web-Indexierung benötigen, nicht punktuelle Datenerfassung.
Die beste No-Code-Open-Source-Browser-Erweiterung: Web Scraper
Web Scraper ist die Point-and-Click-Option — ein Sitemap- und Selektorbaum-Builder direkt in Chrome DevTools. Die Erweiterung folgt Paginierung, klickt Buttons, scrollt unendlich ladende Seiten und exportiert lokal nach CSV/XLSX — ganz ohne eine einzige Codezeile.
Die Open-Core-Trennung ist hier wichtiger als fast überall sonst auf dieser Liste. Die lokale Extraktion ist tatsächlich kostenlos. Aber geplante Automatisierung, Cloud-Ausführung, API-Zugriff und Proxy-Verwaltung liegen hinter Web Scraper Cloud, einem separaten kostenpflichtigen Produkt. Und wie oben erwähnt wurde das öffentlich zugängliche LGPL-3.0-Quellcode-Repository seit 2017 nicht mehr mit Code-Commits aktualisiert — behandeln Sie „Open Source“ daher als Beschreibung der historischen Herkunft der lokalen Erweiterung, nicht als Garantie dafür, was heute im Chrome Web Store Build läuft.
Am besten geeignet für: Einzelpersonen oder kleine Teams mit gelegentlicher lokaler Extraktion, die nicht programmieren wollen und keine Skalierung brauchen.
Statische Parser vs. Headless Browser: Das richtige Tool für JavaScript-lastige Websites wählen
Ein wichtiger Statwert als Kontext: 98,9 % der Websites verwenden JavaScript als clientseitige Sprache. Diese Zahl wird aber ständig falsch wiedergegeben als „98,9 % der Seiten brauchen zum Scrapen einen Headless Browser“ — und genau das sagt sie nicht. Sie misst die Präsenz von JavaScript, nicht ob Ihre konkrete Zielinformation schon im initialen HTML steckt oder erst nach Skriptausführung erscheint.
Genau das ist der eigentliche Entscheidungspunkt. Teilt man die 12 Tools ehrlich in zwei Gruppen ein:
Statische Parser — BeautifulSoup, AutoScraper — sind schnell, günstig und vollständig blind für alles, was clientseitig gerendert wird. Wenn die gewünschten Daten bereits im initialen HTML-Response liegen oder über einen direkt aufrufbaren JSON-Endpunkt verfügbar sind, gewinnen diese Tools bei Tempo und Einfachheit immer.
Headless-Browser-Frameworks — Playwright, Puppeteer, Selenium, Crawlee mit Browser-Crawlern — führen JavaScript tatsächlich aus, was bedeutet, dass sie reale Rechenleistung kosten. Die Daten des HTTP Archive für 2024 beziffern die mediane JavaScript-Nutzlast einer Seite auf dem Mobilgerät auf 558 KB bei 22 separaten JS-Requests — genau diese Arbeitslast muss ein Headless Browser auf jeder einzelnen Seite verarbeiten, während ein statischer Parser einfach nur das rohe HTML abholt.
Und Scrapy liegt in einer merkwürdigen Zwischenposition, die man noch einmal betonen sollte: Es ist weder noch. Es ist ein vollständiges Crawl-Framework ohne natives Rendering und braucht scrapy-playwright als Zusatz, wenn überhaupt JavaScript ins Spiel kommt.
Die versteckten Kosten von „kostenlos“: Proxies, Rechenleistung und Wartungsaufwand
Eine Lizenz ohne Gebühren ist nur ein Baustein der Gesamtkosten, nicht das ganze Bild. Ich würde das reale Kostenmodell in einige konkrete Blöcke aufteilen:
Rechenleistung. Headless Browser in großem Maßstab zu betreiben bedeutet, für Browser-Sekunden zu zahlen, nicht nur für Serverzeit. AWS Fargate berechnet für Linux/x86 ungefähr 0,000011244 $ pro vCPU-Sekunde und 0,000001235 $ pro GB-Sekunde — multiplizieren Sie das mit der Anzahl Ihrer parallelen Playwright-Instanzen, und es summiert sich schneller, als viele erwarten.
Proxies. Die veröffentlichten Preise von Bright Data zeigten Residential Proxies ab etwa 5 $/GB und Datacenter-Proxies ab 0,9 $/IP — und „Bandbreite“ umfasst in solchen Modellen sowohl Anfragen als auch Antworten, nicht nur den Download. Genau diese Position überrascht Teams oft: Rate Limits und Blockaden zu umgehen ist nicht kostenlos, sondern ein wiederkehrender Posten im Infrastruktur-Budget.
Wartung. Jeder statische Parser und jedes Tool für Strukturregeln auf dieser Liste ist anfällig dafür, dass Website-Redesigns die Selektoren kaputtmachen. Im README-Beispiel von AutoScraper musste sogar ein Preis aktualisiert werden, nachdem sich die Zielseite geändert hatte. Das ist genau die Kategorie „versteckte Kosten für Rechenleistung/Proxies“, die ein Lizenzpreis von 0 $ nie erwähnt — nämlich die Engineering-Stunden, die in das Reparieren defekter Extraktionen fließen, nachdem das Dev-Team der Zielseite ein Redesign ausgeliefert hat.
Für Teams, die immer wieder an dieselbe Wand laufen — dauernd kaputte Selektoren, Proxy-Kontoverwaltung, nie endender DevOps-Overhead — ist ein selbst gehosteter Open-Source-Stack nicht automatisch die günstigere Option, sobald man die Arbeitszeit der Engineers mitrechnet. Thunderbits Chrome-Erweiterung geht für Nicht-Entwickler anders vor: Sie auf eine autorisierte Seite richten, auf One Click Extract klicken, und die Seite wird analysiert, um herauszufinden, was extrahiert werden soll — keine Selektoren, kein Wartungsskript, wenn sich das Layout verschiebt. Das ist kein Ersatz für Scrapy im Maßstab eines Crawl-Frameworks, aber ein vernünftiger nächster Schritt für Business-Anwender, die bislang ein fragiles AutoScraper-Regelwerk von Hand pflegen mussten.
Ein Entscheidungsrahmen: Das richtige Tool an die Rahmenbedingungen Ihres Teams anpassen
Die meisten Vergleiche enden bei „am besten für Anwendungsfall X“. Das ist nur eine Variable. In der Praxis jonglieren Teams mindestens vier gleichzeitig: Bedarf an JS-Rendering × Teamsprache × benötigtes Ausgabeformat × Lizenzvorgabe.
| Teamsituation | Passende(s) Tool(s) | Warum |
|---|---|---|
| Python, statisches HTML, schnelles Skript | BeautifulSoup, AutoScraper | Kein JS nötig, MIT-Lizenz, minimale Einrichtung |
| Python, großer strukturierter Crawl | Scrapy | BSD-3-Clause, eingebaute Pipelines, scrapy-playwright nur dann ergänzen, wenn JS wirklich nötig ist |
| Node/TypeScript, Produktion-Crawl mit JS | Crawlee | Apache-2.0, native Browser-Unterstützung direkt im Queue-System eingebaut |
| Mehrere Sprachen, breite Browser-Matrix | Selenium | Apache-2.0, breiteste Abdeckung bei Sprache und Browser |
| Moderne SPA-Automatisierung, Cross-Browser | Playwright | Apache-2.0, natives Rendering, Auto-Wait integriert |
| Chrome-spezifische Automatisierung mit Screenshots/PDF | Puppeteer | Apache-2.0, tiefe CDP-Integration |
| LLM-/RAG-Markdown-Pipeline | Crawl4AI | Apache-2.0 + Attributionsklausel; prüfen, ob Ihr Legal-Team mit der Zusatzbedingung leben kann |
| Promptgesteuerte, unregelmäßige Extraktion | ScrapeGraphAI | MIT, aber Modellkosten für Tokens einplanen |
| API-ähnlicher Self-Hosted-Crawler, AGPL-tolerant | Firecrawl | AGPL-3.0-or-later; juristische Freigabe einholen, bevor Sie darauf Closed-Source-SaaS aufbauen |
| Enterprise-Java-/Hadoop-Indexierung | Apache Nutch | Apache-2.0, speziell für Suchinfrastruktur gebaut |
| No-Code, gelegentliche Nutzung durch Nicht-Entwickler | Web Scraper Extension | Lokal kostenlos; die Open-Core-Trennung verstehen, bevor man von voller Transparenz ausgeht |
Alle 12 Open-Source-Web-Scraper im direkten Vergleich
| Tool | Sprache | Lizenz | Für kommerzielle Nutzung geeignet? | JS-Rendering | Lernkurve | Am besten für |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ Ja | Keines (braucht Kombi) | Niedrig | Statische HTML-Analyse |
| Selenium | Mehrsprachig | Apache-2.0 | ✅ Ja | Nativ | Mittel | Multi-Browser-/Multi-Language-Tests bis hin zum Scraping |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ Ja | Nativ | Mittel | Moderne, stark JavaScript-lastige Websites |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ Ja | Nativ | Mittel | Chrome-fokussierte Automatisierung |
| Crawl4AI | Python | Apache-2.0 + Attributionsklausel | ⚠️ Klausel prüfen | Nativ (via Playwright) | Mittel | LLM-/RAG-Markdown-Pipelines |
| Firecrawl (selbst gehostet) | TypeScript | AGPL-3.0-or-later (Kern) | ⚠️ Bedingt | Nativ (via Playwright) | Hoch (Multi-Service) | Selbst gehostetes KI-Crawling, AGPL-tolerant |
| ScrapeGraphAI | Python | MIT | ✅ Ja | Nativ (via Playwright) | Mittel | Sprachbasierte Extraktion |
| AutoScraper | Python | MIT | ✅ Ja | Keines | Niedrig | Leichte, wiederkehrende statische Aufgaben |
| Scrapy | Python | BSD-3-Clause | ✅ Ja | Braucht Ergänzung | Hoch | Großskalige Crawls statischer Websites |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ Ja | Nativ | Mittel | Produktions-Crawler für Node.js |
| Apache Nutch | Java | Apache-2.0 | ✅ Ja | Braucht Plugin | Hoch | Enterprise-Suchindexierung |
| Web Scraper (Erweiterung) | N/A (No-Code) | Open Core | ⚠️ Abhängig vom Plan | Nativ (Live-Browser) | Niedrig | Gelegentliche Nutzung durch Nicht-Entwickler |
Fazit: Welchen Open-Source-Web-Scraper sollten Sie verwenden?
Es gibt hier nicht das eine „beste“ Tool — die richtige Wahl hängt von Ihren Lizenzanforderungen, der Sprache Ihres Teams und davon ab, ob Ihre Zieldaten in statischem HTML oder hinter einer JavaScript-Hürde liegen. Scrapy gewinnt bei großen statischen Python-Crawls. Playwright oder Crawlee gewinnen, wenn JavaScript-Rendering unverzichtbar ist. Crawl4AI passt, wenn Sie eine LLM-Pipeline speisen, mit dem Vorbehalt, dass die Lizenzdatei eine zusätzliche Attributionsklausel enthält, die man kurz prüfen sollte. Firecrawls selbst gehosteter Kern ist leistungsstark, bringt aber eine AGPL-Diskussion mit sich, bei der Ihr Legal-Team mit am Tisch sitzen sollte.
Und wenn Selektorpflege und Proxy-Verwaltung mehr Engineer-Stunden fressen als das Scraping selbst, dann ist das meist das Signal, dass es Zeit für eine No-Code-Alternative wie Thunderbit ist, statt dem selbst gehosteten OSS-Stack noch eine weitere Schicht hinzuzufügen.
FAQs zu Open-Source-Web-Scraper-Tools
Ist es legal, Open-Source-Web-Scraper-Tools für die geschäftliche Datenerfassung zu nutzen?
Im Allgemeinen ist das Scrapen öffentlich zugänglicher Daten weniger riskant als das Scrapen hinter Logins oder Paywalls, aber automatisch legal ist es deshalb nicht in jedem Fall. Prüfen Sie immer die Nutzungsbedingungen der Zielseite und die robots.txt-Datei — beachten Sie jedoch, dass robots.txt ein Anfrageprotokoll und kein Autorisierungsmechanismus ist. Das Befolgen ist also gute Praxis, verschafft aber an sich keine rechtliche Erlaubnis. Datenschutzgesetze wie die DSGVO gelten ebenfalls, unabhängig davon, ob Daten öffentlich sichtbar sind. Das ist keine Rechtsberatung — sprechen Sie für alles über eine gelegentliche, geringe Nutzung hinaus mit einer Rechtsberatung.
Bedeutet „Open Source“, dass ein Tool kommerziell kostenlos nutzbar ist?
Ja, insofern die Open Source Definition Lizenzen verbietet, die kommerzielle Nutzung zu diskriminieren. Aber „kommerziell nutzbar“ und „ohne Pflichten“ sind zwei verschiedene Dinge — AGPL-3.0 (wie beim selbst gehosteten Kern von Firecrawl) erlaubt kommerzielle Nutzung, verlangt aber weiterhin, dass Sie den entsprechenden Quellcode für veränderte Versionen anbieten, die über ein Netzwerk bereitgestellt werden. MIT, BSD und Apache-2.0 haben diese Pflicht nicht.
Was ist der Unterschied zwischen einem Open-Source-Scraper und einem No-Code-Scraping-Tool?
Open-Source-Scraper wie Scrapy, Playwright oder BeautifulSoup verlangen, dass Sie selbst Code schreiben, Infrastruktur betreiben und Ihre eigene Crawl-Logik, Proxies und Exporte verwalten. No-Code-Tools wie die Web-Scraper-Chrome-Erweiterung oder Thunderbits Browser-Erweiterung übernehmen Felderkennung und Extraktion über eine visuelle Oberfläche oder KI-gestützte Seitenanalyse und tauschen etwas Flexibilität gegen eine deutlich niedrigere Einstiegshürde ein.
Welcher Open-Source-Web-Scraper ist für Nicht-Entwickler am besten?
Fast jedes Tool auf dieser Liste — Scrapy, Playwright, Puppeteer, Crawlee und die übrigen — setzt voraus, dass Sie programmieren können. Für nicht-technische Nutzer bietet die Web-Scraper-Chrome-Erweiterung ein Point-and-Click-Setup, auch wenn Zeitplanung und Cloud-Funktionen hinter einer kostenpflichtigen Stufe liegen. Ein agentisches No-Code-Tool wie Thunderbits Browser-Erweiterung ist ein praktischerer Startpunkt, wenn Sie automatische Felderkennung ohne Selektoren wollen.
Warum braucht Scrapy ein separates Plugin, um JavaScript zu rendern?
Scrapy wurde als HTTP-first-Framework gebaut — es sendet Anfragen und parst das zurückkommende HTML, ohne clientseitige Skripte auszuführen. Diese Architektur macht es für statische Websites schnell und leichtgewichtig, bedeutet aber auch, dass JavaScript-gerenderte Inhalte im von Scrapy erhaltenen Response schlicht nicht enthalten sind. scrapy-playwright schließt diese Lücke, indem bestimmte Anfragen über eine echte Playwright-Browserinstanz geleitet werden, wenn Rendering unvermeidbar ist.
Mehr erfahren
- 15 der besten GitHub-Projekte für Web Scraping 2026, plus die beste No-Code-Alternative
- Crawl4AI nutzt einen echten Browser für Markdown — und nein, es repariert Ihre Selektoren nicht für Sie
- Ich habe Playwright und Puppeteer in dieselben Scraping-Tests geschickt
- Die 10 besten No-Code-Web-Scraper für automatisierte Workflows
- Ist Web Scraping illegal? Die rechtlichen Folgen verständlich erklärt
