Firecrawl: eine Web-Crawling-API für RAG-Pipelines im Test

Firecrawl ist eine gehostete API, die eine URL in sauberes Markdown, JSON oder HTML verwandelt, plus ein Crawler, der dasselbe für eine ganze Website tut. Sie existiert, weil praktisch jede Retrieval-Pipeline irgendwann das Web braucht, und weil eine beliebige Seite in Text, den ein Sprachmodell lesen kann, ein Browser-Automationsproblem im Datenbereinigungs-Gewand ist. Das Urteil hier: der beste Standard für Teams, die Web-Kontext diese Woche in ein Produkt bringen wollen, und ein schlechter Fit für alle, die Egress kontrollieren, die Rohbytes behalten oder pro Megabyte statt pro Seite zahlen müssen.

In einem Stack sitzt Firecrawl zwischen der Fetch-Schicht und der Embedding-Schicht. Ein Vektorstore sieht Firecrawl nie; er sieht das Markdown, das herauskam. Genau darum geht es: Firecrawl konkurriert weniger mit einer allgemeinen Scraping-Bibliothek wie Scrapy als mit der Browser-Flotte, der Proxy-Rotation und der Sperrschicht, die ein Team sonst zusammenbauen müsste, um dieselbe Pipeline zu speisen. Es überschneidet sich außerdem mit Search-APIs, denn /search liefert Seiteninhalt neben den Ergebnis-Metadaten.

Was es ist

Interessant ist nicht, dass Firecrawl Seiten lädt. Interessant ist, dass es pro Anfrage entscheidet, wie hart es versucht: erst ein statischer Abruf, dann ein Headless-Browser, wenn die Seite einen braucht, und Proxy-Rotation, wenn das Ziel Zurückhaltung übt. Die API ist eine dünne JSON-Oberfläche über dieser Maschinerie, und das Repository trägt die ganze Engine unter AGPL-3.0.

• Endpunkte: /scrape, /crawl, /map, /search, /parse, /batch/scrape sowie die nur in der Cloud verfügbaren /interact und /agent
• Ausgabeformate: Markdown, HTML, rohe Links, Screenshots und JSON, extrahiert gegen ein Schema oder einen Prompt in natürlicher Sprache.
• Lizenz: AGPL-3.0 für die Core-Engine und die API, MIT für die SDKs.
• Abrechnungseinheit: ein Credit je Seite bei Scrape, Crawl und Map, zwei Credits je zehn Suchergebnisse, zwei Credits je Browserminute bei Interact.
• Free-Tarif: 1.000 Credits pro Monat, ohne Karte, zwei parallele Browser, zehn Anfragen pro Minute auf /scrape
• MCP: ein schlüsselloser Streamable-HTTP-Server unter https://mcp.firecrawl.dev/v2/mcp deckt Search, Scrape und Parse ab.
• Self-Hosting: die Dokumentation pinnt Release v2.11.162 und liefert die API mit Docker Compose auf Port 3002.

Wie es funktioniert

Jede Seite durchläuft denselben Pfad, unabhängig vom Endpunkt, und genau das macht Crawl billig zu durchdenken: was Scrape kann, kann Crawl auf jeder erreichten Seite. Die Stufen unten sind die dokumentierten, plus der Abrechnungsschritt, der die Rechnung entscheidet.

Zwei Konsequenzen folgen aus dieser Form. Erstens ist /crawl derselbe Codepfad wie /scrape mit einer Warteschlange davor, ein Crawl-Job erbt also jedes Scrape-Verhalten, auch das, um niemand gebeten hat. Zweitens wird der Credit gutgeschrieben, wenn eine Seite erzeugt wird, nicht wenn sie nützlich ist, und genau dort beißt das Kostenmodell.

Der Anbieter veröffentlicht einen eigenen Scrape-Benchmark, gefahren am 13. Januar 2026 über 1.000 öffentliche URLs aus zehn Kategorien, bewertet danach, ob das Werkzeug den Kerntext der Seite geliefert hat. Die Zahlen verdienen eine genaue Lektüre, denn die Erfolgsdefinition ist großzügig.

Eine Seite gilt als abgedeckt, sobald mindestens 10 Prozent des erwarteten Inhalts zurückkommen, die 96 Prozent sind also eine Aussage darüber, dass nicht nichts geliefert wurde, nicht darüber, dass das Richtige geliefert wurde. Der F1 von 0,638 ist die ehrliche Zahl, und sie bedeutet, dass im Schnitt rund ein Drittel des extrahierten Inhalts einer Seite falsch oder fehlend ist. Das reicht für einen Korpus, der ohnehin noch chunked, eingebettet und gefiltert wird; es reicht nicht für eine Pipeline, die den exakten Wert aus einer Tabelle braucht.

