Keys.so + LLM: как автоматизировать SEO и сэкономить 1,7 млн рублей на семантике

Рынок изменился. Экономика проектов — пока нет.

За последние два года условия крупных SEO-тендеров заметно ужесточились. Клиенты из топ-сегмента e-commerce приходят с задачами, которые раньше либо решались силами большой in-house команды, либо не ставились вообще: сотни тысяч страниц, фиксированный бюджет, жёсткие сроки.

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

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

Digital-агентство «Умный маркетинг» прошло через оба сценария, прежде чем нашло третий.

В этой статье ведущий SEO-эксперт агентства Иван Бахтин поделился кейсом, как Keys.so и LLM помогли масштабировать сбор семантики и перестроить экономику для крупного SEO-проекта.

Содержание

1. Задача, которую нельзя решить в лоб
2. Где ломается классика
3. Переосмысление Keys.so: от интерфейса к источнику данных
4. Второй уровень: что делает LLM поверх этих данных
5. Какая модель для какой задачи
6. Как мы контролировали качество
7. Результаты
8. Для каких проектов это имеет смысл
9. Вместо вывода

Задача, которую нельзя решить в лоб

В 2025 году в digital-агентство «Умный маркетинг» пришёл клиент из топ-10 российского e-commerce.

Задача звучала так: за полгода собрать семантику для 500 000 кластеров. По каждому — структура сайта, заголовки H1, анкоры для перелинковки, типизация страниц.

Мы взялись. Классически: шесть специалистов, Wordstat, Keys.so, Excel, руки.

Через три месяца картина была такая:

• Выполнено 10% объёма
• Рентабельность проекта: −60%
• Команда работала по 15 часов в день

Проблема была не в людях и не в инструментах — в подходе. Классический SEO-процесс физически не масштабируется на такие объёмы. Это структурная история.

Посмотрим, где именно ломается.

Где ломается классика

Стандартный процесс для крупного SEO-проекта выглядит так:

Выгрузка семантики из сервисов → Ручная чистка → Кластеризация → Построение структуры → Типизация страниц → Метатеги → Анкоры.

Семь этапов. На небольших проектах работает нормально. На больших каждый этап упирается в свой потолок.

Данные. Keys.so по умолчанию не отдаёт всю семантику сразу по крупным доменам — нужно выгружать частями. Excel начинает буксовать на 300–500 тысячах строк и останавливается на миллионе. Ручная сводка данных по конкурентам — отдельная история, которая съедает часы.

Стоимость входных данных. Если собирать то, что нужно для серьёзного проекта, через стандартные инструменты, это стоит денег. На нашем проекте в 3,5 млн ключей расклад был такой:

И это ещё до того, как команда приступила к содержательной работе.

Ручная обработка. Написать H1 для 100 000 кластеров — это 320 часов работы SEO-специалиста и 640 000 рублей. Умножьте на пять, если кластеров 500 000. Нанять ещё 12 человек — значит добавить проблем с координацией и контролем качества, плюс увести рентабельность в глубокий минус. Решение «больше людей» здесь не работает.

Переосмысление Keys.so: от интерфейса к источнику данных

Переломный момент наступил, когда мы поняли: большинство агентств используют Keys.so как интерфейс. Зашли, посмотрели конкурентов, выгрузили нужное в таблицу, дальше руками. Это нормально, когда объём позволяет работать руками.

Нам объём не позволял. И мы переключились на API Keys.so.

Запросы из сервиса начали поступать напрямую в SQL-базу данных, минуя Excel и ручную сводку. Что это даёт в практическом смысле:

• Объём без ограничений. SQL работает с миллионами строк без пробуксовок. Туда же, в одну базу, стекаются данные по конкурентам, частотки, позиции, релевантные URL.
• Скорость. Данные поступают порциями по API, не нужно ждать, пока выгрузится очередной CSV.
• Готовность к обработке. Данные сразу структурированы и готовы к следующему этапу — никакой ручной сводки.

В цифрах это выглядит так:

На всём проекте в 3,5 млн ключей это дало экономию около 1 765 000 рублей — до того, как мы обработали хоть один кластер.

Keys.so здесь решает задачу поставки данных.

По API собирали данные из инструментов: Групповой отчёт, Список запросов страниц, Запросы сайта, База запросов Keys.so.

Второй уровень: что делает LLM поверх этих данных

Данные из Keys.so — это сырой материал. Их нужно чистить, классифицировать, типизировать, превращать в заголовки и иерархию разделов. Именно здесь классика съедает большую часть бюджета на трудозатраты.

Мы добавили слой LLM-обработки и выстроили поплайн (последовательность) этапов из трёх уровней.

Уровень 1 — Данные. Keys.so API → SQL-база. Хранит миллионы запросов, принимает данные порциями, никаких ограничений по объёму.

Уровень 2 — Оркестрация. Python-парсер разбивает массив на батчи (группы) по 200–300 строк (лимит LLM-контекста) и отправляет в нейросеть по API. Через интерфейс парсера можно выбрать шаблон задачи, отредактировать промпт, выбрать модель из 300+ доступных через OpenRouter, запустить несколько параллельных процессов. Результаты объединяются обратно в базе.

Уровень 3 — Обработка. LLM берёт на себя всё, что раньше делали руками.

Вот полный список того, что мы передали нейросетям:

Вы читаете блог Keys.so, сервиса анализа сайтов в SEO и контекстной рекламе

Попробовать сервис бесплатно

