LLM не превращает бардак в систему. Он просто масштабирует его быстрее.

SEO-индустрия стабильно делает две вещи: каждые несколько лет объявляет свою смерть и продаёт одни и те же хаотичные процессы под новыми названиями. Был «контент-маркетинг», потом «topic clusters», затем «programmatic SEO». Теперь на сцене — LLM, AI Overviews, GEO, AEO и десяток других аббревиатур, от которых у редактора дергается глаз.

Снова звучат заявления: «SEO умерло, теперь нейросети всё сделают». Кто-то запускает ChatGPT, просит «собрать семантику по нише» и получает 400 галлюцинированных запросов, 120 дублирующих страниц и 30 заголовков в стиле «Купить недорого». Это называют pipeline. Но проблема не в LLM. Проблема в том, что хаос не становится системой только потому, что вы добавили API-ключ.

Захват ниши начинается не с контента и не с промпта «сделай мне хорошо». Он начинается с инженерии спроса — с понимания, какие интенты существуют, какие типы страниц им соответствуют, где нужна посадочная, где фильтр, где сравнение, а где вообще не нужно ничего создавать.

В этой статье — не набор SEO-ритуалов и не модные слова про AI, а рабочая система. Система, в которой семантика превращается в управляемый пайплайн: от сырых запросов до кластеров, от кластеров до структуры сайта, от структуры до страниц и плана разработки. Это не теория. Это схема, которую можно адаптировать под реальную нишу, сайт и production.

Покажу, где LLM действительно полезен, а где лучше сначала включить правила, здравый смысл и не автоматизировать бардак. Потому что сегодня LLM в SEO часто используют так же, как в 2018 году использовали word2vec: с видом человека, который открыл тайну вселенной, а на деле просто ускорил производство мусора.

Чтобы не оставаться на уровне схем на салфетке, я собрал демо-пайплайн: с репозиторием, структурой данных, этапами обработки, промптами, очередью ручной проверки и интерфейсом. Это не production-ready фреймворк, а демонстрация, как такую систему можно разложить на внятные этапы.

Немного цифр, чтобы обсуждать AI-поиск без шаманизма

Если думаете, что AI-поиск — это игрушка, вот факты:

• Февраль 2026: OpenAI сообщила, что ChatGPT используют более 900 млн человек в неделю. Источник: OpenAI.
• Ноябрь 2025: Google заявила, что AI Overviews уже имеют 2 млрд пользователей в месяц. Источник: Google Blog.
• Январь 2026: AP и Reuters передали позицию британского CMA — после запуска AI Overviews новостные издания столкнулись со снижением трафика, потому что пользователи реже кликают по первоисточникам. Источник: AP.

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

Что это значит для SEO-команд в 2026

Эпоха, когда можно было выигрывать объёмом публикаций, быстро превращается в убыточную. Когда сеть переполнена AI-сгенерированным и AI-ассистированным контентом, конкурентным преимуществом становится не сам факт публикации, а качество структуры, источника, формата ответа, ясности сущностей и точность попадания в интент.

Для SEO-команд это означает:

• понимать, нужна ли странице отдельная сущность в архитектуре;
• маппить интенты не в «темы», а в конкретные типы страниц;
• не плодить дубли, каннибализацию и конфликтующие посадочные;
• превращать семантику в структурную модель сайта, а не в кладбище таблиц;
• делать контент не отдельным текстом, а частью retrieval-ready системы.

Ирония в том, что на фоне истерики про AI SEO становится не менее, а более инженерной дисциплиной.

Не «писать больше», а проектировать точнее

Слишком долго SEO изображали линейным процессом: собрали ключи, написали тексты, расставили метатеги, докинули ссылок — и вот, система. Эта схема ещё работает там, где конкуренция спит. Но в насыщенных нишах она уже слишком примитивна.

Пользовательский спрос давно перестал быть плоским. В одной нише живут коммерческие, информационные, сравнительные, брендовые, локальные, навигационные и post-purchase интенты. Пытаться закрывать всё это моделью «давайте ещё напишем статью» — как чинить архитектуру базы данных новым баннером на главной.

Отсюда типичные симптомы:

• несколько страниц конкурируют за один запрос;
• часть интентов не закрыта никакими URL;
• коммерческий спрос ведёт на блоговые статьи;
• фильтры, категории и посадочные плодятся без спроса и роли;
• новые страницы публикуются быстрее, чем команда понимает, зачем они нужны.

Основная задача сегодня — не «писать больше», а «проектировать точнее». Речь не о контенте, а о системе преобразования спроса в типы страниц, URL-слои и архитектурные правила.

Google всё чётче говорит: нужен helpful, reliable, people-first content. Особенно предупреждает против массового контента, сделанного ради ранжирования, а не ради пользы. Формально AI не запрещён. Практически сигнал ясен: если вы промышленно штампуете страницы без новой ценности, не удивляйтесь, что эта стратегия перестаёт работать — и для поиска, и для пользователя.

Цифры подтверждают: Ahrefs проанализировала 900 000 новых англоязычных страниц в апреле 2025 — 74,2% из них содержали AI-generated content. Исследование на arXiv весной 2025 оценило долю AI-текста на активных страницах минимум в 30%, с возможностью роста до 40%. Вопрос уже не в том, пришёл ли AI-контент. Вопрос в том, сколько ещё одинаково прилизанных страниц нужно индексу и пользователю, чтобы структура, источник и полезность стали важнее самого факта публикации.

Что значит «захват ниши» в 2026 году

Под «захватом ниши» я не имею в виду миллион страниц или миллион ключей. Эти метрики хороши до тех пор, пока не приходится объяснять, почему половина URL не приносит ничего, кроме расходов и головной боли.

Реальный захват ниши — это когда сайт системно покрывает значимые классы спроса и делает это архитектурно согласованно.

На практике это означает:

• сайт закрывает максимум значимых интентов, включая те, которые будут извлекаться не только классическим поиском, но и AI-интерфейсами;
• каждый интент маппится не в «какой-нибудь материал», а в конкретный тип страницы с понятной ролью;
• система поддерживается как живой слой: обновляется, валидируется, масштабируется и не превращается в археологию из URL, сделанных «под SEO».

Сегодня ниша существует в трёх плоскостях:

1. классический поиск;
2. архитектура сайта;
3. AI-поиск и LLM-интерфейсы, которые вытаскивают определения, сравнения, сущности и короткие ответы.

Поэтому быть «просто в индексе» уже недостаточно. Нужна структура и представление сущностей, удобные и поисковику, и человеку, и модели, которая может пересказать ваш контент без спроса.

Сначала рынок как система, потом семантика как данные

Одна из самых дорогих ошибок в SEO выглядит профессионально: открыть сервис, выгрузить десять тысяч запросов и назвать это стратегией. Но таблица запросов — это сырой вход, а не архитектурное решение.

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

Поэтому до сбора семантики нужен более взрослый этап: описать рынок как систему:

• какие базовые сущности есть;
• какие подтипы;
• какие атрибуты влияют на выбор;
• какие сценарии коммерческие, какие исследовательские, какие информационные;
• где важна география;
• где возникают бренды, сравнения и FAQ.

Например, в нише беговых кроссовок рынок — это не только «купить кроссовки». Здесь есть поверхность бега, дистанция, уровень подготовки, амортизация, бренд, пол, сценарии выбора, сравнения, локальный спрос и post-purchase вопросы. То есть сайт — это не «категория плюс блог», а многослойная система типов страниц.

Именно здесь видно, как SEO-проекты годами подменяли архитектурное решение фразой: «ну мы потом допишем контент».

Карта интентов: первый момент, когда SEO становится инженерией

Каждый интент должен вести к своему типу страницы: категория, сравнение, гайд или геостраница.

Когда есть модель спроса, следующий шаг — карта интентов. Это слой преобразования рынка в архитектуру.

