Ik heb Crawl4AI getest op vijf soorten pagina’s — hier blinkt het uit en hier loopt het vast

Sommige vergelijkingen van scrapers van derden schrijven “Adaptive Intelligence” — selectors die een site leren kennen en zichzelf herstellen na wijzigingen in de markup — toe aan Crawl4AI. In de geteste API heb ik dat gedrag niet aangetroffen. Wat Crawl4AI wél biedt, is Markdown-generatie op basis van een browser, plus extractie via CSS/XPath. Scrapling biedt een aparte functie voor adaptieve selectors, binnen de grenzen die in de eigen review worden beschreven.

Ik heb Crawl4AI 0.9.0 getest op vijf paginatypen met bekende brondata: een statische catalogus, een catalogus die via JavaScript wordt opgebouwd, een artikel met veel omringende boilerplate, een opzettelijke 500-fout en een gelinkte meerpagina-structuur. De geteste Markdown- en schema-routes leverden de verwachte fixture-inhoud op. Ruwe Markdown behield boilerplate, deep crawling had pagespecifieke wachttijden nodig, en een gewone 500 kreeg een foutlabel met een anti-bot-sausje.

Wat Crawl4AI eigenlijk is

Begin bij iets dat veel mensen al bij installatie verkeerd inschatten. Crawl4AI is geen kleine Python-parser. De eerste crawl4ai-setup haalt stilletjes twee volledige browserstacks binnen — Playwright en Patchright — en zodra je dat ziet, valt het hele product op zijn plek: dit is een gecontroleerde headless browser met daarbovenop een Markdown-converter, verkleed als scraper.

Officieel is het een open-source library onder Apache-2.0 om webpagina’s om te zetten naar Markdown voor RAG-pipelines, agents en datastromen. Ik heb v0.9.0 getest. De kern bestaat uit AsyncWebCrawler, BrowserConfig, CrawlerRunConfig, Markdown-generatie en extractiestrategieën op basis van CSS/XPath of LLM’s, volgens de officiële quick start.

Dit is het mentale model dat telt. De meeste parsers sturen een HTTP-request en verwerken de teruggegeven bytes; Crawl4AI bestuurt een echte browser. Browser-rendering zit ingebouwd, wat de installatie zwaarder maakt dan bij een pure HTTP-parser. Tegelijk kan betrouwbare extractie van asynchroon gerenderde elementen nog steeds een expliciete wachttijd vereisen. Niets in deze test herschreef selectors na een redesign. Zie de claim over zelfherstel dus als een fout in een vergelijking van derden, tenzij er een specifieke officiële bron en reproduceerbare API worden aangereikt.

Belangrijkste functies en hoe ze onder de motorkap werken

De route voor één pagina is de kern. Je wijst AsyncWebCrawler naar een URL, de pagina wordt in een browser geladen, en je krijgt Markdown terug. Op de officiële quickstart met example.com duurde die ronde 1,81 seconden en kwam er een nette 200 terug. Niet spectaculair, maar het bevestigt dat de minimale route werkt met bijna geen configuratie — geen schema, geen waits, geen browserconfiguratie.

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

Gestructureerde extractie is de tweede pijler, en het is het dichtst dat Crawl4AI bij “begrijpen” van een pagina komt — al gaat het niet om inferentie, maar gewoon om een schema dat jij zelf schrijft. In plaats van alleen Markdown uit te spugen, geef je via JsonCssExtractionStrategy een CSS-schema mee en krijg je JSON-objecten terug met precies de velden die je hebt gevraagd. Op mijn lokale statische catalogus leverde dat 6 nette JSON-records op — productnaam, categorie, prijs, beoordeling, detail-URL — exact passend bij de 6 verwachte producten. Dat is het verschil tussen “hier is de pagina als tekst” en “hier zijn de gegevens als rijen”, en Crawl4AI doet beide vanuit dezelfde crawl. De selectors moet je wel zelf definiëren; de tool volgt wat jij opgeeft en verzint het schema niet voor je.

Dynamische rendering is waar de browser-aanpak zijn waarde laat zien. Geef een JavaScript-gerenderde catalogus door met wait_for="css:.product-card" en de crawler blijft wachten tot de client-side render klaar is voordat er wordt geëxtraheerd. Dat leverde op mijn lokale JS-fixture 8/8 product recall op, zowel in Markdown als in schema-output, in ongeveer 1,56 seconden. Op de openbare Quotes to Scrape JS-pagina pakte hij de gerenderde quotes mee en sloeg hij een bruikbare screenshot op — content die een gewone HTTP-request nooit zou zien, omdat er in de initiële HTML simpelweg niets staat om te parseren.