Erste Schritte

Das Python-SDK verpackt Job-Queue, Paging und Polling, womit das kürzest nützliche Snippet auch dasjenige ist, das die Fehler-Buchhaltung versteckt. Das Beispiel unten crawlt eine kleine Dokumentationsmenge und fragt danach die API direkt, welche Seiten sie nie geholt hat.

import os
import time

import requests
from firecrawl import Firecrawl

key = os.environ["FIRECRAWL_API_KEY"]
app = Firecrawl(api_key=key)

job = app.start_crawl(
    "https://docs.example.com",
    limit=100,                                # the default is 10000 pages
    scrape_options={"formats": ["markdown"], "only_main_content": True},
)

# poll until a terminal status: completed, failed or cancelled
while True:
    status = app.get_crawl_status(job.id)
    if status.status in ("completed", "failed", "cancelled"):
        break
    time.sleep(5)

print(len(status.data), "pages scraped")

# completed == total does not mean every page arrived
res = requests.get(
    f"https://api.firecrawl.dev/v2/crawl/{job.id}/errors",
    headers={"Authorization": f"Bearer {key}"},
).json()

for page in res.get("errors", []):
    print("failed:", page["url"], page["error"])

print("robots-blocked:", len(res.get("robotsBlocked", [])))

Zwei Details in diesem Aufruf sind wichtiger, als sie aussehen. Das Crawl-Limit steht standardmäßig auf 10.000 Seiten, und der Endpunkt lehnt den Job mit einem 402 ab, wenn das verbleibende Guthaben das verlangte Limit nicht deckt; das Weglassen des Standards auf einem Testkonto führt also schnell zu gar nichts. Und only_main_content entfernt Navigation und Fußzeilen; ohne diesen Schalter zahlt man für Boilerplate und bettet sie gleich mit ein.

Selbst betreiben

Der Core ist unter AGPL-3.0 quelloffen, was doppelt zählt: Er ist prüfbar, und eine modifizierte über das Netz ausgelieferte Version schuldet ihrem Nutzer den Quelltext. Der Standard-Compose-Stack startet die API auf Port 3002 mit einer PostgreSQL-Queue, Redis und einem Playwright-Service, und die Dokumentation pinnt ein verifiziertes Release, statt dem Hauptbranch zu folgen.

• Standardmäßig enthalten: die Routen für Scrape, Crawl, Map und Search, mit Fetch- und Playwright-Verarbeitung.
• Braucht einen anzubindenden Provider: LLM-gestützte Extraktion und JSON-Formate verlangen einen OpenAI-kompatiblen Endpunkt oder Ollama.
• Nicht im Standard-Stack: der Anti-Bot-Dienst fire-engine, Screenshots und Seitenaktionen.
• Nur in der Cloud: Agent, Browser, Interact, das Dashboard und die Enterprise-Kontrollen.
• Nicht produktionsreif, wie ausgeliefert: Der Quickstart läuft ohne Authentifizierung und ohne dauerhafte Volumes.

Preise

Alles wird gegen ein einziges Credit-Guthaben abgerechnet. Die Sätze sind auf jedem Plan identisch, was die Kostenvorhersage zu einer Seitenzahlfrage statt zu einer Stufenfrage macht; nur die Limits wandern.

Die Stückökonomie ist einfach genug, um sie nachzurechnen. Ein Hobby-Plan für $16 im Monat kauft 5.000 Seiten, rund $0,003 je Seite für die ersten 5.000 und danach $5 je zusätzliche 1.000 Credits. Drei Dinge brechen diese Rechnung. Die Formate JSON, Question und Highlight kosten 4 Credits je Seite obendrauf. Interact rechnet 2 Credits je Browserminute ab statt je Seite. Und eine Seite, die mit 403 oder 404 antwortet, wird trotzdem zurückgegeben und trotzdem mit 1 Credit berechnet; eine Website voller Soft-404s ist also eine echte Rechnung und kein Rundungsfehler.

Wo es passt und wo nicht

