Практическая методология, как собрать данные с десятков, сотен и тысяч сайтов конкурентов, привести их в порядок и подать в Codex (или любому другому агенту) так, чтобы он фактически с ними работал, а не захлёбывался в мусоре. Это не обзор одного сервиса — это карта всего конвейера и развилок на каждом шаге.

Главная мысль: парсинг — это не цель, а первый шаг конвейера «собрать → очистить → сохранить → подать агенту». Слабое звено на любом этапе обнуляет результат. Чистый агент на грязных данных всё равно врёт.

Что это

Конвейер конкурентной разведки для ИИ-агента — пять звеньев: список доменов → сбор данных → очистка и схема → хранилище → подача в Codex через AGENTS.md или RAG. На каждом шаге своя развилка: что именно собирать, какой сервис использовать, как нормализовать результат и в каком виде отдать агенту.

Пара базовых понятий:

  • Скрапинг (scrape) — забрать одну конкретную страницу по URL.
  • Краулинг (crawl) — обойти весь сайт по ссылкам и собрать все страницы разом. Для конкурентной разведки почти всегда нужен именно краулинг.

Зачем нужно

  • Сравнить цены и тарифы 50–200 конкурентов без ручного открывания каждого сайта.
  • Собрать каталог фич и позиционирование для маркетингового анализа.
  • Найти общие паттерны в отрасли — какие блоки есть на лендингах, какие аргументы используют, какие кейсы показывают.
  • Следить за изменениями: цены, офферы, новые фичи — по расписанию, без ручного мониторинга.
  • Подать собранный датасет в Codex как контекст: агент отвечает на вопросы по конкурентам со ссылками на источник.

Как устроено

Конвейер выглядит так:

