Crawl4AI rulează un browser real ca să genereze Markdown — și nu, nu îți repară selectorii singur

Circulă de ceva vreme un mit despre Crawl4AI: că ar avea nu știu ce inteligență adaptivă, un fel de creier care se repară singur și îți găsește din nou datele când un site își reorganizează HTML-ul. Nu e așa. Asta e alt instrument (Scrapling, dacă ești curios). Crawl4AI e ceva mai concret — și mai util de înțeles pe scurt: un browser fără interfață, legat de un convertor Markdown, cu un extractor CSS/XPath pe lângă.

Am trecut instrumentul prin teste pe pagini statice, cataloage randate cu JavaScript, o pagină 500 construită intenționat și un mic deep crawl. Nucleul lui e cu adevărat bun. Părțile pe care mulți le trec cu vederea — greutatea instalării, comportamentul la deep crawl, un mesaj de eroare înșelător — sunt exact ce analizează restul acestui review. Tot ce urmează este provizoriu, bazat pe testele pe care chiar le-am rulat, nu pe un benchmark final. O să precizez și ce n-am testat, ca să nu mă citeze nimeni pentru lucruri la care n-am umblat.

Ce este, de fapt, Crawl4AI (și mitul pe care nu îl confirmă)

Dacă dai la o parte textele de prezentare, Crawl4AI este, în esență, trei lucruri puse unul peste altul.

Mai întâi, un browser real. Sub capotă folosește Playwright, plus o variantă modificată pentru stealth numită Patchright, ca să încarce o pagină așa cum ar face Chrome — rulând JavaScript, construind DOM-ul, așteptând conținutul dacă îi ceri asta. Asta e partea importantă. Nu este un client HTTP care descarcă HTML brut și gata. Pornește un motor real de randare.

Apoi, un generator de Markdown. După ce pagina este randată, Crawl4AI convertește DOM-ul în Markdown, formatul pe care îl „mănâncă” foarte bine LLM-urile și pipeline-urile RAG. Autorii îl poziționează exact din acest motiv ca un crawler prietenos cu LLM-urile: îi dai un URL, primești text pe care un model îl poate analiza.

În al treilea rând, un extractor structurat. Dacă vrei JSON curat, nu proză, îi dai o schemă — selectori CSS sau XPath mapați la nume de câmpuri — prin JsonCssExtractionStrategy, iar el returnează înregistrări. (Există și o cale de extracție bazată pe LLM, dar aceea are nevoie de API key și n-am testat-o, deci n-o să pretind că știu exact cum se comportă.)

Iată partea care contează și pe care zvonul despre „inteligența adaptivă” o încurcă: schema aceea este statică și o scrii manual. Îi spui lui Crawl4AI că numele produsului stă în .product-card h3 și prețul în .price, iar dacă site-ul schimbă mâine acele clase, selectorii tăi se strică și rămân stricați. Nimic nu se auto-repară. Nu există reconectare fuzzy. Este un browser, un convertor și niște selectori pe care îi întreții — nici mai mult, nici mai puțin. Dacă înțelegi asta de la început, nu mai aștepți o funcție care de fapt există într-un alt repo.

Primitivii cu care lucrezi efectiv au nume suficient de clare: AsyncWebCrawler este motorul, BrowserConfig setează browserul, iar CrawlerRunConfig controlează o rulare individuală (inclusiv wait_for, la care revin imediat). Este o API Python async-first, care devine foarte lizibilă după ce te prinzi de nomenclatură.

Repo-ul, pentru context, avea 71.259 de stele, 7.326 de fork-uri și licență Apache-2.0 la data de 2026-07-07 (unclecode/crawl4ai), pe release-ul v0.9.0. Numărul de stele se schimbă, deci tratează-l ca pe o captură de moment, nu ca pe o valoare live — dar îți spune clar că proiectul este folosit intens, are licențiere permisivă și nu e un experiment de weekend.

Instalarea: partea în care îți apar două stack-uri complete de browser pe disc

Instalarea este momentul în care Crawl4AI încetează să se comporte ca o bibliotecă ușoară — și e partea pe care aproape niciun articol nu o menționează.

