Firecrawl: webkúszó API RAG pipeline-okhoz, értékeléssel

A Firecrawl hosztolt API, amely egy URL-t tiszta Markdowndá, JSON-ná vagy HTML-lé alakít, és egy crawler, amely ugyanezt egy teljes weboldalra elvégzi. Azért létezik, mert szinte minden retrieval pipeline-be végül bekerül a web, és mert egy tetszőleges oldalból nyelvi modell által olvasható szöveget készíteni böngészőautomatizálási probléma, adat tisztítási ruhában. Az ittani ítélet: a legjobb alapértelmezés azoknak a csapatoknak, akik ezen a héten webes kontextust akarnak egy termékbe, és rossz választás annak, aki egresszt akar irányítani, meg akarja tartani a nyers bájtokat, vagy megabajtonként fizet oldal helyett.

A stackben a fetch réteg és az embedding réteg közé kerül. Egy vektortár soha nem látja a Firecrawl-t, csak az abból kijövő Markdownot. Erről szól az egész: a Firecrawl kevésbé versenyez egy általános scraping könyvtárral, mint a Scrapy-vel, mint a böngészőflottával, a proxy-rotációval és a blokkoló réteggel, amelyet egy csapat amúgy is össze kellene építenie ugyanahhoz a pipeline-hez. Search API-kkal is átfed, mert a /search a találati metadatok mellett oldaltartalmat is ad.

Mi ez

Nem az érdekes, hogy a Firecrawl letölti az oldalakat. Az az, hogy kérésenként eldönti, mennyire erősen próbál: először egy statikus letöltés, majd headless böngésző, ha az oldalnak kell, és proxy-rotáció, ha a cél ellenáll. Az API vékony JSON-felület e felett a gépezet felett, a repository pedig az egész engine-t AGPL-3.0 alatt hordozza.

• Végpontok: /scrape, /crawl, /map, /search, /parse, /batch/scrape, valamint a csak Cloudban lévő /interact és /agent
• Kimeneti formátumok: Markdown, HTML, nyers linkek, képernyőképek és séma vagy természetes nyelvű prompt alapján kivonatolt JSON.
• Licenc: AGPL-3.0 a core engine-re és az API-ra, MIT az SDK-kra.
• Számlázási egység: egy credit oldalanként scrape, crawl és map esetén, két credit tíz keresési találatonként, két credit böngészőpercenként az Interactben.
• Ingyenes csomag: havi 1.000 credit, kártya nélkül, két párhuzamos böngésző, tíz kérés percenként a /scrape végponton
• MCP: kulcs nélküli Streamable HTTP szerver a https://mcp.firecrawl.dev/v2/mcp címen, ami a Search, Scrape és Parse műveleteket fedi le.
• Saját szerver: a dokumentáció a v2.11.162 release-t pinneli, és Docker Compose-szal a 3002-es porton szolgálja ki az API-t.

Hogyan működik

Minden oldal ugyanazt az utat járja be, függetlenül a végponttól, és éppen ez teszi a crawlt olcsón átgondolhatóvá: amit a scrape tud, azt a crawl minden elért oldalon meg tud. Az alábbi lépések a dokumentáltak, plusz a számlázási lépés, amely eldönti a számlát.

Két következmény adódik ebből az alakból. Először a /crawl ugyanaz a kódút, mint a /scrape, csak egy várólista előtte, így egy crawl felörökli a scrape minden viselkedését, még azokat is, amelyet senki nem kért. Másodszor a credit akkor íródik le, amikor az oldal létrejön, nem amikor hasznos, és itt kezd csíkkázni a költségmodell.

A gyártó saját scrape benchmarkot publikál, 2026. január 13-án futtatva, tíz kategóriából származó 1.000 nyilvános URL-en, azt mérve, hogy az eszköz visszaadta-e az oldal szövegmagját. A számok pontos olvasást érdemelnek, mert a siker definíciója bőkezű.

