Otestoval jsem Crawl4AI na pěti typech stránek — tady vyniká a tady naráží

Některé srovnávací texty třetích stran připisují Crawl4AI „adaptivní inteligenci“ — tedy selektory, které se prý naučí strukturu webu a po změnách v HTML se samy opraví. V testovaném API jsem nic takového nenašel. Crawl4AI ve skutečnosti nabízí generování Markdownu nad prohlížečem a také extrakci přes CSS/XPath. Scrapling má samostatnou funkci adaptivních selektorů, ovšem s omezeními popsanými v jeho vlastní recenzi.

Nasadil jsem Crawl4AI ve verzi 0.9.0 na pět typů stránek se známou „ground truth“: statický katalog, katalog renderovaný v JavaScriptu, článek s balastním obsahem, záměrný error 500 a propojený více stránkový graf. Otestované cesty pro Markdown i schéma vrátily očekávaný fixture obsah. Surový Markdown si ale ponechal boilerplate, hluboké procházení potřebovalo specifické čekání na danou stránku a běžná chyba 500 dostala štítek připomínající anti-bot ochranu.

Co Crawl4AI ve skutečnosti je

Začněme tím, co si při instalaci lidé nejčastěji vyloží špatně. Crawl4AI není malý Python parser. První příkaz crawl4ai-setup tiše stáhne dva celé browser stacky — Playwright i Patchright — a jakmile tohle víte, celý nástroj začne dávat smysl: jde o řízený headless prohlížeč s konverzí do Markdownu navrchu, jen oblečený do kabátu scraperského nástroje.

Oficiálně jde o open-source knihovnu s licencí Apache-2.0 pro převod webových stránek do Markdownu pro RAG pipeline, agenty a datové workflow. Testoval jsem v0.9.0. Mezi její základní stavební kameny patří AsyncWebCrawler, BrowserConfig, CrawlerRunConfig, generování Markdownu a extrakční strategie založené na CSS/XPath nebo LLM, podle oficiálního quick startu.

Důležitý mentální model je tento: většina parsovacích knihoven pošle HTTP požadavek a zpracuje vrácená data; Crawl4AI ovládá skutečný prohlížeč. Renderování je součástí balíku, což z instalace dělá těžší krok než u čistého HTTP parseru, a spolehlivá extrakce z asynchronně vykreslovaných prvků může stále vyžadovat explicitní čekání. Nic z toho, co jsem testoval, po redesignu nepřepisovalo selektory. Tvrzení o self-healing berte jako chybu v porovnání třetí strany, dokud nepřijde konkrétní oficiální zdroj a reprodukovatelné API.

Klíčové funkce a jak fungují pod kapotou

Jádrem je jednoznačně jednopage cesta. Zadáte AsyncWebCrawler URL, on stránku načte v prohlížeči a vrátí Markdown. Na oficiálním quickstartu s example.com trval tento round-trip 1,81 sekundy a vrátil čistý status 200. Nic okázalého, ale potvrzuje to, že základní scénář funguje téměř bez konfigurace — bez schématu, bez čekání, bez nastavení browseru.

Video tutorial (1:02:38): Crawl4AI Official Tutorial, Full 1hr with Quickstart Examples.

Druhým pilířem je strukturovaná extrakce, a to je také nejbližší věc k tomu, co Crawl4AI „rozumí“ stránce — přesněji řečeno, ne inferenci, ale vámi zadanému schématu. Místo pouhého dumpu Markdownu mu předáte CSS schéma přes JsonCssExtractionStrategy a dostanete JSON objekty s přesně těmi poli, která jste definovali. Na mém lokálním statickém katalogu vrátil 6 čistých JSON záznamů — název produktu, kategorie, cenu, hodnocení, URL detailu — a sedělo to na všech 6 očekávaných produktech. To je rozdíl mezi „tady je stránka jako text“ a „tady jsou data po řádcích“, a Crawl4AI zvládá obojí ze stejného crawl. Selektory si ale musíte definovat sami; nástroj bere to, co mu dáte, schéma za vás nevymýšlí.