pip install nu ridică probleme. pip install -U crawl4ai s-a terminat curat — și, notabil, s-a instalat pe Python 3.14.2, deși documentația cere oficial >=3.10 și pe mașina mea nu exista niciun runtime 3.10–3.13. Semn bun pentru cine lucrează pe un interpreter foarte nou.

Apoi rulezi crawl4ai-setup, iar aici începe să se umple discul.

Pasul de setup nu descarcă un singur browser. Descarcă două stack-uri complete — Playwright și Patchright — iar logul de instalare arată că mai aduce în plus Chrome for Testing, FFmpeg și un Headless Shell. Acesta e prețul unui instrument bazat pe browser real: browserele trebuie să locuiască undeva, iar aici stau pe mașina ta, de două ori. Dacă lucrezi pe un laptop cu SSD mic sau construiești un container slim unde fiecare megabyte contează, trebuie să planifici asta. Nu este footprint-ul unui parser HTTP pur și nu va fi niciodată.

În favoarea lui, tooling-ul este sincer despre propria stare de sănătate. crawl4ai-doctor a rulat, a trecut și a făcut crawl pe https://crawl4ai.com în 14,65 secunde ca să demonstreze că fluxul browserului funcționează cap-coadă. Un command doctor integrat care chiar randază o pagină live e o idee bună — înseamnă că întrebarea „mi-a mers instalarea?” are un răspuns real, nu o ridicare din umeri.

Verdictul la instalare e, deci, împărțit: partea de Python e lină și indulgentă, partea de browser e grea. Ambele lucruri sunt adevărate simultan, și merită să le știi înainte să te angajezi.

Practic: ce a mers bine, cu cifrele reale

Am construit un site local de test cu adevăr cunoscut — produse statice, produse randate cu JS, un articol cu boilerplate intenționat, o pagină 500 stricată și un mic graf de linkuri — apoi am pus Crawl4AI la lucru pe acel set plus două site-uri demo publice. Iată rezultatul.

Pagini statice: victorie completă. Quickstart-ul oficial pe example.com a returnat Markdown în 1,81s. Pe catalogul meu static local, Markdown-ul a păstrat toate cele 6/6 nume de produse așteptate, iar extracția pe schemă CSS a scos toate cele 6 înregistrări JSON — nume, categorie, preț, rating și URL-ul detaliilor, fiecare câmp intact. Nicio dramă.

Pagini dinamice: la fel de bine, dacă îi spui corect ce să aștepte. Aici stă avertismentul important. Pe catalogul meu randat cu JS, adăugarea wait_for="css:.product-card" în config-ul de rulare a dus la 8/8 produse recuperate atât în Markdown, cât și în extracția pe schemă. Pe pagina publică quotes.toscrape.com/js, a randat citatele injectate de JavaScript și a salvat o captură de ecran utilă drept dovadă că browserul chiar a desenat conținutul. Cuvântul „dinamic” aici nu e marketing — browserul chiar randază. Dar trebuie să-i spui la ce să aștepte. Dacă sari peste wait_for, obții o pagină pe jumătate construită.

Batch: rezistă. arun_many() peste șase URL-uri locale de produs a revenit cu 6/6, toate 200, într-o singură trecere concurentă. E un eșantion mic, dar calea de concurrency și-a făcut treaba.

Volum de Markdown de pe site real. Pe homepage-ul public Books to Scrape, Crawl4AI a generat 13.476 de caractere de Markdown dintr-o pagină live, într-un singur apel — o măsură concretă a cât text pregătit pentru LLM poate scoate o singură rulare dintr-un catalog real.

Acum partea cu muchiile aspre — lucrurile care apar doar când treci dincolo de traseul fericit.