Dan is er nog schaal en crawling. arun_many() draaide zes lokale detailpagina’s gelijktijdig met volledige 6/6 recall in 3,76 seconden. En Crawl4AI levert deep-crawl-strategieën mee — BFS, DFS, BestFirst — die een linkgrafiek aflopen met dieptelimieten, paginacaps, filtering en scoring. Een BFS-deepcrawl liep door de linkgrafiek van mijn fixture-homepage en haalde vijf pagina’s binnen. Hier beginnen belofte en werkelijkheid langzaam uiteen te lopen, en daar kom ik hieronder op terug.

Setup: het deel dat niemand in de README-intro zet

De installatie op mijn machine verliep op één punt soepeler dan verwacht en op een ander punt zwaarder dan verwacht. pip install -U crawl4ai en de smoke test slaagden op Python 3.14.2 op macOS arm64. De >=3.10-specificatie op PyPI dekt 3.14 al; dit resultaat bevestigt alleen de geteste installatie en workflow, niet bredere compatibiliteit.

De frictie zit in de setupstap. crawl4ai-setup downloadt browser-assets voor zowel Playwright als Patchright — Chrome for Testing, FFmpeg en een Headless Shell. Als je op een laptop met weinig opslag werkt of een beperkte verbinding hebt, is dat een echte kostenpost, en de documentatie noemt dat meer terloops dan upfront. Daarna slaagde crawl4ai-doctor en crawlde crawl4ai.com in 14,65 seconden. Dat is een prima end-to-end smoke test, maar geen benchmark van iets — daar zou ik geen snelheidssignaal in lezen.

De conclusie voor het setup-gedeelte van je eigen evaluatie: reserveer ruimte en bandbreedte voor de browserdownload, niet alleen voor de pip-installatie. Dit lijkt meer op het opzetten van een headless browseromgeving dan op het simpel toevoegen van een library aan een script. Er landen twee browserstacks op disk voordat je ook maar één echte pagina crawlt, en dat is een eenmalige kostenpost die je betaalt, ook als je workload die stealth-laag van Patchright nooit nodig heeft.

Hands-on: wat overeind bleef en wat ik zou aantekenen

Vier resultaten verdienen het om zorgvuldig op te schrijven, omdat dit precies het soort nuance is dat marketingpagina’s gladstrijkt — en in één geval zelfs verkeerd labelt.

Twee openbare demo-pagina’s haalden ook de happy path. Op de homepage van Books to Scrape produceerde Crawl4AI 13.476 tekens aan Markdown in 2,43 seconden. De openbare Quotes JS-pagina leverde ongeveer 3,1 seconden later 1.666 gerenderde Markdown-tekens op. Geen van beide zegt iets over schaal, vijandige sites, langdurige stabiliteit, sessies, proxies, retries of geheugenverbruik.

De artikel-fixture laat een kanttekening bij Markdown-kwaliteit zien. Crawl4AI pakte de titel en alle 3/3 alinea’s in de body mee — prima. Maar de ruwe Markdown bevatte ook navigatietekst, gerelateerde links, een inschrijvingsregel en footertekst. Dat is geen bug; zonder contentfilter of target selector betekent “zet deze pagina om naar Markdown” eerlijk gezegd de hele pagina. De les is om ruwe Markdown-conversie te onderscheiden van schone artikel-extractie. Als je het tweede wilt, gebruik je een contentfilter zoals PruningContentFilter of een target selector — maar dat heb ik nog niet zwaar getest, dus ik noem daar geen schoonheidsscore bij.

De kapotte pagina was het meest veelzeggende resultaat. Ik serveerde opzettelijk een HTTP 500 met een klein bodytje. Crawl4AI gaf success=false en status 500 terug — correct — maar het foutbericht noemde het "Blocked by anti-bot protection: Structural: minimal_text on small page." Er was geen anti-botmuur. Het was gewoon een kleine foutpagina. Crawl4AI’s structurele heuristiek zag weinig zichtbare tekst en trok daar een anti-botverklaring uit. Voor iedereen die hierop bouwt, is dat belangrijk: vertrouw het label "anti-bot" niet op zijn woord. Controleer de statuscode en de echte response voordat je concludeert dat een site zich verdedigt. Het ruwe resultaat staat in de benchmarkrepo op results/local_failure_500.json.