Egy oldal akkor számít lefedettnek, ha a várt tartalom legalább 10%-a visszaérkezett, tehát a 96% azt állítja, hogy nem jött vissza semmi, nem azt, hogy a megfelelő jött vissza. Az F1 értéke, 0,638, az őszinte szám, és azt jelenti, hogy egy átlagos oldalon a kivonatolt tartalom körülbelül harmada hibás vagy hiányzik. Ez elég egy olyan korpuszhoz, amit amúgy is chunkolni, beágyazni és szűrni fogunk; nem elég ahhoz a pipeline-hoz, aminek egy táblából kell a pontos érték.

Első lépések

A Python SDK becsomagolja a feladatsort, a lapozást és a lekérdezést, így a legrövidebb hasznos kódrészlet egyben az is, amelyik elrejti a hibaszámlálást. Az alábbi példa egy kis dokumentációs halmazt crawlol, majd közvetlenül az API-tól kérdezi meg, mely oldalakat nem sikerült letöltenie.

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", [])))

Ebben a hívásban két részlet fontosabb, mint elsőre látszik. A crawl limitje alapértelmezés szerint 10.000 oldal, és a végpont 402 hibával utasítja el a feladatot, ha a megmaradt credit nem fedezi a kért limitet, tehát a próbafiókon bekapcsolva hagyott alapértelmezés gyorsan ahhoz vezet, hogy semmi sem történik. És a only_main_content távolítja el a navigációt és a láblécet; enélkül a sablonszöveget is fizetjük, és be is ágyazzuk.

Saját szerveren

A core AGPL-3.0 alatt nyílt forrású, ami kétszer számít: átvizsgálható, és egy hálózaton kiszolgált módosított változat a forráskódját annak is adja, aki hozzá kapcsolódik. Az alap Compose stack a 3002-es porton indítja az API-t egy PostgreSQL sorral, a Redis-szel és egy Playwright szolgáltatással, és a dokumentáció egy ellenőrzött release-t pinel a fő branch követése helyett.

• Alapértelmezés szerint benne van: a scrape, crawl, map és search útvonalak, fetch és Playwright feldolgozással.
• Külön csatlakoztatott provider kell hozzá: az LLM-alapú kivonatolás és a JSON formátumok OpenAI-kompatibilis végpontot vagy Ollamát kérnek.
• Nincs az alap stackben: a fire-engine anti-bot szolgáltatás, a képernyőképek és az oldalműveletek.
• Csak Cloudban: az Agent, a Browser, az Interact, a dashboard és az enterprise vezérlők.
• Szállításkor nem production-ready: a quickstart hitelesítés nélkül és tartós volume-ok nélkül indul.

Árak

Minden egyetlen credit-egyenlegen fut le. A díjszabás minden csomagban azonos, így a költségtervezés oldalszám kérdés lesz, nem csomagszintű kérdés; csak a limitek mozognak.

Az egységgazdaságtan elég egyszerű ahhoz, hogy utánaszámolható legyen. A havi 16 dolláros Hobby csomag 5.000 oldalt ad, ami körülbelül 0,003 dollár oldalonként az első 5.000-re, utána pedig 5 dollár minden további 1.000 credit. Három dolog töri ezt a számítást. A JSON, Question és Highlight formátumok oldalanként további 4 creditet adnak a alapdíjhoz. Az Interact böngészőpercenként 2 creditet számol, nem oldalanként. És az az oldal, amely 403 vagy 404 választ ad, visszaadásra kerül, és 1 creditet fizet; a tele 404-es oldalakból álló webhely ezért valódi számla, nem kerekítési hiba.

Hol illik és hol nem

Először a gyengeségek. A crawl számlázása nem tudja megmondani, hogy tiszta volt-e a futás: a total számláló a completed, active, queued és backlogged oldalakat összeadja, és kihagyja a hibákat, így egy befejezett feladaton a completed megegyezik a total értékkel, függetlenül attól, kiestek-e oldalak, és csak a crawl errors végpont nevezi meg őket. A felderítés sem determinisztikus, mert az oldalak párhuzamosan jönnek, és a linkek sorrendje a hálózati időzítést követi. A keresés oldalán a Firecrawl saját benchmarkoldala a többkörös felfedezésen tizenkettesik a tizenhat konfiguráció közül, 30,4-es F1-gyel, míg a csak keresésen alapuló kódolási feladatokon második. Ez erős fetcher, amihez keresőtermék van csatolva, nem erős keresőtermék.

