Программатик-SEO
Задача: закрыть огромную нишу без команды
Ко мне пришла идея сделать SEO-агрегатор колледжей и среднего профобразования — каталог, где абитуриент и родители находят ссузы, программы обучения и разборы конкретных профессий. Ниша большая: тысячи учебных заведений, сотни направлений, десятки тысяч возможных поисковых запросов вида «профессия + колледж + город». Обычный путь — нанять контент-агентство, редактора, верстальщика, разработчика. Это месяцы и сотни тысяч рублей до первого органического клика.
Я решил собрать всё в одиночку на вайбкодинге — то есть работая с Claude Code как с единственным «разработчиком» и «редактором» в одном лице. Задача была не «написать пару статей», а построить систему, которая производит контент пачками и не разваливается на масштабе.
Что получилось: масштаб проекта
За несколько итераций каталог вырос до конкретных цифр, которые и определяют SEO-вес проекта:
305
колледжей в каталоге
409
программ обучения
840
статей-разборов профессий и навыков
В сумме это около 1554 страниц в индексе. Технически всё сделано подчёркнуто просто: vanilla HTML и CSS, без React, без Next.js, без сборщиков со сложной конфигурацией. Деплой — обычный rsync на shared-хостинг, не Vercel. Причина не в экономии, а в контроле: когда страниц полторы тысячи и их число растёт каждую неделю, важно, чтобы каждая страница была статичным файлом, который отдаётся мгновенно и не зависит от рантайма фреймворка.
Как устроен контент-пайплайн
Ключевой вопрос для агрегатора такого размера — откуда берётся уникальный текст на каждую из 840 статей, чтобы это не было тонким машинным контентом. Пайплайн выстроен так:
- Генерация в чате. Сама нейросеть пишет уникальный SEO-текст для статьи прямо в диалоге с Claude Code — не через API-вызов, а в обычной рабочей сессии, где я вижу текст и могу сразу поправить структуру, факты, тон.
- Сохранение в JSON. Готовый текст ложится в структурированный JSON-файл — заголовки, подзаголовки, блоки, метаданные страницы отдельно от разметки.
- Рендер по шаблону. Скрипт превращает JSON в готовый HTML по единому шаблону сайта, так что вёрстка везде одинаковая, а меняется только контент.
- Заливка на прод. Готовые страницы уходят на хостинг через
rsync— без ручного копирования файлов и без даунтайма.
Инсайт
Генерация текста через API дешевле и быстрее, но я сознательно выбрал писать статьи в чате. В диалоговом режиме я вижу черновик целиком, могу тут же попросить убрать штампы, добавить конкретику или пересобрать структуру — контроль качества встроен в сам процесс написания, а не вынесен в отдельный этап проверки постфактum.
Автопилот: контент растёт без меня
Ручное написание 840 статей одну за другой — это по-прежнему я, сидящий с ноутбуком. Чтобы каталог продолжал расти без постоянного участия, генерацию статей пачками я поставил на планировщик задач: по расписанию нейросеть сама берёт следующую порцию профессий и навыков, пишет разборы, прогоняет их через тот же пайплайн JSON → рендер → rsync и выкладывает на прод. Моя роль сводится к периодической проверке качества и точечным правкам, а не к тому, чтобы каждый день садиться и писать тексты руками.
SEO-инфраструктура для полутора тысяч страниц
Когда страниц много и они постоянно обновляются, стандартный sitemap быстро превращается в проблему: поисковик либо не успевает всё переобойти, либо тратит краулинговый бюджет на страницы, которые не менялись месяцами. Я решил это так:
- Sitemap-index строится с полем
lastmod, которое вычисляется по хешу содержимого страницы. Если текст не менялся — хеш тот же, дата в sitemap не трогается. Изменилась хотя бы буква — хеш другой, и поисковик видит реальное обновление, а не искусственную «свежесть». - Новые URL сразу уходят в поисковики через протокол IndexNow, вместо того чтобы ждать, пока краулер сам их найдёт.
- Для контроля индексации подключён доступ к Google Search Console через сервисный аккаунт — можно проверять статус страниц и находить проблемы без ручного захода в интерфейс.
Это не разовая настройка, а конвейер: с ростом каталога на сотни страниц в месяц вручную такие вещи не отследить — только автоматизацией, которая интегрирована в сам процесс публикации.
Монетизация: реклама и лиды с первого дня
Агрегатор такого масштаба имеет смысл монетизировать не только через собственные заявки, но и через размещение рекламы образовательных учреждений. Первый рекламодатель встал в проект тремя форматами одновременно: поп-ап, сквозная растяжка на всех страницах и обогащённая карточка в каталоге, закреплённая первой позицией (pinned-first) — то есть выделяющаяся визуально и стоящая выше органической выдачи каталога. Клики по всем трём форматам считаются целями в Яндекс.Метрике, так что эффективность размещения видна сразу в цифрах, а не оценивается на глазок.
Вывод: что переносится на другие проекты
Главный урок этого кейса не в конкретной нише, а в архитектуре подхода к SEO-проектам такого масштаба:
- Одному человеку с Claude Code вполне по силам построить и вести каталог из полутора тысяч страниц — если контент-пайплайн выстроен как конвейер, а не как ручная работа.
- Писать SEO-тексты в диалоге с нейросетью, а не только через API, даёт больше контроля над качеством — особенно когда нужно закрыть тысячи узких тематических страниц без превращения их в шаблонный шум.
- Автоматизация индексации (хеш-based lastmod, IndexNow, GSC-контроль) — не опциональная надстройка, а необходимое условие, когда сайт растёт на сотни страниц в месяц.
- Монетизацию рекламой стоит проектировать заранее, вместе со структурой каталога, а не пристраивать её поверх готового сайта — тогда формат вроде pinned-first карточки органично встраивается в существующую верстку и сразу измеряется через аналитику.
Если вы планируете собственный агрегатор или каталог с сотнями и тысячами страниц, начните не с дизайна, а именно с этого конвейера: генерация → структурированное хранение → рендер → деплой → мгновенная индексация. Всё остальное — включая монетизацию — встраивается в него намного проще, чем выглядит на старте.