> A Firecrawl egy hosztolt API-jal URL-ekből tiszta Markdownot csinál. Mennyibe kerül, hol hibázik a crawl-számlázás, és mikor érdemes saját AGPL-magját futtatni. > > Web page: https://balazscsorba.com/hu/blog/firecrawl · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/firecrawl.md) · [Deutsch](https://balazscsorba.com/de/blog/firecrawl.md) > Author: Balázs Csorba · Published: 2026-08-25 · Keywords: firecrawl, firecrawl vs apify, firecrawl alternative, web scraping api for llm, firecrawl self-hosting, markdown scraper api [Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés # Firecrawl: webkúszó API RAG pipeline-okhoz, értékeléssel A Firecrawl egy hosztolt API-jal URL-ekből tiszta Markdownot csinál. Mennyibe kerül, hol hibázik a crawl-számlázás, és mikor érdemes saját AGPL-magját futtatni. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. augusztus 25.·10 perc olvasás - Web scraping - RAG ingestion - Crawling - MCP - AGPL ![Széles lap három kis négyzettel alatta, és egy tálca rendezett lappal.](https://balazscsorba.com/images/blog/firecrawl/cover.webp?v=cc8d0a7926) ## A lényeg röviden - A Firecrawl saját scrape benchmarkje 96%-os lefedettséget, de csak 0,638 F1-et ad: egy oldal tartalmának körülbelül harmada hibás vagy hiányzik. - Egy credit egy oldalra jut scrape, crawl és map esetén; a JSON, Question és Highlight formátum oldalanként további 4 credit. - A befejezett crawl, ahol a completed megegyezik a total értékkel, nem árulja el a hibákat; csak a crawl errors végpont nevezi meg az elveszett oldalakat. - Az AGPL-3.0 licenc alatt futtatható stack a scrape, crawl, map és search műveleteket fedi le; a képernyőképek, az oldalműveletek, a fire-engine, az Agent és az Interact a Cloudon marad. - A crawl feladatok 24 órán át lekérdezhetők, és a Scale csomag alatt a credit nem rolloverezik, így a betöltési állapothoz és a kiadásokhoz is kell keret. Ezen az oldalon 1. [Mi ez](https://balazscsorba.com/#what-it-is) 2. [Hogyan működik](https://balazscsorba.com/#how-it-works) 3. [Első lépések](https://balazscsorba.com/#getting-started) 4. [Saját szerveren](https://balazscsorba.com/#self-hosting) 5. [Árak](https://balazscsorba.com/#pricing) 6. [Hol illik és hol nem](https://balazscsorba.com/#where-it-fits) 7. [Ítélet](https://balazscsorba.com/#verdict) 8. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 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. ![A Firecrawl oldal-pipeline és a creditek elszámolása Négy lépés halad balról jobbra: letöltés, renderelés, kivonatolás és visszaadás. Az első két lépés alatt egy doboz jelöli a feloldási utat: először statikus letöltés, és headless böngésző, ha az oldalnak kell. Egy második doboz jelöli az elszámolást: egy credit minden visszaadott oldal után, plusz négy credit a JSON kimeneti formátumért. Alatta három sor rögzíti, hogy a crawl oldalanként ugyanezt az utat járja be, hogy a hibás oldalak kiesnek a data tömbből és csak a crawl errors végpont jelzi őket, és hogy a 403 vagy 404 választ adó céloldal is egy creditbe kerül.](https://balazscsorba.com/images/blog/firecrawl/diagram-7.webp?v=5719d4fef3) Egyetlen scrape út minden végponton, a credit a végén esedékes. 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ű. Metrika Firecrawl eredmény Adathalmaz 1.000 nyilvános URL tíz kategóriából Lefedettség, sikerarány 96% Kivonatolási pontosság, F1 0,638 Tartalmi visszakeresés 0,639 Késleltetés, P95 3.387 ms 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. **A crawl eredményei lejárnak** A feladat eredményei a crawl befejezése után 24 órán át kérdezhetők le az API-ról. Utána csak a tevékenységi napló marad, így mindent, aminek egy elbukott downstream feladaton át kell élnie, ebben az ablakban kell tartós tárolásba írni. ## 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. **Hol húzódik a licenc határa** A repository AGPL-3.0 alatt áll, az SDK-k viszont MIT alatt, ami szokatlan helyre teszi a határt: a klienskönyvtár megengedő, a futtatott szolgáltatás nem. Aki egy termék részeként egy módosított deploymentet fontolgat, olvassa el a 13. szakaszt, mielőtt feltételezi, hogy a megengedő SDK bármit is engedne. ## Á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. Csomag Havi credit Párhuzamos böngészők Rate limit a /scrape, /map és /search végponton Free 1.000 2 10 / perc Hobby, évente $16 5.000 5 100 / perc Standard, évente $83 100.000 25 500 / perc Growth, évente $333 500.000 50 5.000 / perc Scale, évente $599 1.000.000 100 10.000 / perc 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. **Két számlázási alapérték, amit érdemes átírni** A fel nem használt credit a Hobby, Standard és Growth csomagokban nem rolloverezik, tehát egy kihasználatlan hónap elveszett pénz, nem tartalék. A pay-as-you-go pedig 5 dolláros lépésekkel tölti fel az egyenleget a regisztrált kártyán, ha nincs havi limit beállítva, és ez a különbség a meglepetés és a könyvelési tétel között. ## 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. Eszköz Mit ad el Számlázási egység Miben nyer Firecrawl Egy API a scrape, crawl, map, search és parse műveletekhez, Markdownot ad vissza Credit oldalanként Tiszta Markdown, alig kell utómunka Apify Automatizálási platform: Actorok, adathalmazok, proxyk, ütemezés Számítási egység, egy CU egy óra alatt 1 GB, plusz proxyk és tárhely Szabálytalan oldalak, amelyek saját kódot vagy proxyválasztást igényelnek Browserbase Menedzselt böngésző-munkamenetek plusz Fetch és Search API Böngészőórák, $0,12 óránként a Developer csomagban az első 100 után Interaktív folyamatok: belépés, kattintási útvonalak, állapottartó munkamenetek Scrapy és Playwright Könyvtárak, amelyeket saját magad futtatsz, a teljes pipeline a kezedben Saját infrastruktúra és saját idő Kiszámítható költség nagy volumen mellett, és nincs szállító a körben 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](https://www.firecrawl.dev/pricing) — 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ó](https://docs.firecrawl.dev/features/crawl) — 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ó](https://docs.firecrawl.dev/contributing/self-host) — a rögzített release, a Compose stack és az alap build hiányzó képességei 4. [Open source vagy Firecrawl Cloud](https://docs.firecrawl.dev/contributing/open-source-or-cloud) — mely képességek melyik működési modellhez tartoznak 5. [Firecrawl benchmarkok](https://www.firecrawl.dev/benchmarks) — a 2026. januári scrape futás és a hivatkozott harmadik fél keresési vizsgálatai 6. [Apify árazás](https://apify.com/pricing) — 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](https://www.browserbase.com/pricing) — böngészőórák, valamint Fetch és Search hívási díjak az összehasonlító táblához ## Gyakori kérdések Mennyibe kerül egy dokumentációs oldal crawlolása Firecrawl-lal? Egy credit jut egy oldalra scrape, crawl és map esetén, tehát egy 500 oldalas crawl 500 credit. A Hobby csomag éves számlázással havi 16 dollár 5.000 credit, a Standard 83 dollár 100.000 credit. A JSON, Question és Highlight formátum oldalanként további 4 credit, a pay-as-you-go pedig 5 dolláros lépésekkel tölti fel az egyenleget. Elég pontos-e a Firecrawl RAG-hez? A Firecrawl saját benchmarkja 2026. január 13-án futott 1.000 nyilvános URL-en, és 96%-os lefedettséget meg 0,638 F1-et jelent. Egy oldal már 10% várható tartalom visszaérkezése esetén lefedettnek számít, ezért az F1-et érdemes olvasni, nem a lefedettségi számot. Ez a pontosság jó egy chunkolt, beágyazott korpuszhoz, de túl alacsony táblákból származó pontos értékekhez. Futtatható-e a Firecrawl saját szerveren? Igen. A core engine és az API AGPL-3.0 licenc alatt áll, és a self-hosting útmutató Docker Compose-szal indítja a 3002-es porton, egy ellenőrzött release-t pinel a fő branch helyett. Az alap stack a fetch és a Playwright feldolgozással együtt fedi le a scrape, crawl, map és search műveleteket. A képernyőképek, az oldalműveletek, a fire-engine, az Agent és az Interact Cloud funkciók. Honnan tudom, mely oldalaknak sikerült elbuknia egy crawlnak? A státuszszámlálókból nem. A total mező a completed, active, queued és backlogged oldalakat összeadja, és kihagyja a hibákat, így egy befejezett jobon a completed megegyezik a total értékkel, függetlenül attól, hogy estek-e ki oldalak. A crawl errors végpont errors és robotsBlocked tömbjei mondják meg, melyek azok. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026) - [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking) - [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions) - [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)