Вокруг Crawl4AI уже давно крутится стойкий миф: будто бы у него есть какая-то адаптивная «интеллектуальная» система, самовосстанавливающийся механизм, который сам снова находит данные, если сайт меняет HTML. Это не так. Скорее всего, вы думаете о другом инструменте (если интересно — Scrapling). Сам Crawl4AI устроен намного проще и, честно говоря, даже полезнее: это полноценный браузер, к которому прикручен конвертер в Markdown, а сбоку добавлен извлекатель по CSS/XPath.
Я прогнал его через набор тестов: статические страницы, каталоги, страницы с рендерингом через JavaScript, заведомо сломанную страницу с HTTP 500 и небольшой deep crawl. Основа у него и правда сильная. А вот детали, которые часто оставляют без внимания — сложность установки, поведение при глубоком обходе, одно вводящее в заблуждение сообщение об ошибке — как раз и стали главной темой этого обзора. Всё ниже — предварительные выводы, основанные только на тех тестах, которые я реально запускал, а не на финальном бенчмарке. Я отдельно отмечу, что именно я не проверял, чтобы никто не цитировал меня по тем вопросам, до которых я вообще не добрался.
Что Crawl4AI на самом деле собой представляет — и чем не является
Если убрать маркетинговые формулировки, Crawl4AI — это три слоя, собранные вместе.
Во-первых, это настоящий браузер. Под капотом он использует Playwright и ещё защищённую модификацию под названием Patchright, чтобы загружать страницу так, как это сделал бы Chrome: запускать JavaScript, строить DOM и ждать контент, если вы этого попросите. Вот это и есть ключевой момент. Это не HTTP-клиент, который просто скачал сырой HTML и на этом остановился. Здесь поднимается полноценный движок рендеринга.
Во-вторых, это генератор Markdown. После рендеринга Crawl4AI превращает DOM в Markdown — именно в тот формат, который любят LLM и RAG-пайплайны. Авторы проекта прямо позиционируют его как crawler для LLM, и причина тут простая: вы передаёте URL, а в ответ получаете текст, с которым модель уже может работать.
В-третьих, это структурный извлекатель. Если вам нужен не текст, а аккуратный JSON, вы задаёте схему — CSS- или XPath-селекторы, привязанные к именам полей, через JsonCssExtractionStrategy, и на выходе получаете записи. (Есть ещё LLM-ориентированный путь извлечения, но он требует API-ключ, а я его не тестировал, так что делать вид, будто знаю, как он ведёт себя, не буду.)
А теперь главное, и именно здесь слух про «адаптивный интеллект» ошибается: схема статична, и писать её нужно вручную. Вы говорите Crawl4AI, что название товара находится в .product-card h3, а цена — в .price; если завтра сайт переименует эти классы, селекторы сломаются и так и останутся сломанными. Никакого самовосстановления нет. Никакого «примерно совпадающего» повторного поиска тоже. Это браузер, конвертер и селекторы, которые поддерживаете вы — не больше и не меньше. Если сразу понимать это правильно, не придётся ждать от инструмента функции, которая живёт совсем в другом репозитории.
Рабочие примитивы у него названы вполне прозрачно: AsyncWebCrawler — это движок, BrowserConfig настраивает браузер, а CrawlerRunConfig управляет одним запуском (в том числе параметром wait_for, к которому я ещё вернусь). Это Python API с упором на async, и когда названия начинают «щелкать», читать его становится довольно легко.
Кстати, сам репозиторий на 2026-07-07 имеет 71 259 звёзд, 7 326 форков и лицензию Apache-2.0 (unclecode/crawl4ai), а версия на тот момент — v0.9.0. Количество звёзд меняется, так что воспринимайте это как снимок на конкретный день, а не как живой счётчик — но он хорошо показывает, что перед нами востребованный проект с открытой лицензией, а не чья-то поделка на выходные.
Установка: когда на диск приезжают сразу два полных браузерных стека
Установка — это момент, когда Crawl4AI перестаёт выглядеть как лёгкая библиотека. И почти никто об этом в обзорах не пишет.
Сам pip install проходит без приключений. Команда pip install -U crawl4ai завершилась успешно — и, что особенно приятно, установилась на Python 3.14.2, хотя в документации формально указан минимум >=3.10 и на машине у меня не было рантаймов 3.10–3.13. Для тех, кто сидит на самой свежей версии интерпретатора, это хороший знак.
А потом вы запускаете crawl4ai-setup — и вот тогда диск начинает ощутимо худеть.
Этот шаг не скачивает один браузер. Он тянет сразу два полных стека — и Playwright, и Patchright — а в логе установки ещё видно, что сверху подтягиваются Chrome for Testing, FFmpeg и Headless Shell. Это и есть цена настоящего браузерного инструмента: браузеры должны где-то жить, и в этом случае они живут у вас на машине, причём дважды. Если вы работаете на ноутбуке с тесным SSD или собираете минималистичный контейнер, где важен каждый мегабайт, это нужно учитывать заранее. Это не след лёгкого HTTP-парсера, и таким он не станет.
При этом сам tooling довольно честно сообщает о своём состоянии. crawl4ai-doctor у меня запустился, прошёл проверку и за 14.65 секунды успешно обошёл https://crawl4ai.com, доказав, что браузерный путь действительно работает end-to-end. Встроенная команда-«доктор», которая реально рендерит живую страницу, — очень удачное решение: вопрос «у меня всё установилось?» получает настоящий ответ, а не неопределённое пожимание плечами.
Итак, вердикт по установке двойственный: Python-часть гладкая и терпимая, браузерная — тяжёлая. Оба утверждения верны одновременно, и это стоит знать до того, как вы решите внедрять инструмент.
Практика: что выдержало тесты, с реальными цифрами
Я собрал локальный тестовый сайт с известной «истиной» — статические товары, товары с JS-рендерингом, статья с намеренно вставленным boilerplate-текстом, битая 500-страница и небольшой граф ссылок — и прогнал Crawl4AI по нему, а также по двум публичным демо-сайтам. Вот что получилось.
Статические страницы: полный успех. Официальный quickstart на example.com вернул Markdown за 1.81 секунды. На моём локальном статическом каталоге Markdown сохранил все 6/6 ожидаемых названий товаров, а извлечение по CSS-схеме вернуло все 6 записей в JSON — имя, категория, цена, рейтинг и ссылка на карточку, всё на месте. Без сюрпризов.
Динамические страницы: тоже без проблем, если дать правильную команду. И вот здесь важная оговорка. На моём каталоге с JS-рендерингом добавление wait_for="css:.product-card" в конфиг запуска дало 8/8 совпадений по товарам и в Markdown, и в schema extraction. На публичной странице quotes.toscrape.com/js он отрисовал JavaScript-инжектированные цитаты и сохранил рабочий скриншот как доказательство того, что браузер действительно отрисовал контент. Слово «dynamic» тут не рекламный оптимизм — браузер правда рендерит страницу. Но вы должны сказать ему, чего ждать. Пропустите wait_for, и вы заберёте наполовину собранную страницу.
Пакетный запуск: работает. arun_many() по шести локальным URL товаров вернул 6/6, все ответы — 200, за один конкурентный проход. Выборка небольшая, но путь параллельного выполнения сработал так, как и обещано.
Объём Markdown с реального сайта. На публичной главной странице Books to Scrape Crawl4AI сгенерировал 13 476 символов Markdown из живой страницы одним вызовом — это хорошо показывает, сколько LLM-ready текста может дать один обход реального каталога.
Теперь о шероховатостях — о том, что проявляется только после выхода за пределы happy path.
Raw Markdown по замыслу широкий. В моём тестовом article fixture Crawl4AI забрал заголовок и все 3/3 абзаца основного текста — но также прихватил текст навигации, блок со связанными ссылками, фальшивую строку подписки и футер. Это не баг; это и есть смысл raw Markdown conversion. Вся отрисованная страница становится Markdown, включая служебные блоки. Если вам нужен действительно чистый текст статьи, документация советует включать content filter — PruningContentFilter оценивает узлы по плотности текста относительно ссылок и отбрасывает мусор, а BM25ContentFilter ранжирует содержимое относительно запроса. В этом проходе я эти фильтры не запускал, поэтому не буду придумывать им оценку чистоты — но модель поведения ясна: raw Markdown — это широкий дефолт, а чистый Markdown включается фильтром. Не ждите редакционно вылизанного результата от пути без настройки.
500-страница слегка соврала. Я подал Crawl4AI специально сломанную страницу, которая возвращает HTTP 500. Он корректно отметил success=false и статус 500 — но сообщение об ошибке звучало как «Blocked by anti-bot protection: Structural: minimal_text on small page». Никакой антибот-защиты там не было. Это была крошечная error page с почти отсутствующим видимым текстом, и структурная эвристика Crawl4AI увидела тонкое содержимое и решила пометить его как антибот-блокировку. Вывод для тех, кто будет использовать его на масштабе: не доверяйте формулировке «anti-bot» буквально. Сначала смотрите на статус-код и контекст, а уже потом делайте вывод, что сайт действительно сопротивляется. Иногда это просто маленькая страница.
Deep crawl не наследует ваши ожидания автоматически. Это, пожалуй, самый важный вывод, если вы собираетесь собирать обход сайта. Прямой обход моей динамической страницы с wait_for сработал идеально — 8/8. Но когда я дал BFS deep crawler самому находить ссылки с главной страницы и идти по ним, он обнаружил 5 страниц, успешно обработал 3 и провалил 2. Одна из неудач — та самая динамическая страница каталога, которая отлично работает при явном ожидании. В deep crawl он увидел 45 символов предрендерного текста, решил, что страница слишком «тонкая», и завершил работу с тем же вводящим в заблуждение сообщением про антибот-защиту ещё до того, как JavaScript успел отработать.
Вывод точный: фраза «Crawl4AI поддерживает динамические страницы» — правда, а фраза «deep crawl автоматически ждёт каждую динамическую страницу, которую он нашёл» — нет. Это две разные документированные функции — ожидание на уровне страницы и стратегии deep crawl — и сами по себе они не сливаются. Если deep crawl должен уметь работать с JS-тяжёлыми страницами, ожидание нужно явно встраивать в конфигурацию обхода. Это не баг, а реальность настройки, но если вы думаете, что happy path автоматически масштабируется на найденные ссылки, он вас обязательно укусит.
Плюсы и минусы — без дипломатии
За что он получает свои звёзды:
- Одна библиотека закрывает сразу много задач: Markdown из рендеринга, структурный JSON, скриншоты, batch crawling и deep crawling — без склеивания четырёх разных инструментов.
- Статическое извлечение работает идеально — в моих тестах было 6/6 по Markdown и 6/6 по структурным записям, быстро и без потерь.
- Динамический рендеринг действительно работает, потому что рендерит его настоящий браузер — 8/8 при явном ожидании, что подтверждено скриншотом.
- Лицензия Apache-2.0, удобная для коммерческого использования, и активно развиваемый проект (v0.9.0) с большим сообществом.
- Встроенный
crawl4ai-doctor, который рендерит реальную страницу и подтверждает, что установка действительно работает.
За что приходится платить:
- Тяжёлая первая установка: два браузерных стека плюс FFmpeg и Headless Shell на диске. На ограниченных машинах это ощутимо.
- Raw Markdown содержит служебные блоки, если не включить content filter — «чистый» путь не дефолтный, а осознанный.
- Deep crawling не подхватывает ваши ожидания для динамических страниц автоматически; JS-страницы, найденные в процессе обхода, могут падать без дополнительной настройки.
- Сообщения об ошибках могут вводить в заблуждение — тонкая 500-страница у меня получила ярлык «anti-bot protection», хотя никто ничего не блокировал.
- Никаких self-healing селекторов нет. Ваша CSS/XPath-схема статична, и именно вы должны поддерживать её при изменении разметки.
Кому стоит использовать Crawl4AI, а кому лучше пройти мимо
Используйте его, если вы разработчик и строите RAG- или agent-пайплайн, где нужен один инструмент, который отдаёт и LLM-ready Markdown, и структурированный JSON с одной и той же отрендеренной страницы. Если ваши источники тяжело нагружены JavaScript, если вы готовы писать явные ожидания и если вам комфортно запускать настоящий headless browser на своей инфраструктуре, Crawl4AI — сильный и хорошо поддерживаемый вариант. Связка «Markdown для модели плюс schema для базы данных» в одной библиотеке с лицензией Apache-2.0 — это реально удобно.
Пропустите его, если вам нужен лёгкий HTTP-парсер, который за миллисекунды тянет статический HTML без браузера — Crawl4AI сознательно тяжелее, и одни только загрузки браузеров уже могут раздражать. Пропустите его, если у вас мало дискового пространства или канала, либо если вы разворачиваете минимальный контейнер, где два браузерных стека — это уже перебор. И уж точно проходите мимо, если ищете self-healing селекторы — такая функция действительно существует, просто не в этом инструменте.
Где уместен managed API — взгляд через Thunderbit
Попробовать Thunderbit для извлечения веб-данных
Всё, что описано выше, исходит из того, что вы хотите сами запускать браузер. Это вполне разумный выбор, и для многих команд он действительно лучший: полный контроль, нулевая стоимость за вызов, код полностью под вашим управлением. Но важно честно назвать компромисс, потому что в Thunderbit мы строили developer stack на обратной модели: убрать браузер, антибот-защиту и JavaScript-рендеринг с вашей машины полностью.
Параллель достаточно близкая, чтобы сравнивать напрямую. Наш endpoint POST /distill делает то же, что Markdown-путь Crawl4AI: страница входит, на выходе — чистый LLM-ready Markdown, только JS-рендеринг и антибот-слой выполняются у нас, а не в браузере, который вы установили. Наш POST /extract закрывает структурную часть и возвращает JSON по заданной вами схеме, а вместо ручной настройки wait_for использует переключатель renderMode (none, basic, full). У обоих есть batch-версии. Есть и MCP server — thunderbit_distill, thunderbit_extract и бесплатный thunderbit_suggest_fields, чтобы агент в Claude или Cursor мог вызывать всё напрямую, а ещё есть npx @thunderbit/thunderbit-cli для терминала, CI и cron.
Суть выбора — в том, кто несёт нагрузку. Crawl4AI бесплатный, open-source и self-hosted, а операционную тяжесть несёте вы сами — загрузки браузеров, wiring для deep crawl, машина, на которой всё это работает. Наш developer stack — это managed API, где эта нагрузка лежит на нас, а вы платите за каждый вызов. Нельзя сказать, что один вариант всегда лучше другого. Если вы хотите контролировать каждый слой и не платить за запросы, берите Crawl4AI. Если вы хотите избавиться от браузерной операционки и просто вызывать endpoint, тогда managed route выглядит логично. За API стоит тот же движок, что и в нашем расширении с аудиторией более 100 000 пользователей, так что это точно не игрушечный уровень.
Если вас интересует более широкий контекст, наши собственные материалы про AI web scraping и open-source GitHub scrapers, которые мы сравнивали напрямую, идут заметно глубже, чем я могу уйти здесь, не превращая этот текст в совсем другую статью.
Итог: стоит ли использовать Crawl4AI?
Да — если вы разработчик, которому нужны LLM-ready Markdown и структурированный JSON из одной и той же отрендеренной страницы, если вы строите RAG- или agent-систему и готовы принять настоящий headless browser на своей инфраструктуре. В моих тестах core делал именно то, что обещает: 6/6 на статическом извлечении, 8/8 на динамических страницах с явным ожиданием, 13 476 символов Markdown с живого каталога и чистый batch crawling. Это сильный, хорошо лицензированный и активно поддерживаемый инструмент, который действительно работает.
Только заходите в него с ясной головой и помните о трёх вещах: при установке на диск ложатся два браузерных стека, deep crawl не ждёт динамические страницы автоматически, а тонкая error page может получить сбивающую с толку метку «anti-bot». Ни одно из этих замечаний не является критичным. Но все вместе они и отличают ожидание чуда от работы с реальным инструментом — который, опять же, является браузером, конвертером Markdown и набором селекторов, которые вы поддерживаете сами. Если воспринимать его именно так, это один из лучших способов превращать живые страницы в текст, пригодный для модели.
Это предварительный вывод по итогам одного прогона. Я не гонял его на обходе в тысячу страниц, не запускал content filters, не трогал LLM-extraction path и не проверял Docker server mode. Считайте эту оценку формулой «сильный инструмент, но домашка ещё осталась», а не окончательным приговором — и обязательно перепроверьте звёзды и версию перед тем, как цитировать метаданные, потому что оба параметра меняются.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
Часто задаваемые вопросы
Есть ли у Crawl4AI self-healing или адаптивные селекторы? Нет. Это самое распространённое заблуждение о нём. Crawl4AI использует статические CSS/XPath-схемы, которые вы пишете и поддерживаете сами — если сайт переименует классы, на которых держатся ваши селекторы, извлечение сломается, пока вы не исправите схему. Адаптивные селекторы, которые сами находят новое место, — это функция другого инструмента (Scrapling), а не Crawl4AI.
Нужен ли полный браузер, чтобы запускать Crawl4AI?
Практически да. Его главная ценность — рендеринг JavaScript в настоящем браузере, поэтому crawl4ai-setup скачивает два браузерных стека (Playwright и Patchright), а также FFmpeg и Headless Shell. Если вам нужен крошечный HTTP-only парсер без браузерного следа, Crawl4AI для этого не подходит — лучше смотреть в сторону более лёгкого фреймворка.
Почему Crawl4AI написал "anti-bot protection" на странице, которую никто не блокировал? Его структурная эвристика помечает страницы с очень небольшим количеством видимого текста, а в сообщении используется формулировка про anti-bot protection. В моём тесте специально созданная HTTP 500-страница почти без контента получила именно такую метку, хотя никакой блокировки запроса не было. Всегда смотрите на статус-код и реальный контекст, прежде чем делать вывод, что сайт вам мешает — иногда это просто тонкая или сломанная страница.
Умеет ли deep crawl Crawl4AI автоматически работать с JavaScript-страницами?
Сам по себе — нет. Прямой обход с явным wait_for отлично обработал мою динамическую страницу, дав 8/8, а вот BFS deep crawl, который нашёл ту же страницу, провалился на ней — 5 страниц найдено, 3 успешно, 2 с ошибкой — потому что не дождался рендера JavaScript до оценки страницы как слишком тонкой. Если deep crawl должен покрывать динамические страницы, ожидание нужно настраивать явно.
Чем Crawl4AI отличается от managed scraping API вроде Thunderbit?
Crawl4AI — бесплатный, open-source и self-hosted: вы сами запускаете и поддерживаете браузер и инфраструктуру, без оплаты за каждый запрос. Developer stack Thunderbit (/distill для Markdown, /extract для структурированного JSON, а также MCP и CLI) — это managed API, где рендеринг, антибот-обработка и браузерная операционка выполняются на нашей стороне, а вы платите за каждый вызов. Разница — между полным контролем и нулевой ценой за запрос, с одной стороны, и передачей операционной нагрузки наружу — с другой.