Deep crawling heeft bewuste configuratie nodig. Een directe dynamische crawl met wait_for werkte netjes, terwijl de BFS-deepcrawl de dynamische catalogus ontdekte maar faalde. De classificatie als minimal-text past bij het lezen vóórdat de kaarten gerenderd waren, en de deepcrawl nam de wait van de directe crawl niet over. Van de vijf pagina’s slaagden er drie en faalden er twee. Omdat hier geen herhaalde run met wait-configuratie wordt getoond, blijft die diagnose een aanname en geen bewezen oorzaak.

Waar de cijfers uitkomen

Deze timings zijn smoke-testmetingen, geen prestatiebenchmark: het artikel documenteert geen hardware, aantal herhalingen, warme/koude toestand, cachestatus, concurrency-instellingen of variatie. Ze laten zien dat de genoemde workflows op deze machine zijn afgerond. De volledige run-artifacts staan in de benchmarkrepodirectory.

Voor een prestatie-run die je echt kunt gebruiken voor een beslissing, herhaal je elke workflow in verse en hergebruikte browsersessies, rapporteer je verdelingen in plaats van één decimaal, pin je browser-builds, en noteer je CPU, geheugen, cachestatus en concurrency. Zo scheid je library-overhead van browser-opstart en netwerkvariatie.

Voor- en nadelen

Voordelen:

• Eén library doet ruwe Markdown en gestructureerde JSON via CSS-schema’s — je hoeft geen twee tools aan elkaar te knopen.
• Browser-rendering zit ingebouwd; asynchroon gerenderde doelen kunnen een expliciete wait_for nodig hebben.
• De geteste single-page workflows vielen binnen de hierboven gemeten tijden; er wordt geen vergelijkende snelheid claim gemaakt.
• Apache-2.0-licentie — commercieel vriendelijk, zonder copyleft-verrassingen.
• Actief project met een recente release en een grote, betrokken community.

Nadelen:

• Zware eerste setup (twee browserstacks) die de introductie te rooskleurig voorstelt.
• Ruwe Markdown bevat boilerplate, tenzij je contentfilters instelt.
• Deep crawling wacht niet automatisch op dynamische pagina’s — dat configureer je per crawl, anders krijg je fouten.
• Foutmeldingen kunnen een gewone fout als "anti-bot" labelen, wat verwarrend is in logs.
• Geen zelfaanpassende selectors, ondanks wat sommige vergelijkingen suggereren — schema’s zijn handgeschreven en statisch.
• Je runt en onderhoudt de browseromgeving zelf, inclusief updates en breekbaarheid.

Voor wie het is — en wie het beter kan overslaan

Crawl4AI is het onderzoeken waard als je een developer bent die een RAG- of agent-pipeline bouwt, je comfortabel bent met het draaien van een headless browseromgeving, en je Markdown plus gestructureerde JSON uit dezelfde crawl wilt halen. De tests dekten geen robuustheid tegen vijandige sites, langdurige stabiliteit, geheugen, sessies, retries, proxies of productie-deployment, dus de aanbeveling blijft beperkt tot de hier uitgevoerde workflows.

Sla het over — of pauzeer in elk geval — als je een kleine HTTP-parser met weinig afhankelijkheden wilde (dit is juist het tegenovergestelde), als je de schijfruimte en bandbreedte voor browserdownloads niet kunt missen, of als je niet zelf het onderhoud van een browserstack in productie wilt dragen. En sla het specifiek over als je op zoek bent naar zelfherstellende selectors: dat is niet wat dit gereedschap is, en een workflow bouwen rond een functie die het niet heeft, gaat je later opbreken. Voor pure extractie van artikeltekst, met weggesneden boilerplate, kan een lichter hulpmiddel dat precies voor die taak is gemaakt beter passen.

Alternatieven, inclusief waar Thunderbit past

De eerlijke framing: Crawl4AI is een gratis open-source library die je zelf host en onderhoudt. Je krijgt volledige controle en geen licentiekosten per gebruik, maar je betaalt nog steeds voor compute, bandbreedte, opslag, browser-updates, schema’s en operationeel werk.

