Crawl4AI bruker en ekte nettleser for å lage Markdown — og nei, den fikser ikke selektorene dine for deg

Det går en seiglivet misforståelse om Crawl4AI: at den på et eller annet vis har adaptiv intelligens, en selvlærende hjerne som finner dataene dine på nytt når et nettsted endrer HTML-strukturen sin. Det stemmer ikke. Det er et annet verktøy (Scrapling, hvis du er nysgjerrig). Crawl4AI er noe mer konkret, og enklere å forstå: en hodeløs nettleser koblet til en Markdown-konverterer, med en CSS/XPath-ekstraktor ved siden av.

Jeg brukte en hel testkjøring på å presse den gjennom statiske sider, JavaScript-renderte kataloger, en bevisst ødelagt 500-side og en liten deep crawl. Kjernen er genuint god. Det folk ofte hopper over — oppsettsvekt, deep-crawl-atferd og én misvisende feilmelding — er det resten av denne gjennomgangen ser nærmere på. Alt under er foreløpig, basert på testene jeg faktisk kjørte, ikke en endelig benchmark. Jeg markerer også det jeg ikke testet, så ingen siterer meg på ting jeg aldri var innom.

Hva Crawl4AI egentlig er (og myten den ikke er)

Skrell bort markedsføringsspråket, og Crawl4AI er i praksis tre ting stablet oppå hverandre.

Først: en ekte nettleser. Under panseret bruker den Playwright, pluss en stealth-patchet variant kalt Patchright, for å laste inn en side slik Chrome ville gjort det — kjøre JavaScript, bygge DOM-en og vente på innhold hvis du ber den om det. Dette er den viktige delen. Det er ikke en HTTP-klient som bare henter rå HTML og er ferdig med det. Den starter en faktisk rendering-motor.

Deretter: en Markdown-generator. Når siden er rendret, konverterer Crawl4AI DOM-en til Markdown, som er formatet LLM-er og RAG-pipelines helst vil ha. Vedlikeholderne beskriver hele prosjektet som en LLM-vennlig crawler av nettopp denne grunnen — gi den en URL, få tilbake tekst som en modell kan jobbe med.

Til slutt: en strukturert ekstraktor. Hvis du vil ha ren JSON i stedet for løpende tekst, gir du den et skjema — CSS- eller XPath-selektorer koblet til feltnavn — via JsonCssExtractionStrategy, og den returnerer poster. (Det finnes også en LLM-basert ekstraksjonsvei, men den krever API-nøkkel og jeg testet den ikke, så jeg later ikke som om jeg vet hvordan den oppfører seg.)

Her er poenget som betyr noe, og som ryktet om «adaptiv intelligens» bommer på: skjemaet er statisk og du skriver det selv. Du forteller Crawl4AI at produktnavnet ligger i .product-card h3 og prisen i .price, og hvis nettstedet bytter navn på disse klassene i morgen, ryker selektorene dine og forblir ødelagt. Ingenting selvreparerer. Det finnes ingen fuzzy rematching. Det er en nettleser, en konverterer og selektorer du selv vedlikeholder — verken mer eller mindre. Forstår du det fra starten, slipper du å lete etter en funksjon som faktisk bor i et annet repo.

Primitive-ene du faktisk jobber med, er navngitt fornuftig: AsyncWebCrawler er motoren, BrowserConfig setter opp nettleseren, og CrawlerRunConfig styrer én enkelt kjøring (inkludert wait_for, som jeg kommer tilbake til). Det er et async-first Python-API, og navngivingen er ryddig når brikkene faller på plass.

For ordens skyld ligger repoet på 71 259 stjerner, 7 326 forks og Apache-2.0 per 2026-07-07 (unclecode/crawl4ai), på release v0.9.0. Stjerntall endrer seg, så regn dette som et øyeblikksbilde, ikke en live-lesing — men det sier likevel at dette er et mye brukt prosjekt med liberal lisens, ikke et helgeeksperiment.

Oppsett: delen der to hele nettleserstakker havner på disken din

