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

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

flowchart LR
	A["Список доменов"] --> B{"Нужны отдельные факты или страницы?"}
	B -->|"Отдельные факты"| C["Поисковый API"]
	B -->|"Контент страниц"| D["Краулинг и извлечение"]
	C --> E["Очистка и JSON по схеме"]
	D --> E
	E --> F["Файлы, БД или векторный индекс"]
	F --> G["Codex: инструкции проекта и поиск"]

Чеклист быстрой проверки

Пройдите его на пилоте из 10–20 сайтов до запуска большого сбора.

Когда достаточно поиска, а когда нужен краулинг

Поисковый API

Используйте поисковый API, если нужны точечные факты: например, найти страницы с тарифами у 50 компаний или собрать ссылки на документацию. Такой подход уменьшает число загружаемых страниц, но полнота результата зависит от поискового индекса и качества запроса.

Подходящие варианты: Tavily, Brave Search API и Parallel.

Краулинг и скрапинг

Они нужны, когда требуется содержимое страниц, структура каталога, документация, блог или полный набор материалов в заданной области сайта.

В переданном снимке документации Firecrawl API v2, полученном 5 сентября 2026 года, перечислены отдельные операции поиска, скрапинга, построения карты URL, разбора файлов и краулинга. Для скрапинга страницы документация указывает выдачу в Markdown или JSON. При превышении плановых ограничений скорости или параллельности API возвращает HTTP-код 429.

Источник: Firecrawl API Reference v2.

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

Количество сайтов само по себе не определяет инструмент. Считайте домены, страницы, долю JavaScript-сайтов и частоту обновления.

Как выбрать инструмент

Firecrawl предоставляет API для поиска, скрапинга, построения карты URL, разбора файлов и краулинга. Он подходит, когда нужен управляемый сервис с выдачей содержимого страниц в Markdown или JSON.

ZenRows предоставляет Fetch, Extract, Batch и Browser Sessions. Режим автоматического выбора защиты может подключать нужный стек для сложных сайтов. Стоимость следует оценивать в кредитах, поскольку разные режимы расходуют общий баланс по-разному.

Scrapy подходит для собственного краулера с контролем над очередью, правилами обхода, повторами и хранением. Вместе с контролем вы получаете ответственность за эксплуатацию, прокси и обработку блокировок.

Playwright / Puppeteer используют управляемый браузер. Они полезны для страниц, где содержимое появляется после выполнения JavaScript, а также для кликов, авторизации и многошаговых сценариев. Браузерный сбор требует больше памяти и процессорного времени на страницу.

Apify можно рассматривать как платформу для готовых и собственных сборщиков. Перед использованием конкретного решения проверяйте его поддержку, ограничения источника и качество выходной схемы.

Актуальный ориентир по ZenRows

В переданном снимке ценовой документации ZenRows от 5 сентября 2026 года указано, что все продукты используют общий кредитный баланс:

• бесплатный план: 5 000 кредитов в месяц;
• первый платный план Build B1: $19 в месяц и 45 000 кредитов;
• стандартный успешный запрос: 1 кредит;
• JavaScript-рендеринг: 5 кредитов;
• премиальные прокси (Premium Proxies): 10 кредитов;
• JavaScript-рендеринг вместе с премиальными прокси: 25 кредитов;
• неуспешные и повторные запросы не расходуют баланс, а ответы 404 и 410 считаются успешными;
• лимит параллельных запросов зависит от уровня плана.

В том же снимке указано, что веса запросов одинаковы для всех планов. Цены и состав планов могут измениться. Перед расчётом бюджета сверяйтесь с актуальной документацией ZenRows.

Ограничения доступа: частота запросов, JavaScript и robots.txt

Ограничивайте параллельность отдельно для каждого домена и увеличивайте задержку после временных ошибок. Для страниц, которые отдают содержимое только после выполнения JavaScript, применяйте браузер или сервис с поддержкой рендеринга.

Капча или блокировка требуют остановить запросы и проверить допустимый способ доступа. Бесконечно повышать агрессивность обхода нельзя.

Требования RFC 9309 к robots.txt

robots.txt размещают по пути /robots.txt в корне сервиса. Если файл успешно загружен, краулер должен соблюдать распознаваемые правила для своего User-Agent.

При совпадении нескольких правил применяется наиболее конкретное совпадение. RFC 9309 определяет его как совпадение с наибольшим числом октетов; при равнозначных правилах Allow и Disallow предпочтение рекомендуется отдавать Allow.

RFC отдельно описывает обработку ошибок:

• при ответах, означающих недоступность ресурса, например 4xx, краулер может считать доступ разрешённым;
• при сетевой ошибке или ответе сервера 5xx краулер должен считать доступ полностью запрещённым;
• сохранённую копию robots.txt обычно не следует использовать дольше 24 часов, если файл доступен;
• правила robots.txt не являются механизмом авторизации и не заменяют техническую защиту ресурса.

Источник: RFC 9309 — Robots Exclusion Protocol.

Очистка и единая схема

Сырой HTML содержит навигацию, служебные элементы, повторяющиеся блоки и скрипты. Сначала сохраните исходный результат для диагностики, затем создайте нормализованное представление.