Если пользователь хочет купить — нужен коммерческий тип страницы. Если сравнивает — страница сравнения. Если ищет информацию — гайд, FAQ или экспертный материал. Если спрос геозависим — локальная ветка.

На этом этапе формируется базовый слой типов страниц:

• категории;
• подкатегории;
• страницы фильтров;
• брендовые страницы;
• региональные страницы;
• страницы сравнения;
• FAQ;
• гайды;
• хабы и обзорные страницы.

Главная идея проста: структура сайта не должна рисоваться «по вдохновению». Она должна быть следствием карты интентов. Если нет этапа, где спрос преобразуется в типы страниц, неизбежны конфликтующие URL, каннибализация, дубли и архитектурный сюрреализм, который потом называют «исторически сложилось».

Сквозной мини-кейс: один рынок, много разных страниц

Возьмём нишу беговых кроссовок. Вот несколько запросов:

• купить беговые кроссовки;
• беговые кроссовки для асфальта;
• лучшие беговые кроссовки для марафона;
• сравнение nike pegasus и adidas boston;
• как выбрать беговые кроссовки;
• беговые кроссовки москва;
• мужские беговые кроссовки;
• беговые кроссовки с амортизацией.

Если смотреть на это как на «набор ключей», рука тянется раскидать всё по текстам. Но если смотреть как на спрос, видно, что перед нами разные типы страниц:

• общая коммерческая категория;
• фильтры по поверхности или амортизации;
• гендерные подкатегории;
• локальная страница;
• страница сравнения;
• гайд по выбору;
• подборка под марафон.

Один рынок уже требует не текстов, а архитектурных решений. Значит, нужен пайплайн, который принимает такие решения не интуитивно, а системно и воспроизводимо.

Сам пайплайн: не магия, а скучная последовательность решений

Когда карта интентов готова, можно переходить к пайплайну. Он превращает сырой спрос в структуру сайта, а не в очередную таблицу, которую никто не откроет через месяц.

Пайплайн выглядит так:

1. Intake — приём сырых данных
2. Preprocessing — нормализация и базовая чистка
3. Semantic parsing — извлечение сущностей, атрибутов и модификаторов
4. Intent classification — определение интента
5. Clustering — объединение запросов в кластеры
6. Page typing — выбор целевого типа страницы
7. H1 / Title generation — создание человекочитаемых названий
8. URL matching — сопоставление с существующей архитектурой
9. Conflict detection — поиск каннибализации и конфликтов
10. Content brief generation — подготовка брифа для контента
11. Human review — ручная проверка спорных кейсов

Это не «AI-pipeline». Сегодня так называют всё, что не собирается в Excel. Здесь речь о pipeline принятия решений. На одних этапах работают правила, на других — embeddings, на третьих — LLM. В конце всё равно нужен человек, который не даёт системе уверовать в собственную гениальность.

Этап 1. Intake: без нормального входа нет никакого «умного SEO»

На вход система получает данные из:

• CSV или XLSX;
• Google Search Console;
• подсказок поисковиков;
• related searches;
• парсинга конкурентов;
• внутреннего поиска;
• ручных списков.

Главная задача — собрать вход аккуратно, воспроизводимо и с трассировкой происхождения данных.

Минимальный набор полей для raw-query:

• query_text
• source
• region
• language
• frequency
• competition
• batch_id
• created_at
• status

Если вы не можете ответить, откуда взялся запрос и в каком batch он был обработан, у вас не pipeline. У вас пакет файлов под названием semantics_final_v7_really_final.xlsx.

Этап 2. Предобработка: никакого глянца, только санитарная обработка

Очистка — этап, который недооценивают, потому что он не эффектный. Никаких векторных чудес — просто приведение данных к виду, пригодному для решений.

На этом этапе система:

• приводит регистр к единому виду;
• убирает мусорные символы;
• нормализует пробелы;
• выносит дубли;
• выделяет гео-модификаторы;
• помечает шумовые фразы;
• формирует базовые токены.

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

Здесь кстати появляется Python — не как культовый язык, а как рабочая лошадка для токенизации, нормализации, дедупликации, работы со словарями, стоп-словами, гео-справочниками, брендовыми списками и морфологией.

Предобработка — это Python-обвязка вокруг:

• rule-based логики;
• локальных словарей и справочников;
• внутренних retrieval / RAG-слоёв;
• исторических списков исключений;
• брендовых, товарных и географических матчингов.

Python успевает почистить мусор, привести сущности к нормальной форме, проверить совпадения, подсветить подозрительные кейсы и подтянуть контекст из внутренней базы знаний.

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

Хорошая предобработка — это lightweight enrichment + retrieval before reasoning. Python берёт запрос, проверяет по базам, достаёт контекст и либо сам решает, либо передаёт обогащённый объект в LLM-этап.

Полезно получать флаги:

• is_duplicate
• is_garbage
• has_geo_modifier
• needs_review

Ещё до «настоящего AI» система убирает мусор, размечает рискованные кейсы и строит очередь ручной валидации.

Этап 3. Semantic parsing: вот где LLM действительно полезен

Здесь LLM приносит пользу не как генератор вдохновляющих абзацев, а как структурный парсер с structured output.

Задача — превратить запрос в машиночитаемый объект:

• основная сущность;
• тип сущности;
• атрибуты;
• модификаторы;
• география;
• гипотеза по интенту;
• предварительный кандидат на тип страницы.

Например, для запроса «купить зимние шины r17 в москве» система должна вернуть не размышление, а структурированный объект, который можно валидировать, сохранять и передавать дальше.

Здесь хорошо работает связка Python + retrieval + LLM. Python собирает объект, подтягивает справочники, исторические кейсы, исключения и правила. LLM получает не голую строку, а обогащённый объект. Это почти всегда выигрывает у «чистого» LLM-вызова.

Полезен скоринг: confidence по сущности, надёжность интента, вероятность объединения, качество сопоставления и приоритет ручной проверки.

Но хорошая скоринговая база под конкретную нишу не появляется мгновенно. Она собирается через исторические кейсы, ручную разметку, накопленные ошибки, обратную связь и живые данные. За красивой идеей scoring pipeline — прозаичное накопление доменной базы признаков.

Этап 4. Классификация интента: слово «купить» — не единственный носитель смысла

Наивная версия: «ну тут же видно, коммерческий запрос или нет». Иногда видно. На живых данных — не всегда.

Поэтому intent classification стоит выделять в отдельный слой. Система определяет:

• commercial
• informational
• comparison
• navigational
• local
• transactional
• mixed / ambiguous

Интент напрямую влияет на тип страницы. Один и тот же корень может вести в категорию, гайд, страницу сравнения или не требовать URL.

Здесь хорошо работает гибрид:

• словари и маркеры;
• rule-based логика;
• LLM-классификация на спорных кейсах;
• SERP-проверка на ценных кластерах.

Если ваш «AI SEO tool» не работает с интентом явно — есть шанс, что это просто перекрашенный генератор заголовков.

Этап 5. Кластеризация: конец магии, начало инженерии

Кластеризация — любимое место для SEO-оккультизма. «Скормим всё векторам и посмотрим, что получится». Обычно получается вдохновляюще в интерфейсе и бесполезно в архитектуре.

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

Рабочая кластеризация почти всегда гибридная:

• грубая группировка по сущности;
• уточнение по атрибутам;
• проверка интента;
• смысловая близость по векторам;
• LLM для спорных случаев;
• ручная проверка ценных конфликтов.

На выходе должен быть не «кластер похожих слов», а осмысленная единица спроса и страницы: либо URL-кандидат, либо сознательно отвергнутый слой спроса.

Скоринг снова полезен — не как серебряная пуля, а как второй слой решений. Можно считать близость по сущности, совместимость по интенту, совпадение по атрибутам, конфликтность по гео, риск каннибализации и силу совпадения с утверждёнными кластерами. Когда сигналы собраны, кластеризация превращается в процедуру с понятными confidence coefficients.