Installasjonen er der Crawl4AI slutter å oppføre seg som et lettvektsbibliotek, og det er også den delen nesten ingen omtaler nevner.

Selve pip-installasjonen er udramatisk. pip install -U crawl4ai gikk helt fint — og viktig nok ble den installert på Python 3.14.2, selv om dokumentasjonen formelt ber om >=3.10 og maskinen min ikke hadde noe 3.10–3.13-miljø liggende. Et godt tegn for dem som bruker en helt fersk interpreter.

Så kjører du crawl4ai-setup, og det er da lagringsplassen begynner å fylles opp.

Oppsettssteget henter ikke bare én nettleser. Det drar ned to fullverdige stakker — Playwright og Patchright — og oppsettsloggen viser i tillegg at den laster ned Chrome for Testing, FFmpeg og en Headless Shell. Det er prisen for å være et verktøy som bruker ekte nettleser: nettleserne må bo et sted, og her bor de på maskinen din, to ganger. Hvis du sitter på en laptop med liten SSD eller bygger et slankt containerimage der hver megabyte teller, må du planlegge for det. Dette er ikke fotavtrykket til en ren HTTP-parser, og det blir det heller aldri.

Til sin ære er verktøyet ærlig om egen helse. crawl4ai-doctor kjørte, bestod og crawlet https://crawl4ai.com på 14,65 sekunder for å bevise at nettleserveien faktisk fungerer fra ende til ende. En innebygd diagnosekommando som faktisk renderer en levende side, er et fint grep — det betyr at «virket installasjonen min?» får et reelt svar i stedet for et skuldertrekk.

Oppsettsdommen blir derfor delt: Python-siden er smidig og tilgivende, nettlesersiden er tung. Begge deler er sanne samtidig, og det bør du vite før du bestemmer deg.

Praktisk test: hva som holdt, med de faktiske tallene

Jeg bygde et lokalt testsystem med kjent fasit — statiske produkter, JS-renderte produkter, en artikkel med bevisst boilerplate, en ødelagt 500-side og en liten lenkegraf — og pekte deretter Crawl4AI mot det, pluss to offentlige demosider. Her er resultatkortet.

Statiske sider: full klaff. Den offisielle quickstarten mot example.com returnerte Markdown på 1,81 sekunder. På min lokale statiske katalog beholdt Markdown alle de forventede produktnavnene, 6/6, og CSS-basert skjemaekstraksjon hentet ut alle 6 postene som JSON — navn, kategori, pris, vurdering og detalj-URL, hvert eneste felt intakt. Ingen dramatikk.

Dynamiske sider: også full klaff, når du ber om det riktig. Dette er den bærende forutsetningen. På min JS-renderte katalog ga det å legge til wait_for="css:.product-card" i run-configen 8/8 produktgjenfinning både i Markdown og i skjemaekstraksjon. På den offentlige quotes.toscrape.com/js-siden rendret den de JavaScript-innsatte sitatene og lagret et brukbart skjermbilde som bevis på at nettleseren faktisk tegnet innholdet. Ordet «dynamisk» er ikke ambisiøst pynt her — nettleseren rendrer virkelig. Men du må fortelle den hva den skal vente på. Hopper du over wait_for, henter du en halvferdig side.

Batch: den holder. arun_many() over seks lokale produkt-URL-er kom tilbake med 6/6, alle 200-svar, i én parallell kjøring. Lite utvalg, men concurrency-sporet gjorde det det skulle.

Markdown-volum fra ekte nettsted. Mot forsiden til den offentlige Books to Scrape-siden produserte Crawl4AI 13 476 tegn med Markdown fra en levende side i ett kall — et konkret mål på hvor mye LLM-klart tekstinnhold én crawling-økt kan gi fra en ekte katalog.

Så kommer kantene — det som først dukker opp når du går forbi happy path.