Dynamické renderování je místo, kde se výhoda browser backendu ukáže naplno. Když jsem ho namířil na katalog renderovaný v JavaScriptu s wait_for="css:.product-card", počkal, až doběhne klientské renderování, a teprve pak data vytáhl. Na mém lokálním JS fixture to vedlo k 8/8 záchytu produktů v Markdownu i ve výstupu podle schématu, a to zhruba za 1,56 sekundy. Na veřejné stránce Quotes to Scrape JS page zachytil vykreslené citáty a uložil použitelný screenshot — obsah, který by prostý HTTP požadavek nikdy neviděl, protože v úvodním HTML prostě není co parsovat.

Pak je tu škálování a crawling. arun_many() spustilo šest lokálních detailních stránek paralelně s plným 6/6 záchytem za 3,76 sekundy. A Crawl4AI dodává i strategie hlubokého crawl — BFS, DFS, BestFirst — které procházejí graf odkazů s limity hloubky, počtem stránek, filtrováním a skórováním. BFS deep crawl prošel graf odkazů na mém fixture homepage a stáhl pět stránek. Tady se začíná oddělovat marketing od reality, a hned se k tomu dostanu.

Instalace: ta část, kterou nikdo nedá do úvodu README

Instalace na mém stroji byla v jednom směru hladší, v jiném těžší, než jsem čekal. pip install -U crawl4ai a smoke test proběhly úspěšně na Pythonu 3.14.2 na macOS arm64. Specifikace >=3.10 na PyPI už 3.14 zahrnuje; tenhle výsledek potvrzuje jen testovanou instalaci a workflow, ne širší kompatibilitu.

Skutečný třecí bod je krok setupu. crawl4ai-setup stáhne browser assets pro Playwright i Patchright — Chrome for Testing, FFmpeg a Headless Shell. Pokud máte notebook s omezeným diskem nebo připojení s datovým limitem, je to reálná cena a dokumentace to zmiňuje spíš mimochodem než hned na začátku. crawl4ai-doctor pak prošel a prolezl crawl4ai.com za 14,65 sekundy, což je fajn end-to-end smoke test, ale ne benchmark výkonu — z téhle hodnoty bych rychlost nevyvozoval.

Poučení pro vlastní evaluaci: počítejte s downloadem browseru, ne jen s instalací přes pip. Je to blíž nasazení headless browser prostředí než přidání knihovny do skriptu. Na disk se před prvním reálným crawl uloží dva browser stacky, a to je jednorázový náklad, který zaplatíte bez ohledu na to, jestli vaše workload někdy vůbec využije stealth vrstvu Patchrightu.

Praktický test: co drželo a co bych označil

Čtyři výsledky stojí za to zapsat si pečlivě, protože přesně takové nuance marketingová stránka obvykle uhladí — a v jednom případě i špatně pojmenuje.

Dvě veřejné demo stránky také dopadly dobře. Na domovské stránce Books to Scrape vytvořil Crawl4AI za 2,43 sekundy 13 476 znaků Markdownu. Veřejná stránka Quotes JS vrátila 1 666 znaků vykresleného Markdownu asi za 3,1 sekundy. Ani jedno ale nevypovídá o škále, nepřátelských webech, dlouhodobé stabilitě, session, proxy, retry ani paměťovém chování.

Fixture článku odhaluje jeden háček kvality Markdownu. Crawl4AI zachytil nadpis a všechny 3/3 odstavce těla článku — to je dobře. Surový Markdown ale zároveň ponechal text navigace, související odkazy, řádek o odběru i patičku. To není chyba; bez content filtru nebo cílového selektoru totiž „převést stránku do Markdownu“ znamená poctivě celou stránku. Poučení je rozlišovat mezi surovou konverzí do Markdownu a čistou extrakcí článku. Pokud chcete to druhé, použijete content filter jako PruningContentFilter nebo target selector — ty jsem ale zatím netestoval dostatečně, takže si nebudu vymýšlet žádné číslo čistoty.

Rozbitá stránka byla nejpoučnější výsledek. Na záměrně servírovanou HTTP 500 s malým tělem Crawl4AI vrátil success=false a status 500 — správně — ale chybovou zprávu formuloval jako „Blocked by anti-bot protection: Structural: minimal_text on small page.“ Žádná anti-bot bariéra tam nebyla. Šlo o malou chybovou stránku. Strukturální heuristika Crawl4AI viděla velmi málo viditelného textu a sáhla po vysvětlení typu anti-bot. Pro každého, kdo na tom staví, je to důležité: neberte štítek „anti-bot“ doslova. Nejdřív zkontrolujte status code a skutečnou odpověď, než usoudíte, že vás web blokuje. Surový výsledek je v repozitáři benchmarku na results/local_failure_500.json.