Но универсального scoring setup почти не существует. То, что работает в шинах, может не работать в медицине. То, что подходит e-commerce, бесполезно для SaaS. Поэтому сильная система оценок — это всегда доменная работа: разметка, переоценка, исправление ошибок, проверка на живых кейсах. Хорошие нишевые pipeline редко рождаются быстро, но потом работают стабильнее любой автокластеризации «в один клик».

Этап 6. Выбор типа страницы: самый недооценённый шаг

После кластеризации система должна ответить: что это за страница?

В большинстве SEO-процессов этот шаг формально есть, но нигде не зафиксирован. Решение принимается, но не формализуется. Команда разработки получает ТЗ: «сделайте ещё SEO-страницу, она вроде нужна» — и архитектурная точность заканчивается.

Типовые варианты:

• category
• subcategory
• filter_page
• brand_page
• geo_page
• comparison_page
• guide_page
• faq_page
• hub_page
• no_page_needed

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

Этап 7. H1 и Title: автоматизировать, но без SEO-лихорадки

Когда кластер и тип страницы определены, возникает соблазн нажать «Generate SEO Title». И родить: «Купить зимние шины R17 в Москве недорого цена». Привет из 2011-го.

Поэтому генерация заголовков должна быть управляемой. Нормальный pipeline не просит LLM «придумай красиво». Он передаёт жёсткий вход и ограничения:

• тип страницы;
• canonical label кластера;
• стилистические ограничения;
• запрет на спам и повторения;
• формат вывода.

На выходе:

• recommended_h1
• recommended_title
• slug_candidate
• meta_description_draft

Полезно хранить происхождение решения: что сделано правилами, что — моделью. Иначе потом невозможно понять, почему появилось «Лучшие лучшие кроссовки для лучших бегунов».

Этап 8. Сопоставление URL: жизнь начинается там, где кончаются идеальные схемы

Пока структура рисуется «с нуля», всё красиво. Настоящая жизнь — когда новые кластеры нужно сматчить с существующим сайтом: со старой архитектурой, кривыми slug-ами и забытыми фильтрами.

Задача url_matching:

• проверить существующие страницы;
• учесть синонимы и морфологию;
• сравнить атрибуты;
• поймать совпадения по брендам, фильтрам и гео;
• посчитать match_confidence;
• выдать решение: reuse_existing_url / create_new_url / needs_review.

Вот здесь pipeline становится реальным продуктом, а не слайдом с модными словами про «векторную близость».

Этап 9. Поиск конфликтов: взрослость системы начинается здесь

Один из признаков зрелой системы — наличие слоя, который ищет не только возможности, но и противоречия.

Поиск конфликтов ловит:

• два кластера на один URL;
• конфликтующее назначение типа страницы;
• пересечение H1;
• конфликт slug-ов;
• каннибализацию parent/child-страниц;
• смешение geo и non-geo;
• смешение informational и commercial интентов.

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

Этап 10. Генерация контент-брифа: контент должен идти после архитектуры

Слишком часто контент-процесс запускают до того, как ясна роль страницы. В итоге тексты пишутся до понимания, где они будут жить и какую функцию выполнять.

В нормальном pipeline бриф появляется только после фиксации:

• типа страницы;
• интента;
• целевого кластера;
• обязательных сущностей;
• родительской логики;
• существующего или нового URL.

Тогда бриф становится рабочим документом. В нём можно явно указать:

• цель страницы;
• обязательные блоки;
• ключевые вопросы пользователя;
• где нужен FAQ;
• где нужны коммерческие факторы;
• где полезна structured data;
• где не надо лить пять тысяч знаков текста просто потому, что кому-то так спокойнее.

Этап 11. Ручная проверка: да, человек всё ещё нужен

Сильный pipeline не обещает магической автономности. Он сокращает рутину и отдаёт человеку только кейсы, где его решение стоит дороже автоматизации.

На ручную проверку уходят:

• кластеры с низким confidence;
• подозрение на merge / split конфликт;
• спорный тип страницы;
• слабый URL match;
• потенциальная каннибализация;
• слишком SEO-шные H1;
• критичные бизнес-страницы.

Это и есть нормальный human-in-the-loop контур. Человек не перекладывает тысячи фраз. Он включается там, где цена ошибки высока.

Где LLM действительно нужен, а где лучше не устраивать техно-спиритизм

Главный антихайповый тезис: LLM не должен заменять pipeline. Он должен быть встроенным модулем внутри него.

Где LLM особенно полезен:

• извлечение сущностей и атрибутов;
• классификация спорных интентов;
• предварительное назначение типа страницы;
• генерация канонического названия кластера;
• генерация H1 в заданных ограничениях;
• выявление конфликтов в сложных случаях;
• построение контентного брифа.

Где лучше сначала использовать правила:

• дедупликация;
• базовая чистка;
• выделение очевидных geo-модификаторов;
• первичный шум и стоп-слова;
• техническая нормализация;
• контроль ограничений по формату.

Стратегия:

1. сначала правила;
2. потом LLM там, где он добавляет ценность;
3. потом человек там, где цена ошибки высока.

Все истории про «полностью автоматизировали SEO через AI» обычно требуют дополнения: «а потом три недели руками разгребали результат».

Production prompts: шаблоны, которые не стыдно запускать массово

Это не магические заклинания. Это production-шаблоны с жёстким structured output. Их задача — не впечатлять, а давать результат, который можно валидировать, логировать и безопасно прогонять массово.

Они хороши не креативностью, а надёжностью.

Prompt 1. Извлечение сущностей: сначала сущность, потом всё остальное

Системный промпт:

You analyze search queries for SEO architecture. Your task is to extract the main entity, entity type, attributes, modifiers, geo, and initial intent hypothesis. Return only valid JSON matching the required schema. If data is insufficient, do not guess. Use null or empty arrays. Do not output explanations outside JSON.

Пользовательский промпт:

Analyze query: “{query}”

Return strict JSON with fields:

• entity
• entity_type
• attributes
• modifiers
• geo
• intent_candidate
• page_type_candidate
• confidence

Prompt 2. Классификация интента: слово «купить» — не единственный сигнал

System prompt:

You classify search queries by intent. Allowed values for primary_intent: commercial, informational, comparison, navigational, local, transactional, mixed. Return strict JSON only. If ambiguity is high, set secondary_intent and needs_manual_review=true. Do not explain outside JSON.

User prompt:

{ “query”: “{query}”, “normalized_query”: “{normalized_query}”, “entity”: “{entity}”, “attributes”: {attributes} }Expected output:{ “primary_intent”: “”, “secondary_intent”: “”, “reason_short”: “”, “needs_manual_review”: false, “confidence”: 0.0 }

Prompt 3. Назначение типа страницы: не каждый кластер заслуживает отдельный URL

System prompt:

You determine the optimal page type for a search cluster. Choose only from: category, subcategory, filter-page, brand-page, geo-page, comparison-page, guide-page, faq-page, hub-page, no-page-needed. Consider intent, entity stability, attributes, and whether a separate page is actually justified. Return strict JSON only.

System prompt:

Cluster: “{cluster_label}” Main entity: “{entity}” Intent: “{intent}” Attributes: {attributes} Query count: {query_count} Total frequency: {total_frequency}Expected output:{ “page_type”: “”, “why_short”: “”, “should_create_new_page”: true, “needs_manual_review”: false, “confidence”: 0.0 }

Prompt 4. Генерация H1: автоматизация без SEO-лихорадки

System prompt:

You generate H1 for an SEO page. H1 must be natural, short, readable, and non-spammy. Do not repeat keywords, do not list modifiers with commas, do not use bureaucratic phrasing. Keep alignment with cluster meaning and page type. Return strict JSON only.

User prompt:

Page type: “{page_type}” Cluster: “{cluster_label}” Main entity: “{entity}” Attributes: {attributes} Geo: “{geo}”Expected output:{ “h1”: “”, “short_title”: “”, “slug_candidate”: “”, “confidence”: 0.0 }