• Используйте Markdown как читаемый промежуточный формат.
• Извлекайте сравниваемые поля в JSON по одной схеме.
• Храните URL и дату сбора рядом с каждым фактом.
• Сохраняйте отсутствующие значения как null. Не подставляйте догадки.
• Для PDF и изображений применяйте распознавание текста только там, где оно действительно требуется.
• Считайте хэш нормализованного содержимого и схлопывайте точные дубли.
• Не объединяйте автоматически похожие страницы, если они относятся к разным тарифам, регионам или датам.

Пример структуры карточки конкурента:

{
  "company": "Название компании",
  "source_url": "https://example.com/page",
  "positioning": null,
  "pricing_plans": [
    {
      "name": "Название тарифа",
      "price": null,
      "features": []
    }
  ],
  "key_features": [],
  "target_audience": null,
  "collected_at": "2026-09-05"
}

Где хранить результат

Для важных фактов храните происхождение данных: исходный URL, время получения, хэш содержимого и версию схемы. Это позволяет понять, откуда взялось значение и когда его нужно перепроверить.

Как подготовить датасет для Codex

Небольшой датасет можно хранить прямо в репозитории. Разделяйте исходные материалы и структурированные карточки, а в AGENTS.md опишите расположение файлов и правила ответа.

# Датасет конкурентов

## Структура
- structured/*.json — карточки по competitor.schema.json
- raw/*.md — исходный очищенный контент
- index.md — соответствие домена и файлов

## Правила
- Для сравнений сначала используй structured/.
- Если значения нет, отвечай «нет данных».
- Для цены указывай source_url и collected_at.
- Не объединяй данные, собранные для разных регионов или дат.

Большие файлы делите по сайту или смысловому разделу. Если карточек тысячи, сначала выполняйте поиск и передавайте агенту только найденные фрагменты вместе с метаданными источника.

Повторяемую процедуру проверки, фильтрации и формирования отчёта можно оформить как навык Codex.

Эталонный сценарий для 200 сайтов

1. Создайте domains.txt, по одному домену на строку.
2. Определите разрешённые разделы и лимит страниц для каждого домена.
3. Проверьте robots.txt и зафиксируйте результат проверки.
4. Поставьте задания в очередь с ограничением параллельности на домен.
5. Получите Markdown или JSON через выбранный API либо собственный краулер.
6. Сохраните исходный результат в raw/ вместе с URL, временем и кодом ответа.
7. Извлеките поля по competitor.schema.json.
8. Провалидируйте карточки и отправьте ошибки в отдельную очередь.
9. Дедуплицируйте точные копии по хэшу нормализованного содержимого.
10. Соберите index.md и выборочно проверьте результаты вручную.
11. Подключите Codex к репозиторию через инструкции в AGENTS.md.
12. Настройте инкрементальное обновление и сравнение версий.

competitors-dataset/
  raw/                    # исходный результат сбора
  structured/             # валидированные JSON-карточки
  errors/                 # ошибки извлечения и валидации
  competitor.schema.json  # единая схема
  index.md                # домен → файлы
  AGENTS.md               # правила работы агента

Как проверить результат

Пилот считается успешным, если для выбранной контрольной выборки:

• каждая карточка проходит валидацию схемы;
• source_url открывает страницу, из которой получен факт;
• отсутствующие значения не заменены догадками;
• точные дубли удалены;
• ошибки можно повторно обработать отдельно;
• агент указывает источник и дату при сравнении изменяемых данных.

Регулярное обновление

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

• Выполняйте задания через очередь с повторами и ограничением числа попыток.
• Не загружайте неизменившиеся страницы без необходимости.
• Храните предыдущие версии значимых полей.
• Отделяйте изменение страницы от изменения извлечённого факта.
• Настройте уведомления о росте ошибок, ответах 429 и резком падении числа собранных страниц.
• Перед каждым циклом перепроверяйте правила доступа и актуальные тарифы используемых сервисов.

Для оркестрации отдельных этапов можно использовать n8n или собственную систему фоновых задач.

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

• ❌ Собирать весь сайт без списка нужных полей и ограничения области обхода
• ❌ Запускать сотни параллельных запросов к одному домену
• ❌ Считать капчу обычной временной ошибкой и повторять запрос бесконечно
• ❌ Передавать агенту сырой HTML без очистки и метаданных
• ❌ Смешивать подтверждённые карточки с ошибками извлечения
• ❌ Удалять похожие страницы без учёта региона, тарифа и даты
• ❌ Помещать весь крупный датасет в контекст вместо предварительного поиска
• ❌ Сравнивать цены без URL и даты получения
• ❌ Считать полугодовой снимок рынка актуальным без перепроверки

Следующий шаг

Начните с пилота на 10–20 сайтах: утвердите схему, измерьте долю успешных страниц и посчитайте фактическую стоимость одной валидной карточки. Затем опишите структуру и правила работы в AGENTS.md.

Связанные материалы

• Как собирать данные из соцсетей: полный справочник
• Firecrawl: Web Data API для ИИ
• ZenRows Universal Scraper API

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov