FirecrawlAgent: известный инструмент для AI-обучения и агентов

FirecrawlAgent — не безымянный «сервисный обход», а продукт конкретной, хорошо известной в разработческой среде компании Firecrawl (Mendable.ai): API для превращения любого сайта в чистый markdown или структурированные данные для AI-агентов и LLM. Токен встречается в крупных открытых списках AI-краулеров (например, в проекте ai-robots-txt) рядом с GPTBot и подобными — и это не случайность: Firecrawl прямо продвигает себя в том числе как инструмент сбора данных для обучения языковых моделей.

1. Что такое FirecrawlAgent на самом деле

Firecrawl — API-сервис для разработчиков: по запросу превращает любой URL в чистый markdown, структурированный JSON, краткое содержание или скриншот, убирая навигацию, рекламу и скрипты. Каждый запрос выполняется в реальном браузере Chromium — то есть с полным рендерингом JavaScript, как у настоящего посетителя, а не лёгким HTTP-запросом. Сервис умеет обходить целый домен целиком (endpoint /crawl), масштабируясь до сотен параллельных браузеров и миллионов URL в день.

Ключевая особенность, объясняющая широту применения: Firecrawl — это инфраструктура, которую покупают и используют множество разных, никак не связанных между собой разработчиков и компаний для собственных целей: RAG-пайплайны, AI-агенты, конкурентная разведка, обогащение лидов, мониторинг цен — и, отдельно заявлено, подготовка обучающих датасетов для LLM. Поэтому за одним и тем же UA может стоять любая из этих задач в зависимости от конкретного клиента Firecrawl.

2. Зачем FirecrawlAgent приходит на сайт

• клиент Firecrawl собирает данные для RAG-системы или AI-агента, которому нужен контекст с вашего сайта в реальном времени;
• подготовка обучающего датасета для языковой модели — сервис прямо рекламирует эту задачу как один из основных сценариев использования;
• конкурентная разведка, обогащение лидов, мониторинг цен — прикладные бизнес-задачи клиентов, не связанные с AI напрямую;
• поскольку это self-service API, конкретную цель для конкретного визита на конкретный сайт со стороны узнать невозможно — только характер обхода (глубина, охват, повторяемость) может дать косвенную подсказку.

Типичный кейс: системный обход всего домена — от главной до глубокой пагинации — с полным рендерингом каждой страницы. Из-за реального браузера в основе такой обход по нагрузке ощутимо тяжелее, чем у лёгких HTTP-ботов вроде go-http-client или aiohttp, даже при сопоставимом количестве запросов.

3. Нагрузка и риски

Здесь стоит явно усилить формулировку черновика: нагрузка от FirecrawlAgent — не только «фон в аналитике», а потенциально ощутимый расход ресурсов именно из-за полного рендеринга JS в реальном браузере на каждый запрос. При массовом обходе целого домена (что сервис прямо умеет делать в промышленных масштабах) origin-сервер получает нагрузку, сопоставимую с наплывом реальных пользователей, а не с лёгким ботом.

Риск для контента при этом реален и подтверждён самим оператором: Firecrawl открыто позиционирует себя как инструмент для подготовки обучающих датасетов LLM — то есть общая логика черновика про «риск утечки уникальных текстов в чужой AI-контур без атрибуции» здесь обоснована сильнее, чем для многих других записей категории «AI и LLM-краулеры», ошибочно попавших в неё по одному лишь названию.

4. Как найти FirecrawlAgent в логах

# Базовый поиск
grep -i "firecrawl" /var/log/nginx/access.log

# Топ URL, которые вычитывает бот
grep -i "firecrawl" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "firecrawl" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "firecrawl" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

# Признак полного обхода домена (характерно для /crawl-режима сервиса)
grep -i "firecrawl" /var/log/nginx/access.log | awk '{print $7}' | sort -u | wc -l

Верификация. Строку UA подделать может любой скрипт. Официального списка IP-диапазонов не найдено — для решения allow/deny смотрите связку UA + IP/ASN + признак полного JS-рендеринга (запросы к статике, шрифтам, скриптам страницы, а не только к HTML-документу — характерно для реального браузера, а не лёгкого HTTP-клиента):

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

5. robots.txt для FirecrawlAgent

# Жёсткий запрет — рекомендуемый вариант по умолчанию
User-agent: FirecrawlAgent
Disallow: /

# Разрешить всё — только при явной пользе (например, собственный AI-продукт компании использует Firecrawl)
User-agent: FirecrawlAgent
Allow: /

# Компромисс: закрыть личный кабинет и служебные разделы, оставить публичку
User-agent: FirecrawlAgent
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Хостируемый сервис Firecrawl официально заявляет соблюдение robots.txt, поэтому правило имеет практический смысл — в отличие от многих других ботов в этой категории. Учитывайте, однако, что open source ядро Firecrawl может быть развёрнуто третьими лицами самостоятельно, вне контроля политики соблюдения самой компании.

6. Блокировка вручную и через TrafficVeil

Nginx:

if ($http_user_agent ~* "firecrawl") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=firecrawl:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "firecrawl") {
        limit_req zone=firecrawl burst=20 nodelay;
    }
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} firecrawl [NC]
RewriteRule ^ - [F,L]

TrafficVeil:

• найдите firecrawl в разделе ботов домена или в /system/bots;
• для подавляющего большинства сайтов, где пользы от обучения чужих LLM или чужих AI-агентов нет — категория «запретить» обоснована сразу;
• учитывая полный JS-рендеринг, при заметной нагрузке рассмотрите rate-limit как промежуточный шаг, но не полагайтесь на него как на постоянное решение при массовом обходе домена;
• после изменения сверьте логи: хиты FirecrawlAgent должны уйти в блок/лимит, а нужные поисковики остаться.

7. Что делать: короткий алгоритм

• Обычный сайт без заинтересованности в AI-обучении или AI-агентах — блокируйте по умолчанию, риск реальный и подтверждён самим оператором;
• Наблюдаете системный обход всего домена с полным рендерингом — учитывайте повышенную нагрузку по сравнению с лёгкими HTTP-ботами при оценке приоритета блокировки;
• Сайт сам заинтересован в присутствии в AI-продуктах (например, документация, публичный API-справочник) — allow может быть осмысленным решением, аналогично AI-краулерам с открытой политикой;
• Не блокируйте по маске User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.

8. С кем не путать FirecrawlAgent

9. Стратегия allow/deny для FirecrawlAgent