Wokół Crawl4AI krąży uporczywa legenda: że narzędzie ma jakąś adaptacyjną inteligencję, samonaprawiający się mechanizm, który ponownie odnajduje dane, gdy strona przestawi swój HTML. To nieprawda. To zupełnie inne narzędzie (jeśli jesteś ciekaw, chodzi o Scrapling). Crawl4AI jest czymś bardziej konkretnym i — szczerze mówiąc — łatwiejszym do zrozumienia: to headless browser połączony z konwerterem do Markdown, a obok działa ekstraktor CSS/XPath.
Przeprowadziłem serię testów na stronach statycznych, katalogach renderowanych przez JavaScript, celowo uszkodzonej stronie 500 oraz niewielkim deep crawl. Rdzeń działa naprawdę dobrze. Części, które zwykle się pomija — ciężar instalacji, zachowanie podczas głębokiego crawl, jedno mylące сообщение o błędzie — to właśnie one są tematem reszty tej recenzji. Wszystko poniżej ma charakter wstępny i opiera się na testach, które faktycznie wykonałem, a nie na ostatecznym benchmarku. Zaznaczę też, czego nie sprawdzałem, żeby nikt nie cytował mnie w kwestiach, których nigdy nie dotykałem.
Czym Crawl4AI naprawdę jest (i czym nie jest mit)
Odetnijmy warstwę marketingową: Crawl4AI składa się z trzech elementów ułożonych jeden na drugim.
Po pierwsze, to prawdziwa przeglądarka. Pod spodem korzysta z Playwright, a także ze specjalnie podmienionej, bardziej „stealth” wersji o nazwie Patchright, aby ładować stronę tak, jak zrobiłby to Chrome — uruchamiać JavaScript, budować DOM i czekać na treść, jeśli mu to wskażesz. I to jest najważniejsze. To nie jest klient HTTP, który po prostu pobiera surowy HTML i na tym kończy pracę. To uruchomiony silnik renderujący.
Po drugie, to generator Markdown. Gdy strona zostanie wyrenderowana, Crawl4AI zamienia DOM na Markdown — format, który lubią LLM-y i pipeline’y RAG. Twórcy pozycjonują cały projekt właśnie jako crawler przyjazny dla LLM, bo o to dokładnie chodzi: podajesz URL, a dostajesz tekst, nad którym model może pracować.
Po trzecie, to ekstraktor strukturalny. Jeśli zamiast prozy chcesz czyste JSON-y, przekazujesz schemat — mapowanie selektorów CSS lub XPath na nazwy pól — przez JsonCssExtractionStrategy, a narzędzie zwraca rekordy. (Istnieje też ścieżka ekstrakcji oparta o LLM, ale wymaga klucza API i nie testowałem jej, więc nie będę udawał, że wiem, jak się zachowuje.)
I tu właśnie leży sedno, którego nie rozumie plotka o „adaptive intelligence”: schemat jest statyczny i tworzysz go ręcznie. Mówisz Crawl4AI, że nazwa produktu znajduje się w .product-card h3, a cena w .price, i jeśli strona jutro zmieni nazwy klas, selektory się psują i pozostają zepsute. Nic się samo nie naprawia. Nie ma żadnego fuzzy re-matching. To przeglądarka, konwerter i selektory, które sam utrzymujesz — nic więcej i nic mniej. Zrozumienie tego od początku oszczędza rozczarowania wynikające z oczekiwania funkcji, która znajduje się w zupełnie innym repo.
Praktyczne prymitywy są nazwane całkiem sensownie: AsyncWebCrawler to silnik, BrowserConfig ustawia przeglądarkę, a CrawlerRunConfig kontroluje pojedyncze uruchomienie (w tym wait_for, do którego jeszcze wrócę). To asynchroniczne API Pythona, które po zaskoczeniu nazwami staje się całkiem czytelne.
Dla porządku: repozytorium miało 71 259 gwiazdek, 7 326 forków i licencję Apache-2.0 w dniu 2026-07-07 (unclecode/crawl4ai), na wydaniu v0.9.0. Liczba gwiazdek zmienia się z czasem, więc traktuj to jako migawkę, nie stan na żywo — ale i tak pokazuje to, że mamy do czynienia z szeroko używanym projektem o liberalnej licencji, a nie weekendowym eksperymentem.
Instalacja: moment, w którym dwa pełne stosy przeglądarek lądują na dysku
Instalacja to ten etap, w którym Crawl4AI przestaje przypominać lekką bibliotekę — i właśnie o tym prawie nikt nie pisze.
Samo pip install nie robi problemów. pip install -U crawl4ai zakończył się bezboleśnie — i co ważne, zadziałał na Pythonie 3.14.2, mimo że dokumentacja formalnie prosi o >=3.10 i na mojej maszynie nie było żadnego runtime 3.10–3.13. To dobry znak dla osób korzystających z najnowszych interpreterów.
Potem uruchamiasz crawl4ai-setup — i właśnie wtedy zaczyna się zapełniać dysk.
Krok instalacyjny nie pobiera jednej przeglądarki. Pobiera dwa pełne stosy — Playwright i Patchright — a log pokazuje dodatkowo ściąganie Chrome for Testing, FFmpeg i Headless Shell. To koszt bycia narzędziem opartym na prawdziwej przeglądarce: przeglądarki muszą gdzieś żyć, a tutaj żyją na Twojej maszynie, i to podwójnie. Jeśli pracujesz na laptopie z ciasnym SSD albo budujesz lekki obraz kontenera, w którym liczy się każdy megabajt, trzeba to uwzględnić. To nie jest ślad zajmowany przez czysty parser HTTP — i nigdy nim nie będzie.
Na plus: narzędzie samo mówi prawdę o swoim stanie. crawl4ai-doctor uruchomił się, przeszedł test i w 14,65 sekundy zeskrobał https://crawl4ai.com, żeby udowodnić, że ścieżka przez przeglądarkę działa od końca do końca. Wbudowana komenda diagnostyczna, która faktycznie renderuje żywą stronę, to świetny detal — oznacza, że pytanie „czy instalacja działa?” dostaje realną odpowiedź, a nie wzruszenie ramionami.
Wniosek z instalacji jest więc mieszany: strona Pythona jest płynna i wyrozumiała, strona przeglądarki — ciężka. Obie rzeczy są prawdziwe jednocześnie i warto o nich wiedzieć, zanim się zdecydujesz.
Testy praktyczne: co się sprawdziło, z konkretnymi liczbami
Zbudowałem lokalny serwis testowy z ustaloną prawdą referencyjną — statyczne produkty, produkty renderowane przez JS, artykuł z celowym boilerplate, zepsutą stronę 500 i małym grafem linków — a potem podpiąłem pod to Crawl4AI oraz dwa publiczne demo. Oto wynik.
Strony statyczne: pełen sukces. Oficjalny quickstart dla example.com zwrócił Markdown w 1,81 s. Na moim lokalnym katalogu statycznym Markdown zachował wszystkie 6/6 oczekiwanych nazw produktów, a ekstrakcja na podstawie schematu CSS wyciągnęła wszystkie 6 rekordów jako JSON — nazwa, kategoria, cena, ocena i URL szczegółów, każde pole nienaruszone. Bez dramatu.
Strony dynamiczne: też bez problemu, jeśli poprosisz właściwie. I to jest kluczowy warunek. Na moim katalogu renderowanym przez JS dodanie wait_for="css:.product-card" do konfiguracji uruchomienia dało 8/8 trafień produktów zarówno w Markdown, jak i w ekstrakcji schematem. Na publicznej stronie quotes.toscrape.com/js zrenderował cytaty wstrzyknięte przez JavaScript i zapisał użyteczny zrzut ekranu jako dowód, że przeglądarka naprawdę wyrenderowała treść. Słowo „dynamiczne” nie jest tu życzeniowe — przeglądarka rzeczywiście renderuje. Ale trzeba jej powiedzieć, na co ma czekać. Bez wait_for zbierasz stronę w połowie budowy.
Batch: działa stabilnie. arun_many() na sześciu lokalnych URL-ach produktów zwrócił 6/6, wszystkie odpowiedzi 200, w jednym równoległym przebiegu. Mała próba, ale ścieżka współbieżności zrobiła to, co obiecuje.
Objętość Markdown z prawdziwej strony. Dla publicznej strony głównej Books to Scrape Crawl4AI wygenerował 13 476 znaków Markdown z żywej strony w jednym wywołaniu — to daje bardzo namacalne wyobrażenie, ile tekstu gotowego dla LLM-a może wypluć pojedynczy crawl na rzeczywistym katalogu.
Teraz mniej wygładzone miejsca — te, które wychodzą na jaw dopiero poza happy path.
Surowy Markdown jest szeroki z założenia. Na moim artykule testowym Crawl4AI pobrał tytuł i wszystkie 3/3 akapity treści — ale także tekst z nawigacji, blok linków powiązanych, fałszywą linię subskrypcji i stopkę. To nie wada; tak właśnie działa konwersja do surowego Markdown. Cała wyrenderowana strona trafia do Markdown, łącznie z boilerplate. Jeśli chcesz naprawdę czysty artykuł, dokumentacja zaleca włączenie filtra treści — PruningContentFilter ocenia węzły po stosunku tekstu do linków i usuwa śmieci, a BM25ContentFilter rankuje je względem zapytania. W tym podejściu nie uruchamiałem tych filtrów, więc nie podaję im punktacji czystości — ale model mentalny jest jasny: surowy Markdown to szeroki domyślny wynik, a czysty Markdown to filtr, który trzeba świadomie włączyć. Nie oczekuj wyników klasy redakcyjnej z trybu bez konfiguracji.
Strona 500 powiedziała małe kłamstwo. Kazałem Crawl4AI odwiedzić celowo uszkodzoną stronę zwracającą HTTP 500. Narzędzie poprawnie zgłosiło success=false oraz status 500 — ale komunikat błędu brzmiał: „Blocked by anti-bot protection: Structural: minimal_text on small page.” Żadnej blokady anty-bot nie było. To była mała strona błędu z prawie zerową ilością widocznego tekstu, a heurystyka strukturalna Crawl4AI zobaczyła chudą treść i przypięła etykietę anty-bot. Wniosek dla osób pracujących na większą skalę: nie ufaj na słowo sformułowaniu „anti-bot”. Zanim uznasz, że witryna z Tobą walczy, sprawdź status code i rzeczywisty kontekst. Czasem to po prostu mała strona.
Deep crawl nie dziedziczy Twoich waitów. To byłby mój najważniejszy wniosek przed podpinaniem crawla pod produkcję. Bezpośredni crawl mojej dynamicznej strony z wait_for zadziałał idealnie — 8/8. Ale kiedy pozwoliłem BFS deep crawlerowi samemu odkrywać linki ze strony głównej i podążać za nimi, znalazł 5 stron, 3 obsłużył poprawnie, a 2 nie. Jedną z porażek była właśnie ta sama dynamiczna strona katalogu — ta, która działa dobrze przy jawnie ustawionym wait. W deep crawl zobaczył 45 znaków tekstu sprzed renderowania, uznał stronę za zbyt „chudą” i odrzucił ją z tym samym mylącym komunikatem o „anti-bot” zanim JavaScript zdążył się skończyć.
Wniosek jest bardzo precyzyjny: „Crawl4AI obsługuje strony dynamiczne” — tak; „deep crawl automatycznie poczeka na każdą dynamiczną stronę, którą odkryje” — nie. To dwie osobne udokumentowane funkcje: waity per strona i strategie deep crawl, które same z siebie się nie łączą. Jeśli deep crawl ma obsługiwać strony ciężkie od JS, musisz świadomie włączyć czekanie w konfiguracji. To nie bug, tylko realia konfiguracji — ale jeśli założysz, że happy path skaluje się na odkryte linki bez zmian, z pewnością się potkniesz.
Plusy i minusy, bez owijania w bawełnę
Za co zdobywa gwiazdki:
- Jedna biblioteka pokrywa dużo terenu: renderowany Markdown, strukturalną ekstrakcję JSON, zrzuty ekranu, batch crawling i deep crawling — bez sklejania czterech narzędzi.
- Ekstrakcja ze stron statycznych jest żelazna — w moich testach 6/6 trafień w Markdown i 6/6 rekordów strukturalnych, szybko i bez strat.
- Renderowanie dynamiczne naprawdę działa, bo naprawdę renderuje je prawdziwa przeglądarka — 8/8 z jawnym waitem, potwierdzone zrzutem ekranu.
- Licencja Apache-2.0, przyjazna do zastosowań komercyjnych, oraz aktywnie rozwijany projekt (v0.9.0) z dużą społecznością.
- Wbudowany
crawl4ai-doctor, który renderuje prawdziwą stronę i potwierdza, że instalacja faktycznie działa.
Za co płacisz:
- Ciężka pierwsza instalacja: dwa stosy przeglądarek plus FFmpeg i Headless Shell na dysku. To realny problem na ograniczonych maszynach.
- Surowy Markdown zawiera boilerplate, chyba że włączysz filtr treści — ścieżka do czystego wyniku wymaga świadomego działania, nie jest domyślna.
- Deep crawling nie zastosuje automatycznie waitów dla dynamicznych stron; odkryte w trakcie crawl strony JS mogą się wyłożyć bez dodatkowej konfiguracji.
- Komunikaty o błędach potrafią wprowadzać w błąd — cienka strona 500 została opisana jako „anti-bot protection”, choć nic niczego nie blokowało.
- Brak samonaprawiających się selektorów. Twój schemat CSS/XPath jest statyczny i to Ty musisz go utrzymywać, gdy zmienia się markup.
Dla kogo Crawl4AI ma sens, a kto powinien przejść obok
Warto go użyć, jeśli jesteś developerem budującym pipeline RAG albo agenta i chcesz jednym narzędziem dostać zarówno Markdown gotowy dla LLM, jak i ustrukturyzowany JSON z tej samej wyrenderowanej strony. Jeśli Twoje źródła są mocno zależne od JavaScriptu, nie przeszkadza Ci pisanie jawnych waitów i możesz uruchamiać prawdziwą headless browser na własnej infrastrukturze, Crawl4AI jest mocnym i dobrze utrzymanym wyborem. Połączenie „Markdown dla modelu” plus „schema dla bazy” w jednej bibliotece Apache-2.0 to prawdziwa wygoda.
Pomiń go, jeśli szukasz lekkiego parsera HTTP, który pobiera statyczny HTML w milisekundach i nie zostawia po sobie śladu przeglądarki — Crawl4AI jest celowo cięższy, a same pobierane przeglądarki będą Cię irytować. Pomiń go, jeśli masz mało miejsca na dysku albo ograniczony transfer, albo wdrażasz w minimalnym kontenerze, gdzie dwa stosy przeglądarek są nie do przyjęcia. I zdecydowanie go pomiń, jeśli przyszedłeś po samonaprawiające się selektory — to prawdziwa funkcja, ale nie tego narzędzia.
Gdzie pasuje zarządzane API — perspektywa Thunderbit
Wypróbuj Thunderbit do ekstrakcji danych z sieci
Wszystko powyżej zakłada, że chcesz uruchamiać przeglądarkę samodzielnie. To uzasadniony wybór, a dla wielu zespołów nawet najlepszy — pełna kontrola, brak kosztu za wywołanie, kod należący do Ciebie od początku do końca. Warto jednak nazwać uczciwie kompromis, który zawierasz, bo w Thunderbit zbudowaliśmy nasz stack developerski wokół odwrotnej decyzji: przeglądarka, obsługa anty-bot i renderowanie JavaScriptu mają nie obciążać Twojej maszyny.
Analogii jest tu wystarczająco dużo, żeby porównanie było uczciwe. Nasz endpoint POST /distill robi to samo, co ścieżka Markdown w Crawl4AI — strona wchodzi, a na wyjściu dostajesz czysty Markdown gotowy dla LLM — z tą różnicą, że renderowanie JS i warstwa anty-bot działają po naszej stronie, a nie w przeglądarce, którą sam zainstalowałeś. Endpoint POST /extract pokrywa stronę strukturalną, zwracając JSON zgodny ze schematem, który zdefiniujesz, z przełącznikiem renderMode (none, basic, full) zamiast wait_for, który trzeba ręcznie dostrajać. Oba mają wersje batch. Jest też serwer MCP — thunderbit_distill, thunderbit_extract oraz darmowe thunderbit_suggest_fields — więc agent w Claude albo Cursor może wywołać go bezpośrednio, a npx @thunderbit/thunderbit-cli działa w terminalu, CI i cron.
Różnica sprowadza się do tego, kto dźwiga ciężar. Crawl4AI jest darmowy, open source i self-hosted, więc to Ty ponosisz ciężar operacyjny — pobranie przeglądarek, konfigurację deep crawl i maszynę, na której to wszystko działa. Nasz stack developerski to zarządzane API, gdzie ten ciężar jest po naszej stronie, a koszt przenosi się na użycie per call. Żadne z tych rozwiązań nie jest uniwersalnie lepsze. Jeśli chcesz kontrolować każdy poziom i nic nie płacić za żądanie, uruchom Crawl4AI. Jeśli wolisz usunąć problem operowania przeglądarką i po prostu wywołać endpoint, to jest argument za ścieżką managed. Ten sam silnik, który napędza naszą wtyczkę używaną przez ponad 100 000 użytkowników, stoi też za API, więc nie mówimy o zabawce.
Jeśli rozważasz szerszą kategorię, nasze własne materiały o AI web scraping oraz o open-source’owych scraperach GitHub testowanych łeb w łeb wchodzą głębiej niż mogę tutaj, bez zamieniania tej recenzji w zupełnie inny artykuł.
Werdykt: czy warto używać Crawl4AI?
Tak — jeśli jesteś developerem, który chce z tej samej wyrenderowanej strony dostać Markdown gotowy dla LLM i ustrukturyzowany JSON, budujesz rozwiązanie pod RAG lub agentów i akceptujesz prawdziwą headless browser na swojej infrastrukturze. W moich testach rdzeń zrobił dokładnie to, co obiecuje: 6/6 w ekstrakcji statycznej, 8/8 na stronach dynamicznych z jawnym waitem, 13 476 znaków Markdown z żywego katalogu i bezproblemowy batch crawling. To solidne, dobrze licencjonowane i aktywnie rozwijane narzędzie, które faktycznie pracuje.
Wejdź w to z jasną świadomością trzech rzeczy, a wszystko będzie w porządku: instalacja wrzuca na dysk dwa stosy przeglądarek, deep crawling nie poczeka automatycznie na dynamiczne strony, które odkryje, a cienka strona błędu może dostać mylący label „anti-bot”. Żadna z tych rzeczy nie jest dealbreakerem. Wszystkie są różnicą między oczekiwaniem cudu a korzystaniem z realnego narzędzia — a to, jeszcze raz, jest przeglądarka, konwerter Markdown i utrzymywane przez Ciebie selektory. Jeśli rozumiesz je właśnie tak, to jest to jeden z lepszych sposobów na zamianę żywych stron w tekst, z którego model może korzystać.
To wstępny obraz na podstawie jednego przebiegu testowego. Nie męczyłem tego crawl’em na tysiąc stron, nie uruchamiałem filtrów treści, nie dotykałem ścieżki ekstrakcji LLM ani trybu serwera Docker. Traktuj mój wynik jako „mocny, ale z pracą domową do zrobienia”, a nie jako końcową ocenę — i sprawdź jeszcze raz liczbę gwiazdek oraz wersję, zanim zacytujesz którekolwiek metadatas, bo obie rzeczy się zmieniają.
Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free
FAQ
Czy Crawl4AI ma samonaprawiające się albo adaptacyjne selektory? Nie. To najczęstsze nieporozumienie dotyczące tego narzędzia. Crawl4AI używa statycznych schematów CSS/XPath, które sam tworzysz i utrzymujesz — jeśli strona zmieni nazwy klas, od których zależą selektory, ekstrakcja przestanie działać, dopóki nie poprawisz schematu. Adaptacyjne, samoczynnie odnajdujące selektory to cecha innego narzędzia (Scrapling), nie Crawl4AI.
Czy do uruchomienia Crawl4AI potrzebuję pełnej przeglądarki?
W praktyce tak. Jego największą zaletą jest renderowanie JavaScriptu w prawdziwej przeglądarce, więc crawl4ai-setup pobiera dwa stosy przeglądarek (Playwright i Patchright) oraz FFmpeg i Headless Shell. Jeśli chcesz maleńkiego parsera HTTP bez śladu przeglądarki, Crawl4AI nie jest właściwym wyborem — lepszy będzie lekki framework.
Dlaczego Crawl4AI napisał „anti-bot protection” na stronie, która nie była blokowana? Heurystyka strukturalna oznacza strony z bardzo małą ilością widocznego tekstu, a w komunikacie pojawia się wzmianka o ochronie anty-bot. W moim teście celowa strona HTTP 500 z niemal zerową treścią dostała właśnie taką etykietę, mimo że nic nie blokowało żądania. Zawsze sprawdzaj status code i rzeczywisty kontekst, zanim uznasz, że witryna aktywnie Cię odcina — czasem to po prostu cienka albo uszkodzona strona.
Czy deep crawl w Crawl4AI sam obsługuje strony JavaScriptowe?
Nie sam z siebie. Bezpośredni crawl z jawnym wait_for poradził sobie z moją dynamiczną stroną w 8/8, ale BFS deep crawl, który odkrył tę samą stronę, nie — 5 stron znalezionych, 3 udane, 2 nieudane — bo nie poczekał na renderowanie JavaScriptu, zanim uznał stronę za zbyt cienką. Jeśli deep crawl ma obejmować dynamiczne strony, trzeba świadomie skonfigurować czekanie.
Czym Crawl4AI różni się od zarządzanego API do scrapingu, takiego jak Thunderbit?
Crawl4AI jest darmowy, open source i self-hosted — to Ty uruchamiasz i utrzymujesz przeglądarkę oraz infrastrukturę, bez kosztu per call. Stack developerski Thunderbit (/distill dla Markdown, /extract dla strukturalnego JSON, plus MCP i CLI) to zarządzane API, w którym renderowanie, obsługa anty-bot i operacje przeglądarki dzieją się po naszej stronie, a Ty płacisz za użycie. Kompromis to pełna kontrola i brak kosztu za żądanie kontra przeniesienie ciężaru operacyjnego na usługę zewnętrzną.
