ScrapeGraphAI: Scraping-Pipelines als Prompt statt als Selektor
Python scraper based on AI
Auf einen Blick
- Was ist das?
- ScrapeGraphAI beschreibt einen LLM-gesteuerten Scraper, der aus einem Prompt und einer URL ein Dictionary zurückgibt. Die Bibliothek ist MIT-lizenziert und liegt als PyPI-Paket vor; dieser Text ordnet ein, wo das Modell die Arbeit macht, wo die Konfiguration hakt und für wen sich der Ansatz lohnt.
- Für wen ist es gedacht?
- Wer Seiten mit wechselnder Struktur auslesen will und die Extraktionslogik lieber in einem Prompt als in einem Selektorbaum pflegt, findet hier ein passendes Werkzeug. Wer deterministische, reproduzierbare Ergebnisse ohne LLM-Kosten braucht, ist mit einem klassischen Selektor-Scraper besser bedient.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 8 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: Selektoren brechen, Prompts bleiben
Klassisches Scraping beschreibt das Ziel über die Struktur der Quelle. Ein CSS-Pfad wie div.product-list > article h3 gilt so lange, bis das Markup sich ändert. Genau diese Kopplung will ScrapeGraphAI auflösen. Die README formuliert den Anspruch so: Man sage, welche Information man extrahieren will, und die Bibliothek erledige den Rest. Statt Selektoren zu pflegen, beschreibt man das Ergebnis. Im Beispiel der README lautet der Prompt: Extract useful information from the webpage, including a description of what the company does, founders and social media links. Die Antwort ist ein Dictionary mit den Schlüsseln description, founders und social_media_links. Adressiert sind damit Teams, die viele unterschiedlich aufgebaute Seiten auswerten und die Extraktionslogik nicht pro Domain neu schreiben wollen. Ebenso angesprochen sind lokale Dokumente, denn die Beschreibung nennt XML, HTML, JSON und Markdown als Quellen. Wer dagegen eine einzelne, seit Jahren stabile Seite mit festem Schema ausliest, gewinnt durch diesen Ansatz wenig und zahlt zusätzlich für Modellaufrufe.
Graph statt Kette: was zwischen URL und Dictionary passiert
Der Name ist Programm: Die Bibliothek organisiert die Verarbeitung als Graph, nicht als lineare Kette. Die README spricht von direct graph logic, mit der Pipelines für Websites und lokale Dokumente erzeugt werden. Die sichtbare Schnittstelle ist ein Objekt pro Pipeline, das mit prompt, source und config instanziiert und über run() gestartet wird. Die Konfiguration übergibt man als verschachteltes Dictionary namens graph_config. Darin steckt mindestens der Schlüssel llm mit model und, je nach Anbieter, api_key. Im Ollama-Beispiel der README stehen zusätzlich model_tokens mit dem Wert 8192 und format auf json; für OpenAI genügt api_key plus model, etwa openai/gpt-4o-mini. Die beiden übrigen Schlüssel auf oberster Ebene sind verbose und headless. headless steuert, ob der Browser sichtbar läuft, was beim Debuggen hilft und im Produktivbetrieb störend ist. Das Ergebnis von run() ist laut README ein Dictionary, das direkt per json.dumps ausgegeben werden kann. Für das Abrufen der Seiteninhalte ist Playwright zuständig, weshalb die README nach pip install scrapegraphai ausdrücklich playwright install verlangt. Wer diesen Schritt überspringt, hat die Bibliothek installiert, aber keinen funktionierenden Seitenabruf.
Installation und erster Lauf in konkreten Zeilen
Die Installation besteht aus zwei Befehlen: pip install scrapegraphai und anschließend playwright install. Die README empfiehlt ausdrücklich eine virtuelle Umgebung, um Konflikte mit anderen Bibliotheken zu vermeiden. Der minimale Lauf sieht dann so aus: Zuerst der Import von SmartScraperGraph aus scrapegraphai.graphs, danach das graph_config-Dictionary, dann die Instanziierung mit prompt, source und config, schließlich result = smart_scraper_graph.run(). Der Wechsel des Modellanbieters erfordert laut README nur eine Änderung am llm-Block: api_key und model austauschen, der Rest des Codes bleibt. Das ist der praktische Kern des Entwurfs. Wer den Ablauf nachvollziehen will, setzt verbose auf True und headless auf False, dann ist der Browser während des Laufs sichtbar. Für mehrere Seiten oder andere Ausgabeformate nennt die README weitere Pipelines: SearchGraph arbeitet die Top-n-Treffer einer Suchmaschine ab, SpeechGraph erzeugt aus einer Seite eine Audiodatei, ScriptCreatorGraph generiert Python-Skripte. Die README-Tabelle ist an dieser Stelle abgeschnitten, weitere Pipeline-Namen lassen sich daraus nicht belegen.
Die Kosten liegen im Modell, nicht im Paket
Der entscheidende Aufwandsposten ist nicht die Bibliothek, sondern der LLM-Aufruf. Jede Extraktion ist ein Modellaufruf, und die Qualität des Ergebnisses hängt an der Fähigkeit des Modells, die Seiteninhalte zu interpretieren. Die README zeigt beide Enden dieser Skala: ein lokales ollama/llama3.2 mit model_tokens 8192, bei dem keine API-Kosten anfallen, und openai/gpt-4o-mini, bei dem pro Aufruf abgerechnet wird. Wer viele Seiten verarbeitet, sollte diese Rechnung vor dem Rollout aufstellen. Hinzu kommt ein zweiter, weniger offensichtlicher Kostenfaktor: model_tokens begrenzt, wie viel Seiteninhalt das Modell überhaupt sieht. Große Seiten können diese Grenze überschreiten, und die README sagt nicht, was dann geschieht. Ob gekürzt, abgeschnitten oder ein Fehler geworfen wird, lässt sich aus dem Material nicht ableiten. Das ist eine offene Flanke für alle, die mit langen Artikeln oder umfangreichen Produktlisten arbeiten.
Wo der Ansatz an seine Grenzen stößt
Der wichtigste Nachteil steckt im Entwurfsprinzip selbst: Ein Modell liefert nicht bei jedem Lauf dieselbe Ausgabe. Das README-Beispiel zeigt das unbeabsichtigt deutlich. Im founders-Array steht ein Eintrag mit leerem name-Feld, nur role und linkedin sind gefüllt. Ein Selektor-Scraper hätte an dieser Stelle entweder einen Wert oder nichts geliefert, aber keine strukturell gültige Zeile mit fehlendem Inhalt. Wer Ergebnisse in ein Datenbankschema mit Pflichtfeldern schreibt, braucht daher eine Validierungsschicht hinter run(), die die README nicht mitliefert. Zweitens ist der Ansatz die falsche Wahl, wenn Antwortzeit oder Reproduzierbarkeit harte Anforderungen sind. Ein Modellaufruf pro Seite ist langsamer und teurer als ein HTTP-Request plus Parser, und zwei Läufe über dieselbe Seite können sich unterscheiden. Drittens setzt der Betrieb Playwright voraus, also einen Browser im Ausführungsumfeld. In einer schlanken Container-Umgebung ist das ein zusätzlicher Brocken. Viertens ist der Suchpfad über SearchGraph an eine Suchmaschine gebunden, deren Verhalten und Rate-Limits die README nicht beschreibt.
Was ein Selektor-Scraper anders macht
Die naheliegende Alternative ist ein klassischer Scraper wie BeautifulSoup in Kombination mit requests, oder ein Framework wie Scrapy. Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Fehlerquelle. Ein Selektor-Scraper beschreibt, wo im Dokument die Information steht. Ändert der Betreiber das Markup, bricht die Extraktion, und man korrigiert den Selektor. Ein LLM-Scraper beschreibt, welche Information gemeint ist. Ändert sich das Markup, läuft die Extraktion in vielen Fällen weiter, weil das Modell den Inhalt neu interpretiert. Dafür verliert man die Garantie, dass die Ausgabe einem festen Schema folgt. Es ist ein Tausch: Wartungsaufwand gegen Vorhersagbarkeit. Für Seiten mit stabiler Struktur und hohem Volumen ist der Selektor-Scraper die günstigere und schnellere Wahl. Für eine lange Liste heterogener Quellen, bei denen man sonst für jede Domain einen eigenen Parser schreiben würde, kippt die Rechnung zugunsten des Modellansatzes. Die README positioniert die Bibliothek ausdrücklich als firecrawl-alternative, was die Themen des Repositories bestätigen, ohne dass daraus ein technischer Vergleich ableitbar wäre.
Pflege, Releases und Lizenz
Das Repository ist nicht archiviert und wird aktiv gepflegt. Die letzten veröffentlichten Versionen sind v2.2.4 vom 7. September 2026 sowie die zugehörige Beta v2.2.4-beta.1 und die vorausgehende v2.2.3. Der Abstand zwischen den Tags ist gering, was auf eine kurze Release-Kadenz hindeutet. Für den Betrieb heißt das: Wer die Bibliothek produktiv einsetzt, sollte die Version pinnen und Upgrades bewusst ziehen, weil sich bei einem so jungen Projekt die Pipeline-Schnittstellen zwischen Minor-Versionen ändern können. Die README listet zahlreiche Integrationswege, darunter SDKs für Python und Node, Anbindungen an Langchain, Llama Index, CrewAI, Agno, Pipedream, Zapier, n8n und Dify sowie einen MCP-Server. Diese Aufzählung zeigt, dass ein Teil der Funktionalität über die gehostete Plattform scrapegraphai.com läuft, auf die die README mehrfach verweist. Wer die Bibliothek selbst betreibt, nutzt nur den Teil, der im Paket steckt. Lizenziert ist das Projekt unter MIT. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass der Lizenztext und der Urheberrechtshinweis beibehalten werden. Das ist keine Rechtsberatung: Die Lizenz des eingesetzten Modells ist davon unberührt und muss separat geprüft werden.
Redaktionelles Fazit
Wer Seiten mit wechselnder Struktur auslesen will und die Extraktionslogik lieber in einem Prompt als in einem Selektorbaum pflegt, findet hier ein passendes Werkzeug. Wer deterministische, reproduzierbare Ergebnisse ohne LLM-Kosten braucht, ist mit einem klassischen Selektor-Scraper besser bedient. Vor dem ersten Einsatz zu prüfen: ob die installierte Version die gewünschte Pipeline enthält, ob das gewählte Modell das in der README gezeigte json-Format unterstützt und ob die Lizenz des Modells zu den eigenen Anforderungen passt.
Community-Notizen