Die meisten KI-Workflows sind für das Abrufen gebaut, nicht für die Recherche. Ein Agent lädt eine Seite, zieht heraus, was er braucht, beantwortet die Frage und zieht weiter. Stellen Sie morgen eine verwandte Frage, und er lädt dieselbe Seite erneut. Für einmalige Nachschläge ist das in Ordnung. Es fällt in dem Moment auseinander, in dem Sie laufende Recherche gegen dieselben Quellen betreiben.
Recherche ist kumulativ. Sie kehren zu Quellen zurück, vergleichen sie über die Zeit und stellen neue Fragen an alte Daten. Wenn jede Frage einen weiteren Crawl auslöst, verhält sich Ihr Assistent wie eine Suchmaschine, nicht wie ein Recherchesystem. Der Engpass ist nicht das Crawlen. Es ist das fehlende Gedächtnis.
Diese Anleitung baut das fehlende Gedächtnis: ein persistentes Recherche-Dataset mit dem Crawlbase Web MCP Server. Sie crawlen jede Seite einmal, speichern sie in Crawlbase Cloud Storage als wiederverwendbaren Markdown-Snapshot und lassen jede spätere Analyse gegen das gespeicherte Dataset laufen statt gegen das Live-Web. Ein Begleit-Repository liefert die Prompts, die MCP-Konfiguration, Beispiel-URLs und ein Ingestion-Skript, die durchgängig verwendet werden.
Warum KI-Recherche-Workflows immer wieder von vorn beginnen
Wenn Sie schon einmal KI-Recherche-Workflows gebaut haben, kennen Sie das Muster. Sie bitten einen Agenten, die Preisseite eines Wettbewerbers zu analysieren. Er crawlt die Seite, extrahiert die Details, antwortet und vergisst. Ein paar Tage später stellen Sie eine andere Frage zu demselben Unternehmen, und er crawlt die Seite erneut. Nächste Woche vergleichen Sie KI-Funktionen über zehn Wettbewerber hinweg, und jede Seite wird ein drittes Mal gecrawlt.
Technisch ist nichts kaputt. So arbeiten die meisten KI-Scraping-Systeme heute. Das Problem ist, dass jede Frage bei null beginnt, weil das System um das Abrufen herum entworfen wurde: laden, antworten, verwerfen.
Kontinuierliche Sammlung ist manchmal genau der Punkt. Ein KI-Tool zur Produktbeobachtung besucht Seiten nach einem Zeitplan erneut, gerade um neue Preise, Bestandsänderungen oder Bewertungsverschiebungen zu erfassen. Recherche ist anders. Sie achten nicht darauf, was sich in der letzten Stunde geändert hat; Sie bauen Wissen auf, das Sie über Wochen erneut betrachten, vergleichen und neu befragen können. Behandeln Sie die Seiten also als wiederverwendbare Assets, nicht als wegwerfbare Eingaben: einmal crawlen, speichern und die Analyse gegen das Dataset laufen lassen.
Architektur: von Webseiten zu Recherche-Assets
Sobald Sie Webinhalte als Dataset behandeln statt als Suchergebnis, werden Sammlung und Analyse zu zwei getrennten Problemen. Der Web MCP Server bewältigt beide; Cloud Storage bewahrt die Snapshots auf, nachdem das Gespräch endet; ein kleines Manifest ist der Katalog, der sie zusammenhält.
Statt eine Website erneut zu besuchen, sobald eine neue Frage auftaucht, arbeitet der Assistent gegen Snapshots, die bereits existieren. Das Manifest indexiert, was gesammelt wurde (URLs, Crawl-Zeitstempel, Firmennamen, Storage-IDs), ohne jedes Dokument in den Speicher zu zwingen.
Wenn Sie über Dutzende oder Hunderte von Seiten hinweg arbeiten, ist es verschwenderisch, jede einzelne zu laden. Erkunden Sie zuerst die Metadaten, grenzen Sie die Menge ein und holen Sie sich vollständige Dokumente nur dann, wenn sie es verdienen. Das hält die Analyse jetzt schnell und wird umso wichtiger, je größer das Dataset wird.
Den Web MCP Server verbinden
Richten Sie Ihren MCP-Client auf den Crawlbase Web MCP Server aus, bevor Sie irgendetwas bauen. Wenn Sie zunächst einen ausführlicheren Rundgang durch das wünschen, was der Server bereitstellt, lesen Sie unsere Einführung in den Crawlbase Web MCP Server.
{ "mcpServers": { "crawlbase": { "type": "stdio", "command": "npx", "args": ["@crawlbase/mcp@latest"], "env": { "CRAWLBASE_TOKEN": "YOUR_TOKEN", "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN" } } } }
Das Begleit-Repo enthält eine fertige mcp-config.sample.json. Legen Sie sie in Cursor, Codex oder einen beliebigen MCP-kompatiblen Client, ersetzen Sie die Token-Platzhalter durch Ihre Crawlbase-Zugangsdaten und starten Sie neu. Anschließend sollten Sie Tools wie crawl_markdown, storage_count, storage_list, storage_get und storage_bulk_get sehen. Von hier aus kann der Assistent das Dataset ohne eigenen Code crawlen, speichern, abrufen und verwalten.
Das Dataset einmal aufbauen
Die Beispiel-URL-Liste enthält zwanzig öffentliche SaaS-Preisseiten. Der Build-Prompt crawlt jede einzelne, speichert einen Markdown-Snapshot und schreibt die Metadaten in output/dataset-manifest.json.
Die eine Einstellung, die zählt, ist store=true. Ohne sie existiert eine Seite nur innerhalb des aktuellen Gesprächs; wenn die Sitzung endet, ist der Inhalt weg, und die nächste Frage braucht einen weiteren Crawl. Mit ihr bewahrt Crawlbase den Snapshot in Cloud Storage auf und gibt eine RID zurück, mit der Sie das Dokument später wieder abrufen können. Genau dieses eine Flag verwandelt einen Strom temporärer Antworten in ein wiederverwendbares Dataset.
Gegen das Dataset arbeiten, nicht gegen das Web
Sobald die Seiten gespeichert sind, ändert sich der Workflow: Sie fragen ein Dataset ab, statt Websites zu durchstöbern. Der Analyse-Prompt beginnt mit Metadaten, nicht mit Dokumenten.
storage_count storage_list storage_bulk_get(as=metadata_only)
Nutzen Sie die Metadaten, um zu sehen, was existiert, und um zu entscheiden, welche Datensätze einen näheren Blick verdienen; holen Sie sich dann vollständiges Markdown nur dort, wo Sie es brauchen. Von dort aus baut derselbe Prompt einen Vergleich über die Wettbewerber hinweg auf: Er klassifiziert Abrechnungsmodelle, zieht Tarifnamen und Schlagzeilenpreise heraus und markiert, ob ein kostenloser Tarif existiert. Am Ende können Sie Fragen beantworten wie, welches Abrechnungsmodell am häufigsten ist, wer nutzungsbasierte Preise verwendet und wie viele Anbieter einen kostenlosen Tarif veröffentlichen, alles ohne die Live-Seiten erneut anzufassen.
Veränderungen über die Zeit erkennen
„Welche Wettbewerber haben ihr Preismodell in den letzten drei Monaten geändert?" ist eine häufige Frage der Wettbewerbsanalyse, und sie funktioniert nur, wenn Sie Historie behalten haben. Der Änderungserkennungs-Prompt vergleicht Snapshots über die Zeit.
Mit einem einzigen Snapshot pro Wettbewerber klassifiziert er das aktuelle Modell und erklärt, dass Zeitvergleiche noch nicht möglich sind. Mit mehreren Snapshots vergleicht er Versionen und legt echte Verschiebungen offen: von pro Sitzplatz zu nutzungsbasiert, von Pauschale zu Hybrid oder eine Neuordnung der Pakete. Jeder Crawl fügt eine Schicht hinzu. Der erste gibt Ihnen Sichtbarkeit, der zweite gibt Ihnen Vergleich, der dritte beginnt, einen Trend zu zeigen.
Mit der Zeit hört das Dataset auf, ein Stapel von Seiten zu sein, und wird zu einer Aufzeichnung darüber, wie sich diese Seiten verändern.
Wiederverwenden und aufräumen
Der Nutzen gespeicherter Snapshots zeigt sich nach der Sammlung: Neue Fragen bedeuten keine neuen Crawls mehr. Der Wiederverwendungs-Prompt führt völlig andere Analysen gegen dieselben zwanzig Seiten aus, darunter wer einen kostenlosen Tarif anbietet, wer jährliche und monatliche Preise nebeneinander zeigt, wer mit nutzungsbasierter Preisgestaltung führt und wer KI-Funktionen auf der Preisseite in den Vordergrund stellt. Das Ausgangsmaterial ist bereits gesammelt; der Assistent stellt einfach neue Fragen daran. Wenn Sie möchten, dass der Agent auf diese Daten in einer Live-Schleife reagiert, statt einen gespeicherten Bestand zu analysieren, lesen Sie Build AI Agent Workflows with Web MCP.
Wenn ein Projekt abgeschlossen ist, räumen Sie Snapshots auf, die Sie nicht mehr brauchen, damit sie künftige Sitzungen nicht trüben. Der Aufräum-Prompt listet gespeicherte Datensätze auf, bittet um Bestätigung und löscht in Stapeln. Da das Löschen unumkehrbar ist, fragt er immer nach, bevor er etwas entfernt.
Die Sammlung automatisieren
Prompts von Hand auszuführen, ist ideal, solange Sie erkunden. Sobald der Workflow zur Routine wird (dieselben Quellen, nach einem Zeitplan, wachsende Datasets), automatisieren Sie die Sammlungsphase. Das ingest_dataset.py des Repos tut genau das über die Crawling API.
pip install -r requirements.txt export CRAWLBASE_TOKEN="YOUR_CRAWLBASE_TOKEN" python ingest_dataset.py --urls urls.saas-pricing.txt
Das Skript liest die URL-Liste, fordert jede Seite als Markdown an, speichert den Snapshot und schreibt ein Manifest. Die Anfrage selbst ist bewusst schlicht gehalten:
response = requests.get( "https://api.crawlbase.com/", params={ "token": token, "url": url, "format": "md", "md_readability": "true", "store": "true", }, )
Es fordert Markdown-Ausgabe mit format=md an, schaltet Lesbarkeit mit md_readability=true ein und speichert das Ergebnis mit store=true. Statt Dokumentinhalte lokal zu speichern, erfasst es, was es braucht, um sie später abzurufen, allen voran die RID, die Cloud Storage für jede Seite zurückgibt. Diese Datensätze landen in output/dataset-manifest.json:
{ "generated_at": "...", "entry_count": 20, "stored_count": 20, "entries": [...] }
Denken Sie an das Manifest als den Katalog: Die Dokumente leben in Cloud Storage, und das Manifest hält fest, wie man sie findet. Es leistet dieselbe Arbeit wie der MCP-Workflow, nur wiederholbar.
Infrastruktur statt erneutes Crawlen
Ein Recherche-Dataset zu bauen bedeutet normalerweise, einen Crawler, eine Speicherschicht, einen Abrufmechanismus und einen Analyse-Workflow zusammenzuflicken. Der Crawlbase Web MCP Server fasst das meiste davon in Tools zusammen, die innerhalb von Cursor, Codex und anderen MCP-Clients leben, und Cloud Storage hält die Snapshots noch lange nach dem Crawl erreichbar.
Das verändert die Ökonomie. Sammeln Sie Inhalte einmal und verwenden Sie sie über viele Analysen hinweg wieder, und jede Seite wird zu einem Recherche-Asset statt zu einer Wegwerf-Antwort. Der Wert des Datasets wächst, während die Kosten der Sammlung ungefähr gleich bleiben. Dieselbe Idee liegt Machine-Learning-Pipelines zugrunde, wo gesammelte Daten über Training und Evaluierung hinweg wiederverwendet werden; siehe Web Scraping for Machine Learning für diese Perspektive. Für laufende Marktforschung und Wettbewerbsanalyse ist diese Verschiebung oft mehr wert als der Crawl selbst.
Geben Sie Ihrem KI-Client Crawlen, Speichern und Abrufen in einem einzigen Satz von Tools. Jeder Crawl rendert JavaScript hinter einer rotierenden Residential-IP und gibt sauberes Markdown zurück, wobei Snapshots zur Wiederverwendung in Cloud Storage aufbewahrt werden. Kein Proxy-Pool, keine Headless-Flotte, kein eigener Code. Bauen Sie Ihr erstes Dataset im kostenlosen Tarif.
Wichtigste Erkenntnisse
- Recherchesysteme und Abrufsysteme lösen unterschiedliche Probleme; die meisten KI-Workflows sind für das Abrufen gebaut.
- Dieselben Seiten für jede Frage erneut zu crawlen, zahlt die Sammlungskosten immer wieder.
- Persistente Speicherung trennt die Beschaffung von der Analyse, sodass ein Crawl vielen künftigen Fragen dient.
- Metadaten-orientierte Erkundung skaliert besser, als jedes Dokument zu laden.
- Historische Snapshots sind es, die Trendanalyse und Änderungserkennung möglich machen.
- Ein Recherche-Dataset wird über die Zeit wertvoller, weil die Sammlungskosten über jede spätere Frage amortisiert werden.
- Der Crawlbase Web MCP Server vereint Crawlen, Speichern, Abrufen und Analyse in einem einzigen Workflow, und das Begleit-Repo ist eine funktionierende Implementierung davon.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem KI-Recherche-Dataset und einer RAG-Wissensdatenbank?
Eine RAG-Wissensdatenbank ist darauf optimiert, zur Abfragezeit relevanten Kontext abzurufen: Dokumente werden in Abschnitte zerlegt, eingebettet und durchsucht, sodass ein Modell mit dem richtigen Kontext antworten kann. Ein KI-Recherche-Dataset ist auf Anhäufung optimiert: Das Ziel ist, Informationen über die Zeit zu sammeln und zu bewahren, damit sie viele künftige Analysen unterstützen können, darunter RAG, Wettbewerbsanalyse, Marktforschung und Trenderkennung. Sie können ein RAG-System aus einem Recherche-Dataset bauen, aber das Dataset ist breiter als jede einzelne Abruf-Pipeline.
Warum Webseiten speichern, statt sie jedes Mal zu crawlen?
Wiederholtes Crawlen ist für einmalige Fragen in Ordnung, aber ineffizient für laufende Recherche. Angenommen, Sie sammeln heute zwanzig Preisseiten von Wettbewerbern; morgen vergleichen Sie KI-Funktionen, nächste Woche analysieren Sie Jahresrabatte, einen Monat später prüfen Sie das Enterprise-Paketangebot. Die Seiten haben sich vielleicht nicht geändert, doch wiederholtes Crawlen lässt Sie die Sammlungskosten jedes Mal zahlen. Snapshots zu speichern trennt die Beschaffung von der Analyse, sodass dasselbe Dataset viele künftige Fragen beantwortet, ohne die ursprünglichen Websites erneut anzufassen.
Warum Markdown statt rohem HTML verwenden?
Markdown behält die Informationen, die zählen, und lässt den größten Teil des Präsentations-Rauschens fallen. Überschriften bleiben Überschriften, Listen bleiben Listen, Tabellen bleiben lesbar. Rohes HTML schleppt Navigationsmenüs, Skripte und Styling mit, die zur Recherche wenig beitragen, und Markdown-Snapshots sind leichter zu lesen, zu analysieren, in Abschnitte zu zerlegen, einzubetten und über Versionen hinweg zu vergleichen.
Kann ich diesen Ansatz für andere Daten als SaaS-Preisseiten verwenden?
Ja. Das Repo verwendet Preisseiten, weil sie leicht zu durchdenken sind und Workflows der Wettbewerbsanalyse demonstrieren, aber dieselbe Architektur passt zu Produktdokumentation, Branchenberichten, öffentlichen Unterlagen, Nachrichtenartikeln, Wissensdatenbank-Inhalten, akademischen Ressourcen und Marktforschungsquellen. Der Beschaffungs- und Speicher-Workflow bleibt derselbe, unabhängig davon, was Sie sammeln.
Ersetzt der Crawlbase Web MCP Server Vektordatenbanken und Embeddings?
Nein. Der Web MCP Server bewältigt Beschaffung, Speicherung und Abruf von Quelldokumenten. Vektordatenbanken und Embedding-Modelle kommen ins Spiel, wenn Sie semantische Suche, RAG-Pipelines oder ähnlichkeitsbasierten Abruf wünschen. Viele Teams nutzen den Web MCP Server als Beschaffungsschicht und speisen gespeicherte Dokumente später in Embedding-Pipelines, Vektorspeicher oder Agenten ein, sodass das Dataset zur Grundlage wird, auf der andere KI-Systeme aufbauen.
Crawlen Sie jede Website im großen Maßstab, ohne gegen die Infrastruktur zu kämpfen.
Crawlbase übernimmt Proxys, Fingerprints und CAPTCHAs, damit Ihr Team Datenpipelines ausliefert, statt Crawl-Infrastruktur zu pflegen. 1.000 Anfragen kostenlos, keine Karte erforderlich.