SearXNG + Crawl4AI: Warum wir SerpAPI gefeuert haben

Die 847-Euro-Rechnung, die uns zum Umdenken zwang

Im März 2024 haben wir für SerpAPI und Firecrawl zusammen 847 Euro bezahlt. Für Suchanfragen und strukturiertes Crawling. Zwei Dienste, die wir in vier n8n-Workflows eingebunden hatten, um Research-Material für Content-Briefings und Marktanalysen zu sammeln. Die Rechnung kam, wir haben genickt, bezahlt, und dann hat jemand gefragt: "Warum hosten wir das eigentlich nicht selbst?"

Drei Wochen später liefen SearXNG und Crawl4AI auf eigener Infrastruktur. Beide Sourcing-Flows, einmal für Themenrecherche, einmal für Wettbewerbsmonitoring, ziehen jetzt Daten aus unserem eigenen Stack. Die monatliche Rechnung für diese beiden Dienste: null. Die Erkenntnis: Self-hosting ist nicht immer die Antwort, aber wenn du denselben API-Call 40.000 Mal im Monat machst, wird es schnell wirtschaftlich.

Architektur: Zwei Werkzeuge, ein Ziel

Unser Setup besteht aus zwei Komponenten, die nacheinander arbeiten. SearXNG ist eine Meta-Suchmaschine, die Ergebnisse von Google, Bing, DuckDuckGo und anderen aggregiert, ohne dass wir bei jedem Anbieter separate API-Schlüssel brauchen. Wir betreiben eine Instanz auf einem dedizierten Server, der nur für interne Workflows erreichbar ist. Die Suchanfragen kommen aus n8n-Workflows, die entweder manuelle Trigger oder zeitgesteuerte Runs haben.

Crawl4AI übernimmt den zweiten Schritt: strukturiertes Scraping der URLs, die SearXNG liefert. Die Library extrahiert Text, Metadaten und, wenn gewünscht, auch strukturierte Daten via LLM-gestütztes Parsing. Wir nutzen hauptsächlich den Markdown-Export, weil der sich direkt in unsere Briefing-Templates einspeisen lässt. Crawl4AI läuft in einem Python-Container, den wir per HTTP-API aus n8n ansprechen.

Die vier Workflows, die auf diesem Stack aufsetzen, decken unterschiedliche Use Cases ab: Themenrecherche für Redaktionspläne, Wettbewerbsanalyse (welche Keywords ranken bei Konkurrenten?), Lead-Enrichment (öffentliche Infos zu Zielunternehmen) und Trend-Monitoring (was wird in Fachmedien diskutiert?). Jeder Workflow ruft zuerst SearXNG auf, filtert die Ergebnisse nach Relevanz, und schickt die Top-10-URLs an Crawl4AI. Die extrahierten Inhalte landen in einer Datenbank, aus der andere Systeme sie weiterverarbeiten.

Warum nicht einfach Google Custom Search?

Google Custom Search API wäre günstiger gewesen als SerpAPI, 5 Dollar pro 1.000 Queries statt 50. Aber: Sie liefert nur 10 Ergebnisse pro Request, und du kannst nicht nach Datum oder Sprache so granular filtern, wie wir es brauchen. SearXNG aggregiert mehrere Quellen, gibt uns 50+ Ergebnisse pro Query und läuft komplett auf unserer Infrastruktur. Kein Rate Limit, keine Vendor-Lock-in, keine plötzlichen API-Deprecations.

Entscheidung eins: SearXNG statt Vendor-APIs

Wir haben SerpAPI nicht aus ideologischen Gründen rausgeworfen. Die API war stabil, die Ergebnisse gut, die Dokumentation solide. Aber: Wir haben pro Monat zwischen 35.000 und 42.000 Search-Requests gefahren. Bei SerpAPI kostet das je nach Plan zwischen 400 und 600 Euro. SearXNG kostet uns die Server-Miete (80 Euro/Monat für eine dedizierte Maschine, die auch andere interne Services hostet) plus ein paar Stunden Setup-Zeit.

Der Break-even war nach sechs Wochen erreicht. Seitdem sparen wir jeden Monat dreistellig. Aber der eigentliche Gewinn ist Kontrolle: Wir können beliebig viele Queries fahren, ohne dass jemand die Rate Limits hochzieht oder die Preise ändert. Und wir loggen nichts nach außen, für DSGVO-sensible Recherchen (z. B. wenn wir im Auftrag eines Kunden Marktdaten sammeln) ist das ein echtes Argument.

Der Haken: Maintenance und Uptime

SearXNG ist kein SaaS. Wenn die Instanz down ist, steht die Pipeline. Wir haben in den ersten zwei Monaten dreimal erlebt, dass Google oder Bing die IP unseres Servers temporär geblockt haben, weil das Request-Pattern verdächtig aussah. Lösung: Wir rotieren jetzt über mehrere Ausgangs-IPs und haben Rate Limiting eingebaut. Das hätte uns bei SerpAPI niemand abgenommen.

