Das Problem
Alle vertikalen KI-Startups stoßen etwa im zweiten Monat auf dasselbe Problem. Sie launchen einen Support-Copiloten, einen juristischen Recherche-Assistenten oder einen Compliance-Bot. Die erste Demo gewinnt Kunden. Dann veralten die Daten und die Antworten weichen zunehmend von der Realität ab.
Wir haben beobachtet, wie Teams die KI-Seite sauber aufbauen und die Datenseite nur als Nebensache behandeln. Die Ingestion-Pipeline ist ein Python-Skript, das auf dem Laptop von jemandem läuft. Es crawlt 200 Quell-URLs einmal, lädt sauberes Markdown in einen Vector Store und alle feiern. Sechs Wochen später zitieren die Hälfte der Antworten gelöschte Seiten, veraltete APIs oder Produktfunktionen, die im März veröffentlicht und im Mai erneut geändert wurden.
Die Lösung klingt einfach: Jede Quelle wöchentlich neu crawlen. Die Realität ist jedoch unschöner. Bis 2026 blockieren etwa 60% der seriösen Websites KI-Crawler (ein Anstieg von 23% Ende 2023), und die Schutzmechanismen sind keine dummen User-Agent-Prüfungen mehr. Sie analysieren Sitzungsverhalten, Request-Rhythmus und Signale auf Handshake-Ebene. Ein einfaches Skript, das im Januar funktionierte, liefert im März stillschweigend leere Seiten.
Noch schlimmer: Einige Seiten liefern jetzt Tarpit-Content (durch Markov-Ketten generierter Unsinn, der sich wie echter Text liest), bis dieser deine Embeddings vergiftet. Deine Entwickler verbringen die halbe Woche damit, den Scraper zu patchen, anstatt das Produkt weiterzuentwickeln. Die Retrieval-Qualität sinkt, die Kunden bemerken es und das Team, das du für den Aufbau von KI eingestellt hast, wird zu einer Scraper-Wartungstruppe.
Der Ansatz
Das Recrawl-Problem lässt sich in drei konkrete Entscheidungen aufteilen, die bei jedem Request getroffen werden müssen:
- Rendern oder nicht? Die meisten Dokumentationsportale liefern sauberes HTML. Ein wachsender Anteil (alles, was auf Next.js basiert, alles mit clientseitigem Rendering) erfordert ein vollständiges Browser-Rendering, um nützliche Inhalte zurückzugeben.
- Welcher Proxy? Residential, Datacenter, Mobile, Geo-Pinned, ISP-spezifisch. Die richtige Wahl ändert sich je nach Ziel.
- Hat es tatsächlich funktioniert? Ein 200 mit einem leeren Body oder eine CAPTCHA-HTML-Seite ist ein erfolgreicher HTTP-Request, aber ein fehlgeschlagener Crawl.
Eine Plattform wie FourA behandelt jede dieser Entscheidungen als erstklassiges Anliegen.
Für die Rendering-Entscheidung rufst du Single für den günstigen, schnellen Fall und Browser für JS-lastige Ziele auf. Der Body des Aufrufs hat dieselbe Struktur, sodass dein Ingestion-Code auf Basis eines quellenspezifischen Flags verzweigt, anstatt hunderte seitenspezifische Besonderheiten mitzuschleppen.
Für die Proxy-Auswahl läuft Proxy Finder als Teil jedes Single-, Browser- und Auto-Aufrufs. Die Plattform wählt pro Request einen funktionierenden Exit, gibt dessen opake ID in der Response zurück (auf r.proxy Top-Level bei Single/Browser oder r.session.proxy bei Auto), und du verwendest diese ID in Folgeaufrufen wieder, wenn du beim selben Exit bleiben musst. Dein Crawler benötigt keinen eigenen Proxy-Ranking-Algorithmus. (Wir haben darüber geschrieben, warum die Pool-Größe kein Unterscheidungsmerkmal mehr ist: Why Proxy Pool Size Stopped Mattering in 2026.)
Und für die Frage "Hat es tatsächlich funktioniert?" unterstützt jeder Request einen validate-Block. Du legst fest, was als Erfolg zählt: akzeptierte Statuscodes, erforderliche Header-Werte, Body-Strings, die vorkommen müssen oder nicht vorkommen dürfen. FourA gibt eines von sieben Ergebnissen zurück und nur success wird in Rechnung gestellt. Ein 200, der deine Content-Regeln nicht erfüllt, wird als application_fail markiert und gelangt nie in deinen Datensatz.
Hier ist ein Beispiel für einen Recrawl-Aufruf für ein Dokumentationsportal, das ein JS-Render benötigt. Wir lassen Auto orchestrieren, es wählt das richtige Produkt (Single, Proxy oder Browser), kümmert sich um Bot-Abwehrmaßnahmen und gibt das Session-Triple zurück, sodass der nächste Recrawl beim selben Exit bleiben kann:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://docs.example.com/changelog",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto runs the right sub-product per host;
# Single populates "data", Browser populates "body")
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.
Wenn das Ziel ein Cloudflare-Interstitial liefert, greift die validate.data.fail-Regel. Das für deine Nutzung vermerkte Ergebnis ist application_fail. Du bezahlst nicht dafür und dein Ingestion-Code weiß, dass er den Versuch mit einem anderen Proxy wiederholen muss, anstatt eine "Just a moment..."-Seite in die Embeddings einzuspeisen.
Für den breiteren Korpus kapselst du dasselbe Muster in deine bestehende Job-Queue. Teams, mit denen wir gesprochen haben, führen nächtliche Diffs gegen den vorherigen Crawl durch, re-embedden nur die Dokumente, die sich tatsächlich geändert haben, und aktualisieren 500-Quellen-Korpora in ein paar Stunden reiner Laufzeit. Die Job-Queue bleibt deine. Die Proxy-Rotation, die Render-Entscheidung und das Erfolgsurteil liegen bei uns.
Ergebnisse
So sieht der Aktualisierungszyklus aus, wenn die Infrastruktur nicht mehr der Engpass ist (illustratives Szenario basierend auf Mustern, die wir bei vertikalen KI-Teams sehen):
- 500 Quell-URLs wöchentlich neu gecrawlt, anstelle eines einmaligen 200-URL-Crawls beim Launch
- Engineering-Zeit für den Scraper: unter 2 Stunden pro Woche, statt 1-2 Tage
- Retrieval-Veralterungsfenster: 5-7 Tage, statt unbegrenzt
- Ausschussrate im Vector Store nahe null, weil Cloudflare-Interstitials und Tarpit-Seiten auf der
validate-Ebene abgelehnt werden, bevor sie dein Embedding-Modell erreichen - Vorhersehbare Kosten pro Quelle, da fehlgeschlagene Crawls nicht berechnet werden
Der Punkt ist nicht, dass irgendetwas davon magisch ist. Der Punkt ist, dass es langweilig ist. Und langweilig ist das, was Produktions-KI braucht. (Weitere Informationen darüber, wann sich gehostete LLM-Extraktion nicht mehr rechnet, findest du unter When LLM Extraction Stops Paying for Itself.)
Wichtigste Erkenntnis
Die meisten Teams, die vertikale KI entwickeln, denken, ihr Wettbewerbsvorteil sei der Prompt, die Wahl des Modells oder der Retrieval-Algorithmus. Das ist nicht der Fall. Der Wettbewerbsvorteil ist der Aktualisierungszyklus: die unglamouröse Infrastruktur, die die Wissensbasis Woche für Woche aktuell hält.
Die Teams, die bis 2026 im Bereich der vertikalen KI gewinnen, werden nicht die mit den cleversten Prompts sein. Es werden diejenigen sein, deren Nutzer nie bemerken, dass die Daten aktuell sind, weil sie es immer sind.