Aan de andere kant staat een beheerde scrapingdienst zoals Thunderbit, waar ophalen en extractie achter een API zitten. Thunderbit is niet met deze fixtures getest, dus dit artikel doet geen overeenkomstige claim over rendering, anti-bot-afhandeling, CAPTCHA’s, nauwkeurigheid of snelheid. De relevante vergelijking is operationeel eigenaarschap: host je zelf de browser-gedreven library, of betaal je een dienst om die laag te beheren.

Het verschil zit in wie de browser draait. Met Crawl4AI beheer je rendering, waits, schema’s en onderhoud zelf. Met een managed API betaal je per call en schuif je een deel van de operationele verantwoordelijkheid door naar de provider. Dit experiment heeft die twee routes niet op uitkomst vergeleken.

Gerelateerde benchmarkreviews: de volledige vergelijking van open-source scrapers, de self-hosted review van Firecrawl, en de review van article extraction met trafilatura.

Probeer Thunderbit voor webdata-extractie

Oordeel

Crawl4AI is een redelijke kandidaat als je open-source, browser-gedreven extractie wilt die Markdown en schema-achtige JSON oplevert, en je bereid bent de browseromgeving zelf te beheren. De directe statische workflows en de dynamische workflows met wait slaagden in deze fixtures. Apache-2.0 is ruimhartig, al blijft een normale check van afhankelijkheden en distributie natuurlijk nodig.

Reserveer budget voor de browser-assets. Ruwe Markdown moet worden gefilterd voordat het schone artikeltekst is. Waits voor deep crawls vragen om bewuste configuratie, en een logregel met "anti-bot" moet je altijd toetsen aan de statuscode en de response. Schema-selectors moet je zelf schrijven en onderhouden. Dat zijn de geteste grenzen voor een beslissing; productie-schaal en gedrag op vijandige sites blijven open vragen.

Probeer Thunderbit voor webdata-extractie Get Started Free

Veelgestelde vragen

Heeft Crawl4AI adaptieve of zelfherstellende selectors? Nee. Ondanks dat sommige vergelijkingen het toeschrijven aan "adaptive intelligence", matcht Crawl4AI het CSS/XPath-schema dat jij schrijft — het fingerprint elementen niet en zoekt ze ook niet opnieuw op na een wijziging in de markup. In de test haalde de gestructureerde extractie 6/6 en 8/8 recall met schema’s die ik handmatig had gedefinieerd. Als een site zijn klassen wijzigt, breekt je schema totdat je het bijwerkt. Zelfherstellende elementtracking is een functie van een andere library, niet van deze.

Waarom is de installatie zo groot? crawl4ai-setup downloadt volledige browser-assets voor zowel Playwright als Patchright — Chrome for Testing, FFmpeg en een Headless Shell. Dat is de prijs van echte browser-rendering. Reserveer schijfruimte en bandbreedte; het is zwaarder dan een pure HTTP-parser, en je betaalt die prijs zelfs als je workload de stealth-stack nooit gebruikt.

Kan Crawl4AI JavaScript-gerenderde pagina’s aan? Ja, omdat het een echte headless browser bestuurt. In de test gaf een dynamische catalogus met wait_for="css:.product-card" volledige 8/8 product recall, en de openbare Quotes JS-pagina werd netjes gerenderd. Het addertje onder het gras is dat deep crawls die wait niet automatisch toepassen op ontdekte pagina’s — een BFS-crawl faalde op een dynamische pagina die hij vond, omdat hij niet wachtte. Dat wachtgedrag configureer je zelf, per crawl.

Geeft Crawl4AI me schone artikeltekst of de hele pagina? Standaard de hele pagina. In de test werden alle alinea’s in de body meegenomen, maar ook nav, gerelateerde links en footertekst. Voor schone artikel-extractie gebruik je een contentfilter (zoals PruningContentFilter) of een target selector, in plaats van alleen op ruwe Markdown te vertrouwen.

Kan ik de foutmeldingen van Crawl4AI vertrouwen? Lees ze met enige scepsis. Een opzettelijke 500-foutpagina met een kleine body werd gelabeld als "Blocked by anti-bot protection" puur vanwege een heuristiek met weinig zichtbare tekst — er was geen anti-botmuur. Het ruwe resultaat staat in de benchmarkrepo. Controleer altijd eerst de daadwerkelijke HTTP-statuscode en de response body voordat je concludeert dat een site je blokkeert.