Prompt 5. Обнаружение конфликтов: должны ли эти кластеры жить на одной странице

System prompt:

You check two SEO clusters for structural conflict. Decide whether they should map to the same page, different pages, or require manual review. Consider intent, entity, attributes, geo, and page type. Return strict JSON only.

User prompt:

Cluster A: {cluster_a} Cluster B: {cluster_b}Expected output:{ “decision”: “same-page|different-pages|manual-review”, “conflict_type”: “”, “reason_short”: “”, “confidence”: 0.0 }

Общий принцип всех шаблонов:

• жёсткий structured output;
• ограниченный словарь допустимых решений;
• confidence там, где нужен контроль;
• manual_review там, где ошибка может быть дорогой.

Это не косметика. Это разница между «чатик что-то ответил» и production-слоем, который можно встроить в pipeline.

Что лежит в демо-репозитории: не схема, а рабочий каркас

Чтобы статья не осталась правильными словами, к ней приложен демо-репозиторий: тот же pipeline, но в коде, данных и интерфейсе.

В репозитории:

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

Как это запустить локально и зачем вообще это делать

Важно, чтобы систему можно было не только прочитать, но и руками прогнать по шагам.

Базовый сценарий локального запуска:

1. Клонируете репозиторий.
2. Устанавливаете зависимости.
3. Прописываете ключ LLM-провайдера в .env.
4. Запускаете пайплайн на демо-датасете.
5. Открываете демо-админку и смотрите, как список запросов превращается в кластеры, типы страниц, H1, URL-кандидаты и очередь ручной проверки.

Смысл не в стеке, а в логике. Важно пройти путь: от сырых запросов к нормализованным, от них — к сущностям и интентам, дальше — к кластерам, типам страниц, структуре сайта, конфликтам и брифам.

Это лучше любой абстрактной диаграммы с шестью прямоугольниками и словом «AI» посередине.

Интерфейс как часть аргумента

Важно показать не только код, но и интерфейс. В SEO слишком много процессов живёт в пачке таблиц, понятных одному человеку.

В демо-админке:

• обзорная панель;
• импорты и batch-загрузки;
• сырые запросы;
• смысловой разбор;
• кластеры;
• структура сайта;
• сопоставление URL;
• студия промптов;
• очередь проверки;
• контент-брифы.

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

Почему это уже не SEO-хак, а продуктовый подход

Речь уже не про «оптимизацию текстов». Это система преобразования спроса в продуктовые решения.

Хороший SEO-pipeline похож на внутреннюю поисковую операционную систему:

1. собирает данные;
2. приводит их к структурированному виду;
3. принимает решения по типам страниц;
4. проверяет конфликты;
5. управляет приоритетами;
6. помогает разработке и контенту работать от одной картины мира.

Разговор о будущем SEO уже нельзя вести только в терминах текстов, ссылок и метатегов. На первый план выходят структура, сущности, архитектура, quality control и способность соединять классический поиск с AI-видимостью.

Что получается на выходе

Если pipeline собран нормально, команда получает не абстрактную «семантику», а конкретные рабочие сущности:

• карта интентов;
• кластеры;
• типы страниц;
• H1 и slug-кандидаты;
• матчи с существующими URL;
• бэклог новых страниц;
• список конфликтов;
• контент-брифы;
• очередь ручной валидации.

И семантика наконец перестаёт быть таблицей, живущей своей жизнью, и становится базой для реальной разработки сайта.

Вместо вывода: у поиска заканчивается терпение, и это только начало

В ближайшие годы проиграют не только те, кто не использует AI. Проиграют и те, кто использует его как конвейер по производству цифрового пенопласта.

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

Главный вопрос больше не в том, умеете ли вы генерировать тексты. Это уже умеют почти все. Главный вопрос в другом: умеете ли вы строить систему, в которой каждая страница имеет право на жизнь.

Если нет — никакой LLM вас не спасёт. Он просто ускорит производство ошибок.

Если да — у вас появляется шанс не пополнить бесконечную серую массу страниц, которые поиск индексирует по инерции, а пользователь закрывает по привычке.

И это самый неприятный вывод для рынка: будущее выигрывают не самые шумные и не самые «AI-native». Его выигрывают самые дисциплинированные — те, кто готов разбираться в сущностях, интентах, скоринге, архитектуре, ручной валидации и всей той доменной грязной работе, без которой ничего устойчивого не строится.

Все остальное — это просто очень быстрый способ масштабировать мусор.

LLM не превращает бардак в систему. Он просто масштабирует его быстрее.

SEO‑индустрия умеет делать две вещи особенно стабильно. Во‑первых, каждые несколько лет торжественно объявлять свою смерть. Во‑вторых, продавать одни и те же хаотичные процессы под новыми словами. Раньше это называлось «контент‑маркетинг», потом «topic clusters», потом «programmatic SEO», теперь на сцену влетели LLM, AI Overviews, GEO, AEO и еще десяток аббревиатур, от которых у любого редактора дергается глаз.

На этом месте обычно появляется очередной бодрый тред в духе «SEO умерло, теперь нейросеть сама все сделает». Потом кто‑то идет в ChatGPT, просит «собери семантику по нише», получает 400 красивых галлюцинаций, 120 дублирующих друг друга страниц, 30 заголовков в стиле «Купить купить купить недорого цена» и торжественно называет это pipeline.

Проблема, конечно, не в LLM. Проблема в том, что хаос не становится системой только потому, что вы добавили к нему API‑ключ.

Если упростить весь тезис статьи до одной мысли, то она будет такой: захват ниши начинается не с контента и не с промпта «сделай мне хорошо». Он начинается с инженерии спроса. С понимания того, какие интенты вообще существуют в рынке, какие типы страниц им соответствуют, где нужна коммерческая посадочная, где фильтр, где сравнительная страница, а где честнее вообще ничего не создавать.

В этой статье я хочу разобрать не набор SEO‑ритуалов и не коллекцию модных слов про AI, а рабочую систему. Ту самую, в которой семантика перестает быть кладбищем таблиц и превращается в управляемый пайплайн: от сырых запросов до кластеров, от кластеров до структуры сайта, от структуры до страниц, а от страниц до понятного плана разработки, контента и AI‑видимости. Это не теоретическая экскурсия и не набор “полезных советов”. Это схема процессов, которую можно адаптировать под реальную нишу, реальный сайт и реальный production.

Отдельно покажу, где в этом процессе LLM действительно приносит пользу, а где лучше сначала включить правила, здравый смысл и привычку не автоматизировать бардак. Потому что LLM в SEO сегодня часто используют примерно так же, как в 2018 использовали word2vec: с видом человека, который открыл тайную дверь во вселенную, а на деле просто ускорил производство мусора.

Чтобы статья не осталась на уровне схем на салфетке, я собрал к ней демо-pipeline: с репозиторием, структурой данных, этапами обработки, LLM-промптами, очередью ручной проверки и простым интерфейсом для просмотра артефактов. Это не production-ready фреймворк, а демонстрация того, как такую систему можно разложить на внятные этапы.

Репозиторий демо‑пайплайна:https://github.com/staurus86/llm-pipeline-demo

Немного цифр, чтобы обсуждать AI-поиск без шаманизма

Если всё ещё хочется считать AI-поиск игрушкой для любителей промптов, вот несколько вполне приземлённых цифр, после которых спорить становится чуть сложнее.

• 27 февраля 2026 OpenAI сообщила, что ChatGPT используют более 900 млн человек в неделю.. Источник:OpenAI
• 18 ноября 2025 Google заявила, что AI Overviews уже имеют 2 млрд пользователей в месяц.. Источник:Google Blog
• В январе 2026 AP и Reuters пересказывали позицию британского CMA: после запуска AI Overviews новостные издатели столкнулись со снижением трафика, потому что пользователи реже кликают по первоисточникам. Источник:AP