Markdown-ul brut este larg, prin design. Pe articolul meu de test, Crawl4AI a prins titlul și toate cele 3/3 paragrafe din body — dar și textul din navigație, blocul de linkuri înrudite, o linie falsă de abonare și footer-ul. Nu e un defect; asta înseamnă conversia brută în Markdown. Întreaga pagină randată devine Markdown, inclusiv boilerplate-ul. Dacă vrei un articol cu adevărat curat, răspunsul din documentație este să activezi un filtru de conținut — PruningContentFilter punctează nodurile după densitatea text/link și elimină zgomotul, iar BM25ContentFilter prioritizează în raport cu o interogare. N-am rulat acești filtri în acest test, deci nu le pun un scor de curățenie — dar modelul mental e clar: Markdown-ul brut e setarea largă implicită, Markdown-ul curat e un filtru pe care îl activezi. Nu te aștepta la output editorial din varianta fără configurare.

Pagina 500 a spus o mică minciună. I-am dat lui Crawl4AI o pagină stricată intenționat, care returnează HTTP 500. A raportat corect success=false și status 500 — dar mesajul de eroare spunea „Blocked by anti-bot protection: Structural: minimal_text on small page.” Nu exista niciun zid anti-bot. Era o pagină de eroare mică, cu foarte puțin text vizibil, iar euristica structurală a lui Crawl4AI a văzut corpul subțire și a sărit la eticheta anti-bot. Lecția pentru cine rulează asta la scară: nu te baza pe formularea „anti-bot” la prima vedere. Uită-te la codul de status și la contextul real înainte să conchizi că site-ul se luptă cu tine. Uneori e doar o pagină mică.

Deep crawl nu preia automat așteptările tale. Asta e descoperirea pe care chiar aș vrea s-o știu înainte să leg un crawl. Un crawl direct al paginii dinamice cu wait_for a mers perfect — 8/8. Dar când am lăsat crawlerul BFS pentru deep crawling să descopere linkuri din homepage și să le urmeze, a găsit 5 pagini, a reușit pe 3 și a eșuat pe 2. Una dintre eșecuri a fost chiar acel catalog dinamic — pagina care merge perfect cu așteptare explicită. În deep crawl a văzut 45 de caractere de text pre-randare, a decis că pagina e prea subțire și a renunțat cu același mesaj înșelător „anti-bot” înainte ca JavaScript-ul să termine de rulat.

Lecția este exactă: „Crawl4AI suportă pagini dinamice” este adevărat, iar „un deep crawl așteaptă automat fiecare pagină dinamică pe care o descoperă” nu este. Sunt două funcții documentate separat — așteptări per pagină și strategii de deep crawl — și nu se combină singure. Dacă deep crawl-ul tău trebuie să acopere pagini grele în JS, trebuie să configurezi așteptarea în mod deliberat. Este o realitate de configurare, nu un bug, dar sigur te va lovi dacă presupui că traseul fericit se scalează intact pe linkurile descoperite.

Pro și contra, fără ocolișuri

Unde își merită stelele:

• O singură bibliotecă acoperă mult teren: Markdown randat, extracție JSON structurată, capturi de ecran, crawl în batch și deep crawl, fără să legi patru unelte între ele.
• Extracția statică este impecabilă — 6/6 recall în Markdown și 6/6 înregistrări structurate în testele mele, rapid și fără pierderi.
• Randarea dinamică chiar funcționează pentru că randarea e făcută de un browser real — 8/8 cu wait explicit, confirmat cu screenshot.
• Licență Apache-2.0, prietenoasă pentru uz comercial, și un proiect activ, ajuns la v0.9.0, cu o comunitate mare în spate.
• crawl4ai-doctor integrat, care randază o pagină reală ca să-ți confirme că instalarea chiar funcționează.

Unde te costă:

• Setup inițial greu: două stack-uri de browser plus FFmpeg și un Headless Shell pe disc. Fricțiune reală pe mașini constrânse.
• Markdown-ul brut include boilerplate dacă nu activezi un filtru de conținut — calea curată este un pas intenționat, nu implicit.
• Deep crawling nu aplică automat așteptările tale pentru paginile dinamice; paginile JS descoperite în timpul crawl-ului pot eșua fără configurare suplimentară.
• Mesajele de eroare pot induce în eroare — o pagină 500 subțire a venit etichetată ca „anti-bot protection”, deși nimic nu bloca nimic.
• Nu există selectori self-healing. Schema ta CSS/XPath este statică și trebuie întreținută când se schimbă markup-ul.

