Автоматизация SEO-работ через нейросети
Как автоматизировать SEO через LLM: пайплайн от сбора семантики до готовых страниц
Когда нужно обработать не 1000 запросов, а 500 000 — ручная работа не масштабируется. Нанять 12 человек? Дорого и долго. Мы выбрали третий путь: выстроили пайплайн автоматизации через LLM.
Результат: 50−100 тысяч запросов в сутки, экономия в 3−6 раз по деньгам и в 10−15 раз по времени.
Рассказываем, как это работает технически и где все еще нужны руки специалистов.
Разбираем полный цикл автоматизации SEO-работ через нейросети — от парсинга запросов до прописанных H1. С архитектурой, стеком технологий и реальными цифрами производительности.
Оглавление
Классический SEO-процесс для крупного проекта выглядит так:
01
Выгружаем семантику из Keyso/Serpstat частями (лимит выгрузки)
02
Склеиваем куски в Excel (лимит 1 048 576 строк)
03
Вручную чистим мусор
04
Кластеризуем
05
Строим структуру
06
Типизируем страницы (категория/тег/товар)
07
Прописываем H1, Title, Description
08
Прописываем анкоры для внутренней перелинковки
За 3 месяца классической работы команда из 6 человек обработала только 10% объема. Рентабельность -60%, все перерабатывают, качество страдает.
Нужно было решение, которое масштабируется
→
Чистка семантики жрет 40% времени команды
→
Структура — самая дорогая задача (требует экспертизы и внимания)
→
Типизация и заголовки — рутина, но тоже долго
→
Keyso по умолчанию не отдает всю семантику сразу по большому проекту
→
Excel умирает на миллионе строк — медленно, больно, неэффективно
Проблемы на каждом этапе:
→ Проблема
Excel не тянет, люди не масштабируются
→ Решение: трехуровневая архитектура
[SQL БД]←→[Python API Parser]←→[LLM через OpenRouter]
Хранение
↑
Оркестрация
↑
Обработка
↑
Выстроили систему из трех уровней:
[SQL БД]
↑
↓
[Python API Parser]
↑
↓
[LLM через OpenRouter]
↑
↓
[Python API Parser]
↑
↓
[LLM через OpenRouter]
Хранение
→
Оркестрация
→
Обработка
→
→ Уровень 1
SQL БД — хранилище и источник данных
→
Хранит миллионы строк без проблем
→
API парсинг напрямую из Keyso и JustMagic в БД
→
Метчинг ключей на стороне БД (быстрее и надежнее)
→
Выгружаем данные небольшими порциями для обработки
Зачем нужна БД, а не Excel:
Структура данных в БД:
→
Сам запрос
→
Частотность (WS, «WS», «!WS», «[WS]», «[!WS]»)
→
Позиции конкурентов
→
URL-адреса где ранжируются конкуренты
→
Результаты классификации (категория)
→
Номер кластера
→
Тип страницы
→
Готовые заголовки/анкоры
Что хранится:
→ Уровень 2
Задача парсера:
01
Взять данные из БД (CSV на вход)
02
Разбить на куски по 200−300 строк (лимит контекста LLM)
03
Отправить через API к нейросети
04
Склеить результаты обратно
05
Сохранить в БД
Python Parser — оркестратор процесса
→
Веб-интерфейс нормально обрабатывает 200−300 строк
→
Больше — начинает «тупить» и терять качество
→
Запускать вручную кусками по 200 строк для 100 000 запросов = ад
Почему не через веб-интерфейс ChatGPT:
→
Выбор шаблона задачи (чистка СЯ, H1, структура, анкоры)
→
Поле для промпта (можно править на лету)
→
Выбор модели из 300+ доступных
→
Размер итерации (по умолчанию 200)
→
Количество итераций (сколько запускать параллельно)
Интерфейс парсера (скриншот из материалов):
Архитектура парсера:
# Упрощенная схема
CSV_FILE = «input.csv» # Исходные данные
TXT_PROMPT = «prompt.txt» # Промпт для LLM
CHUNK_SIZE = 250 # Размер куска
def process():
data = load_csv(CSV_FILE)
chunks = split_to_chunks(data, CHUNK_SIZE)
results = []
for chunk in chunks:
response = api_call_to_llm(chunk, TXT_PROMPT)
results.append(response)
final_csv = merge_results(results)
save_to_db(final_csv)
CSV_FILE = «input.csv» # Исходные данные
TXT_PROMPT = «prompt.txt» # Промпт для LLM
CHUNK_SIZE = 250 # Размер куска
def process():
data = load_csv(CSV_FILE)
chunks = split_to_chunks(data, CHUNK_SIZE)
results = []
for chunk in chunks:
response = api_call_to_llm(chunk, TXT_PROMPT)
results.append(response)
final_csv = merge_results(results)
save_to_db(final_csv)
→
5 ПК в локальной сети
→
10 копий парсера на каждом ПК
→
Свой API-ключ для каждого ПК
Решение:
Проблема: один API-ключ + один ПК = узкое горлышко.
Итого: 50 параллельных потоков обработки.
Почему важно разделение по ключам: Много копий парсера на одном API-ключе → качество падает, скорость не растет.
Квантовый скачок производительности:
→ Уровень 3
Но популярность ≠ качество для SEO-задач (см. наше исследование по 9 моделям).
Популярность моделей для SEO/Marketing (данные OpenRouter):
01
Claude 3.7 Sonnet — 37.9M токенов/неделя
02
GPT-4o-mini — 35.6M токенов/неделя
03
Gemini 2.0 Flash — 25M токенов/неделя
04
Gemini 2.0 Flash Lite — 17.7M токенов/неделя
LLM через OpenRouter — обработка данных
→
Доступ к 300+ нейросетям через единый API
→
Можно быстро переключаться между моделями
→
Мониторинг трендов (какие модели популярны)
→
Единая биллинговая система
Почему OpenRouter, а не напрямую к ChatGPT:
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Технологии: SQL, API Keyso/JustMagic, Python для оркестрации
Экономия: 50 часов и 85 000 рублей на 100к кластеров
Этап 0: Сбор и загрузка данных (автоматизация)
→
Выгружаем из Keyso CSV частями (лимит 100к строк)
→
Вручную склеиваем в Excel
→
Тратим 60 часов на 100к кластеров
Было:
→
API парсинг напрямую в SQL БД
→
Автоматическая склейка на уровне БД
→
10 часов на 100к кластеров
Стало:
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Определить, к какой категории относится запрос.
Модель: Gemini Flash 2 (быстрая и дешевая для первичной сортировки)
Результат: Семантика поделена по категориям, можем выгружать и работать по частям.
Определи категорию для запроса.
Доступные категории: Одежда и обувь, Спорт и отдых, Ювелирные украшения, […]
Верни только название категории, без пояснений.
Доступные категории: Одежда и обувь, Спорт и отдых, Ювелирные украшения, […]
Верни только название категории, без пояснений.
Этап 1: Классификация запросов (ML)
→
«термобелье мужское» → Одежда и обувь
→
«палатка 4 местная» → Спорт и отдых
→
«кольцо с топазом» → Ювелирные украшения
Было:
→
На старте отсекаем нерелевантные категории
→
Работаем итерациями (сначала приоритетные/сезонные)
→
Не обрабатываем все подряд
Зачем:
Промпт (упрощенно):
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Отделить коммерческие запросы от мусора.
Входные данные: CSV с колонкой «Запрос»
Выходные данные: CSV с двумя колонками — «Запрос» и «Результат» (либо сам запрос, либо «Мусор»)
Этап 2: Чистка семантики (LLM)
→
Навигационные запросы к конкурентам («wildberries», «интимиссими»)
→
Информационные запросы («как выбрать», «что лучше»)
→
Нерелевантные запросы («манго» — фрукт, не бренд одежды)
Что считаем мусором:
→
Для максимального качества: DeepSeek V3.1 (8/10, но медленно)
→
Для баланса: Gemini Flash 2 (7/10, быстро и дешево)
Модель:
→
DeepSeek: 10% мусора пропущено, 2% коммерческих отсеяно, 240 мин, $ 0.67
→
Gemini Flash 2: 20% мусора пропущено, 3% коммерческих отсеяно, 42 мин, $ 0.26
Метрики качества (на 10к запросов):
Результат: Чистая семантика, готовая к кластеризации.
Задача: отфильтровать нецелевые запросы для интернет-магазина одежды.
Убери:
→
Запросы к конкурентам и другим брендам
→
Информационные запросы (советы, гайды)
→
Запросы не про одежду/обувь
Промпт (принцип):
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Сгруппировать запросы по интенту.
Важно: Эту задачу LLM пока не решают хорошо. Используем проверенные сервисы.
Этап 3: Кластеризация (внешние сервисы)
→
Key Collector (классика)
→
Rush Analytics
→
Топвизор
→
Собственные алгоритмы
Инструменты:
→
Из 100 000 запросов получаем, например, 15 000 кластеров
→
Каждый кластер = одна страница сайта
Результат:
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Проверить результат LLM и исправить косяки.
Кто делает: SEO-специалист (Middle/Senior)
Объем работы: Проверяем выборочно 5-10% результата
Важно: Это НЕ полная ручная работа, а контроль качества. Без этого этапа качество падает до 6−7 из 10.
Результат: Утвержденные кластеры, готовые к дальнейшей обработке.
Этап 4: Ручная проходка (человек + здравый смысл)
→
Адекватность чистки (не потеряли ли важное)
→
Корректность кластеризации
→
Смысловую логику
Что проверяем:
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Найти и объединить кластеры-дубли.
Модель: Gemini 2.5 Flash (быстрая, минимум потерь)
Найди кластеры с одинаковым интентом и объедини их.
Учитывай синонимы и перестановку слов.
Верни CSV с колонками: Исходный кластер | Объединить с кластером
Учитывай синонимы и перестановку слов.
Верни CSV с колонками: Исходный кластер | Объединить с кластером
Результат: Убрали дубли, структура стала чище.
Этап 5: Сцепка дублей (LLM)
→
«термобелье мужское» и «мужское термобелье»
→
«пуховик зимний женский» и «зимний женский пуховик»
→
«кольцо с топазом» и «топазовое кольцо»
Примеры дублей:
Промпт (принцип):
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Определить тип страницы для каждого кластера.
Модель: DeepSeek V3.1 (важна точность)
Определи тип страницы для запроса.
Типы: Категория, Категория + бренд, Тег, Товар, Бренд, Категория + атрибут
Типы: Категория, Категория + бренд, Тег, Товар, Бренд, Категория + атрибут
Результат: Каждый кластер размечен по типу, можем строить структуру.
Этап 6: Типизация страниц (LLM)
→
Категория («пуховики женские»)
→
Категория + атрибут («пуховики женские зимние»)
→
Категория + бренд («пуховики Nike»)
→
Тег («красные пуховики»)
→
Товар («пуховик Nike Air Max женский»)
→
Бренд («Nike одежда»)
Типы страниц:
→
Разные типы страниц = разные шаблоны
→
Разная структура URL
→
Разная стратегия продвижения
Зачем:
→
Если есть конкретная модель товара → Товар
→
Если бренд + общее («Nike одежда») → Бренд
→
Если категория + бренд («пуховики Nike») → Категория+бренд
→
Если только категория → Категория
Правила:
Промпт (упрощенно):
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Задача: Написать заголовок для каждой страницы.
Модель: Gemini 2.5 Flash (хороший баланс скорости и качества)
Экономия: 300 часов и 600 000 ₽.
Итеративная доработка промпта:
Как исправили:
01
Запустили LLM → получили плохой результат
02
Сравнили с эталоном (ручная работа SEO)
03
Классифицировали типы ошибок
04
Дописали правила в промпт
05
Повторили → качество выросло с 4 до 7−8 из 10
Этап 7: Формирование H1 (LLM)
→
Естественность (не «keyword keyword keyword»)
→
Правильный регистр (бренды на латинице, не «фокс про»)
→
Правильное число («Аккумулятор», не «Аккумуляторы», если запрос в ед. числе)
→
Правильный порядок слов («Печенье Shock», не «Shock Печенье»)
Требования к H1:
→
Было (руками): 320 часов, 640 000 ₽
→
Стало (LLM): 20 часов, 40 000 ₽
Результат на 100к кластеров:
Примеры ошибок ДО настройки промпта:
Правила формирования H1:
Фрагмент промпта после доработки:
01
Бренды ВСЕГДА на латинице (Fox Pro, не «фокс про»)
02
Регистр: первое слово с большой, остальные с маленькой (кроме брендов)
03
Число: как в запросе (если «аккумулятор» → не «аккумуляторы»)
04
Порядок слов: сначала товар, потом бренд («Печенье Shock», не «Shock Печенье»)
→ Полный пайплайн: 8 этапов от запроса до готовой страницы
Правильный ответ: «Колье ювелирные» (приоритет товарного класса над материалом)
Модель: DeepSeek V3.1 (самая точная для структуры)
→
Тег «Колье из жемчуга» → к какой категории привязать?
→
Варианты: «Украшения из жемчуга» (широко) или «Колье ювелирные» (узко)
Пример задачи:
Приоритет товарного класса:
Если в запросе есть явный тип изделия (колье, браслет, цепочка),
выбери товарную категорию, игнорируя модификаторы
(материал/вставка/пол: жемчуг, гранат, мужские).
Общий класс vs вариации:
Если доступны «Цепочки ювелирные» и «Цепочки мужские»,
всегда выбирай общий класс «Цепочки ювелирные».
Узкая товарная > широкая атрибутная:
«Колье ювелирные» (узкая товарная) лучше чем
«Украшения из жемчуга» (широкая атрибутная).
Если в запросе есть явный тип изделия (колье, браслет, цепочка),
выбери товарную категорию, игнорируя модификаторы
(материал/вставка/пол: жемчуг, гранат, мужские).
Общий класс vs вариации:
Если доступны «Цепочки ювелирные» и «Цепочки мужские»,
всегда выбирай общий класс «Цепочки ювелирные».
Узкая товарная > широкая атрибутная:
«Колье ювелирные» (узкая товарная) лучше чем
«Украшения из жемчуга» (широкая атрибутная).
Ключевые правила в промпте (после доработки):
Результат: Древовидная структура с 6 уровнями вложенности, готовая к заливке на сайт.
Задача: Привязать теговые страницы к категориям, построить иерархию.
Этап 8: Построение структуры (LLM + логика)
→
DeepSeek: 7% структурных ошибок
→
ChatGPT-4: 49% структурных ошибок
Сравнение качества:
Примеры ошибок ChatGPT:
→ Итоговая схема процесса (визуализация)
Время прохождения 10 000 запросов через весь пайплайн: 4−6 часов (с учетом ручной проходки).
Команда: 6 человек (vs 18 человек без автоматизации).
→ Итоговая схема процесса (визуализация)
Время прохождения 10 000 запросов через весь пайплайн: 4−6 часов (с учетом ручной проходки).
Команда: 6 человек (vs 18 человек без автоматизации).
→ Цифры эффективности
Проект: Топ-10 e-commerce РФ, расширение структуры по категории одежда/обувь.
Экономия в 10 раз по времени.
Что получилось
→
Обработано: 450 000 кластеров (vs 50 000 без ИИ)
→
Скорость: 50 000 — 100 000 запросов в сутки
→
Создано: 690 000 новых страниц
→
Проработано: 19 000 категорий
→
Общий объем: 6 млн запросов в семантике
Результаты за 3 месяца с автоматизацией:
→
7 300 кластеров
→
35 000 запросов
Ежесуточная производительность:
→
Было: 10 минут на 1 кластер (сбор СЯ + H1 + структура)
→
Стало: 1 минута на 1 кластер
Время обработки:
→ Экономика
Сколько стоит автоматизация
→
Время: ~2 000 часов
→
ФОТ команды: ~2 500 000 ₽
→
Срок: 4-6 месяцев
Сравнение затрат на 100 000 кластеров:
Классический подход (без ИИ):
Экономия:
→
По деньгам: в 3.3 раза (1.75 млн ₽)
→
По времени: в 6−12 раз (4−5 месяцев)
→
Настройка пайплайна: ~100 часов работы
→
Стоимость настройки: ~200 000 ₽
Порог эффективности
До 1000 кластеров: дешевле сделать руками.
От 1 000 кластеров: автоматизация начинает окупаться.
От 10 000 кластеров: автоматизация дает кратную экономию.
100 000+ кластеров: без автоматизации вообще нереально в разумные сроки.
С автоматизацией (LLM):
→
Время: ~200 часов (человеко-часов)
→
ФОТ: ~400 000 ₽ (меньше людей)
→
Итого: ~750 000 ₽
→
LLM API: ~350 000 ₽ (все модели)
→
Срок: 2-4 недели
→ Подводные камни
01
LLM не понимают бизнес-контекст
→
LLM может предложить структуру под «купальники» зимой
→
Или не учтет, что у клиента нет определенных брендов
Проблема: Модель не знает специфику ниши, ассортимент, сезонность.
Решение: Ручная проходка 5−10% результата + корректировка промптов под нишу.
Пример:
02
Промпты нужно дорабатывать под каждый проект
→
В ювелирке: «кольцо с топазом» → категория «Кольца», не «Украшения с топазом»
→
В одежде: «пуховик красный» → тег, не категория
Проблема: Универсального промпта нет. Каждая ниша имеет особенности.
Решение: Итеративная доработка промптов с проверкой на эталоне.
Пример:
03
Качество LLM — максимум 95%
→
5−10% результата нужно проверять и править руками
→
Полностью доверять нельзя
Реальность: Даже лучшая модель (DeepSeek, 8/10) делает ошибки.
Решение: Гибридный подход = 90−95% ИИ + 5−10% человек.
Что это значит:
05
API могут падать
→
GPT-4o: 32% сбоев API
→
Qwen3: 20% потерь данных
Проблема: Сбои API убивают весь процесс.
Решение:
→
Выбирать стабильные модели (Gemini, Claude, DeepSeek)
→
Иметь резервную модель
→
Логировать все запросы для восстановления
Пример из исследования:
06
Кластеризация — слабое место LLM
Проблема: LLM пока плохо справляются с кластеризацией запросов.
Решение: Используем проверенные сервисы (Key Collector, Rush Analytics).
04
Разные задачи = разные модели
→
Чистка СЯ: Gemini Flash 2 (скорость + цена)
→
Структура: DeepSeek V3.1 (точность)
→
H1: Gemini 2.5 Flash (скорость + качество)
→
Типизация: DeepSeek V3.1 (точность)
Ошибка: Использовать одну модель для всех задач.
Решение: Выбирать модель под задачу, а не использовать одну для всего.
Реальность:
Подводные камни и где все еще нужны руки
Инфраструктура
- SQL БД — хранение
- Python 3.x — оркестрация
- 5 ПК в локальной сети — параллелизация
- OpenRouter — доступ к 300+ LLM
- Keyso API — парсинг семантики
- JustMagic API — дополнительный источник
API и сервисы
Модели LLM
- DeepSeek V3.1 — структура, типизация
- Gemini Flash 2 — чистка СЯ, классификация
- Gemini 2.5 Flash — H1, скорость
- Claude Sonnet 4 — резерв для критичных задач
Инструменты кластеризации
- Key Collector
- Rush Analytics
- Топвизор
Дополнительная автоматизация
- Google Apps Script — интеграции
- API коннекторы различных SEO-сервисов
→ Технологический стек
→ Чеклист: что нужно для запуска пайплайна
→
Python-скрипт для API запросов к LLM
→
SQL БД, можно начать с SQLite
→
Аккаунт OpenRouter — $ 50 на старте
→
Тестовый массив 1 000—5 000 запросов
→
SEO-специалист для настройки промптов
Бюджет: ~50 000 рублей (работа + API)
Срок: 2−3 недели на настройку
Минимальный вариант для теста
Полноценный вариант для production
→
SQL БД с API интеграцией Keyso
→
Python-парсер с интерфейсом
→
Аккаунты OpenRouter на каждый ПК
→
3−5 ПК для параллелизации
→
Команда: 2−3 SEO + 1 Python-разработчик
→
Набор промптов под разные задачи
→
Процесс ручной проходки
Бюджет: 200 000 — 500 000 рублей на настройку
Срок: 1−2 месяца на развертывание
→ Итоги: когда это имеет смысл
ИИ обрабатывает 90−95% → Человек проверяет 5−10% → Результат 8/10
→ Что дальше
Автоматизация SEO через LLM — это не замена специалистов, а инструмент масштабирования.
03
Генерация мета-описаний с учетом CTR
04
Предсказание приоритетных кластеров
02
Автоматическая привязка товаров к категориям
01
Автоматизация генерации контента
Следующие шаги:
Технологии быстро развиваются. То, что год назад делали руками за месяц, сегодня автоматизируется за неделю.
Главное: не пытаться заменить людей ИИ, а дать людям инструмент для работы с нечеловеческими объемами.
Хочешь внедрить такой пайплайн в своем проекте? Пиши @headofseo_um — разберем специфику и посчитаем целесообразность.
Формула успеха:
Погрузимся в особенности вашего бизнеса, составим стратегию и запустим продвижение