Az összehasonlítás nem egyforma, és a különböző fajta az hasznos rész. A Firecrawl és a Browserbase is egy fetch-eredményt ad el. Az Apify számítást ad el egy piactérrel együtt. A Scrapy és a Playwright semmit nem ad el, és csak figyelmet fizet. Egy fix betöltési célhoz, stabil HTML struktúrával egy saját szerveren futtatott crawler még mindig olcsóbb oldalanként bármelyiknél, mert a határköltség egy core és egy sor ahelyett, hogy credit.

Itt van a lock-in kérdés is. A Firecrawl Cloudban vannak a jó részek: a fire-engine, a képernyőképek, az oldalműveletek, az Interact és az Agent mind Cloud funkcióként dokumentáltak. A saját szerver az AGPL-3.0 alatti core engine-t adja és keveset mást, ami szűkebb ajánlat, mint a repository népszerűsége sugallja.

Ítélet

A Firecrawl megérdemli az átvételt a betöltési problémára, és érdemes távol tartani a keresési problémától. A 0,638-as kivonatolási F1 elfogadható, éppen azért, mert a chunkelés és a visszakeresés elnyeli a kivonatolási hiba egy részét, a creditmodell kiszámítható, és egy böngészőflotta, proxykészlet és blokkoló réteg üzemeltetése valódi operatív munka, amit a legtöbb termékcsapatnak nem kellene a vállára vennie. Az ellenérv szűk, de éles: ha az oldaltartalomnak pontosnak kell lennie, vagy ha az egress és az adat helye a valódi megkötés, akkor a credit a rossz dolgot vásárolja.

1. Vedd át, ha egy terméknek most kell webes tartalom, és a céloldalak szokásos HTML-ek vagy dokumentációk.
2. Vedd át agent- és MCP-integrációhoz. A kulcs nélküli Streamable HTTP szerver és a CLI skillek a legrövidebb út egy agenttől egy olvasható oldalig.
3. Az ingyenes csomaggal nézd meg, hogy a kivonatolási minőség illik-e a korpuszodhoz. A havi 1.000 credit ehhez bőven elég.
4. Ne vetted át kereső API-ként. A cég saját többkörös benchmarkján a mező végén áll, és eredményenként számol.
5. Ne vetted át táblákból, hivatalos dokumentumokból vagy árakból való pontos kivonatolásra. Budgetálj egy ellenőrző körre, vagy használj olyan forrást, amely strukturált adatot ad.

A Firecrawl-t legjobban renderelő szolgáltatásként érdemes érteni, amelyhez JSON API van csatolva. Amit korábban Playwrightből és proxy-előfizetésből építettek volna, azt mostantól oldalanként kell megvenni. Amit sitemapből és ütemezett jobból építettek, azt továbbra is érdemes saját kezbe venni.

Források

1. Firecrawl árazás — credit díjak, csomag limitek, rollover és pay-as-you-go szabályok, 2026. szeptember 4-től érvényben
2. Firecrawl crawl dokumentáció — státuszszámlálók, lapozási szerződés, a hibavégpont és a crawl konfigurációs referencia
3. Firecrawl self-hosting útmutató — a rögzített release, a Compose stack és az alap build hiányzó képességei
4. Open source vagy Firecrawl Cloud — mely képességek melyik működési modellhez tartoznak
5. Firecrawl benchmarkok — a 2026. januári scrape futás és a hivatkozott harmadik fél keresési vizsgálatai
6. Apify árazás — számítási egységek, proxy díjak és az előre fizetett használat az összehasonlító táblához
7. Browserbase árazás — böngészőórák, valamint Fetch és Search hívási díjak az összehasonlító táblához