Kolem Crawl4AI se pořád drží jeden rozšířený mýtus: že má jakousi adaptivní inteligenci, samoopravný mozek, který si po změně HTML na webu znovu najde vaše data. Nemá. To je jiný nástroj (pokud vás zajímá, jmenuje se Scrapling). Crawl4AI je něco mnohem konkrétnějšího a mnohem užitečnějšího, když se popíše napřímo: headless prohlížeč připojený ke konvertoru do Markdownu, s CSS/XPath extraktorem navíc.
V rámci testů jsem ho prověřil na statických stránkách, katalozích renderovaných přes JavaScript, záměrně rozbité stránce s kódem 500 a menším deep crawl výletem. Jádro je opravdu dobré. To, co lidé často přehlížejí — náročnější instalace, chování při deep crawl, jedna zavádějící chybová hláška — je přesně to, čím se zabývá zbytek téhle recenze. Všechno níže je předběžné a vychází jen z testů, které jsem skutečně spustil, ne z finálního benchmarku. U každé věci, kterou jsem netestoval, to výslovně zmíním, aby mi nikdo nepřipisoval závěry z oblastí, kterých jsem se ani nedotkl.
Co Crawl4AI ve skutečnosti je (a mýtus, který to není)
Když odhodíte marketing, Crawl4AI jsou ve skutečnosti tři vrstvy naskládané na sobě.
Zaprvé, skutečný prohlížeč. Uvnitř používá Playwright, plus upravenou stealth verzi zvanou Patchright, aby načetl stránku stejně jako Chrome — spustí JavaScript, vytvoří DOM a počká na obsah, pokud mu to řeknete. A to je ten důležitý bod. Není to HTTP klient, který jen stáhne syrové HTML a tím skončí. Spouští reálný renderovací engine.
Zadruhé, generátor Markdownu. Jakmile se stránka vyrenderuje, Crawl4AI převede DOM do Markdownu — přesně do formátu, který chtějí LLM a RAG pipeline. Autoři projekt prezentují jako crawler přátelský pro LLM právě proto: pošlete URL a dostanete text, nad kterým model dokáže uvažovat.
Zatřetí, strukturovaný extraktor. Pokud nechcete souvislý text, ale čisté JSON, předáte mu schéma — CSS nebo XPath selektory namapované na názvy polí — přes JsonCssExtractionStrategy a vrátí vám záznamy. (Existuje i cesta založená na LLM, ale ta vyžaduje API klíč a já ji netestoval, takže nebudu předstírat, že vím, jak se chová.)
A tady je ta část, na které záleží a kterou pověst o „adaptivní inteligenci“ zásadně míjí: to schéma je statické a píšete ho ručně. Řeknete Crawl4AI, že název produktu je v .product-card h3 a cena v .price, a pokud web zítra přejmenuje tyhle třídy, selektory se rozbijí a rozbité zůstanou. Nic se samo neopraví. Žádné fuzzy přemapování tu není. Je to prohlížeč, konvertor a selektory, které si spravujete vy — nic víc, nic míň. Když to víte dopředu, nečekáte funkci, která žije v úplně jiném repozitáři.
Primitiva, se kterými skutečně pracujete, mají rozumné názvy: AsyncWebCrawler je engine, BrowserConfig nastavuje prohlížeč a CrawlerRunConfig řídí jeden běh (včetně wait_for, k němuž se ještě vrátím). Je to async-first Python API, které je po pochopení názvů docela čitelné.
Repozitář má k datu 2026-07-07 mimochodem 71 259 hvězdiček, 7 326 forků a licenci Apache-2.0 (unclecode/crawl4ai), na release v0.9.0. Počty hvězdiček se mění, takže to berte jako snímek, ne živý stav — ale ukazuje to, že jde o hodně používaný projekt s permisivní licencí, ne o víkendový experiment.
Instalace: část, kdy vám na disk přistanou dva celé browser stacky
Instalace je místo, kde Crawl4AI přestává působit jako lehká knihovna, a je to také věc, kterou téměř žádný popis nezmiňuje.
Samotný pip install proběhl bez potíží. pip install -U crawl4ai doběhl čistě — a důležité je, že fungoval i na Pythonu 3.14.2, přestože dokumentace oficiálně požaduje >=3.10 a na mém stroji žádný runtime 3.10–3.13 neležel. To je dobré znamení pro každého, kdo jede na nejnovější verzi interpreteru.
Pak ale spustíte crawl4ai-setup a právě tam se začne plnit disk.
Instalační krok nestáhne jeden prohlížeč. Stáhne dva celé stacky — Playwright a Patchright — a log navíc ukazuje, že se stahuje Chrome for Testing, FFmpeg i Headless Shell. To je cena za nástroj, který opravdu používá prohlížeč: browsery někde žít musí, a tady žijí u vás na stroji, dokonce dvakrát. Pokud máte notebook s malým SSD nebo stavíte minimalistický container image, kde záleží na každém megabytu, počítejte s tím. To není footprint čistého HTTP parseru a nikdy nebude.
K jeho cti je tooling upřímný i o vlastním zdraví. crawl4ai-doctor proběhl, prošel a v 14,65 sekundách prolezl https://crawl4ai.com, aby dokázal, že browserová cesta funguje od začátku do konce. Vestavěný doktor, který skutečně vyrenderuje živou stránku, je příjemný detail — znamená to, že na otázku „instalace funguje?“ dostanete skutečnou odpověď, ne jen pokrčení rameny.
Verdikt k instalaci je tedy dvojí: Python vrstva je hladká a odpouštějící, browser vrstva je těžká. Obě věci platí současně a je dobré o nich vědět dřív, než se rozhodnete.
Praktické testy: co obstálo a jaká jsou čísla
Postavil jsem si lokální testovací web s jasně známou pravdou — statické produkty, produkty renderované přes JS, článek s úmyslným boilerplate, rozbitou 500 stránku a malý odkazový graf — a pak jsem na něj i na dvě veřejné demo stránky Crawl4AI nasměroval. Tady je výsledková tabule.
Statické stránky: naprostý úspěch. Oficiální quickstart proti example.com vrátil Markdown za 1,81 s. Na mém lokálním statickém katalogu Markdown zachoval všech 6/6 očekávaných názvů produktů a CSS schéma vytáhlo všech 6 záznamů jako JSON — název, kategorii, cenu, hodnocení i detailní URL, všechny položky bez ztráty. Bez problémů.
Dynamické stránky: také bez problémů, když to řeknete správně. Tohle je zásadní podmínka. U mého JS renderovaného katalogu přidání wait_for="css:.product-card" do run configu dalo 8/8 úspěšnost při načítání produktů jak v Markdownu, tak při schema extrakci. Na veřejné stránce quotes.toscrape.com/js se úspěšně vyrenderovaly citace vložené JavaScriptem a uložil se použitelný screenshot jako důkaz, že prohlížeč obsah opravdu skutečně vykreslil. Slovo „dynamický“ tady není jen marketing — browser opravdu renderuje. Ale musíte mu říct, na co má čekat. Když wait_for vynecháte, berete si rozpracovanou stránku.
Dávkové zpracování: drží. arun_many() přes šest lokálních URL produktů vrátilo 6/6, všechno 200, v jednom souběžném průchodu. Je to malý vzorek, ale paralelní cesta fungovala přesně tak, jak slibuje.
Objem Markdownu z reálného webu. Na veřejné domovské stránce Books to Scrape vygeneroval Crawl4AI z živé stránky jedním voláním 13 476 znaků Markdownu — dobrá představa o tom, kolik textu připraveného pro LLM dostanete z jedné reálné crawl operace.
A teď hrany a nedodělky — věci, které se ukážou až ve chvíli, kdy přestanete jet po hladké cestě.
Syrový Markdown je záměrně široký. Na mém testovacím článku Crawl4AI vzal titul a všechny 3/3 odstavce těla — ale také text navigace, blok s related odkazy, falešnou subscribe řádku i patičku. To není chyba; přesně to znamená konverze do raw Markdownu. Celá vyrenderovaná stránka se promění do Markdownu, včetně boilerplate. Pokud chcete opravdu čistý článek, dokumentovaná odpověď je zapnout content filter — PruningContentFilter hodnotí uzly podle poměru textu k odkazům a zahazuje bordel, BM25ContentFilter řadí podle dotazu. Tyto filtry jsem v tomto běhu nespouštěl, takže jim nepřiřazuji žádné číslo čistoty — ale mentální model je jasný: raw Markdown je široký výchozí stav, čistý Markdown je filtr, který si zapnete. Od zero-config cesty nečekejte redakční kvalitu.
Stránka 500 řekla malou lež. Do Crawl4AI jsem poslal záměrně rozbitou stránku vracející HTTP 500. Správně nahlásil success=false a status 500 — ale chybová zpráva zněla „Blocked by anti-bot protection: Structural: minimal_text on small page.“ Žádná anti-bot bariéra tam nebyla. Byla to drobná chybová stránka s téměř nulovým obsahem a strukturální heuristika si z tenkého těla vyvodila antiboťácký závěr. Poučení pro kohokoli, kdo to bude provozovat ve větším měřítku: nevěřte nápisu „anti-bot“ doslova. Nejdřív zkontrolujte status code a skutečný kontext, a teprve pak vyvozujte, že vás web aktivně blokuje. Někdy je to jen malá stránka.
Deep crawl nepřebírá vaše čekání. Tohle je zjištění, které bych chtěl znát ještě před zapojením crawl procesu do produkce. Přímý crawl mé dynamické stránky s wait_for fungoval bezchybně — 8/8. Ale když jsem nechal BFS deep crawler objevit odkazy z homepage a následně je sledovat, našel 5 stránek, 3 dokončil úspěšně a 2 selhaly. Jedním z pádů byla právě ta samá dynamická katalogová stránka — ta, která při explicitním čekání funguje bez problému. V deep crawl režimu viděl jen 45 znaků před-render textu, vyhodnotil stránku jako příliš tenkou a skončil se stejnou zavádějící hláškou o „anti-bot protection“ ještě předtím, než JavaScript doběhl.
Poučení je přesné: tvrzení „Crawl4AI podporuje dynamické stránky“ je pravdivé, ale „deep crawl automaticky počká na každou dynamickou stránku, kterou najde“ už ne. Jde o dvě oddělené zdokumentované funkce — čekání na úrovni stránky a strategie deep crawl — a samy se do sebe nespojí. Pokud má váš deep crawl zvládat JS-heavy stránky, musíte čekání do konfigurace zapojit záměrně. Je to realita nastavení, ne bug, ale velmi snadno se na tom spálíte, když předpokládáte, že to bude fungovat stejně jako na přímé URL.
Klady a zápory, bez vykrucování
Kde si zaslouží hvězdy:
- Jedna knihovna pokrývá hodně: vyrenderovaný Markdown, strukturovanou JSON extrakci, screenshoty, batch crawling i deep crawling, bez slepování čtyř různých nástrojů.
- Statická extrakce je naprosto spolehlivá — v mých testech 6/6 úspěšnost u Markdownu i 6/6 u strukturovaných záznamů, rychle a bez ztrát.
- Dynamické renderování skutečně funguje, protože rendering dělá skutečný browser — 8/8 s explicitním čekáním, ověřeno screenshotem.
- Licence Apache-2.0, tedy přívětivá pro komerční použití, a aktivně vyvíjený projekt (v0.9.0) s velkou komunitou za zády.
- Vestavěný
crawl4ai-doctor, který vyrenderuje skutečnou stránku a potvrdí, že instalace opravdu běží.
Kde vás to něco stojí:
- Těžká první instalace: dva browser stacky navíc, FFmpeg a Headless Shell na disku. Na omezených strojích je to znatelná zátěž.
- Syrový Markdown obsahuje boilerplate, pokud nezapnete content filter — čistá cesta je vědomý krok, ne výchozí stav.
- Deep crawling automaticky nepoužije vaše čekání pro dynamické stránky; JS stránky objevené v průběhu crawl mohou bez další konfigurace selhat.
- Chybové hlášky umí mást — tenká 500 stránka se mi vrátila s popiskem „anti-bot protection“, i když nic neblokovalo.
- Žádné samoopravné selektory. Vaše CSS/XPath schéma je statické a po změně markup struktury je na vás ho udržovat.
Pro koho je Crawl4AI a kdo by se mu měl vyhnout
Použijte ho, pokud jste vývojář a stavíte RAG nebo agent pipeline a chcete jeden nástroj, který vám ze stejné vyrenderované stránky vrátí jak Markdown připravený pro LLM, tak strukturovaný JSON. Pokud jsou vaše cíle JavaScript-heavy a nevadí vám psát explicitní waity, a zároveň vám nevadí provozovat skutečný headless browser na vlastní infrastruktuře, Crawl4AI je silná a dobře udržovaná volba. Kombinace „Markdown pro model“ plus „schéma pro databázi“ v jedné knihovně s licencí Apache-2.0 je opravdu praktická.
Přeskočte ho, pokud chcete lehký HTTP parser, který stáhne statické HTML během milisekund bez browseru — Crawl4AI je záměrně těžší a samotné stahování browserů vás bude štvát. Přeskočte ho, pokud máte málo místa na disku nebo bandwidth, nebo nasazujete do minimalistického kontejneru, kde jsou dva browser stacky přes čáru. A rozhodně ho přeskočte, pokud jste hledali samoopravné selektory — to je skutečná funkce, jen ne této knihovny.
Kde dává smysl řízené API — pohled Thunderbit
Vyzkoušet Thunderbit pro extrakci webových dat
Všechno výše předpokládá, že si browser chcete provozovat sami. To je legitimní volba a pro spoustu týmů i správná — maximální kontrola, nulový poplatek za jednotlivé volání, kód, který máte celý pod sebou. Ale stojí za to pojmenovat kompromis, který tím děláte, protože my v Thunderbit jsme náš vývojářský stack postavili na opačném rozhodnutí: nechat browser, anti-bot vrstvy i JavaScript rendering mimo váš stroj.
Paralela je dost blízká na to, aby šla férově porovnat. Naše POST /distill dělá totéž co Markdown cesta v Crawl4AI — stránka dovnitř, čistý Markdown připravený pro LLM ven — jenže JS rendering i anti-bot vrstva běží na naší straně, ne v browseru, který jste si instalovali. Naše POST /extract pokrývá strukturovanou část a vrací JSON podle schématu, které si definujete, s přepínačem renderMode (none, basic, full) místo wait_for, který ladíte ručně. Obě cesty mají i dávkové varianty. K dispozici je také MCP server — thunderbit_distill, thunderbit_extract a zdarma thunderbit_suggest_fields — takže ho může volat agent v Claude nebo Cursoru přímo, plus npx @thunderbit/thunderbit-cli pro terminál, CI a cron.
Ten rozdíl je hlavně v tom, kdo nese tíhu. Crawl4AI je zdarma, open-source a self-hosted, a provozní zátěž je na vás — stažené browsery, deep-crawl zapojení, stroj, na kterém to celé běží. Náš dev stack je řízené API, kde je tahle tíha náš problém a cena se přesouvá na usage per call. Ani jedna varianta není univerzálně lepší. Pokud chcete vlastnit každou vrstvu a neplatit za request, běžte do Crawl4AI. Pokud byste raději odstranili starosti s browser provozem a jen volali endpoint, to je argument pro řízenou cestu. Stejný engine, který pohání naše rozšíření s více než 100 000 uživateli, stojí i za API, takže to není žádná hračkářská úroveň.
Pokud zvažujete širší kategorii, naše vlastní články o AI web scrapingu a o open-source GitHub scrapers, které jsme testovali proti sobě, jdou mnohem hlouběji, než se sem vejde, aniž by se z toho stal úplně jiný text.
Verdikt: máte Crawl4AI používat?
Ano — pokud jste vývojář, který chce ze stejné vyrenderované stránky dostat Markdown připravený pro LLM i strukturovaný JSON, stavíte pro RAG nebo agenty a nevadí vám skutečný headless browser na vlastní infrastruktuře. V mých testech jádro dělalo přesně to, co slibuje: 6/6 u statické extrakce, 8/8 u dynamických stránek s explicitním čekáním, 13 476 znaků Markdownu z živého katalogu a čisté batch crawling. Je to solidní, dobře licencovaný a aktivně udržovaný nástroj, který dělá reálnou práci.
Jen do něj vstupte s otevřenýma očima ve třech věcech: instalace vám na disk přidá dva browser stacky, deep crawl nebude automaticky čekat na dynamické stránky, které objevíte, a tenká chybová stránka může nést zavádějící štítek „anti-bot“. Nic z toho není zásadní překážka. Všechno dohromady ale rozhoduje o tom, jestli čekáte zázrak, nebo používáte skutečný nástroj — který je, znovu, browser, konvertor do Markdownu a selektory, které spravujete vy. Když ho pochopíte takhle, je to jeden z lepších způsobů, jak převést živé weby na text, který může model skutečně používat.
Tahle recenze je zatím předběžná a stojí na jednom testovacím běhu. Neprošel jsem ho tisícistránkovým crawl testem, nespustil content filtry, nezkoušel LLM extrakci ani Docker server mode. Výsledek berte spíš jako „silný, ale s domácím úkolem“, ne jako finální známku — a než budete citovat metadata, znovu si ověřte počet hvězdiček i verzi, protože oboje se mění.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
Často kladené otázky
Má Crawl4AI samoopravné nebo adaptivní selektory? Ne. To je nejčastější omyl. Crawl4AI používá statická CSS/XPath schémata, která si píšete a udržujete sami — pokud web přejmenuje třídy, na kterých vaše selektory závisí, extrakce přestane fungovat, dokud schéma neopravíte. Adaptivní, samo se přesouvající selektory jsou funkcí jiného nástroje (Scrapling), ne Crawl4AI.
Potřebuji k běhu Crawl4AI plnohodnotný browser?
Prakticky ano. Jeho hlavní hodnota je v renderování JavaScriptu ve skutečném browseru, takže crawl4ai-setup stáhne dva browser stacky (Playwright a Patchright) plus FFmpeg a Headless Shell. Pokud chcete malý HTTP-only parser bez browserové stopy, Crawl4AI je špatný tvar a budete chtít lehčí framework.
Proč Crawl4AI u stránky bez blokace napsal „anti-bot protection“? Jeho strukturální heuristika označuje stránky s velmi malým množstvím viditelného textu a zpráva, kterou vypisuje, zmiňuje anti-bot ochranu. V mém testu dostala takový štítek záměrně rozbitá HTTP 500 stránka s téměř nulovým obsahem, i když nic neblokovalo požadavek. Než usoudíte, že vás web skutečně aktivně brzdí, vždycky si zkontrolujte status code i reálný kontext — někdy je to jen tenká nebo rozbitá stránka.
Zvládá deep crawl v Crawl4AI automaticky JavaScriptové stránky?
Ne sám od sebe. Přímý crawl s explicitním wait_for zvládl moji dynamickou stránku na 8/8, ale BFS deep crawl, který stejnou stránku objevil, na ní selhal — našel 5 stránek, 3 prošly a 2 spadly — protože před vyhodnocením stránky jako příliš tenké nepočkal na dokončení JavaScriptu. Pokud má váš deep crawl pokrývat dynamické stránky, musíte čekání nakonfigurovat záměrně.
Jak se Crawl4AI liší od řízeného scraping API, jako je Thunderbit?
Crawl4AI je zdarma, open-source a self-hosted — browser i infrastrukturu provozujete a udržujete sami a neplatíte za jednotlivé volání. Vývojářský stack Thunderbit (/distill pro Markdown, /extract pro strukturovaný JSON, plus MCP a CLI) je řízené API, kde rendering, anti-bot handling a provoz browseru běží na naší straně a vy platíte za použití. Rozdíl je mezi plnou kontrolou a nulovou cenou za request na jedné straně a přenesením provozní zátěže na druhé.