Rå Markdown er bred av design. På min artikkeltest plukket Crawl4AI opp tittelen og alle 3/3 brødtekstavsnittene — men også navigasjonslenkene, blokken med relaterte lenker, en falsk abonnementslinje og bunnteksten. Det er ikke en feil; det er hva rå Markdown-konvertering betyr. Hele den rendrede siden blir til Markdown, boilerplate inkludert. Hvis du vil ha en faktisk ren artikkel, er den dokumenterte løsningen å slå på et innholdsfilter — PruningContentFilter scorer noder etter tekst-til-lenke-tetthet og fjerner støy, mens BM25ContentFilter rangerer mot en forespørsel. Jeg kjørte ikke disse filtrene i denne runden, så jeg setter ikke noe renhetstall på dem — men mentalmodellen er klar: rå Markdown er standarden, ren Markdown er et filter du slår på. Ikke forvent redaksjonsklart resultat fra null-konfigurasjonsveien.

500-siden fortalte en liten løgn. Jeg ga Crawl4AI en bevisst ødelagt side som returnerer HTTP 500. Den rapporterte riktig success=false og status 500 — men feilmeldingen sa «Blocked by anti-bot protection: Structural: minimal_text on small page.» Det fantes ingen anti-bot-vegg. Det var en liten feilside med nesten ingen synlig tekst, og Crawl4AIs strukturelle heuristikk så den tynne kroppen og satte anti-bot-etikett på den. Poenget for alle som kjører dette i skala: ikke stol blindt på ordlyden «anti-bot». Les statuskoden og den faktiske konteksten før du konkluderer med at et nettsted slåss mot deg. Noen ganger er det bare en liten side.

Deep crawl arver ikke ventingen din. Dette er funnet jeg helst ville visst før jeg kobler opp en crawl. En direkte crawl av den dynamiske siden min med wait_for fungerte perfekt — 8/8. Men da jeg lot BFS deep crawler oppdage lenker fra forsiden og følge dem, fant den 5 sider, lyktes på 3 og feilet på 2. Én av feilene var akkurat den samme dynamiske katalogsiden — den som fungerer fint med eksplisitt venting. I deep crawl så den 45 tegn med pre-render-tekst, bestemte seg for at siden var for tynn, og avbrøt med samme misvisende «anti-bot»-melding før JavaScript i det hele tatt var ferdig.

Lærdommen er presis: «Crawl4AI støtter dynamiske sider» er sant, og «en deep crawl venter automatisk på hver dynamiske side den finner» er det ikke. Dette er to separate dokumenterte funksjoner — venting per side og deep-crawl-strategier — og de smelter ikke sammen av seg selv. Hvis deep crawl-en din må håndtere JS-tunge sider, må du konfigurere ventingen bevisst. Det er en konfigurasjonsrealitet, ikke en bug, men den kommer absolutt til å bite deg hvis du antar at happy path skalerer uendret til nye lenker.

Fordeler og ulemper, uten å sminke det

Der den fortjener stjernene sine:

• Én bibliotekdekning som favner mye: rendret Markdown, strukturert JSON-ekstraksjon, skjermbilder, batch-crawling og deep crawling, uten å lime sammen fire verktøy.
• Statisk ekstraksjon er bunnsolid — 6/6 treff på Markdown og 6/6 strukturerte poster i testene mine, raskt og tapsfritt.
• Dynamisk rendering fungerer faktisk fordi en ekte nettleser gjør jobben — 8/8 med eksplisitt venting, verifisert med skjermbilde.
• Apache-2.0-lisens, som er vennlig for kommersiell bruk, og et aktivt prosjekt (v0.9.0) med et stort miljø bak seg.
• Innebygd crawl4ai-doctor som renderer en ekte side for å bekrefte at installasjonen faktisk virker.

Der det koster deg noe:

• Tung førstegangsoppsett: to nettleserstakker pluss FFmpeg og Headless Shell på disk. Det merkes på maskiner med begrensede ressurser.
• Rå Markdown inneholder boilerplate med mindre du slår på et innholdsfilter — den rene veien er et bevisst valg, ikke standard.
• Deep crawling bruker ikke automatisk venting for dynamiske sider; JS-sider som oppdages underveis kan feile uten ekstra konfigurasjon.
• Feilmeldinger kan villede — en tynn 500-side ble stemplet som «anti-bot protection» selv om ingenting blokkerte noe.
• Ingen selvreparerende selektorer. CSS/XPath-skjemaet ditt er statisk og ditt ansvar når markup endrer seg.