Die Schwächen zuerst. Die Crawl-Abrechnung kann nicht sagen, ob ein Lauf sauber war: Der Zähler total summiert completed, active, queued und backlogged und lässt Fehlschläge weg, completed gleich total gilt bei einem beendeten Job also unabhängig davon, ob Seiten verloren gingen, und nur der Crawl-Errors-Endpunkt benennt sie. Auch die Discovery ist nicht deterministisch, weil Seiten nebenläufer geholt werden und die Linkreihenfolge dem Netzwerktiming folgt. Auf der Suchseite führt Firecrawl nach eigener Benchmark-Seite bei Multi-Hop-Discovery mit einem F1 von 30,4 Prozent auf Platz zwölf von sechzehn Konfigurationen, landet bei Such-Only-Coding-Tickets dagegen auf Platz zwei. Es ist ein starker Fetcher mit anhängendem Suchprodukt, kein starkes Suchprodukt.

Der Vergleich ist nicht wie für wie, und der Unterschied der Art ist der nützliche Teil. Firecrawl und Browserbase verkaufen beide ein Fetch-Ergebnis. Apify verkauft Compute plus einen Marktplatz. Scrapy und Playwright verkaufen nichts und kosten nur Aufmerksamkeit. Für ein festes Ingestions-Ziel mit stabiler HTML-Struktur bleibt ein selbst betriebener Crawler auch pro Seite günstiger als alle anderen, denn die Grenzkosten sind ein Core und eine Queue statt eines Credits.

Dazu kommt die Lock-in-Frage. In der Firecrawl Cloud liegen die guten Teile: fire-engine, Screenshots, Seitenaktionen, Interact und Agent sind allesamt als Cloud-Funktionen dokumentiert. Self-Hosting liefert die Core-Engine unter AGPL-3.0 und wenig mehr, was schmaler ist, als die Popularität des Repositorys vermuten lässt.

Urteil

Firecrawl verdient eine Übernahme für das Ingestions-Problem und Abstand beim Such-Problem. Eine Extraktions-F1 von 0,638 ist hinnehmbar, genau weil Chunking und Retrieval einen Teil des Extraktionsfehlers schlucken, das Credit-Modell planbar ist und der Betrieb einer Browser-Flotte, eines Proxy-Pools und einer Sperrschicht echte Arbeit ist, die die meisten Produktteams nicht auf sich nehmen sollten. Die Gegenrede ist schmal, aber scharf: Wenn Seiteninhalt exakt sein muss oder wenn Egress und Datenstandort die eigentliche Randbedingung sind, kauft man mit Credits das Falsche.

1. Nimm es, wenn ein Produkt jetzt Web-Inhalt braucht und die Zielseiten gewöhnliches HTML oder Dokumentation sind.
2. Nimm es für Agent- und MCP-Integrationen. Der schlüssellose Streamable-HTTP-Server und die CLI-Skills sind der kürzeste Weg von einem Agenten zu einer lesbaren Seite.
3. Nutze den Free-Tarif, um herauszufinden, ob die Extraktionsqualität zum eigenen Korpus passt. 1.000 Credits pro Monat reichen dafür.
4. Nimm es nicht als Search-API. Auf dem eigenen Multi-Hop-Benchmark der Firma steht es nahe am Ende des Feldes, und es rechnet pro Ergebnis ab.
5. Nimm es nicht für exakte Extraktion aus Tabellen, Filings oder Preisen. Budgete eine Verifikationsrunde ein oder nimm eine Quelle, die strukturierte Daten liefert.

Firecrawl versteht man am besten als Rendering-Dienst mit angehängter JSON-API. Alles, was man aus Playwright und einem Proxy-Abonnement gebaut hätte, sollte man jetzt pro Seite kaufen. Alles, was man aus einer Sitemap und einem Scheduler gebaut hätte, baut man weiterhin selbst.

Quellen

1. Firecrawl-Preise — Credit-Sätze, Plan-Limits, Rollover und Pay-as-you-go-Regeln, gültig ab 4. September 2026
2. Firecrawl-Crawl-Dokumentation — Statuszähler, Paging-Vertrag, der Errors-Endpunkt und die Crawl-Konfigurationsreferenz
3. Firecrawl-Self-Hosting-Guide — das gepinnte Release, der Compose-Stack und die Lücken im Standard-Build
4. Open Source oder Firecrawl Cloud — welche Fähigkeiten zu welchem Betriebsmodell gehören
5. Firecrawl-Benchmarks — der Scrape-Lauf vom Januar 2026 und die externen Suchstudien, die Firecrawl zitiert
6. Apify-Preise — Compute Units, Proxy-Tarife und Prepaid-Nutzung für die Vergleichstabelle
7. Browserbase-Preise — Browserstunden sowie Fetch- und Search-Aufrufe für die Vergleichstabelle