Die Herausforderung
Vertical-AI-Startups stoßen etwa im zweiten Monat alle auf dieselbe Hürde. Sie veröffentlichen einen Support-Copiloten, einen Assistenten für die Rechtsrecherche oder einen Compliance-Bot. Die erste Demo überzeugt Kunden. Dann veralten die Daten und die Antworten weichen zunehmend von der Realität ab.
Wir haben oft gesehen, wie Teams den KI-Teil sauber aufbauen und die Datenseite vernachlässigen. Die Ingestion-Pipeline besteht aus einem einzelnen Python-Skript auf dem Laptop eines Entwicklers. Es scrapt einmalig 200 Quell-URLs, lädt sauberes Markdown in einen Vector Store und alle feiern den Erfolg. Sechs Wochen später verweist die Hälfte der Antworten auf gelöschte Seiten, veraltete APIs oder Produktfeatures, die im März geändert und im Mai erneut angepasst wurden.
Die Lösung klingt simpel: Crawle jede Quelle wöchentlich neu. Die Realität ist komplizierter. Bis 2026 blockieren etwa 60 % der seriösen Websites KI-Crawler (gegenüber 23 % Ende 2023). Dabei handelt es sich nicht mehr um einfache User-Agent-Prüfungen. Sie analysieren Sitzungsverhalten, Request-Muster und Signale auf Handshake-Ebene. Ein einfaches Skript, das im Januar funktionierte, liefert im März unbemerkt leere Seiten zurück.
Erschwerend kommt hinzu, dass einige Websites mittlerweile Tarpit-Inhalte ausspielen (mittels Markov-Ketten generierter Kauderwelsch, der wie echter Text wirkt), bis deine Embeddings unbrauchbar werden. Deine Engineers verbringen die halbe Woche damit, den Scraper zu reparieren, anstatt am Produkt zu arbeiten. Die Retrieval-Qualität sinkt, Kunden bemerken es und dein KI-Team verwandelt sich in eine Scraper-Wartungstruppe.
Der Ansatz
Das Recrawl-Problem erfordert bei jedem Request drei konkrete Entscheidungen:
- Rendern oder nicht? Die meisten Dokumentationsportale liefern sauberes HTML. Ein wachsender Anteil (alles auf Next.js-Basis, alles mit clientseitigem Rendering) benötigt ein vollständiges Browser-Rendering für brauchbare Inhalte.
- Welcher Proxy? Residential, Datacenter, Mobile, mit Geo-Targeting oder spezifischem ISP. Die passende Wahl variiert je nach Zielseite.
- War der Abruf wirklich erfolgreich? Ein Statuscode 200 mit leerem Body oder eine Verifizierungsseite ist ein erfolgreicher HTTP-Request, aber ein fehlgeschlagener Crawl.
Eine Plattform wie FourA behandelt jeden dieser Punkte als Kernfunktionalität.
Für die Render-Entscheidung nutzt du Single für den schnellen, kostengünstigen Fall und Browser für JavaScript-lastige Ziele. Der Request-Body bleibt identisch strukturiert. Dein Ingestion-Code verzweigt sich einmal anhand eines Flags pro Quelle, anstatt hunderte seitenspezifische Ausnahmen zu verwalten.
Bei der Proxy-Auswahl wird der Proxy Finder automatisch bei jedem Single-, Browser- und Auto-Call ausgeführt. Die Plattform wählt pro Request einen funktionierenden Exit-Node, 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 nutzt diese ID für Folgeaufrufe, wenn du denselben Exit beibehalten willst. Dein Crawler benötigt keinen eigenen Proxy-Ranking-Algorithmus. (Warum die Pool-Größe kein Unterscheidungsmerkmal mehr ist, haben wir in Why Proxy Pool Size Stopped Mattering in 2026 beschrieben.)
Und für die Frage "Hat es wirklich funktioniert?" unterstützt jeder Request einen validate-Block. Du definierst, was als Erfolg gilt: akzeptierte Status-Codes, erforderliche Header-Werte, Body-Strings, die vorkommen müssen oder nicht vorkommen dürfen. FourA liefert eines von sieben Ergebnissen zurück, und nur success ist abrechenbar. Ein 200er-Status, der deine Content-Regeln verletzt, wird als application_fail markiert und landet nie in deinem Dataset.
So sieht ein Recrawl-Aufruf für ein Dokumentationsportal aus, das JS-Rendering erfordert. Wir überlassen Auto die Orchestrierung: Es wählt das passende Produkt (Single, Proxy oder Browser), umgeht Bot-Abwehrmechanismen und gibt das Session-Triple zurück, damit der nächste Recrawl denselben Exit nutzen 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 eine Cloudflare-Zwischenseite anzeigt, greift die validate.data.fail-Regel. Das in deiner Nutzung erfasste Ergebnis ist application_fail. Du zahlst nicht dafür, und dein Ingestion-Code weiß, dass er es mit einem anderen Proxy wiederholen muss, anstatt eine "Just a moment..."-Seite in die Embeddings einzuspeisen.
Für das gesamte Korpus nutzt du dasselbe Muster in deiner bestehenden Job Queue. Teams, mit denen wir gesprochen haben, führen nächtliche Diffs gegen den vorherigen Crawl durch, betten nur geänderte Dokumente neu ein und aktualisieren Korpora mit 500 Quellen in wenigen Stunden realer Laufzeit. Die Job Queue bleibt bei dir. Die Proxy-Rotation, die Render-Entscheidung und die Erfolgsbewertung übernehmen wir.
Ergebnisse
So sieht der Freshness Loop aus, sobald die Infrastruktur kein Flaschenhals mehr ist (illustratives Szenario basierend auf typischen Mustern bei vertikalen AI-Teams):
- 500 Quell-URLs wöchentlich neu gecrawlt, statt einmalig 200 URLs beim Start
- Entwicklungszeit für den Scraper: unter 2 Stunden pro Woche, vorher 1 bis 2 Tage
- Retrieval-Veraltungsfenster: 5 bis 7 Tage, statt unbegrenzt
- Müllrate im Vector Store nahe null, da Cloudflare-Zwischenseiten und Tarpits auf der
validate-Ebene verworfen werden, bevor sie dein Embedding-Modell erreichen - Planbare Kosten pro Quelle, da fehlgeschlagene Crawls nicht abgerechnet werden
Keiner dieser Punkte ist magisch. Sie sind schlicht unaufgeregt. Und genau das braucht Produktiv-AI. (Mehr dazu, wann sich gehostete LLM-Extraktion rechnerisch nicht mehr lohnt, findest du unter When LLM Extraction Stops Paying for Itself.)
Fazit
Die meisten Teams, die vertikale AI entwickeln, halten Prompts, Modellauswahl oder Retrieval-Algorithmen für ihren Burggraben. Das stimmt nicht. Der eigentliche Wettbewerbsvorteil ist der Freshness Loop: die unscheinbare Infrastruktur, die deine Wissensbasis Woche für Woche aktuell hält.
Die Teams, die sich bis 2026 im Bereich vertikale AI durchsetzen, sind nicht die mit den raffiniertesten Prompts. Es sind die, deren Nutzer gar nicht bemerken, dass die Daten aktuell sind, weil sie es einfach immer sind.