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

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

Любая задача «спарсить конкурентов для Codex» раскладывается на пять звеньев. Думайте о ней не как о парсинге, а как о потоке данных от сырого сайта до готового датасета, на котором агент даёт ответы.

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

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

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

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

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

Search API против краулинга

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

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

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

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

Firecrawl — managed API, который забирает контент целого сайта одной командой и сразу отдаёт его в LLM-ready виде. Берите, когда нужно быстро получить чистый Markdown или JSON по всему сайту и не хочется возиться с инфраструктурой: его AI-extract умеет вытаскивать поля прямо по вашему описанию схемы.

ZenRows — тоже managed API, но заточенный под сайты с жёсткой антибот-защитой — Cloudflare, DataDome и подобными. Его сильная сторона — высокий процент успешных запросов и оплата по сути за результат (платите только за успешные запросы; 404 и 410 считаются успехом), поэтому он выручает там, где обычные парсеры упираются в капчи и блокировки. Важный нюанс по цене: базовый запрос дешёвый, но JS-рендеринг множит стоимость ×5, premium-прокси — ×10, а оба режима вместе — ×25, причём на хорошо защищённых сайтах сервис может включать их сам. Поэтому реальную цену на защищённых доменах считайте с учётом множителей.

Tavily / Brave Search API — это поисковые API, а не краулеры. Выбирайте их, когда нужны конкретные ответы и факты, а не весь сайт: они находят и извлекают релевантный контент без обхода всех страниц, что заметно дешевле и быстрее для точечных вопросов.

Scrapy — self-hosted фреймворк для тех, кому нужно собрать тысячи сайтов с полным контролем и минимальной ценой за страницу. Это зрелый инструмент под крупные краулы, но взамен вы сами держите прокси, ротацию IP и обработку ошибок.

Playwright / Puppeteer — браузерная автоматизация для сложных случаев: SPA на React/Vue, авторизация, клики и многошаговые сценарии. Даёт полный рендеринг страницы и контроль над поведением, но требует больше кода и ресурсов на каждый сайт.

Apify — платформа с маркетплейсом готовых «акторов» (скраперов). Удобна, когда нужны соцсети и нишевые источники: часто под нужный сайт уже есть готовое решение, которое не придётся писать с нуля.

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

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

• Антибот-защита. Cloudflare, DataDome, reCAPTCHA блокируют обычные скрипты после нескольких запросов. Либо берите сервис, который обходит это сам (ZenRows, Firecrawl), либо стройте свою ротацию резидентных прокси.
• Rate limiting. Не бейте по сайту в сотню потоков. Ставьте задержки и лимит параллельных запросов на домен — иначе бан и испорченные данные.
• JavaScript-сайты. React/Vue/Angular отдают пустую болванку обычному парсеру. Нужен рендеринг страницы (браузер или сервис с JS-рендером).

Шаг 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-06-19"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

Собранный рабочий пример, на который можно опираться.

Шаг 1. Собрать список доменов в domains.txt — по одному на строку.

Шаг 2. Краулить каждый домен через 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

Шаг 3. Нормализовать результаты в единый вид и сложить в structured/<domain>.json по единой схеме из раздела «Очистка и структурирование».

Шаг 4. Дедуплицировать по хэшу контента и собрать index.md (домен → файл).

Шаг 5. Разложить в репозиторий с понятной структурой:

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

Шаг 6. Подключить Codex к репозиторию: агент читает AGENTS.md, работает с structured/ и ссылается на source_url.

Шаг 7. Поставить на расписание инкрементальное обновление и сравнение срезов.

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

• ❌ Краулить всё подряд без схемы данных — получите терабайты мусора, который агент не переварит
• ❌ Игнорировать антибот и бить в сотню потоков — бан, капчи и битые страницы
• ❌ Скидывать сырой HTML агенту — теги и скрипты съедают контекст и качество ответов
• ❌ Забыть про дедуп — повторы искажают любые сравнения и агрегаты
• ❌ Совать весь датасет в контекст вместо RAG, когда данных тысячи карточек
• ❌ Собрать один раз и считать данные актуальными через полгода

По теме

• Статья: Мои закладки больше не умирают: как Notion-агент заменил мне 80% работы над контентом
• Блог: Один промпт, который заставляет Codex перепроверять себя — и реально улучшает результат
• База знаний: ZenRows Universal Scraper API: парсинг любого сайта без боли

Если перед вами стоит задача собрать данные по рынку или конкурентам и превратить их в рабочий контур для агента — обычно дешевле начать с одного аккуратного пайплайна на 10–20 сайтов и довести его до автоматизма, прежде чем масштабировать на тысячи.

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