Перевод на нормальный язык простой: это уже не футурология. Это изменение интерфейса поиска, модели клика и логики потребления ответа. И если у сайта до сих пор нет внятной логики сущностей, page types и архитектурных правил, то догонять придётся уже на бегу — в момент, когда интерфейс поиска начал отдавать ответ раньше, чем пользователь дошёл до вашей страницы.

Что это значит для SEO-команд в 2026

Коротко: эпоха, в которой можно было выигрывать просто объёмом публикаций, быстро превращается из комфортной в убыточную. Когда сеть переполнена AI-сгенерированным и AI-ассистированным контентом, конкурентным преимуществом становится не сам факт публикации, а качество структуры, источника, формата ответа, entity clarity и точность попадания в интент.

Для SEO‑команд это означает довольно приземленную вещь. Конкурентным преимуществом становится не скорость штамповки страниц сама по себе, а способность:

• понимать, нужна ли странице вообще отдельная сущность в архитектуре;
• маппить интенты не в “темы”, а в конкретные page types;
• не плодить дубли, каннибализацию и конфликтующие посадочные;
• превращать семантику в структурную модель сайта, а не в кладбище таблиц;
• делать контент не отдельным текстом, а частью retrieval-ready системы.

Ирония в том, что на фоне всей истерики про AI SEO становится не менее, а более инженерной дисциплиной.

Не «писать больше», а проектировать точнее

Слишком долго SEO было удобно изображать линейным и почти бытовым процессом: собрали ключи, написали тексты, расставили метатеги, докинули ссылок, сделали вид, что построили систему. Эта схема все еще местами работает, особенно там, где конкуренция спит и не просыпается. Но в насыщенных нишах она уже слишком примитивна.

Пользовательский спрос давно перестал быть плоским. Внутри одной ниши живут коммерческие, информационные, сравнительные, брендовые, локальные, навигационные и post-purchase интенты. Пытаться закрывать всё это моделью “давайте ещё напишем статью” — примерно как чинить архитектуру базы данных новым баннером на главной.

Отсюда появляются хорошо знакомые симптомы:

• несколько страниц начинают конкурировать за один и тот же запрос;
• часть интентов вообще не закрыта никакими URL;
• коммерческий спрос ведет на блоговые статьи;
• фильтры, категории и посадочные плодятся без достаточного спроса и без внятной роли в архитектуре;
• новые страницы публикуются быстрее, чем команда успевает понять, зачем они нужны.

То есть основная задача сегодня звучит уже не как «писать больше», а как «проектировать точнее». И вот здесь начинается разговор не про контент сам по себе, а про систему преобразования спроса в page types, URL-слои и архитектурные правила.

Судя по официальной риторике Google, терпимость к массовому “нормально звучащему” контенту без добавочной ценности становится всё менее бесконечной. Google по-прежнему довольно прямо говорит про helpful, reliable, people-first content и отдельно предупреждает против массового контента, сделанного прежде всего ради ранжирования, а не ради пользы человеку. Формально AI не запрещён. Практически сигнал читается просто: если вы промышленно штампуете страницы без новой ценности, не надо потом удивляться, что эта стратегия выглядит всё менее убедительно и для поиска, и для пользователя.

По цифрам картина тоже показательна. Ahrefs в исследовании 900 000 новых англоязычных страниц, найденных в апреле 2025, сообщили, что 74.2% из них содержали AI-generated content. Отдельно paper на arXiv весной 2025 оценивал долю AI-текста на активных веб-страницах минимум в 30%, с возможным приближением к 40%. Иными словами, вопрос уже не в том, пришёл ли AI-контент в веб. Вопрос в том, сколько ещё одинаково прилизанных страниц нужно индексу и пользователю, чтобы структура, источник и полезность стали важнее самого факта публикации.

Что значит «захват ниши» в 2026 году

Под “захватом ниши” я не имею в виду миллион страниц и не имею в виду миллион собранных ключей. Эти метрики любят ровно до того момента, пока не приходится объяснять, почему половина URL не приносит ничего, кроме расходов, шума и головной боли.

Реальный захват ниши — это когда сайт системно покрывает значимые классы спроса и делает это архитектурно согласованно.

На практике это означает три вещи.

• сайт закрывает максимум значимых интентов, включая те, которые будут извлекаться не только классическим поиском, но и AI-интерфейсами;
• каждый интент маппится не в “какой-нибудь материал”, а в конкретныйpage typeс понятной ролью в архитектуре;
• система поддерживается как живой слой: обновляется, валидируется, масштабируется и не превращается в археологию из URL, которые когда-то делали “под SEO”.

Сегодня ниша существует сразу в трех плоскостях:

1. классический поиск;
2. архитектура самого сайта;
3. AI-поиск и LLM-интерфейсы, которые вытаскивают определения, сравнения, сущности и короткие ответы.

Поэтому быть “просто в индексе” уже недостаточно. Нужна такая структура и такое представление сущностей на сайте, чтобы ими было удобно пользоваться и поисковику, и человеку, и модели, которая решила внезапно пересказать половину вашего контента без спроса.

Сначала рынок как система, потом семантика как данные

Одна из самых дорогих ошибок в SEO выглядит очень профессионально: открыть сервис, выгрузить десять тысяч запросов и с серьёзным видом назвать это стратегией. Но таблица запросов — это ещё не модель спроса. Это сырой вход, а не архитектурное решение.

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

Поэтому до сбора семантики нужен не ещё один сервис, а более взрослый этап: описать рынок как систему:

• какие базовые сущности в нем есть;
• какие есть подтипы;
• какие атрибуты влияют на выбор;
• какие сценарии коммерческие, какие исследовательские, а какие информационные;
• где важна география;
• где возникают бренды, сравнения и FAQ‑ветки.

Например, если ниша — беговые кроссовки, то рынок состоит не только из запроса “купить беговые кроссовки”. Внутри него есть поверхность бега, дистанция, уровень подготовки, амортизация, бренд, пол, сценарии выбора, сравнения моделей, локальный спрос и post-purchase вопросы. То есть будущий сайт — это уже не “категория плюс блог”, а многослойная система page types.

И именно здесь особенно хорошо видно, сколько SEO-проектов годами подменяли архитектурное решение фразой “ну мы потом допишем контент”.

Карта интентов: первый момент, когда SEO становится инженерией

Каждый интент должен вести к своему типу страницы: категория, сравнение, гайд или геостраница.

Как только появляется модель спроса, следующим шагом становится карта интентов. Это и есть слой преобразования рынка в архитектуру.

Если пользователь хочет купить — нужен коммерческий page type. Если сравнивает две сущности — страница сравнения. Если пытается понять различия, критерии выбора и сценарии применения — guide, FAQ или экспертный материал. Если спрос завязан на регионе — локальная ветка.

На этом этапе формируется базовый page-type layer:

• категории;
• подкатегории;
• страницы фильтров;
• брендовые страницы;
• региональные страницы;
• страницы сравнения;
• FAQ;
• гайды;
• хабы и обзорные страницы.

Главная идея простая: структура сайта не должна рисоваться «по вдохновению». Она должна быть следствием карты интентов. Если в системе нет явного этапа, где спрос преобразуется в типы страниц, дальше почти неизбежно начинаются конфликтующие URL, каннибализация, дублирование и тот жанр архитектурного сюрреализма, который потом вежливо называют “исторически сложилось”.

Сквозной мини‑кейс: один рынок, много разных страниц

Чтобы не оставаться на уровне абстракции, возьмем условную нишу беговых кроссовок.

Вот несколько запросов:

• купить беговые кроссовки;
• беговые кроссовки для асфальта;
• лучшие беговые кроссовки для марафона;
• сравнение nike pegasus и adidas boston;
• как выбрать беговые кроссовки;
• беговые кроссовки москва;
• мужские беговые кроссовки;
• беговые кроссовки с амортизацией.

Если смотреть на это как на “набор ключей”, рука сама тянется раскидать всё по нескольким текстам и назвать это контент-планом. Но если смотреть на это как на спрос, быстро становится видно, что перед нами разные типы страниц:

• общая коммерческая категория;
• фильтры по поверхности или амортизации;
• гендерные подкатегории;
• локальная страница;
• страница сравнения;
• гайд по выбору;
• возможно, отдельная подборка под марафон.

То есть один рынок уже на старте требует не текстов, а архитектурных решений. А значит, нужен pipeline, который умеет принимать такие решения не интуитивно, а системно и воспроизводимо.

Сам пайплайн: не магия, а скучная последовательность решений

Когда карта интентов собрана, можно переходить к pipeline. Именно он превращает сырой спрос в структуру сайта, а не в очередную красивую таблицу, которую никто не откроет через месяц.

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

1. Intake — прием сырых данных
2. Preprocessing — нормализация и базовая чистка
3. Semantic parsing — извлечение сущностей, атрибутов и модификаторов
4. Intent classification — определение интента
5. Clustering — объединение запросов в кластеры
6. Page typing — выбор целевого page type
7. H1 / Title generation — создание человекочитаемых названий
8. URL matching — сопоставление с существующей архитектурой сайта
9. Conflict detection — поиск каннибализации и конфликтов
10. Content brief generation — подготовка брифа для контента
11. Human review — ручная проверка спорных кейсов

Сразу зафиксирую: это не “AI-pipeline”. Сегодня AI-pipeline называют всё, что не собирается вручную в Excel. Здесь речь не про магию моделей, а про pipeline принятия решений. На одних этапах работают правила, на других — embeddings и similarity logic, на третьих — LLM, а в конце всё равно нужен человек, который смотрит сложные кейсы и не даёт системе окончательно уверовать в собственную гениальность.

Этап 1. Intake: без нормального входа нет никакого «умного SEO»

На вход система получает сырой материал из нескольких источников:

• CSV или XLSX;
• Google Search Console;
• подсказки поисковиков;
• related searches;
• парсинг конкурентов;
• внутренний поиск;
• ручные списки.

На этом этапе не нужно изображать интеллект. Главная задача — собрать вход аккуратно, воспроизводимо и с нормальной трассировкой происхождения данных.

Минимальный набор полей для raw‑query:

• query_text
• source
• region
• language
• frequency
• competition
• batch_id
• created_at
• status

Звучит скучно, но именно здесь начинается взрослая система. Если вы не можете ответить, откуда взялся конкретный запрос и в каком batch он был обработан, то у вас не pipeline. У вас пакет файлов под названиемsemantics_final_v7_really_final.xlsx.

Этап 2. Предобработка: никакого глянца, только санитарная обработка

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

На этапе предобработки система:

• приводит регистр к единому виду;
• убирает мусорные символы;
• нормализует пробелы;
• выносит очевидные дубли;
• выделяет гео‑модификаторы;
• помечает нерелевантные и шумовые фразы;
• формирует базовые токены.

Это как раз тот слой, где правила почти всегда полезнее, чем немедленный забег к LLM. Простые правила дают дешёвую, быструю и стабильную очистку. Если подать в модель грязный вход, она, конечно, героически что-нибудь проинтерпретирует. Но оплачивать этот героизм потом всё равно будет команда.

И вот здесь в pipeline очень кстати появляется Python. Не как культовый язык “на все случаи жизни”, а как нормальная рабочая лошадка, которой удобно доверить всю грязную, скучную и при этом критически важную механику: токенизацию, нормализацию, дедупликацию, работу со словарями, стоп-словами, гео-справочниками, брендовыми списками, морфологией и внутренними правилами проекта.

На практике слой предобработки хорошо работает именно как Python‑обвязка вокруг нескольких источников знаний:

• rule-based логики;
• локальных словарей и справочников;
• внутренних retrieval / RAG-слоёв;
• исторических списков исключений;
• брендовых, товарных и географических матчингов.

То есть ещё до LLM Python успевает сделать всю неинстаграмную, но критически важную работу: почистить мусор, привести сущности к нормальной форме, проверить совпадения по справочникам, подсветить подозрительные кейсы и, где нужно, подтянуть контекст из внутренней базы знаний.

Особенно хорошо это работает в нишах, где у проекта уже накопились собственные паттерны: синонимы, спорные формулировки, старые кластеры, правила гео-маршрутизации, словари фильтров и всё то, что обычно живёт в головах двух перегруженных специалистов и одной забытой таблице.

Если формализовать этот слой аккуратно, это lightweight enrichment + retrieval before reasoning. Python берёт запрос, проверяет его по базам и правилам, достаёт релевантный контекст и либо сам принимает простое решение, либо передаёт уже обогащённый объект в следующий LLM-этап. Именно поэтому хорошая предобработка выглядит не как “почистили строку”, а как отдельная инженерная мини-система.

Уже здесь полезно получать флаги:

• is_duplicate
• is_garbage
• has_geo_modifier
• needs_review

То есть ещё до “настоящего AI” система уже умеет вычистить значимую долю мусора, разметить рискованные кейсы и построить очередь ручной валидации.

Этап 3. Semantic parsing: вот здесь LLM действительно приносит пользу

Вот здесь LLM начинает приносить реальную пользу. Не как генератор вдохновляющих абзацев, а как структурный парсер с structured output.

Задача этого слоя — превратить запрос в машиночитаемый объект с набором полей, пригодных для дальнейших решений в pipeline:

• основную сущность;
• тип сущности;
• атрибуты;
• модификаторы;
• географию;
• первичную гипотезу по интенту;
• предварительныйpage_type_candidate

Например, для запросакупить зимние шины r17 в москвесистема должна вернуть не размышление в духе “этот запрос, вероятно, относится к автомобильной тематике”, а структурированный объект, который можно валидировать, сохранять, пересчитывать и безопасно передавать на следующий этап.

На этом слое нужен не “умный текст”, а валидируемый structured output. Только такой результат можно сохранять, сравнивать, ревизовать и использовать в production.

Здесь особенно хорошо работает связка Python + retrieval + LLM. Python собирает объект запроса, подтягивает релевантные справочники, исторические кейсы, нишевые исключения и внутренние правила. LLM получает не голую строку, а уже обогащённый объект. В реальной системе это почти всегда выигрывает у “чистого” LLM-вызова, которому предлагают догадаться обо всём с нуля.

Отдельный слой — скоринг. И он полезен почти везде: в чистке, intent classification, clustering, page typing, URL matching и conflict resolution. Можно отдельно считать confidence по сущности, надёжность интента, вероятность объединения, качество сопоставления со старым URL и приоритет отправки в ручной review.

Проблема только в одном: хорошая скоринговая база под конкретную нишу не возникает по щелчку. Она собирается через исторические кейсы, ручную разметку, накопленные ошибки, обратную связь от редакторов и SEO-специалистов и живые данные конкретного рынка. То есть за красивой идеей scoring pipeline обычно стоит довольно прозаичная вещь — длинное накопление доменной базы признаков.

Этап 4. Классификация интента: слово “купить” — не единственный носитель смысла

Наивная версия SEO-анализа выглядит так: “ну тут же и так видно, коммерческий это запрос или нет”. Иногда видно. На живых данных довольно быстро выясняется, что нет, не всегда.

Поэтому intent classification полезно выделять в самостоятельный слой.

Обычно система определяет:

• commercial
• informational
• comparison
• navigational
• local
• transactional
• mixed / ambiguous

Это не усложнение ради красоты. Интент напрямую влияет наpage_type. Один и тот же корень может вести в категорию, гайд, страницу сравнения или вообще не требовать отдельного URL.

Здесь хорошо работает гибрид:

• словари и явные маркеры;
• rule-based логика;
• LLM-классификация на спорных кейсах;
• SERP-проверка на наиболее ценных кластерах.

И это хороший момент напомнить: если ваш “AI SEO tool” не умеет явно работать с интентом, есть неплохой шанс, что это просто перекрашенный генератор заголовков.

Этап 5. Кластеризация: конец магии, начало инженерии