Deep crawling potřebuje záměrnou konfiguraci. Přímý dynamický crawl s wait_for fungoval čistě, zatímco BFS deep crawl sice dynamický katalog našel, ale skončil neúspěchem. Klasifikace jako minimal-text odpovídá tomu, že se načetlo dřív, než se vykreslily karty, a deep crawl nepřevzal čekání z přímé cesty. Z pěti stránek tři uspěly a dvě selhaly. Protože tu není ukázané opakované spuštění s nastaveným waitingem, zůstává tahle diagnóza odhadem, ne prokázanou příčinou.

Kam vycházejí čísla

Tohle jsou časy ze smoke testů, ne výkonový benchmark: článek neuvádí hardware, počet opakování, stav warm/cold, cache, řízení concurrency ani varianci. Ukazují jen to, že se uvedené workflow na tomhle stroji dokončilo. Kompletní artefakty běhu jsou v adresáři benchmark repozitáře.

Pro seriózní výkonový test opakujte každý workflow v čerstvých i znovupoužitých browser sessions, uvádějte rozdělení hodnot místo jedné desetinné čárky, připínejte verze browserů a zaznamenávejte CPU, paměť, stav cache i concurrency. To by oddělilo režii knihovny od startu browseru a síťových odchylek.

Pro a proti

Klady:

• Jedna knihovna zvládne surový Markdown i strukturovaný JSON podle CSS schématu — nemusíte slepovat dva nástroje.
• Renderování v prohlížeči je vestavěné; asynchronně renderované cíle mohou potřebovat explicitní wait_for.
• Testované jednopage workflow se dokončily v uvedených časech; žádné srovnávací tvrzení o rychlosti tím ale nedělám.
• Licence Apache-2.0 — příznivá pro komerční použití, bez copyleft překvapení.
• Aktivní projekt s nedávnou verzí a velkou, angažovanou komunitou.

Zápory:

• Těžší prvotní setup (dva browser stacky), který úvod trochu podává lehčeji, než je.
• Surový Markdown obsahuje boilerplate, pokud nenastavíte content filtry.
• Deep crawling si na dynamické stránky nepohlídá čekání automaticky — musíte ho nastavit pro každý crawl, jinak přijdou chyby.
• Chybové hlášky mohou obyčejnou chybu označit jako „anti-bot“, což je v logách matoucí.
• Žádné samoadaptivní selektory, a to navzdory tomu, co naznačují některá srovnání — schémata jsou ručně psaná a statická.
• Browser prostředí provozujete a udržujete sami, včetně aktualizací a případných rozbití.

Pro koho je — a kdo by se mu měl vyhnout

Crawl4AI má smysl zvažovat, pokud jste vývojář a stavíte RAG nebo agentní pipeline, nevadí vám provoz headless browser prostředí a chcete z jednoho crawl získat Markdown i strukturovaný JSON. Testy nepokrývaly odolnost vůči nepřátelským webům, dlouhodobou stabilitu, paměť, sessions, retry, proxy ani produkční nasazení, takže doporučení platí jen pro workflow, která jsem tu skutečně vyzkoušel.

Přeskočte ho — nebo se alespoň zastavte — pokud jste hledali malý HTTP parser s minimem závislostí (to je přesný opak), pokud si nemůžete dovolit disk a bandwidth na download browserů nebo pokud nechcete v produkci nést údržbu browser stacku. A přeskočte ho hlavně tehdy, pokud jste přišli kvůli self-healing selektorům: tohle ten nástroj není a workflow postavený na funkci, kterou nemá, vás později doběhne. Pro čistou extrakci textu článků se strženým boilerplate může lépe posloužit lehčí nástroj určený přímo na tenhle úkol.

Alternativy, včetně toho, kde dává smysl Thunderbit

Upřímné vymezení: Crawl4AI je bezplatná open-source knihovna, kterou si hostujete a udržujete sami. Dostanete plnou kontrolu a žádný poplatek za používání od dodavatele, ale pořád platíte za compute, bandwidth, storage, aktualizace browserů, schémata i provozní práci.