flowchart LR
  A["Список доменов
конкурентов"] --> B{"Нужен весь сайт
или точечные факты?"}
  B -->|"Точечные ответы"| C["Search API
Tavily / Brave"]
  B -->|"Контент страниц"| D["Краулинг и парсинг
Firecrawl / ZenRows / Scrapy"]
  C --> E["Очистка и структура
Markdown + JSON по схеме"]
  D --> E
  E --> F["Хранилище
файлы / БД / эмбеддинги"]
  F --> G["Подача в Codex
AGENTS.md + RAG"]

Шаг 1. Нужен ли вообще парсинг

Самая частая ошибка — кидаться краулить сайты, когда задача решается дешевле. Развилка по типу задачи:

  • Нужны точечные факты («какая цена на тарифе Pro у 50 конкурентов») — начните с поискового API: Tavily, Brave Search API, Parallel. Сервис возвращает уже найденный и очищенный контент без обхода всего сайта.
  • Нужен весь контент страниц (полные описания, документация, блоги, структура каталога) — тогда краулинг через Firecrawl, ZenRows или собственный Scrapy.
  • Нужны соцсети — это отдельная история со своими API и ограничениями, обычный краулинг там не работает.

Развилка по масштабу:

МасштабЧем братьПочему
10 сайтовManaged API (Firecrawl, ZenRows) или ручной экспортНастройка своей инфраструктуры дороже, чем сами данные
100 сайтовManaged API + очередь и схема данныхНужна автоматизация и нормализация, но не свои прокси
1000+ сайтовManaged API на объёме или собственный Scrapy + проксиНа больших объёмах считайте цену за страницу

Шаг 2. Какой инструмент выбрать

Нет «лучшего» сервиса — есть подходящий под тип сайтов, масштаб и ваш уровень контроля.

  • Firecrawl — managed API, который забирает контент целого сайта одной командой и сразу отдаёт его в LLM-ready виде. Берите, когда нужно быстро получить чистый Markdown или JSON по всему сайту и не хочется возиться с инфраструктурой: его эндпоинт /v2/extract умеет вытаскивать поля по вашей JSON Schema прямо в ответе.
  • ZenRows — тоже managed API, заточенный под сайты с жёсткой антибот-защитой (Cloudflare, DataDome и подобные). Его сильная сторона — высокий процент успешных запросов и оплата по сути за результат (платите только за успешные запросы; 404 и 410 считаются успехом), поэтому он выручает там, где обычные парсеры упираются в капчи и блокировки. Важный нюанс по цене: базовый запрос дешёвый, но JS-рендеринг умножает стоимость ×5, premium-прокси — ×10, а оба режима вместе — ×25, причём на хорошо защищённых сайтах сервис может включать их сам. Поэтому реальную цену на защищённых доменах считайте с учётом множителей.
  • Tavily / Brave Search API — это поисковые API, а не краулеры. Выбирайте их, когда нужны конкретные ответы и факты, а не весь сайт: они находят и извлекают релевантный контент без обхода всех страниц, что заметно дешевле и быстрее для точечных вопросов.
  • Scrapy — self-hosted фреймворк на Python (async-движок, CSS/XPath-селекторы, item-pipelines, экспорт в JSON/CSV/S3) для тех, кому нужно собрать тысячи сайтов с полным контролем и минимальной ценой за страницу. Это зрелый инструмент под крупные краулы, но взамен вы сами держите прокси, ротацию IP и обработку ошибок.
  • Playwright / Puppeteer — браузерная автоматизация для сложных случаев: SPA на React/Vue, авторизация, клики и многошаговые сценарии. Даёт полный рендеринг страницы и контроль над поведением, но требует больше кода и ресурсов на каждый сайт.
  • Apify — платформа с маркетплейсом готовых акторов (скраперов). Удобна, когда нужны соцсети и нишевые источники: часто под нужный сайт уже есть готовое решение, которое не придётся писать с нуля.

Trade-off: managed API экономят месяцы возни с прокси и капчами, но на больших объёмах дороже. Self-hosted дешевле за страницу, но вы сами держите прокси, ротацию IP и обход защит. Граница окупаемости зависит от защиты сайтов и доли premium-прокси — ориентировочно это десятки–сотни тысяч страниц, но точную точку считайте на своих данных.

Грубые цифры (на 2026 год, для прикидки):

  • Поисковые API: Parallel — Search API $0.005 за 10 результатов, Extract API $0.001 за запрос; 16 000 запросов бесплатно на старте. Tavily — бесплатный тариф на 1 000 кредитов в месяц, Pay-As-You-Go $0.008/кредит. Brave Search API — $5 бесплатных кредитов в месяц, 50 запросов/сек, 30+ млрд страниц в индексе.
  • Firecrawl: есть бесплатный тариф на пробу, платные планы помесячно за объём запросов.
  • ZenRows: подписка с балансом (от ~$69/мес), деньги списываются только за успешные запросы по тарифу с множителями (см. выше).
  • Self-hosted (Scrapy + прокси): сам фреймворк бесплатный (BSD-лицензия), основная статья расходов — резидентные прокси (порядка нескольких $ за ГБ трафика).

Цены ориентировочные и быстро меняются — перед запуском проверяйте актуальные цифры на сайтах вендоров.

Шаг 3. Антибот, лимиты и легальность

Этот шаг чаще всего ломает наивные парсеры.

  • Антибот-защита. Cloudflare, DataDome, reCAPTCHA блокируют обычные скрипты после нескольких запросов. Либо берите сервис, который обходит это сам (ZenRows, Firecrawl), либо стройте свою ротацию резидентных прокси.
  • Rate limiting. Не бейте по сайту в сотню потоков. Ставьте задержки и лимит параллельных запросов на домен — иначе бан и испорченный датасет.
  • JavaScript-сайты. React/Vue/Angular отдают пустую болванку обычному парсеру. Нужен рендеринг страницы (браузер или сервис с JS-рендером).
  • Правовые рамки. Перед сбором проверьте robots.txt и Terms of Service источника. Парсинг публичных данных в большинстве случаев допустим, но коммерческое использование, обход защит и сбор персональных данных могут нарушать правила и закон. На больших проектах согласуйте подход с юристом.
  • Особенности для РФ. Если среди собранных данных есть персональные (имена, контакты, профили сотрудников), их обработка попадает под 152-ФЗ «О персональных данных»: нужны законное основание обработки, а в ряде случаев — хранение данных россиян на серверах в РФ. Публичная доступность данных на сайте не делает их свободными для любой обработки. Сбор агрегированных неперсональных данных (цены, фичи, позиционирование) обычно безопаснее, чем персональных, но при сомнениях согласуйте подход с юристом.

Шаг 4. Очистка и структурирование

Сырой HTML или даже Markdown — это ещё не данные. Агенту нужна структура.

  • Markdown как промежуточный формат. Чистый Markdown без скриптов и навигации — то, что хорошо переваривают модели. Managed API отдают его из коробки.
  • JSON по схеме — главный результат. Не храните «простыни текста». Извлекайте поля по заранее заданной схеме, одинаковой для всех сайтов. Тогда данные сравнимы между собой.
  • OCR для PDF и картинок. Если у конкурентов цены или условия лежат в PDF — прогоните их через OCR, иначе потеряете эту часть.
  • Дедупликация. Один и тот же контент часто приходит с разных URL. Считайте хэш контента и схлопывайте дубли, иначе агент будет «голосовать» повторами.

Пример единой схемы извлечения, в которую складывается каждый сайт:

{
  "company": "string",
  "source_url": "string",
  "positioning": "string",
  "pricing_plans": [
    { "name": "string", "price": "string", "features": ["string"] }
  ],
  "key_features": ["string"],
  "target_audience": "string",
  "collected_at": "2026-07-02"
}

Совет: задайте схему один раз и заставляйте сервис извлечения (например, Firecrawl Extract) возвращать строго её. Так вы получите таблицу сравнимых карточек, а не сотни разнородных текстов.

Шаг 5. Где хранить данные

Хранилище выбирается по объёму и тому, как вы будете запрашивать данные.

Объём и задачаХранилищеКогда подходит
До сотен карточек, отдаём агенту целикомФайлы (Markdown + JSON в репозитории)Codex читает папку напрямую, версионирование через git
Тысячи строк, нужны фильтры и агрегатыБД (Supabase, ClickHouse)Сравнение цен, аналитика, выборки по полям
Нужен семантический поиск по контентуЭмбеддинги (BGE-M3, EmbeddingGemma) + векторная БДRAG: агент ищет смысл, а не точное слово
Поиск связей без LLMTF-IDF / semantic snapshotДёшево и быстро, когда эмбеддинги избыточны

Шаг 6. Как подать данные в Codex

Цель — чтобы агент работал с данными уверенно и не выдумывал.

  • Markdown + AGENTS.md. Положите данные в репозиторий и опишите в AGENTS.md, где что лежит и как с этим работать. Это самый надёжный способ для Codex.
  • Чанкинг. Большие файлы режьте на смысловые куски (по одному сайту/разделу на файл), а не один файл на 5 МБ.
  • RAG для больших объёмов. Если данных тысячи карточек — не суйте всё в контекст. Поднимите векторный поиск и подавайте агенту только релевантное.
  • Skills. Повторяемую логику работы с датасетом оформите как навык, чтобы не объяснять её каждый раз.

Пример AGENTS.md для датасета конкурентов:

# Датасет: конкуренты

## Структура
- structured/ — JSON-карточки конкурентов по единой схеме (competitor.schema.json)
- raw/ — исходные markdown-страницы, если нужен контекст
- index.md — оглавление: домен → файл

## Правила
- Отвечай только на основе файлов в structured/.
- Если данных по полю нет — пиши "нет данных", не выдумывай.
- При сравнении цен всегда указывай source_url.

Шаг 7. Масштаб и регулярность

Одноразовый сбор и постоянный мониторинг — разные задачи.

  • Очереди и фоновые задачи. На сотнях сайтов гоняйте сбор через очередь с ретраями, а не одним скриптом, который падает на 50-м домене.
  • Инкрементальный краулинг. Не пересобирайте всё каждый раз — забирайте только изменившиеся страницы.
  • Расписание. Цены и офферы меняются: поставьте регулярный прогон (cron, systemd timer) и сравнивайте срезы во времени.
  • Оркестрация без кода. Для связки «собрал → очистил → положил → уведомил» удобно использовать n8n или Composio.

Когда использовать

  • Маркетинговая разведка: цены, фичи, позиционирование, таргетинг 50–500 конкурентов в одной нише.
  • Мониторинг изменений: раз в неделю/день обходить сайты конкурентов и подсвечивать новые фичи или изменённые тарифы.
  • Наполнение каталога для агента: подать в Codex датасет конкурентов, чтобы он отвечал на вопросы «у кого из конкурентов есть X?» со ссылками на источник.
  • Подготовка к запуску продукта: за месяц до релиза собрать лендинги конкурентов и анализировать, какие блоки работают в нише.
  • Аудит собственного сайта: сравнить свой контент с конкурентами и найти, чего не хватает.

Не используйте этот конвейер, если:

  • Задача решается одним поисковым запросом — не стройте инфраструктуру, используйте Tavily или Brave напрямую.
  • Нужны только 1–3 сайта — хватит ручного экспорта.
  • Данные нужны разово и в малом объёме — проще открыть сайты руками.
  • Бизнесу нужна юридическая чистота — обсудите с юристом до запуска, особенно если собираете персональные данные.

Пример

Эталонный сценарий: 200 сайтов конкурентов → датасет для Codex.

  • Собрать список доменов в domains.txt — по одному на строку.
  • Краулить каждый домен через managed API с извлечением по схеме. Блок ниже — условный псевдокод для иллюстрации логики, а не реальные команды CLI: точный синтаксис смотрите в документации выбранного сервиса.
# псевдо-пайплайн: на каждый домен — crawl + extract по схеме
while read domain; do
  firecrawl crawl "$domain" \
    --extract-schema competitor.schema.json \
    --formats markdown,json \
    --output "raw/${domain}"
done < domains.txt
  • Нормализовать результаты в единый вид и сложить в structured/.json по единой схеме.
  • Дедуплицировать по хэшу контента и собрать index.md (домен → файл).
  • Разложить в репозиторий с понятной структурой:
competitors-dataset/
  raw/                  # сырой markdown по каждому сайту
  structured/           # JSON по единой схеме
  competitor.schema.json # схема данных
  index.md              # оглавление: домен → файл
  AGENTS.md             # инструкция агенту
  • Подключить Codex к репозиторию: агент читает AGENTS.md, работает с structured/ и ссылается на source_url.
  • Поставить на расписание инкрементальное обновление и сравнение срезов.

Итог: на выходе у вас не «куча текста с сайтов», а структурированный, дедуплицированный и описанный датасет, по которому агент даёт проверяемые ответы со ссылками на источник.

Ограничения

Ограничения

Цена растёт на защищённых сайтах — у ZenRows JS-рендер ×5, premium-прокси ×10, оба режима ×25.

На Cloudflare-защищённых доменах реальная стоимость запроса в разы выше базовой.

Managed API упёрся в лимиты — у Parallel 600 req/min на Search, 25/час на Find All, 16 000 бесплатных запросов Pay-as-you-go.

На пиковых сборках быстро упираетесь в потолок.

Self-hosted требует инфраструктуры — резидентные прокси, ротация IP, обработка капч.

Scrapy бесплатный, но эксплуатационные расходы могут перекрыть экономию на managed API.

Парсинг персональных данных в РФ

если среди собранных данных есть имена, контакты или профили сотрудников, обработка попадает под 152-ФЗ и может потребовать хранение на серверах в РФ.

Цены меняются быстро — все тарифы, указанные в материале, ориентировочные.

Перед запуском проверяйте актуальные цифры на сайтах вендоров.

JavaScript-сайты — React/Vue/Angular отдают пустую болванку обычному парсеру.

Без браузерного рендера или сервиса с JS-рендером данные будут неполными.

Объём контекста LLM ограничен — даже при чанкинге тысячи карточек в один файл не влезут.

Для больших датасетов нужен RAG, а не «прочитать всё разом».

Антипаттерны

Антипаттерны

Краулить всё подряд без схемы данных

получите терабайты мусора, который агент не переварит и не сможет сравнивать между конкурентами.

Игнорировать антибот и бить в сотню потоков

бан, капчи, битые страницы, испорченный датасет.

Скидывать сырой HTML агенту

теги и скрипты съедают контекст и качество ответов падает.

Забыть про дедуп

повторы искажают любые сравнения и агрегаты, агент «голосует» одной и той же выдержкой несколько раз.

Совать весь датасет в контекст вместо RAG

когда данных тысячи карточек, контекстное окно закончится, агент начнёт выдумывать или пропускать.

Собрать один раз и считать данные актуальными через полгода

цены и офферы у конкурентов меняются еженедельно, одноразовый сбор быстро устаревает.

Игнорировать robots.txt и ToS

в лучшем случае получите бан, в худшем — юридические проблемы.

Использовать выдуманные CLI-флаги — реальные эндпоинты сервисов (например, POST /v2/extract у Firecrawl) принимают JSON в теле запроса, а не флаги —extract-schema.

Сверяйтесь с документацией вендора, прежде чем копировать псевдокод из чужих туториалов.

Чеклист

Чеклист

Цель сформулирована

понятно, какие именно данные нужны (цены, фичи, позиционирование, контакты), а не «всё подряд».

Тип задачи определён

решено, нужен весь сайт или достаточно поисковой выдачи по конкретным вопросам.

Масштаб оценён

10, 100 или 1000+ сайтов; от этого зависит выбор инструмента.

Антибот-защита изучена

выбран инструмент под конкретную защиту целевых сайтов.

Схема данных задана

JSON-схема, в которую складываются результаты, одинаковая для всех сайтов.

Дедупликация и обработка ошибок продуманы

что делаем с битыми страницами и пустыми ответами.

Хранилище выбрано

файлы, БД или эмбеддинги под итоговый объём данных.

Способ подачи в Codex определён

файлы + AGENTS.md или RAG, понятно, как агент получит данные.

Правовые рамки проверены

robots.txt и ToS источников прочитаны, при необходимости — согласовано с юристом.

Бюджет заложен

посчитан на запросы и регулярное обновление, не только на разовый сбор.

Ссылки

Ссылки

По теме

По теме