Кластеризация — любимое место для SEO-оккультизма. Именно здесь обычно появляются фразы в духе “мы просто скормим всё векторным представлениям и посмотрим, что получится”. Обычно получается что-то вдохновляющее в интерфейсе и довольно бесполезное в архитектуре.

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

Поэтому рабочая кластеризация почти всегда гибридная:

• грубая группировка по сущности;
• уточнение по атрибутам;
• проверка интента;
• смысловая близость по векторам;
• LLM для спорных случаев объединения и разделения;
• ручная проверка наиболее ценных конфликтов.

На выходе должен появляться не “кластер похожих слов”, а осмысленная единица спроса и страницы: либо отдельный URL-кандидат, либо сознательно отвергнутый слой спроса.

И здесь скоринг снова оказывается полезен — не как серебряная пуля, а как второй слой принятия решений. Можно отдельно считать близость по сущности, совместимость по интенту, совпадение по атрибутам, конфликтность по гео, риск каннибализации и силу исторического совпадения с уже утверждёнными кластерами. Когда такие сигналы собраны аккуратно, кластеризация перестаёт быть шаманством “похожи слова или нет” и превращается в процедуру с понятными confidence coefficients.

Но есть нюанс: универсального scoring setup для всех ниш почти не существует. То, что отлично работает в шинах, может посредственно работать в медицине. То, что хорошо для e-commerce, может быть бесполезно для SaaS или вакансий. Поэтому любая по-настоящему сильная система оценок — это всегда доменная работа: разметка, переоценка, исправление ошибок, пересборка правил, проверка на живых кейсах. Именно поэтому хорошие нишевые pipeline редко рождаются быстро, зато потом работают заметно стабильнее любой модной автокластеризации “в один клик”.

Этап 6. Выбор типа страницы: самый недооцененный шаг во всей цепочке

После кластеризации система должна ответить на вопрос: что это за страница вообще?

В удивительно большом количестве SEO-процессов этот шаг формально существует, но нигде не зафиксирован как отдельное решение. Решение как будто принимается, но нигде не фиксируется и не формализуется. В итоге команда разработки получает ТЗ в стиле “сделайте ещё вот такую SEO-страницу, она вроде нужна”, и на этом уровень архитектурной точности обычно заканчивается.

Типовые варианты типа страницы:

• category
• subcategory
• filter_page
• brand_page
• geo_page
• comparison_page
• guide_page
• faq_page
• hub_page
• no_page_needed

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

Этап 7. H1 и Title: автоматизировать, но без SEO-лихорадки

Когда кластер и тип страницы уже определены, у системы появляется соблазн нажать на большую красную кнопкуGenerate SEO Title. И в этот момент часто рождаются конструкции в духе “Купить зимние шины R17 в Москве недорого цена”. Выглядит как привет из 2011-го, зато очень искренне.

Поэтому генерация заголовков должна быть управляемой. Нормальный pipeline не просит LLM “придумай красиво”. Он передаёт жёсткий входной объект и понятные ограничения:

• тип страницы;
• canonical label кластера;
• stylistic constraints;
• запрет на спам и повторения;
• формат вывода.

На выходе появляются:

• recommended_h1
• recommended_title
• slug_candidate
• meta_description_draft

Очень полезно также хранить происхождение решения: что было собрано правилами, а что уточнила модель. Иначе потом невозможно понять, почему в production внезапно появилось “Лучшие лучшие кроссовки для лучших бегунов”.

Этап 8. Сопоставление URL: жизнь начинается там, где кончаются идеальные схемы

Пока структура рисуется “с нуля”, всё выглядит красиво. Настоящая жизнь начинается в момент, когда новые кластеры нужно сматчить с существующим сайтом: со старой архитектурой, историческими slug-ами, кривыми категориями, забытыми фильтрами и каким-нибудь/catalog/new-final-2/.

Задача слояurl_matching:

• проверить существующие страницы;
• учесть синонимы и морфологию;
• сравнить атрибуты;
• поймать совпадения по брендам, фильтрам и гео;
• посчитатьmatch_confidence;
• выдать решение:reuse_existing_url/create_new_url/needs_review.

Вот здесь pipeline впервые начинает выглядеть как реальный продукт, а не как слайд с модными словами про “векторную близость”.

Этап 9. Поиск конфликтов: взрослость системы начинается здесь

Один из лучших признаков зрелой системы — наличие слоя, который ищет не только возможности, но и противоречия.

Поиск конфликтов нужен, чтобы ловить:

• два кластера на один URL;
• конфликтующееpage_type assignmentдля одного кластера;
• пересечение H1;
• конфликт slug-ов;
• каннибализацию parent/child-страниц;
• смешение geo и non-geo логики;
• смешение informational и commercial интентов.

То есть система не только предлагает, что стоит сделать, но и защищает проект от собственной же самоуверенности. По меркам индустрии это уже почти роскошь.

Этап 10. Генерация контент‑брифа: контент должен идти после архитектуры

Слишком часто контент-процесс запускают раньше, чем вообще становится понятна роль будущей страницы. В итоге тексты пишутся до того, как ясно, где они будут жить и какую функцию выполнять.

В нормальном pipeline бриф появляется только после того, как зафиксированы:

• тип страницы;
• интент;
• целевой кластер;
• обязательные сущности;
• родительская логика внутри структуры;
• существующий или новый URL.

Тогда бриф становится рабочим документом, а не сочинением на тему “напишите экспертно и с пользой”. В нём уже можно явно указать:

• цель страницы;
• обязательные блоки;
• ключевые вопросы пользователя;
• где нужен FAQ;
• где нужны коммерческие факторы;
• где полезна structured data;
• где не надо лить пять тысяч знаков текста просто потому, что кому-то так спокойнее.

Этап 11. Ручная проверка: да, человек все еще нужен

Сильный pipeline не обещает магической автономности. Он обещает сократить ручную рутину и отдать человеку только те кейсы, где его решение действительно стоит дороже автоматизации.

На ручную проверку обычно уходят:

• кластеры с низкимconfidence;
• подозрение наmerge / splitконфликт;
• спорныйpage_type;
• слабыйURL match;
• потенциальная каннибализация;
• слишком SEO-шные H1;
• критичные бизнес-страницы.

Это и есть нормальный human-in-the-loop контур. Человек не занимается бессмысленным ручным перекладыванием тысяч фраз. Он включается там, где цена ошибки реально высокая.

Где LLM действительно нужен, а где лучше не устраивать техно-спиритизм

Это главный антихайповый тезис всей статьи: LLM не должен заменять pipeline. Он должен быть встроенным модулем внутри pipeline принятия решений.

Где LLM особенно полезен:

• извлечение сущностей и атрибутов;
• классификация спорных интентов;
• предварительныйpage_type assignment;
• генерация канонического названия кластера;
• генерация H1 в заданных ограничениях;
• выявление конфликтов в сложных случаях;
• построение контентного брифа.

Где лучше сначала использовать правила:

• дедупликация;
• базовая чистка;
• выделение очевидных geo-модификаторов;
• первичный шум и стоп-слова;
• техническая нормализация;
• контроль ограничений по формату.

Если очень коротко, стратегия выглядит так:

1. сначала правила;
2. потом LLM там, где он действительно добавляет value;
3. потом человек там, где цена ошибки слишком высока.

Все остальные истории в стиле “мы полностью автоматизировали SEO через AI” обычно требуют одного дополнительного абзаца мелким шрифтом: “а потом три недели руками разгребали результат”.

Production prompts: шаблоны, которые не стыдно запускать массово

Ниже — не магические заклинания и не “секретная формула агентного SEO 2026”. Это production-шаблоны с жёстким structured output. Их задача не впечатлять креативностью модели, а давать результат, который можно валидировать, логировать, сравнивать и безопасно прогонять массово.

Эти промпты хороши не тем, что они “хитрые”, а тем, что они скучно надёжные.

Prompt 1. Entity extraction: сначала сущность, потом всё остальное