Hvem bør bruke Crawl4AI, og hvem bør gå videre

Bruk den hvis du er utvikler og bygger en RAG- eller agentpipeline, og vil ha ett verktøy som leverer både LLM-klart Markdown og strukturert JSON fra samme rendrede side. Hvis målsidene dine er JavaScript-tunge, du er komfortabel med å skrive eksplisitte waits, og du er greit innstilt på å kjøre en ekte hodeløs nettleser i egen infrastruktur, er Crawl4AI en sterk og godt vedlikeholdt match. Kombinasjonen Markdown-for-modellen pluss schema-for-databasen, i ett Apache-2.0-bibliotek, er genuint praktisk.

Dropp den hvis du vil ha en fjærlett HTTP-parser som henter statisk HTML på millisekunder uten nettleser — Crawl4AI er bevisst tyngre enn det, og nedlastingen av nettleserne alene vil irritere deg. Dropp den hvis du har lite disk eller båndbredde, eller skal deploye i en minimal container der to nettleserstakker er dealbreakeren. Og dropp den definitivt hvis du kom hit for selvreparerende selektorer — det er en ekte funksjon, bare ikke denne verktøykassens.

Hvor en administrert API passer inn — Thunderbit-vinkelen

Prøv Thunderbit for utvinning av webdata

Alt over forutsetter at du vil kjøre nettleseren selv. Det er et legitimt valg, og for mange team er det det riktige — total kontroll, ingen kostnad per kall, kode du eier fra ende til ende. Men det er verdt å si høyt hva du bytter bort, fordi vi i Thunderbit bygde utviklerstacken vår rundt motsatt kompromiss: la nettleseren, anti-bot-håndteringen og JavaScript-renderingen være helt utenfor maskinen din.

Parallellen er nær nok til å sammenligne direkte. Vårt POST /distill-endepunkt gjør det Crawl4AIs Markdown-spor gjør — side inn, rent LLM-klart Markdown ut — bortsett fra at JS-rendering og anti-bot-laget kjøres hos oss, ikke i en nettleser du selv har installert. Vårt POST /extract-endepunkt dekker den strukturerte delen og returnerer JSON mot et skjema du definerer, med en renderMode-bryter (none, basic, full) i stedet for en wait_for du må finjustere manuelt. Begge finnes også i batch-varianter. Det finnes dessuten en MCP-server — thunderbit_distill, thunderbit_extract og en gratis thunderbit_suggest_fields — slik at en agent i Claude eller Cursor kan kalle den direkte, samt npx @thunderbit/thunderbit-cli for terminal, CI og cron.

Kompromisset handler om hvem som bærer vekten. Crawl4AI er gratis, åpen kildekode og self-hosted, og du bærer driftsvekten — nettleser-nedlastinger, deep-crawl-oppsett og maskinen alt kjører på. Vår dev stack er en administrert API der den vekten er vårt problem, og kostnaden flytter seg til forbruk per kall. Ingen av delene er universelt bedre. Hvis du vil eie hvert lag og betale null per forespørsel, kjør Crawl4AI. Hvis du heller vil fjerne browser-ops-byrden og kalle et endepunkt, er det argumentet for den administrerte veien. Samme motor som driver utvidelsen vår med over 100 000 brukere ligger bak API-et, så dette er ikke en lekeversjon.

Hvis du vurderer hele kategorien, går våre egne innlegg om AI web scraping og de open source GitHub-scraperne vi testet mot hverandre dypere enn jeg kan gjøre her uten at dette blir en helt annen artikkel.

Konklusjon: bør du bruke Crawl4AI?

