🔤 Автоматизация SEO в WB: что внутри и почему мы не пишем всё сами 🔤

В моём докладе "SEO в Big проектах" есть слайд, который в кулуарах вызывает вопросы: упрощённая C4-диаграмма сервиса. Разбираю схему и главное — почему часть системы SEO автоматизации пишем сами, а часть покупаем.


🔹 Внутренний контур
Микросервисы на Python. PostgreSQL — управление задачами. ClickHouse — хранилище Big Data. Распределённые агенты A-Parser через Redis как брокер. Фронтенд — Quasar Framework (VueJS).

На этом стеке живёт всё: SEO сканер по 100+ млн страниц (Screaming Frog виснет уже на 6 млн), классификация 15 млн маркерных запросов по 2к категорий, генерация посадочных (Programmatic SEO) и др.


🔹 Внешний контур
10+ интеграций с внешними источниками. Это и платные сервисы рынка — Keys.so, Ahrefs, Semrush и др., — и бесплатные панели вебмастеров поисковых систем.


🔹 Корпоративная инфраструктура
Всё развёрнуто в корпоративном Kubernetes с жёстким CI/CD, авторизация через Keycloak, плюс интеграция с корпоративными сервисами и системами.

Интеграция и даёт скорость: SEO-контур узнаёт об изменениях в каталоге, остатках и поставщиках сразу, а не ждёт ночных выгрузок из БД.

Минус внутри корпоративной инфраструктуры — согласования и долгие релизы. Плюс — прозрачность и безопасность данных. Плюс перевешивает.



🔹 Где заканчивается самопис
Частый вопрос: зачем в Enterprise-контуре покупной A-Parser, если есть свои программисты?

A-Parser у нас с 2012 года. Ядро на NodeJS/V8: из коробки многопоточность, обход капч, ротация прокси, 100+ готовых парсеров, нативный Redis, API и Headless Chrome.

Минусы реальные: капризный API на сверхнагрузках, логи 30 копий пухнут до 400 ГБ за дни, бывают краши в многопотоке.

Но вот арифметика для бизнеса. Зависший API и логи закрываются парой Python-обвязок за неделю работы одного инженера. Написать с нуля стабильное асинхронное парсинг-ядро — годы (ну или месяцы) работы отдела дорогих разработчиков. И потом бесконечно поддерживать его в войне с защитами, которые меняются по нескольку раз в неделю.

Плюс кадры: A-Parser — отраслевой стандарт, его требуют в вакансиях Яндекса и Т-Банка. Нанять инженера со стандартом дешевле, чем полгода погружать его в самопис.



🔹 А Claude Code не отменяет это правило?
Конечно, активно используем ИИ: OpenRouter, Claude Code, Cursor и другие.

И всё равно — не отменяет.

ИИ ускоряет реализацию R&D задач, написанных "на коленке", но выхлоп от поддержки ИИ продакшн парсинга гораздо ниже ожиданий. Судите сами: обход новых защит, стабильность на тысячах потоков, dead локи, лимиты дескрипторов Linux, прокси, капчи. Это сотни мелких граблей, которые вендор собрал за годы. По цене лицензии вы получаете уже вычищенный результат вместо месяцев, а то и лет своей разработки.

И второе, о чём забывают: в Enterprise разработка подчиняется требованиям ИБ. Код и коммерческие данные не уходят в произвольные внешние сервисы — чувствительное гоняем через внутренние RWB LLM, а сгенерированный ИИ код проходит то же ревью и CI/CD, что и написанный руками.

Claude Code даёт максимальный эффект там, где ему и место на схеме: обвязки, скрипты стабилизации, кастомная логика поверх готового ядра, интеграции. Не в переписывании фундамента.


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


---


📝 Оставить заявку на сотрудничество или задать вопрос:
https://docs.google.com/forms/d/1wEnhkS3djoHrSRVi69KEg-b9PTiSOb3UyscQ0LFelIs/


#️⃣ #SEO #BigData #IT