Cine ar trebui să folosească Crawl4AI și cine ar trebui să-l ocolească

Folosește-l dacă ești developer și construiești un pipeline RAG sau agentic și vrei o singură unealtă care îți dă atât Markdown gata pentru LLM, cât și JSON structurat din aceeași pagină randată. Dacă țintele tale sunt intensive în JavaScript și ești confortabil să scrii waits explicite, iar rularea unui browser real fără interfață pe propria infrastructură nu te deranjează, Crawl4AI este o potrivire solidă, bine întreținută. Combinația Markdown-pentru-model plus schemă-pentru-bază de date, într-o singură bibliotecă Apache-2.0, chiar e convenabilă.

Treci mai departe dacă vrei un parser HTTP ușor, care ia HTML static în milisecunde, fără browser — Crawl4AI este în mod deliberat mai greu decât atât, iar descărcările de browser singure te vor enerva. Treci peste el dacă ai spațiu pe disc sau bandă de internet limitate, ori dacă deploy-ul merge într-un container minimal unde două stack-uri de browser sunt un dealbreaker. Și, categoric, treci peste el dacă ai venit după selectori self-healing — asta chiar e o funcție reală, doar că nu a acestui instrument.

Unde se potrivește un API gestionat — unghiul Thunderbit

Încearcă Thunderbit pentru extragerea datelor web

Tot ce am spus mai sus pornește de la ideea că vrei să rulezi browserul singur. E o alegere legitimă și, pentru multe echipe, chiar cea potrivită — control total, cost zero per apel, cod pe care îl deții cap-coadă. Dar merită să numim clar compromisul pe care îl faci, pentru că la Thunderbit am construit stack-ul pentru developeri în jurul compromisului opus: să scoatem de pe mașina ta browserul, gestionarea anti-bot și randarea JavaScript.

Paralela este suficient de apropiată ca să merite comparația. Endpoint-ul nostru POST /distill face ce face calea Markdown din Crawl4AI — pagină intrată, Markdown curat, pregătit pentru LLM, ieșit — doar că randarea JS și stratul anti-bot rulează la noi, nu într-un browser pe care l-ai instalat tu. Endpoint-ul POST /extract acoperă partea structurată, returnând JSON pe baza unei scheme definite de tine, cu un switch renderMode (none, basic, full) în loc de un wait_for ajustat manual. Ambele au și variante batch. Există și un server MCP — thunderbit_distill, thunderbit_extract și un thunderbit_suggest_fields gratuit — astfel încât un agent din Claude sau Cursor îl poate apela direct, plus npx @thunderbit/thunderbit-cli pentru terminal, CI și cron.

Diferența se reduce la cine duce greutatea. Crawl4AI este gratuit, open-source și self-hosted, iar tu porți povara operațională — descărcările de browser, wiring-ul pentru deep crawl, mașina pe care rulează totul. Stack-ul nostru pentru developeri este un API gestionat, unde greutatea asta este problema noastră, iar costul se mută către utilizarea per apel. Niciuna nu e universal mai bună. Dacă vrei să controlezi fiecare strat și să nu plătești nimic per request, rulează Crawl4AI. Dacă preferi să scapi de povara operațiunilor de browser și să chemi un endpoint, ruta gestionată are sens. Același motor care stă în spatele extensiei noastre cu peste 100.000 de utilizatori alimentează și API-ul, deci nu vorbim despre un nivel de jucărie.

Dacă te uiți la categoria mai largă, materialele noastre despre AI web scraping și scraperele open-source de GitHub testate cap la cap merg mai departe decât pot eu aici fără să transform articolul în altceva.

Verdict: merită să folosești Crawl4AI?