Ja — hvis du er utvikler, vil ha LLM-klart Markdown og strukturert JSON fra samme rendrede side, bygger for RAG eller agenter, og aksepterer en ekte hodeløs nettleser i infrastrukturen din. I testene mine gjorde kjernen akkurat det den lover: 6/6 på statisk ekstraksjon, 8/8 på dynamiske sider med eksplisitt venting, 13 476 tegn Markdown fra en levende katalog og ryddig batch-crawling. Det er et solid, vel-lisensiert og aktivt vedlikeholdt verktøy som faktisk gjør jobben.

Gå inn med åpne øyne om tre ting, så går det fint: oppsettet legger to nettleserstakker på disken din, deep crawling venter ikke automatisk på dynamiske sider du oppdager, og en tynn feilside kan få en misvisende «anti-bot»-etikett. Ingen av disse er dealbreakere. Alle er forskjellen mellom å forvente et mirakel og å bruke det faktiske verktøyet — som, igjen, er en nettleser, en Markdown-konverterer og selektorer du selv vedlikeholder. Forstår du det slik, er dette en av de bedre måtene å gjøre levende sider om til tekst en modell kan bruke.

Dette er en foreløpig vurdering fra én testkjøring. Jeg stress-testet den ikke med en crawl på tusen sider, kjørte ikke innholdsfiltrene, rørte ikke LLM-ekstraksjonsveien eller Docker-servermodus. Se poengsummen min som «sterk, men med hjemmelekser igjen» heller enn en endelig karakter — og sjekk stjernetall og versjon på nytt før du siterer noen av metadataene, siden begge endrer seg.

Prøv Thunderbit for utvinning av webdata Get Started Free

Vanlige spørsmål

Har Crawl4AI selvreparerende eller adaptive selektorer? Nei. Dette er den vanligste misforståelsen om verktøyet. Crawl4AI bruker statiske CSS/XPath-skjemaer som du skriver og vedlikeholder — hvis et nettsted endrer navn på klassene selektorene dine er avhengige av, bryter ekstraksjonen til du oppdaterer skjemaet. Adaptive, selvflyttende selektorer er en funksjon i et annet verktøy (Scrapling), ikke i Crawl4AI.

Trenger jeg en full nettleser for å kjøre Crawl4AI? I praksis ja. Kjernen i verdien er å rendere JavaScript med en ekte nettleser, så crawl4ai-setup laster ned to nettleserstakker (Playwright og Patchright) pluss FFmpeg og en Headless Shell. Hvis du vil ha en liten HTTP-only-parser uten nettleserfotavtrykk, er Crawl4AI feil verktøy, og du bør se etter et lettere rammeverk.

Hvorfor sa Crawl4AI «anti-bot protection» på en side som ikke var blokkert? Den strukturelle heuristikken markerer sider med svært lite synlig tekst, og meldingen den sender ut nevner anti-bot protection. I testen min fikk en bevisst HTTP 500-side med nesten ingen innhold den etiketten, selv om ingenting blokkerte forespørselen. Sjekk alltid statuskoden og den reelle konteksten før du konkluderer med at et nettsted aktivt motarbeider deg — noen ganger er det bare en tynn eller ødelagt side.

Håndterer Crawl4AIs deep crawl JavaScript-sider automatisk? Ikke av seg selv. En direkte crawl med eksplisitt wait_for håndterte den dynamiske siden min perfekt, 8/8, men BFS deep crawl som oppdaget samme side feilet på den — 5 sider funnet, 3 lyktes, 2 feilet — fordi den ikke ventet på at JavaScript skulle rendre ferdig før den vurderte siden som for tynn. Hvis deep crawl-en din må dekke dynamiske sider, må du konfigurere ventingen bevisst.

Hva er forskjellen mellom Crawl4AI og en administrert scraping-API som Thunderbits? Crawl4AI er gratis, åpen kildekode og self-hosted — du kjører og vedlikeholder nettleseren og infrastrukturen selv, uten kostnad per kall. Thunderbits utviklerstack (/distill for Markdown, /extract for strukturert JSON, pluss MCP og CLI) er en administrert API der rendering, anti-bot-håndtering og nettleserdrift skjer hos oss, og du betaler per kall. Avveiningen er total kontroll og null kostnad per forespørsel mot å flytte driftsbyrden over på oss.