• Чистка семантики — автоматическое удаление навигационных, информационных и нерелевантных запросов.
• Классификация по категориям — определение тематического раздела для каждого запроса на старте, чтобы сразу отсечь лишнее.
• Определение топонимов и брендов — геопривязка запросов, маркировка брендовых ключей.
• Сцепка дублей — объединение кластеров-синонимов («брюки мужские» и «мужские брюки», «кольцо с сапфиром» и «сапфировое кольцо»).
• Типизация страниц — определение типа под каждый кластер: категория, категория+бренд, товар, статья, UGC.
• Генерация H1 и метатегов — с учётом языка бренда, регистра, числа и порядка слов.
• Написание анкоров — для перелинковки в массовом порядке.
• Построение структуры — иерархия разделов каталога и привязка теговых страниц к категориям.

Кластеризацию по интенту мы не отдали ни внешним сервисам, ни LLM в чистом виде — вместо этого собрали собственный пайплайн (последовательность):

1. Считаем TF-IDF по массиву запросов.
2. Лемматизируем массив (приводим к его начальной словарной форме — лемме).
3. Подключаем библиотеку векторизации (обрабатываем данные пакетом).
4. Строим векторы через эмбеддинги (модели с векторным представлением).
5. Кластеризуем по косинусному расстоянию.
6. LLM валидирует результат.

Это позволило обойтись без Topvisor, Rush Analytics и Key Collector на основном объёме. Экономия на кластеризации — около 250 000 ₽ на проекте.

Какая модель для какой задачи

Типичная ошибка при внедрении ИИ в процессы — выбрать одну модель и использовать её везде. Задачи разные по природе: одни требуют скорости, другие — точности, третьи — большого контекстного окна. Универсального решения нет.

Мы протестировали несколько моделей на реальных данных и пришли к такому распределению:

По надёжности: GPT-4o показывал до 32% сбоев API на больших объёмах, Qwen3 — около 20% потерь данных.

Gemini и DeepSeek вели себя значительно стабильнее — для промышленных объёмов это критически важно. Потерянный батч (пакет) на 10 000 кластеров — это не просто неудобство, это часы на восстановление.

Как мы контролировали качество

Автоматизация без контроля — это не автоматизация, а генератор ошибок в промышленных масштабах. Нейросеть не знает бизнес клиента, не учитывает ассортимент, сезонность, логику конкретной ниши. Ей нужно объяснить — и проверить, что поняла правильно.

На каждом этапе мы выстроили петлю обратной связи:

1. Прогоняем модель на батче (пакете).
2. Сравниваем 5–10% результата с ручным эталоном (делает мидл или сеньор).
3. Фиксируем типовые ошибки.
4. Уточняем промпт.
5. Повторяем до приемлемого качества.

Хороший пример того, насколько это важно — типизация в ювелирной нише. Задача: правильно привязать дочерний кластер к материнскому. На первый взгляд простая. На деле — нет.

На 100 таких ошибок на каждые 10 000 кластеров — это структурные проблемы в архитектуре каталога, которые потом очень дорого исправлять. Именно поэтому выборочный ручной контроль остаётся в процессе — не как дань традиции, а как необходимость.

Если нейросеть продолжает отходить от ТЗ — три настройки, которые помогают: снизить температуру до 20%, уменьшить Top-p/Top-k, убрать Frequency/Presence penalty.

Результаты

Три месяца с новым пайплайном против трёх месяцев классики — на одном и том же проекте:

Итого по проекту: 690 000 новых страниц, 19 000 категорий, 6 млн запросов в общей семантике.

По команде: при классическом подходе задачу такого масштаба потребовалось бы закрывать силами 18 человек. Мы справились командой из 6. Разница — около 8 млн рублей на ФОТ.

Для каких проектов это имеет смысл

Пайплайн — это инвестиция: около 100 часов и 200 000 рублей на настройку. Она не универсальна и не нужна всем.

Экономия начинает ощущаться от 1 000 кластеров, становится кратной — от 10 000.

На объёмах 100 000+ классический подход перестаёт быть конкурентоспособным по определению: такую задачу физически нельзя выполнить в разумный срок и бюджет силами людей. Здесь уже не вопрос «хочу ли я автоматизировать», а «могу ли я вообще участвовать в таких проектах».

Для небольших проектов с понятным объёмом привычная схема работает. Но если агентство смотрит на крупные тендеры — вопрос инвестиции в пайплайн стоит поставить уже сейчас.

Вместо вывода

Мы не изобрели ничего принципиально нового. Keys.so есть у большинства серьёзных SEO-команд. Нейросети доступны всем через API. Разница — в том, как это собрано.

Пока большинство работает с Keys.so через интерфейс и добавляет LLM как вспомогательный инструмент на отдельных этапах — это по-прежнему ручной процесс, просто с умными помощниками.

Когда Keys.so становится поставщиком данных для автоматизированного пайплайна, а LLM закрывает обработку — меняется не удобство работы, а экономика всего проекта.

В 2026 году крупные клиенты начнут разбираться в этом лучше. Требования тендеров по объёму и срокам продолжат расти. Агентства, которые выстроят такую систему сейчас, будут конкурентоспособны на этих проектах. Те, кто не выстроит, — будут проигрывать по цене или брать проекты в убыток.

Вариант «подождём и посмотрим» тоже существует, но история с рентабельностью −60% уже случилась один раз. Повторять не рекомендуем.

• Задача, которую нельзя решить в лоб
• Где ломается классика
• Переосмысление Keys.so: от интерфейса к источнику данных
• Второй уровень: что делает LLM поверх этих данных
• Какая модель для какой задачи
• Как мы контролировали качество
• Результаты
• Для каких проектов это имеет смысл
• Вместо вывода