Da — dacă ești developer și vrei Markdown pregătit pentru LLM și JSON structurat din aceeași pagină randată, construiești pentru RAG sau agenți și accepți un browser real fără interfață pe infrastructura ta. În testele mele, nucleul a făcut exact ce promite: 6/6 pe extracție statică, 8/8 pe pagini dinamice cu wait explicit, 13.476 de caractere de Markdown dintr-un catalog live și crawl în batch fără probleme. Este o unealtă solidă, cu licență bună, întreținută activ, care chiar lucrează.

Intră cu ochii deschiși în privința a trei lucruri și vei fi bine: instalarea îți pune două stack-uri de browser pe disc, deep crawl-ul nu așteaptă automat paginile dinamice pe care le descoperă, iar o pagină de eroare subțire poate purta o etichetă înșelătoare de „anti-bot”. Niciunul dintre acestea nu e un dealbreaker. Toate sunt însă diferența dintre a aștepta un miracol și a folosi un instrument real — care, repet, este un browser, un convertor Markdown și niște selectori pe care îi întreții. Dacă îl înțelegi așa, este una dintre cele mai bune metode de a transforma pagini live în text pe care un model îl poate folosi.

Aceasta este o evaluare provizorie, bazată pe o singură rundă de testare. Nu l-am stresat cu un crawl de o mie de pagini, n-am rulat filtrele de conținut, n-am atins calea de extracție LLM și nici modul server Docker. Consideră scorul meu mental ca fiind „puternic, dar cu teme rămase” și nu o notă finală — și verifică din nou numărul de stele și versiunea înainte să citezi oricare dintre metadate, pentru că ambele se schimbă.

Încearcă Thunderbit pentru extragerea datelor web Get Started Free

Întrebări frecvente

Are Crawl4AI selectori self-healing sau adaptivi? Nu. Aceasta este cea mai frecventă confuzie despre el. Crawl4AI folosește scheme CSS/XPath statice, pe care le scrii și le întreții tu — dacă un site redenumește clasele de care depind selectorii tăi, extracția se rupe până corectezi schema. Selectoarele adaptive, care se relocalizează singure, sunt o funcție a altui instrument (Scrapling), nu a lui Crawl4AI.

Am nevoie de un browser complet ca să rulez Crawl4AI? Practic, da. Valoarea lui principală este randarea JavaScriptului cu un browser real, așa că crawl4ai-setup descarcă două stack-uri de browser (Playwright și Patchright) plus FFmpeg și un Headless Shell. Dacă vrei un parser minuscul, doar HTTP, fără footprint de browser, Crawl4AI nu este forma potrivită și ar fi mai bine să alegi un framework mai ușor.

De ce a spus Crawl4AI „anti-bot protection” pe o pagină care nu era blocată? Euristica lui structurală marchează paginile cu foarte puțin text vizibil, iar mesajul pe care îl emite menționează protecția anti-bot. În testul meu, o pagină 500 deliberat creată, cu aproape niciun conținut, a primit această etichetă, deși nimic nu bloca cererea. Verifică întotdeauna codul de status și contextul real înainte să concluzionezi că un site se opune activ — uneori e doar o pagină subțire sau stricată.

Deep crawl-ul din Crawl4AI tratează automat paginile JavaScript? Nu de la sine. Un crawl direct cu wait_for explicit a tratat perfect pagina mea dinamică la 8/8, dar deep crawl-ul BFS care a descoperit aceeași pagină a eșuat — 5 pagini găsite, 3 reușite, 2 eșecuri — pentru că nu a așteptat randarea JavaScriptului înainte să decidă că pagina e prea subțire. Dacă deep crawl-ul tău trebuie să acopere pagini dinamice, trebuie să configurezi deliberat așteptarea.

Cum diferă Crawl4AI de un API gestionat de scraping, cum e Thunderbit? Crawl4AI este gratuit, open-source și self-hosted — tu rulezi și întreții browserul și infrastructura, fără cost per apel. Stack-ul pentru developeri de la Thunderbit (/distill pentru Markdown, /extract pentru JSON structurat, plus MCP și CLI) este un API gestionat, unde randarea, stratul anti-bot și operațiunile de browser rulează la noi, iar tu plătești per utilizare. Compromisul este control total și cost zero per request versus externalizarea poverii operaționale.