Na opačné straně stojí spravovaná scraping služba, jako je Thunderbit, kde fetch i extrakce běží přes API. Thunderbit jsem na těchto fixturech netestoval, takže tento článek netvrdí nic srovnatelného o renderování, anti-bot ochraně, CAPTCHAs, přesnosti ani rychlosti. Relevantní je tu provozní vlastnictví: buď self-hostujete knihovnu s browser backendem, nebo platíte službu, která tu vrstvu provozuje za vás.

Rozdíl je v tom, kdo spouští prohlížeč. S Crawl4AI vlastníte renderování, čekání, schémata i údržbu. U spravovaného API platíte za volání a část provozní odpovědnosti přesouváte na poskytovatele. Tento experiment oba přístupy výsledkově nesrovnával.

Související benchmark recenze: kompletní srovnání open-source scraperů, recenze self-hosted varianty Firecrawl a recenze extrakce článků v trafilatura.

Vyzkoušejte Thunderbit pro extrakci webových dat

Verdikt

Crawl4AI je rozumný kandidát, pokud chcete open-source extrakci nad prohlížečem, která vrací Markdown i JSON ve struktuře podle schématu, a jste připraveni se postarat o browser prostředí. Přímé statické workflow i dynamické workflow s čekáním v těchto fixturech uspěly. Licence Apache-2.0 je vstřícná, i když běžná kontrola závislostí a distribuce stále platí.

Počítejte s náklady na browser assets. Surový Markdown potřebuje filtr, než se dá použít jako čistý článek. U deep crawl je nutné čekání nastavit záměrně a log se slovem „anti-bot“ je potřeba ověřit proti status code a odpovědi. Selektory schématu jsou pořád vaše starost. To jsou testované hranice rozhodnutí; produkční škála a chování na nepřátelských webech zůstávají otevřené otázky.

Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free

Časté dotazy

Má Crawl4AI adaptivní nebo samouzdravující selektory? Ne. Navzdory tomu, co mu některá srovnání přisuzují jako „adaptive intelligence“, Crawl4AI porovnává CSS/XPath schéma, které sami napíšete — nefingerprintuje elementy ani je po změně HTML znovu nenahledává. V testu strukturovaná extrakce dosáhla 6/6 a 8/8 recallu se schématy, která jsem definoval ručně. Když se na webu změní třídy, vaše schéma se rozbije, dokud ho neaktualizujete. Samozacelující sledování elementů je funkce jiné knihovny, ne této.

Proč je instalace tak velká? crawl4ai-setup stahuje kompletní browser assets pro Playwright i Patchright — Chrome for Testing, FFmpeg a Headless Shell. To je daň za skutečné renderování v prohlížeči. Počítejte s diskem i bandwidth; je to těžší než čistý HTTP parser a zaplatíte to i tehdy, když váš workload stealth stack nikdy nepoužije.

Umí Crawl4AI stránky renderované v JavaScriptu? Ano, protože ovládá skutečný headless browser. V testu dynamický katalog s wait_for="css:.product-card" vrátil plný 8/8 recall produktů a veřejná stránka Quotes JS se vykreslila bez problému. Háček je v tom, že deep crawl to čekání na nově objevené stránky automaticky nepoužije — BFS crawl na dynamické stránce selhal, protože nečekal. Čekání nastavujete sami, pro každý crawl zvlášť.

Dostanu z Crawl4AI čistý text článku, nebo celou stránku? Ve výchozím stavu celou stránku. V testu zachytil všechny odstavce těla, ale zároveň ponechal navigaci, související odkazy i patičku. Pro čistou extrakci článku použijete content filter (například PruningContentFilter) nebo target selector, ne samotný raw Markdown.

Můžu věřit chybovým hláškám Crawl4AI? Čtěte je s rezervou. Záměrná chybová stránka 500 s malým tělem byla označena jako „Blocked by anti-bot protection“ čistě kvůli heuristice nízkého množství viditelného textu — žádná anti-bot bariéra tam nebyla. Surový výsledek je v benchmark repozitáři. Než usoudíte, že vás web blokuje, vždycky zkontrolujte skutečný HTTP status code a body odpovědi.