Системный промпт:

You analyze search queries for SEO architecture. Your task is to extract the main entity, entity type, attributes, modifiers, geo, and initial intent hypothesis. Return only valid JSON matching the required schema. If data is insufficient, do not guess. Use null or empty arrays. Do not output explanations outside JSON.

Пользовательский промпт:

Analyze query: “{query}”

Return strict JSON with fields:

• entity
• entity_type
• attributes
• modifiers
• geo
• intent_candidate
• page_type_candidate
• confidence

Prompt 2. Intent classification: слово “купить” — не единственный сигнал

System prompt:

You classify search queries by intent. Allowed values for primary_intent: commercial, informational, comparison, navigational, local, transactional, mixed. Return strict JSON only. If ambiguity is high, set secondary_intent and needs_manual_review=true. Do not explain outside JSON.

User prompt:

{ “query”: “{query}”, “normalized_query”: “{normalized_query}”, “entity”: “{entity}”, “attributes”: {attributes} }Expected output:{ “primary_intent”: “”, “secondary_intent”: “”, “reason_short”: “”, “needs_manual_review”: false, “confidence”: 0.0 }

Prompt 3. Page type assignment: не каждый кластер заслуживает отдельный URL

System prompt:

You determine the optimal page type for a search cluster. Choose only from: category, subcategory, filter-page, brand-page, geo-page, comparison-page, guide-page, faq-page, hub-page, no-page-needed. Consider intent, entity stability, attributes, and whether a separate page is actually justified. Return strict JSON only.

System prompt:

Cluster: “{cluster_label}” Main entity: “{entity}” Intent: “{intent}” Attributes: {attributes} Query count: {query_count} Total frequency: {total_frequency}Expected output:{ “page_type”: “”, “why_short”: “”, “should_create_new_page”: true, “needs_manual_review”: false, “confidence”: 0.0 }

Prompt 4. H1 generation: автоматизация без SEO-лихорадки

System prompt:

You generate H1 for an SEO page. H1 must be natural, short, readable, and non-spammy. Do not repeat keywords, do not list modifiers with commas, do not use bureaucratic phrasing. Keep alignment with cluster meaning and page type. Return strict JSON only.

User prompt:

Page type: “{page_type}” Cluster: “{cluster_label}” Main entity: “{entity}” Attributes: {attributes} Geo: “{geo}”Expected output:{ “h1”: “”, “short_title”: “”, “slug_candidate”: “”, “confidence”: 0.0 }

Prompt 5. Conflict detection: должны ли эти кластеры жить на одной странице

System prompt:

You check two SEO clusters for structural conflict. Decide whether they should map to the same page, different pages, or require manual review. Consider intent, entity, attributes, geo, and page type. Return strict JSON only.

User prompt:

Cluster A: {cluster_a} Cluster B: {cluster_b}Expected output:{ “decision”: “same-page|different-pages|manual-review”, “conflict_type”: “”, “reason_short”: “”, “confidence”: 0.0 }

Общий принцип у всех шаблонов один:

• жёсткий structured output;
• ограниченный словарь допустимых решений;
• confidenceтам, где нужен контроль;
• manual_reviewтам, где ошибка может оказаться дорогой.

Это не косметика. Это и есть разница между “чатик что-то ответил” и production-слоем, который можно встроить в pipeline.

Что лежит в демо-репозитории: не схема, а рабочий каркас

Чтобы статья не осталась набором правильных слов, к ней приложен демо-репозиторий: тот же pipeline, но уже не на диаграмме, а в коде, данных и интерфейсе.

В репозитории:

• модуль импорта сырых запросов;
• этап предобработки и нормализации;
• LLM-слой для смыслового разбора и классификации интента;
• кластеризация иpage_type assignment;
• модульurl_matching;
• модульconflict_detection;
• генератор контент-брифа;
• демо-админка для ручной проверки;
• демо-датасет;
• шаблоны промптов;
• схема сущностей и этапов пайплайна.

Репозиторий демо:https://github.com/staurus86/llm-pipeline-demo

Как это запустить локально и зачем вообще это делать

Мне важно, чтобы эту систему можно было не только прочитать, но и руками прогнать по шагам.

Базовый сценарий локального запуска такой:

1. Клонируете репозиторий.
2. Устанавливаете зависимости.
3. Прописываете ключ LLM-провайдера в.env.
4. Запускаете пайплайн на демо-датасете.
5. Открываете демо-админку и смотрите, как сырой список запросов превращается в кластеры, типы страниц, H1, URL-кандидаты и очередь ручной проверки.

Здесь логика важнее конкретного стека. Смысл не в том, чтобы показать ещё один фреймворк, а в том, чтобы руками пройти весь путь: от сырых запросов к нормализованным запросам, от них — к сущностям и интентам, дальше — к кластерам,page_types, структуре сайта, конфликтам и контент-брифам.

Это сильно лучше любой абстрактной диаграммы на шесть прямоугольников со стрелками и словом "AI" посередине.

Интерфейс как часть аргумента

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

В демо-админке будут такие разделы:

• обзорная панель;
• импорты иbatch-загрузки;
• сырые запросы;
• смысловой разбор;
• кластеры;
• структура сайта;
• сопоставление URL;
• студия промптов;
• очередь проверки;
• контент-брифы.

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

Почему это уже не SEO-хак, а продуктовый подход

Если посмотреть на эту систему со стороны, становится видно, что речь уже давно не про “оптимизацию текстов”. Мы обсуждаем систему преобразования спроса в продуктовые решения.

Хороший SEO-pipeline всё больше похож на внутреннюю поисковую операционную систему:

1. собирает данные;
2. приводит их к структурированному виду;
3. принимает решения поpage_types;
4. проверяет конфликты;
5. управляет приоритетами;
6. помогает разработке и контенту работать от одной картины мира.

Именно поэтому разговор о будущем SEO уже нельзя вести только в терминах текстов, ссылок и метатегов. На первый план выходят структура, сущности, архитектура, quality control и способность соединять классический поиск с AI-видимостью.

Что получается на выходе

Если pipeline собран нормально, команда получает не абстрактную “семантику”, а вполне конкретные рабочие сущности:

• карту интентов;
• кластеры;
• page_types;
• H1 и slug-кандидаты;
• матчи с существующими URL;
• backlog новых страниц;
• список конфликтов;
• контент-брифы;
• очередь ручной валидации.

И в этот момент семантика наконец перестаёт быть таблицей, которая живёт своей жизнью, а становится базой для реальной разработки сайта.

Вместо вывода: у поиска заканчивается терпение, и это только начало

В ближайшие годы проиграют не только те, кто вообще не использует AI. Проиграют и те, кто использует его как бездумный конвейер по производству цифрового пенопласта.

Поиск уже захлебывается в ровном, гладком, одинаково "нормальном" контенте, который ни о чем не говорит, ничего не доказывает и ничем не помогает. У таких страниц правильная структура, приличная грамматика, уверенный тон и почти полное отсутствие причин существовать. Это и есть главная катастрофа ближайших лет: интернет не умирает, он забивается ерундой с хорошим оформлением.

Поэтому главный вопрос больше не в том, умеете ли вы генерировать тексты. Это уже умеют почти все. Главный вопрос в другом: умеете ли вы строить систему, в которой каждая страница имеет право на жизнь.

Если нет — никакой LLM вас не спасёт. Он просто ускорит производство ошибок.

Если да — у вас появляется шанс не пополнить бесконечную серую массу страниц, которые поиск индексирует по инерции, а пользователь закрывает по привычке.

И это, пожалуй, самый неприятный вывод для рынка: будущее выигрывают не самые шумные и не самые “AI-native”. Его выигрывают самые дисциплинированные — те, кто готов разбираться в сущностях, интентах, скоринге, архитектуре, ручной валидации и всей той доменной грязной работе, без которой ничего устойчивого не строится.

Все остальное — это просто очень быстрый способ масштабировать мусор.