Er gaat hardnekkig een verhaal rond over Crawl4AI: dat het een soort adaptieve intelligentie heeft, een zelfherstellend brein dat je data opnieuw vindt zodra een site zijn HTML door elkaar gooit. Dat klopt niet. Dat is een andere tool (Scrapling, als je nieuwsgierig bent). Crawl4AI is iets concreters — en makkelijker te snappen als je het gewoon bij de naam noemt: een headless browser gekoppeld aan een Markdown-converter, met daarbovenop een CSS/XPath-extractor.
Ik heb het uitgebreid getest op statische pagina’s, JavaScript-gerenderde catalogi, een expres kapotte 500-pagina en een kleine deep crawl. De kern is echt sterk. De onderdelen waar mensen vaak overheen lezen — de zwaardere setup, gedrag bij deep crawling, één misleidende foutmelding — zijn precies waar deze review verder op ingaat. Alles hieronder is voorlopig en gebaseerd op de tests die ik daadwerkelijk heb uitgevoerd, niet op een definitieve benchmark. Ik geef ook aan wat ik níet heb getest, zodat niemand me gaat citeren over iets waar ik nooit aan gezeten heb.
Wat Crawl4AI echt is (en welke mythe het níet is)
Als je de marketingtaal wegstreept, bestaat Crawl4AI uit drie lagen boven op elkaar.
Ten eerste: een echte browser. Onder de motorkap stuurt het Playwright aan, plus een stealth-variant genaamd Patchright, om een pagina te laden zoals Chrome dat zou doen — JavaScript uitvoeren, de DOM opbouwen, wachten op content als je dat aangeeft. En dat is precies de belangrijke eigenschap. Het is geen HTTP-client die simpelweg ruwe HTML ophaalt en daar klaar mee is. Het start daadwerkelijk een render-engine.
Ten tweede: een Markdown-generator. Zodra de pagina is gerenderd, zet Crawl4AI de DOM om naar Markdown, precies het formaat waar LLM’s en RAG-pipelines graag mee werken. De makers positioneren het project daarom ook als een LLM-vriendelijke crawler: geef een URL op en je krijgt tekst terug waar een model iets mee kan.
Ten derde: een gestructureerde extractor. Wil je liever nette JSON dan lopende tekst, dan geef je een schema mee — CSS- of XPath-selectors gekoppeld aan veldnamen — via JsonCssExtractionStrategy, en dan krijg je records terug. (Er is ook een extractieroute op basis van een LLM, maar daarvoor heb je een API-key nodig en die heb ik niet getest, dus ik ga niet doen alsof ik precies weet hoe die zich gedraagt.)
En hier gaat juist dat gerucht over “adaptieve intelligentie” de mist in: dat schema is statisch en schrijf je zelf. Jij vertelt Crawl4AI dat de productnaam op .product-card h3 staat en de prijs op .price, en als de site die klassennamen morgen hernoemt, breken je selectors en blijven ze kapot. Er is geen zelfherstel, geen fuzzy matching. Het is een browser, een converter en selectors die jij onderhoudt — niet meer en niet minder. Als je dat vooraf snapt, verwacht je ook geen functie die in een andere repository leeft.
De bouwstenen waar je echt mee werkt hebben logische namen: AsyncWebCrawler is de motor, BrowserConfig zet de browser op, en CrawlerRunConfig regelt één run (inclusief de wait_for waar ik zo op terugkom). Het is een Python-API die async-first is, en eenmaal je de naming doorhebt leest het vrij prettig.
Ter referentie: de repo stond op 71.259 sterren, 7.326 forks en Apache-2.0 op 2026-07-07 (unclecode/crawl4ai), op release v0.9.0. Sterren schuiven, dus zie dit als een momentopname en niet als live data — maar het laat wel zien dat dit een veelgebruikt project is met een permissieve licentie, geen weekendexperiment.
Setup: het moment waarop twee complete browser-stacks op je schijf belanden
De installatie is het punt waarop Crawl4AI zich niet meer gedraagt als een lichte library, en het is precies het onderdeel dat bijna geen enkele review benoemt.
De pip-installatie zelf verloopt probleemloos. pip install -U crawl4ai liep netjes door — en opvallend genoeg werkte het ook op Python 3.14.2, terwijl de documentatie formeel >=3.10 vraagt en ik op mijn machine geen 3.10–3.13 runtime had staan. Goed teken voor iedereen die al met een gloednieuwe interpreter werkt.
Daarna draai je crawl4ai-setup, en dán begint de schijf vol te lopen.
De setup haalt niet één browser binnen. Hij haalt twee volledige stacks op — Playwright én Patchright — en in de setup-log zie je ook Chrome for Testing, FFmpeg en een Headless Shell meegaan. Dat is de prijs van een tool die echt een browser gebruikt: die browsers moeten ergens draaien, en hier draaien ze lokaal op je machine, dubbelop. Werk je op een laptop met beperkte SSD-ruimte of bouw je een compacte containerimage waarin elke megabyte telt, houd daar dan rekening mee. Dit is absoluut niet het oppervlak van een pure HTTP-parser, en dat wordt het ook niet.
Wel netjes: de tooling is eerlijk over zijn eigen gezondheid. crawl4ai-doctor draaide, slaagde en crawlde https://crawl4ai.com in 14,65 seconden om te bewijzen dat het browserpad van begin tot eind werkt. Een ingebouwd doctor-commando dat ook echt een live pagina rendert, is een fijne touch — het geeft een echt antwoord op “werkt mijn installatie?” in plaats van een schouderophaal.
De setupconclusie is dus gemengd: de Python-kant is soepel en vergevingsgezind, de browserkant is zwaar. Beide dingen zijn tegelijk waar, en je moet ze allebei weten voordat je instapt.
Praktijk: wat standhield, met de echte cijfers
Ik heb een lokale testsite gebouwd met bekende waarheid — statische producten, JS-gerenderde producten, een artikel met expres rommelige boilerplate, een kapotte 500-pagina en een klein linkgrafiekje — en Crawl4AI daarop plus twee publieke demo-sites losgelaten. Dit is het scorebord.
Statische pagina’s: volledig raak. De officiële quickstart tegen example.com leverde Markdown op in 1,81 s. Op mijn lokale statische catalogus behield Markdown alle verwachte productnamen, 6/6, en CSS-schema-extractie haalde ook alle 6 records als JSON binnen — naam, categorie, prijs, beoordeling en detail-URL, elk veld compleet. Geen verrassingen.
Dynamische pagina’s: ook prima, mits je het goed vraagt. En daar zit de belangrijkste nuance. Op mijn JS-gerenderde catalogus gaf het toevoegen van wait_for="css:.product-card" aan de runconfig een recall van 8/8 producten, zowel in Markdown als in schema-extractie. Op de publieke quotes.toscrape.com/js-pagina werden de via JavaScript ingeladen quotes netjes gerenderd en werd als bewijs een bruikbare screenshot opgeslagen. Het woord “dynamisch” is hier niet wishful thinking — de browser rendert echt. Maar je moet hem wel vertellen waarop hij moet wachten. Sla je wait_for over, dan trek je een half opgebouwde pagina binnen.
Batch: werkt. arun_many() over zes lokale product-URL’s kwam terug met 6/6, allemaal 200’s, in één gelijktijdige pass. Kleine steekproef, maar het concurrency-pad deed wat het belooft.
Markdown-volume van echte sites. Tegen de publieke homepage van Books to Scrape genereerde Crawl4AI 13.476 tekens Markdown uit een live pagina in één call — een concreet gevoel voor hoeveel LLM-klaar tekst één crawl uit een echte catalogus haalt.
En dan de ruwe randjes — de punten die pas zichtbaar worden zodra je verder gaat dan het happy path.
Raw Markdown is bewust breed. Op mijn artikeltest haalde Crawl4AI de titel en alle 3/3 alinea’s binnen — maar ook de navigatietekst, het blok met gerelateerde links, een nep-abonneerregel en de footer. Dat is geen fout; dat ís wat raw Markdown-conversie betekent. De hele gerenderde pagina wordt Markdown, inclusief boilerplate. Wil je een echt schoon artikel, dan is het gedocumenteerde antwoord om een contentfilter in te schakelen — PruningContentFilter scoort nodes op tekst-tegen-linkdichtheid en verwijdert rommel, BM25ContentFilter rangschikt op basis van een query. Ik heb die filters in deze ronde niet gedraaid, dus ik hang er geen schoonheidsgetal aan op — maar het mentale model is duidelijk: raw Markdown is de brede standaard, clean Markdown is een filter die je expliciet aanzet. Verwacht geen redactieklaar resultaat uit de zero-config-route.
De 500-pagina vertelde een klein leugentje. Ik gaf Crawl4AI een expres kapotte pagina die HTTP 500 teruggeeft. Het meldde netjes success=false en status 500 — maar de foutmelding luidde: "Blocked by anti-bot protection: Structural: minimal_text on small page." Er was helemaal geen anti-botmuur. Het was een kleine foutpagina met vrijwel geen zichtbare tekst, en de structurele heuristiek van Crawl4AI zag de dunne body en plakte er meteen een anti-bot-label op. De les voor iedereen die dit op schaal inzet: vertrouw de woorden “anti-bot” niet op hun letterlijke waarde. Kijk eerst naar de statuscode en de echte context voordat je concludeert dat een site je tegenwerkt. Soms is het gewoon een kleine pagina.
Deep crawl neemt je waits niet automatisch mee. Dit is het belangrijkste punt dat ik vooraf had willen weten voordat ik een crawl opbouwde. Een directe crawl van mijn dynamische pagina met wait_for werkte perfect — 8/8. Maar toen ik de BFS deep crawler links vanaf de homepage liet ontdekken en volgen, vond hij 5 pagina’s, slaagde op 3 en faalde op 2. Eén van die fouten was precies diezelfde dynamische cataloguspagina — de pagina die met een expliciete wait prima werkt. In de deep crawl zag hij 45 tekens pre-rendertekst, besloot hij dat de pagina te dun was en stopte hij met dezelfde misleidende “anti-bot”-melding nog voordat JavaScript überhaupt klaar was.
De les is heel precies: “Crawl4AI ondersteunt dynamische pagina’s” is waar, en “een deep crawl wacht automatisch op elke dynamische pagina die het ontdekt” is dat niet. Dat zijn twee losse gedocumenteerde functies — per-pagina waits en deep-crawl-strategieën — en ze vallen niet vanzelf samen. Als je deep crawl JavaScript-zware pagina’s moet laten verwerken, moet je het wachten bewust in de configuratie opnemen. Dat is geen bug maar configuratiewerkelijkheid, alleen bijt het je keihard als je aanneemt dat de happy path ook voor gevonden links gewoon blijft werken.
Voor- en nadelen, zonder omwegen
Waar het zijn sterren verdient:
- Eén library dekt veel af: gerenderde Markdown, gestructureerde JSON-extractie, screenshots, batch crawling en deep crawling, zonder dat je vier losse tools aan elkaar hoeft te plakken.
- Statische extractie is messcherp — in mijn tests 6/6 Markdown-recall en 6/6 gestructureerde records, snel en zonder verlies.
- Dynamische rendering werkt echt, omdat er ook echt een browser rendert — 8/8 met een expliciete wait, bevestigd met een screenshot.
- Apache-2.0-licentie, dus vriendelijk voor commercieel gebruik, en een actief onderhouden project (v0.9.0) met een grote community erachter.
- Ingebouwde
crawl4ai-doctordie een echte pagina rendert om te checken of je installatie echt werkt.
Waar het je iets kost:
- Zware eerste setup: twee browserstacks plus FFmpeg en een Headless Shell op schijf. Dat voel je meteen op beperkte machines.
- Raw Markdown bevat boilerplate, tenzij je een contentfilter inschakelt — de schone route is een bewuste stap, niet de standaard.
- Deep crawling past je dynamic-page waits niet automatisch toe; JS-pagina’s die halverwege de crawl worden ontdekt kunnen zonder extra configuratie falen.
- Foutmeldingen kunnen misleiden — een dunne 500-pagina kreeg het label “anti-bot protection” terwijl er niets geblokkeerd werd.
- Geen zelfherstellende selectors. Je CSS/XPath-schema is statisch en moet je zelf bijhouden als de markup wijzigt.
Wie Crawl4AI wel moet gebruiken — en wie beter doorloopt
Gebruik het als je een developer bent die een RAG- of agentpipeline bouwt en je één tool wilt die je zowel LLM-klaar Markdown als gestructureerde JSON van dezelfde gerenderde pagina geeft. Als je targets JavaScript-zwaar zijn, je het prima vindt om expliciete waits te schrijven en je comfortabel bent met het draaien van een echte headless browser op je eigen infrastructuur, dan is Crawl4AI een sterke en goed onderhouden keuze. De combinatie van Markdown voor het model plus schema voor de database, in één Apache-2.0-library, is gewoon heel handig.
Sla het over als je een lichtgewicht HTTP-parser zoekt die statische HTML in milliseconden binnenhaalt zonder browser-voetafdruk — Crawl4AI is bewust zwaarder dan dat, en alleen de browserdownloads zullen je al irriteren. Sla het ook over als je weinig schijfruimte of bandbreedte hebt, of deployt naar een minimale container waar twee browserstacks meteen een dealbreaker zijn. En sla het absoluut over als je op zoek bent naar zelfherstellende selectors — dat is een echte functie, alleen niet van deze tool.
Waar een managed API past — de Thunderbit-invalshoek
Probeer Thunderbit voor webdata-extractie
Alles hierboven gaat ervan uit dat je de browser zelf wilt draaien. Dat is een legitieme keuze, en voor veel teams ook de juiste — volledige controle, geen kosten per call, code die je end-to-end zelf bezit. Maar het helpt om expliciet te maken welke afweging je maakt, want bij Thunderbit hebben we onze developer stack juist rond de tegenovergestelde keuze gebouwd: laat de browser, anti-botafhandeling en JavaScript-rendering volledig buiten je machine.
De parallel is dicht genoeg om netjes te vergelijken. Onze POST /distill-endpoint doet wat Crawl4AI’s Markdown-pad doet — pagina erin, schone LLM-klaar Markdown eruit — alleen lopen JavaScript-rendering en anti-botlaag aan onze kant, niet op een browser die jij hebt geïnstalleerd. Onze POST /extract-endpoint dekt de gestructureerde kant af en geeft JSON terug op basis van een schema dat je zelf definieert, met een renderMode-schakelaar (none, basic, full) in plaats van een wait_for die je handmatig afstemt. Beide hebben batch-varianten. Er is ook een MCP-server — thunderbit_distill, thunderbit_extract en gratis thunderbit_suggest_fields — zodat een agent in Claude of Cursor het direct kan aanroepen, plus npx @thunderbit/thunderbit-cli voor terminal, CI en cron.
De afweging draait om wie het zware werk draagt. Crawl4AI is gratis, open source en self-hosted, en jij draagt de operationele last — de browserdownloads, de deep-crawl-configuratie, de machine waarop het allemaal draait. Onze dev stack is een managed API waarbij die last bij ons ligt, en de kosten verschuiven naar gebruik per call. Geen van beide is in het algemeen beter. Wil je elke laag zelf bezitten en per verzoek niets betalen, draai dan Crawl4AI. Wil je liever de browser-opslast wegstrepen en gewoon een endpoint aanspreken, dan past de managed route beter. Dezelfde engine die onze extensie met meer dan 100.000 gebruikers aandrijft, zit achter de API, dus het is geen speelgoedniveau.
Als je de bredere categorie afweegt, gaan onze eigen stukken over AI web scraping en de open-source GitHub scrapers die we head-to-head testten dieper in op dit onderwerp dan ik hier kan doen zonder er een heel ander artikel van te maken.
Conclusie: moet je Crawl4AI gebruiken?
Ja — als je een developer bent die LLM-klaar Markdown en gestructureerde JSON uit dezelfde gerenderde pagina wilt halen, je bouwt voor RAG of agents, en je een echte headless browser op je infrastructuur accepteert. In mijn tests deed de kern precies wat het belooft: 6/6 op statische extractie, 8/8 op dynamische pagina’s met een expliciete wait, 13.476 tekens Markdown uit een live catalogus en soepel batch crawlen. Dat is een solide, goed gelicenseerde en actief onderhouden tool die echt werk verzet.
Ga wel met open ogen binnen op drie punten, dan komt het goed: de setup zet twee browserstacks op je schijf, deep crawling wacht niet automatisch op dynamische pagina’s die je ontdekt, en een dunne foutpagina kan een misleidend “anti-bot”-label krijgen. Geen van die drie is een showstopper. Ze maken juist het verschil tussen een wonder verwachten en de echte tool gebruiken — die, nogmaals, gewoon een browser, een Markdown-converter en door jou onderhouden selectors is. Als je het zo begrijpt, is het een van de betere manieren om live pagina’s om te zetten naar tekst waar een model iets mee kan.
Dit is een voorlopige beoordeling op basis van één testronde. Ik heb geen crawl van duizend pagina’s gedaan, geen contentfilters gedraaid, de LLM-extractieroute niet aangeraakt en ook de Docker-servermodus niet getest. Zie mijn oordeel dus als “sterk, maar met huiswerk over” en niet als eindcijfer — en check ook de sterrenscore en versie opnieuw voordat je metadata citeert, want beide veranderen.
Probeer Thunderbit voor webdata-extractie Get Started Free
Veelgestelde vragen
Heeft Crawl4AI zelfherstellende of adaptieve selectors? Nee. Dat is de meest voorkomende misvatting. Crawl4AI gebruikt statische CSS/XPath-schema’s die je zelf schrijft en onderhoudt — als een site de klassennamen hernoemt waarop je selectors leunen, breekt de extractie totdat je het schema aanpast. Adaptieve, zelfherstellende selectors zijn een functie van een andere tool (Scrapling), niet van Crawl4AI.
Heb ik een volledige browser nodig om Crawl4AI te draaien?
Praktisch gezien wel. De kernwaarde is dat het JavaScript rendert met een echte browser, dus crawl4ai-setup downloadt twee browserstacks (Playwright en Patchright) plus FFmpeg en een Headless Shell. Als je een piepkleine HTTP-only parser wilt zonder browser-voetafdruk, dan is Crawl4AI niet de juiste vorm en heb je beter een lichte framework-optie.
Waarom zei Crawl4AI “anti-bot protection” op een pagina die helemaal niet geblokkeerd was? De structurele heuristiek markeert pagina’s met heel weinig zichtbare tekst, en de melding die het geeft noemt anti-bot protection. In mijn test kreeg een expres HTTP 500-pagina met vrijwel geen content dat label, terwijl er niets werd geblokkeerd. Kijk altijd naar de statuscode en de echte context voordat je concludeert dat een site actief tegenwerkt — soms is het gewoon een dunne of kapotte pagina.
Kan Crawl4AI’s deep crawl JavaScript-pagina’s automatisch aan?
Niet vanzelf. Een directe crawl met een expliciete wait_for werkte perfect op mijn dynamische pagina met 8/8, maar de BFS deep crawl die dezelfde pagina ontdekte faalde erop — 5 pagina’s gevonden, 3 geslaagd, 2 mislukt — omdat hij niet wachtte tot JavaScript klaar was voordat hij de pagina als te dun beoordeelde. Als je deep crawl dynamische pagina’s moet laten meenemen, moet je het wachten bewust configureren.
Waarin verschilt Crawl4AI van een managed scraping API zoals die van Thunderbit?
Crawl4AI is gratis, open source en self-hosted — jij draait en onderhoudt de browser en infrastructuur zelf, zonder kosten per call. Thunderbit’s developer stack (/distill voor Markdown, /extract voor gestructureerde JSON, plus MCP en CLI) is een managed API waarbij rendering, anti-bothandling en browser-ops aan onze kant draaien en jij per call betaalt. De afweging is dus volledige controle en geen kosten per request versus het uitbesteden van de operationele last.