Entscheidung zwei: Crawl4AI statt Firecrawl

Firecrawl war unser bisheriger Scraper-Service. Einfach zu integrieren, zuverlässig, aber teuer: 0,01 bis 0,03 Euro pro gescrapte Seite, je nach Plan. Bei 15.000 bis 20.000 Seiten pro Monat summiert sich das. Crawl4AI ist Open Source, läuft lokal und kostet uns nur Rechenzeit. Die Library ist in Python geschrieben, nutzt Playwright für JavaScript-Rendering und bietet LLM-Integration für strukturiertes Parsing.

Wir haben Crawl4AI als FastAPI-Service deployed, den unsere n8n-Workflows per HTTP ansprechen. Ein Request enthält die URL und ein paar Parameter (Timeout, ob JavaScript gerendert werden soll, welches Output-Format). Die Response ist entweder Markdown oder JSON mit extrahierten Feldern. Für die meisten Use Cases reicht der Markdown-Export; wenn wir strukturierte Daten brauchen (z. B. Preise, Kontaktdaten), schicken wir den Markdown-Output an ein LLM, das die Felder extrahiert.

Was wir unterschätzt haben: Error Handling

Firecrawl hat Fehler elegant abgefangen. Timeout? Du bekommst einen Partial Result. Bot-Detection? Der Service rotiert automatisch durch verschiedene User Agents und Proxies. Crawl4AI macht das nicht. Wenn eine Seite nicht lädt, bekommst du einen leeren String oder einen HTTP-500. Wir mussten selbst Retry-Logik, Timeout-Handling und Fallback-Strategien bauen. Das hat zwei Tage gekostet und war nervig, aber jetzt haben wir es.

Was schiefgegangen ist: Der erste Produktiv-Run

Wir haben das System drei Wochen im Testbetrieb laufen lassen, bevor wir es scharf geschaltet haben. Alles sah gut aus. Dann haben wir den ersten Produktiv-Run gestartet, 8.000 URLs in vier Stunden, und nach zwei Stunden war der Crawl4AI-Container tot. Out of Memory. Wir hatten vergessen, dass Playwright für jede URL einen Browser-Prozess startet, und bei 50 parallelen Requests frisst das schnell 16 GB RAM.

Die Lösung war simpel: Concurrency-Limit auf 10, und wir haben einen zweiten Container hochgezogen, der die Last verteilt. Aber es war ein klassischer Self-Hosting-Moment: Bei einem SaaS-Dienst wäre das deren Problem gewesen. Bei uns war es unseres. Wir haben es gefixt, aber es hat uns zwei Stunden Downtime und einen Haufen Slack-Nachrichten gekostet.

Zahlen haben wir noch keine (und das ist okay)

Wir tracken noch keine systematischen Metriken für diese Pipeline. Keine Latenz-Dashboards, keine Erfolgsraten, keine Cost-per-Query-Analysen. Das System läuft seit acht Wochen, und bisher konzentrieren wir uns darauf, dass es überhaupt stabil läuft. Quantitative Auswertungen kommen später, vermutlich Q3, wenn wir genug Daten haben, um sinnvolle Vergleiche zu ziehen.

Was wir qualitativ sagen können: Die Ergebnisqualität von SearXNG ist vergleichbar mit SerpAPI, manchmal sogar besser, weil wir mehrere Quellen aggregieren. Crawl4AI liefert saubereren Markdown als Firecrawl, aber dafür müssen wir mehr Error Cases selbst abfangen. Unterm Strich: Es funktioniert, es spart Geld, und wir haben die Kontrolle. Das reicht uns erstmal.

Wo wir gelandet sind

Self-Hosting ist kein Selbstzweck. Wenn du 500 Search-Queries im Monat fährst, nimm SerpAPI. Wenn du 50.000 fährst, bau es selbst. Wir sind bei Blck Alpaca in der Situation, dass wir Research-Pipelines intensiv nutzen, für uns selbst und für Kundenprojekte. Da rechnet sich der Aufwand.

Die wichtigste Erkenntnis: Du tauschst monatliche API-Kosten gegen einmaligen Engineering-Aufwand und laufende Maintenance. Wenn du kein Team hast, das Server betreuen kann, oder wenn deine Nutzung schwankt, bleib bei SaaS. Wenn du konstant hohe Volumina fährst und DSGVO-Konformität ein Argument ist, lohnt sich der Umstieg.

Wir würden es wieder so machen. Aber wir würden beim nächsten Mal von Anfang an Concurrency Limits und besseres Error Handling einbauen. Und wir würden früher anfangen, Metriken zu sammeln, nicht, weil wir sie sofort brauchen, sondern weil es später mühsam ist, sie nachzurüsten.

Zuletzt aktualisiert: August 2026

Blck Alpaca ist eine KI-Marketing-Automatisierungsagentur mit Sitz in Wien, spezialisiert auf datengetriebenes Marketing, maßgeschneiderte KI-Agenten und Enterprise-Workflow-Automatisierung für Unternehmen im DACH-Raum.