Crawl4AI:hin liittyy sitkeä sitkeä sitkeä huhu Crawl4AI -projektin ympärillä: että siinä olisi jonkinlainen mukautuva äly, itseään korjaava aivot, joka löytää tietosi uudelleen, kun sivusto järjestää HTML:nsä uusiksi. Ei ole. Se on joku toinen työkalu (Scrapling, jos kiinnostaa). Crawl4AI on jotain paljon konkreettisempaa ja käytännössä hyödyllistä ymmärtää suoraan: headless-selain, johon on liitetty Markdown-muunnin sekä sivussa CSS/XPath-poimija.
Kokeilin sitä käytännössä testisarjalla, joka sisälsi staattisia sivuja, JavaScriptillä renderöityjä katalogeja, tahallaan rikotun 500-sivun sekä pienen syväindeksoinnin. Sen ydin on aidosti hyvä. Ne kohdat, joista yleensä vaietaan — käyttöönoton paino, syväindeksoinnin käytös ja yksi harhaanjohtava virheilmoitus — ovat juuri niitä, joihin tämä arvostelu pureutuu. Kaikki alla oleva on alustavaa ja perustuu omiin testeihini, ei lopulliseen vertailuun. Kerron myös, mitä en testannut, jotta kukaan ei laita sanoja suuhuni asioista, joihin en koskenut.
Mitä Crawl4AI oikeasti on (ja mikä myytti se ei ole)
Kun markkinointipuheen kuorii pois, Crawl4AI on kolmen asian pino.
Ensinnäkin, oikea selain. Taustalla se ajaa Playwrightia sekä stealth-paikatun Patchright-version avulla sivun auki samalla tavalla kuin Chrome: JavaScript ajetaan, DOM rakennetaan, ja sisältöä odotetaan, jos niin käskee. Tämä on tärkein osa. Se ei ole HTTP-asiakas, joka vain hakee raakaa HTML:ää ja lopettaa siihen. Se käynnistää oikean renderöintimoottorin.
Toiseksi, Markdown-generaattori. Kun sivu on renderöity, Crawl4AI muuntaa DOMin Markdowniksi — juuri sellaiseen muotoon, jota LLM:t ja RAG-putket haluavat syödä. Ylläpitäjät asemoivat koko projektin LLM-ystävälliseksi crawleriksi juuri tästä syystä: anna URL, saat takaisin tekstiä, jota malli voi käsitellä.
Kolmanneksi, rakenteinen poimija. Jos haluat siistin JSONin proosan sijaan, annat sille skeeman — CSS- tai XPath-selektorit kenttien nimiin mapattuina — JsonCssExtractionStrategy-luokan kautta, ja se palauttaa rivit. (Mukana on myös LLM-pohjainen poimintapolku, mutta se vaatii API-avaimen, enkä testannut sitä, joten en väitä tietäväni miten se käyttäytyy.)
Tässä on se kohta, joka ratkaisee asian ja jonka "adaptive intelligence" -huhu ymmärtää väärin: skeema on staattinen ja kirjoitat sen itse. Kerrot Crawl4AI:lle, että tuotteen nimi löytyy .product-card h3:sta ja hinta .price:sta, ja jos sivusto vaihtaa luokkien nimiä huomenna, selektorit hajoavat ja pysyvät rikki. Mikään ei korjaannu itsekseen. Ei ole mitään fuzzy-uudelleenhakua. Se on selain, muunnin ja itse ylläpitämäsi selektorit — ei enempää eikä vähempää. Kun tämän ymmärtää heti alussa, ei odota ominaisuutta, joka elää aivan eri repossa.
Varsinaiset työkalut on nimetty järkevästi: AsyncWebCrawler on moottori, BrowserConfig määrittää selaimen ja CrawlerRunConfig ohjaa yhtä ajoa (mukaan lukien wait_for, johon palaan myöhemmin). Kyseessä on async-first-Python-API, joka toimii varsin siististi, kun nimitys loksahtaa paikoilleen.
Repo on muuten 71 259 tähdessä, 7 326 forkissa ja Apache-2.0-lisenssillä tilanteessa 2026-07-07 (unclecode/crawl4ai), versiossa v0.9.0. Tähtimäärät elävät, joten tätä kannattaa pitää kuvakaappauksena eikä reaaliaikaisena lukemana — mutta se kertoo, että kyseessä on laajasti käytetty, vapaasti lisensoitu projekti, ei viikonloppuharjoitus.
Käyttöönotto: kohta, jossa kaksi kokonaista selainpinoa päätyy koneellesi
Asennus on se vaihe, jossa Crawl4AI lakkaa käyttäytymästä kevyenä kirjastona. Ja juuri siitä melkein kukaan ei kirjoita.
Itse pip install meni läpi ilman draamaa. pip install -U crawl4ai onnistui siististi — ja mikä merkittävää, se asentui Python 3.14.2 -versioon, vaikka dokkarit pyytävät virallisesti versiota >=3.10 ja koneellani ei ollut 3.10–3.13-ajoympäristöä valmiina. Hyvä merkki heille, jotka elävät terävällä kehitysreunalla.
Sitten ajetaan crawl4ai-setup, ja siinä levytila alkaa täyttyä.
Asennus ei vedä yhtä selainta. Se lataa kaksi kokonaista pinota — Playwrightin ja Patchrightin — ja loki näyttää samalla, että mukaan tulevat Chrome for Testing, FFmpeg ja Headless Shell. Se on oikean selainratkaisun hinta: selainten on asuttava jossain, ja tässä ne asuvat omalla koneellasi, kahteen kertaan. Jos käytät kannettavaa, jossa SSD on täynnä, tai rakennat minimalistista konttikuvasta, jossa jokainen megatavu merkitsee, tämä kannattaa ottaa huomioon. Tämä ei ole puhtaan HTTP-parserin jalanjälki, eikä siitä koskaan tulekaan sellaista.
On projektin eduksi, että työkalut ovat rehellisiä omasta terveydestään. crawl4ai-doctor ajettiin, se läpäisi testin ja crawlasi https://crawl4ai.com-sivun 14,65 sekunnissa todistaakseen, että selainpolku toimii alusta loppuun. Sisäänrakennettu doctor-komento, joka oikeasti renderöi live-sivun, on erinomainen lisä — se tarkoittaa, että "asentuiko oikein" saa oikean vastauksen eikä vain olankohautuksen.
Käyttöönoton tuomio on siis kaksijakoinen: Python-puoli on sujuva ja anteeksiantava, selainpuoli raskas. Molemmat pitävät yhtä aikaa paikkansa, ja sinun pitäisi tietää molemmat ennen kuin sitoudut.
Käytännössä: mikä kesti ja millä numeroin
Rakensin paikallisen testisivuston, jossa oli tunnettu totuus: staattisia tuotteita, JS-renderöityjä tuotteita, artikkeli tahallisella boilerplatella, rikkinäinen 500-sivu ja pieni linkkigraafi — ja osoitin Crawl4AI:n sitä sekä kahta julkista demo-sivua vasten. Tässä tulokset.
Staattiset sivut: puhdas voitto. Virallinen quickstart example.com-sivulla palautti Markdownin 1,81 sekunnissa. Omalla paikallisella staattisella katalogillani Markdown säilytti kaikki odotetut 6/6 tuotteen nimeä, ja CSS-skeeman poiminta haki kaikki 6 riviä JSONina — nimi, kategoria, hinta, arvosana ja detail-URL, kaikki kentät ehjinä. Ei mitään dramatiikkaa.
Dynaamiset sivut: myös puhdas voitto, kun pyydät oikein. Tämä on se ratkaiseva ehto. JS-renderöidyllä katalogillani wait_for="css:.product-card"-parametrin lisääminen run-configiin antoi 8/8 tuotteen palautuksen sekä Markdownissa että skeemapoiminnassa. Julkisella quotes.toscrape.com/js -sivulla se renderöi JavaScriptillä injektoidut lainaukset ja tallensi käyttökelpoisen screenshotin todisteeksi siitä, että selain todella piirsi sisällön. Sana "dynaaminen" ei tässä ole toiveajattelua — selain oikeasti renderöi. Mutta sinun on kerrottava, mitä odottaa. Jos jätät wait_for-arvon pois, haet puolivalmista sivua.
Eräajo: toimii. arun_many() kuudelle paikalliselle tuote-URL:lle palasi tuloksella 6/6, kaikki 200-vastauksia, yhdessä rinnakkaisessa ajossa. Pieni otos, mutta rinnakkaisajon polku teki sen, mitä lupaa.
Live-sivun Markdown-määrä. Julkisen Books to Scrape -etusivun kanssa Crawl4AI tuotti 13 476 merkkiä Markdownia yhdestä live-sivusta yhdellä kutsulla — konkreettinen kuva siitä, kuinka paljon LLM-valmista tekstiä yksi crawl tuottaa oikealta katalogisivulta.
Sitten ne karheat reunat — kohdat, jotka näkyvät vasta, kun mennään onnellisen polun yli.
Raaka Markdown on tarkoituksella leveä. Artikkelitestissä Crawl4AI nappasi otsikon ja kaikki 3/3 leipätekstikappaletta — mutta myös navigoinnin tekstin, aiheet-linkkilohkon, tekaistun tilausrivin ja alatunnisteen. Tämä ei ole virhe; tämä on raakan Markdown-muunnoksen luonne. Koko renderöity sivu muutetaan Markdowniksi, boilerplate mukaan lukien. Jos haluat oikeasti siistin artikkelin, dokumentoitu vastaus on ottaa käyttöön sisältösuodatin — PruningContentFilter pisteyttää solmut teksti-linkki-suhteen perusteella ja pudottaa roskat, BM25ContentFilter taas rankkaa suhteessa hakukyselyyn. En ajanut näitä suodattimia tässä kierroksessa, joten en laita niille siisteyslukua — mutta mentaalimalli on selvä: raaka Markdown on leveä oletus, siisti Markdown on suodatin jonka kytket päälle. Älä odota toimituksellista laatua nollakonfiguraation polulta.
500-sivu kertoi pienen valheen. Syötin Crawl4AI:lle tahallaan rikkinäisen sivun, joka palauttaa HTTP 500:n. Se raportoi oikein success=false ja statuksen 500 — mutta virheviesti oli "Blocked by anti-bot protection: Structural: minimal_text on small page." Mitään anti-bot-seinää ei ollut. Kyseessä oli pieni virhesivu, jossa oli tuskin lainkaan näkyvää tekstiä, ja Crawl4AI:n rakenteellinen heuristiikka näki ohuen rungon ja päätyi anti-bot-leimaan. Opetus niille, jotka ajavat tätä laajassa mittakaavassa: älä usko "anti-bot"-sanamuotoa sellaisenaan. Tarkista statuskoodi ja todellinen konteksti ennen kuin päätät, että sivusto taistelee vastaan. Joskus kyse on vain pienestä sivusta.
Syväindeksointi ei peri odotuksia automaattisesti. Tämä on se löydös, jonka haluaisin itse tietää ennen kuin rakennan crawlauksen sen varaan. Suora crawl dynaamiselle sivulleni wait_for-asetuksella toimi täydellisesti — 8/8. Mutta kun annoin BFS-syväcrawlerin löytää linkit etusivulta ja seurata niitä, se löysi 5 sivua, onnistui 3:ssa ja epäonnistui 2:ssa. Yksi epäonnistumisista oli juuri se dynaaminen katalogisivu — sama, joka toimii täysin hyvin eksplisiittisellä odotuksella. Syväcrawlissa se näki 45 merkkiä prerender-tekstiä, päätti että sivu oli liian ohut ja keskeytti samalla harhaanjohtavalla "anti-bot"-viestillä ennen kuin JavaScript ehti valmistua.
Oppi on täsmällinen: "Crawl4AI tukee dynaamisia sivuja" on totta, mutta "syväcrawl odottaa automaattisesti jokaista löytämäänsä dynaamista sivua" ei ole. Nämä ovat kaksi erillistä dokumentoitua ominaisuutta — sivukohtaiset odotukset ja syväcrawl-strategiat — eikä niitä yhdistetä itsestään. Jos syväcrawlisi täytyy käsitellä JS-painotteisia sivuja, odotus täytyy kytkeä crawl-konfiguraatioon erikseen. Tämä on konfiguraatiorealiteetti, ei bugi, mutta se puree varmasti, jos oletat onnellisen polun skaalautuvan löydettyihin linkkeihin muuttumatta.
Plussat ja miinukset, ilman kiertelyä
Missä se ansaitsee tähtensä:
- Yksi kirjasto kattaa paljon: renderöity Markdown, rakenteinen JSON-poiminta, screenshotit, batch-crawl ja syväcrawl, ilman että neljää eri työkalua tarvitsee liimata yhteen.
- Staattinen poiminta on erittäin luotettava — testeissäni 6/6 Markdown-osumassa ja 6/6 rakenteisessa rivissä, nopeasti ja häviöttä.
- Dynaaminen renderöinti oikeasti toimii, koska oikea selain tekee renderöinnin — 8/8 eksplisiittisellä odotuksella, ja screenshotilla varmennettuna.
- Apache-2.0-lisenssi, joka on kaupalliseen käyttöön ystävällinen, sekä aktiivisesti julkaistava projekti (v0.9.0) suuren yhteisön tukemana.
- Sisäänrakennettu
crawl4ai-doctor, joka renderöi oikean sivun ja varmistaa, että asennus todella toimii.
Missä se maksaa:
- Raskas ensimmäinen käyttöönotto: kaksi selainpinoa plus FFmpeg ja Headless Shell levylle. Oikeaa kitkaa rajallisilla koneilla.
- Raaka Markdown sisältää boilerplaten, ellei sisältösuodatinta oteta käyttöön — siisti polku on tietoinen valinta, ei oletus.
- Syväcrawl ei sovella dynaamisten sivujen odotuksia automaattisesti; kesken crawlauksen löydetyt JS-sivut voivat kaatua ilman lisäasetuksia.
- Virheilmoitukset voivat johtaa harhaan — ohut 500-sivu sai leiman "anti-bot protection", vaikka mikään ei estänyt mitään.
- Ei itsekorjautuvia selektoreita. CSS/XPath-skeemasi on staattinen ja sinun vastuullasi, kun markup muuttuu.
Kenelle Crawl4AI sopii — ja kuka voi kävellä ohi
Käytä tätä, jos olet kehittäjä, joka rakentaa RAG- tai agenttiputkea ja haluat yhden työkalun, joka antaa samalta renderöidyltä sivulta sekä LLM-valmista Markdownia että rakenteista JSONia. Jos kohteesi ovat JavaScript-raskaita ja kirjoitat mielelläsi eksplisiittiset odotukset, ja jos sinua ei haittaa ajaa oikeaa headless-selainta omalla infrastruktuurilla, Crawl4AI on vahva ja hyvin ylläpidetty vaihtoehto. Markdown-mallille plus skeema tietokannalle yhdessä Apache-2.0-kirjastossa on aito etu.
Ohita tämä, jos haluat höyhenenkevyen HTTP-parserin, joka noutaa staattista HTML:ää millisekunneissa ilman selainta — Crawl4AI on tarkoituksella raskaampi, ja selainten lataus yksinään ärsyttää sinua. Ohita se, jos levytila tai kaista on tiukilla, tai olet viemässä ratkaisua minimaaliseen konttiin, jossa kaksi selainpinoa on kynnyskysymys. Ja ehdottomasti ohita se, jos tulit hakemaan itsekorjautuvia selektoreita — se on ihan oikea ominaisuus, mutta ei tämän työkalun.
Mihin hallittu API sopii — Thunderbit-näkökulma
Kokeile Thunderbitiä web-datan poimintaan
Kaikki yllä oletusarvoisesti olettaa, että haluat ajaa selainta itse. Se on täysin pätevä valinta, ja monelle tiimille oikea — täysi hallinta, ei per-kutsu-kustannusta, koodi kokonaan omissa käsissä. Mutta on hyödyllistä sanoa ääneen, mitä olet vaihtamassa, koska meillä Thunderbitissä kehittäjäpino on rakennettu päinvastaisen kompromissin varaan: selain, antibot-käsittely ja JavaScript-renderöinti pidetään kokonaan pois omalta koneeltasi.
Vastaavuus on riittävän lähellä suoraa vertailua varten. POST /distill -päätepisteemme tekee saman kuin Crawl4AI:n Markdown-polku — sivu sisään, siisti LLM-valmis Markdown ulos — mutta JS-renderöinti ja antibot-kerros pyörivät meidän puolellamme, eivät selaimessa jonka asensit itse. POST /extract -päätepisteemme kattaa rakenteisen puolen ja palauttaa JSONia määrittelemääsi skeemaan, renderMode-kytkimellä (none, basic, full) sen sijaan, että säätäisit wait_for-asetusta käsin. Molemmissa on myös batch-versiot. Mukana on myös MCP-palvelin — thunderbit_distill, thunderbit_extract ja ilmainen thunderbit_suggest_fields — joten Claude- tai Cursor-agentti voi kutsua sitä suoraan, ja npx @thunderbit/thunderbit-cli terminaaliin, CI:hin ja cron-ajoon.
Kompromissi on lopulta siinä, kuka kantaa painon. Crawl4AI on ilmainen, avoimen lähdekoodin ja itsehostattu, ja sinä kannat operatiivisen painon — selainlataukset, syväcrawl-konfigurointi ja koneen, jolla kaikki pyörii. Meidän kehityspinomme on hallittu API, jossa tuo paino on meidän ongelmamme ja hinta siirtyy käyttöön per kutsu. Kumpikaan ei ole yleispätevästi parempi. Jos haluat omistaa jokaisen kerroksen ja maksaa nollan per pyyntö, käytä Crawl4AI:ta. Jos taas haluat poistaa selainoperaatioiden vaivan ja kutsua päätepistettä, hallittu malli on se vaihtoehto. Sama moottori, joka pyörittää 100 000+ käyttäjän laajennustamme, on API:n taustalla, joten kyse ei ole lelumaisesta tasosta.
Jos punnitset koko kategoriaa laajemmin, omat kirjoituksemme aiheista AI web scraping ja avoimen lähdekoodin GitHub-scraperit, joita testasimme vastakkain menevät syvemmälle kuin mihin tässä voin päästä ilman että tästä tulee kokonaan eri artikkeli.
Tuomio: pitäisikö Crawl4AI:ta käyttää?
Kyllä — jos olet kehittäjä, joka haluaa LLM-valmista Markdownia ja rakenteista JSONia samalta renderöidyltä sivulta, rakennat RAG- tai agenttiratkaisua, ja hyväksyt oikean headless-selaimen omalla infrastruktuurillasi. Testeissäni ydin teki juuri sen mitä lupaa: 6/6 staattisessa poiminnassa, 8/8 dynaamisilla sivuilla eksplisiittisellä odotuksella, 13 476 merkkiä Markdownia live-katalogista ja siisti batch-crawl. Se on vahva, hyvin lisensoitu ja aktiivisesti ylläpidetty työkalu, joka tekee oikeaa työtä.
Lähde mukaan silmät auki kolmen asian suhteen, niin pärjäät hyvin: käyttöönotto pudottaa kaksi selainpinoa levyllesi, syväcrawl ei odota automaattisesti löytämiään dynaamisia sivuja, ja ohut virhesivu voi saada harhaanjohtavan "anti-bot"-leiman. Mikään näistä ei ole dealbreaker. Kaikki nämä yhdessä erottavat sen, odotatko ihmettä vai käytätkö oikeaa työkalua — joka on jälleen kerran selain, Markdown-muunnin ja selektorit, joita ylläpidät itse. Kun ymmärrät sen näin, tämä on yksi paremmista tavoista muuttaa live-sivut tekstiksi, jota malli voi käyttää.
Tämä on alustava arvio yhdestä testiajosta. En stressitestannut sitä tuhannen sivun crawlista, en ajanut sisältösuodattimia, en koskenut LLM-poimintapolkuun enkä Docker-palvelintilaan. Pidä mielessäni oleva pistemäärä luokkaa "vahva, mutta kotitehtäviä vielä jäljellä" eikä lopullisena arvosanana — ja tarkista tähtimäärä sekä versio ennen kuin siteeraat mitään metatiedoista, koska molemmat muuttuvat.
Kokeile Thunderbitiä web-datan poimintaan Get Started Free
Usein kysytyt kysymykset
Onko Crawl4AI:ssa itsekorjautuvia tai mukautuvia selektoreita? Ei. Tämä on yleisin väärinkäsitys. Crawl4AI käyttää staattisia CSS/XPath-skeemoja, jotka kirjoitat ja joita ylläpidät itse — jos sivusto nimeää uudelleen luokat, joihin selektorisi nojaavat, poiminta rikkoutuu kunnes korjaat skeeman. Mukautuvat, itseään uudelleen paikantavat selektorit kuuluvat toiseen työkaluun (Scrapling), eivät Crawl4AI:hin.
Tarvitsenko täyden selaimen ajaakseni Crawl4AI:ta?
Käytännössä kyllä. Sen ydinarvo on JavaScriptin renderöinti oikealla selaimella, joten crawl4ai-setup lataa kaksi selainpinoa (Playwright ja Patchright) sekä FFmpegin ja Headless Shellin. Jos haluat pienen HTTP-only-parserin ilman selainjalanjälkeä, Crawl4AI on väärä muoto, ja tarvitset kevyemmän frameworkin.
Miksi Crawl4AI sanoi "anti-bot protection" sivulla, jota ei edes estetty? Sen rakenteellinen heuristiikka liputtaa sivut, joilla on hyvin vähän näkyvää tekstiä, ja viesti viittaa antibot-suojaukseen. Omassa testissäni tahallisesti rikkinäinen HTTP 500 -sivu, jossa oli tuskin lainkaan sisältöä, sai tuon leiman, vaikka mikään ei estänyt pyyntöä. Tarkista aina statuskoodi ja oikea konteksti ennen kuin päätät, että sivusto taistelee sinua vastaan — joskus kyse on vain ohuesta tai rikki olevasta sivusta.
Käsitteleekö Crawl4AI:n syväcrawl JavaScript-sivut automaattisesti?
Ei itsestään. Suora crawl eksplisiittisellä wait_for-asetuksella onnistui dynaamisella sivullani 8/8, mutta BFS-syväcrawl, joka löysi saman sivun, epäonnistui siinä — 5 sivua löydetty, 3 onnistui, 2 epäonnistui — koska se ei odottanut JavaScriptin renderöitymistä ennen kuin katsoi sivun liian ohueksi. Jos syväcrawlisi täytyy kattaa dynaamisia sivuja, odotus pitää konfiguroida erikseen.
Miten Crawl4AI eroaa hallitusta scraping-API:sta kuten Thunderbitin ratkaisusta?
Crawl4AI on ilmainen, avoimen lähdekoodin ja itsehostattu — sinä ajat ja ylläpidät selaimen sekä infrastruktuurin itse, eikä per-kutsu-kustannusta ole. Thunderbitin kehityspino (/distill Markdownille, /extract rakenteiselle JSONille sekä MCP ja CLI) on hallittu API, jossa renderöinti, antibot-käsittely ja selainoperaatiot pyörivät meidän puolellamme ja maksat käytön mukaan. Kompromissi on täysi hallinta ja nollakustannus per pyyntö vastaan operatiivisen painon ulkoistaminen.
