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-поиск игрушкой для любителей промптов, вот несколько вполне приземлённых цифр, после которых спорить становится чуть сложнее.
27 февраля 2026 OpenAI сообщила, что ChatGPT используют более 900 млн человек в неделю.. Источник: OpenAI
18 ноября 2025 Google заявила, что AI Overviews уже имеют 2 млрд пользователей в месяц.. Источник: Google Blog
В январе 2026 AP и Reuters пересказывали позицию британского CMA: после запуска AI Overviews новостные издатели столкнулись со снижением трафика, потому что пользователи реже кликают по первоисточникам. Источник: AP
Перевод на нормальный язык простой: это уже не футурология. Это изменение интерфейса поиска, модели клика и логики потребления ответа. И если у сайта до сих пор нет внятной логики сущностей, page types и архитектурных правил, то догонять придётся уже на бегу — в момент, когда интерфейс поиска начал отдавать ответ раньше, чем пользователь дошёл до вашей страницы.

Коротко: эпоха, в которой можно было выигрывать просто объёмом публикаций, быстро превращается из комфортной в убыточную. Когда сеть переполнена 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-контент в веб. Вопрос в том, сколько ещё одинаково прилизанных страниц нужно индексу и пользователю, чтобы структура, источник и полезность стали важнее самого факта публикации.

Под “захватом ниши” я не имею в виду миллион страниц и не имею в виду миллион собранных ключей. Эти метрики любят ровно до того момента, пока не приходится объяснять, почему половина URL не приносит ничего, кроме расходов, шума и головной боли.
Реальный захват ниши — это когда сайт системно покрывает значимые классы спроса и делает это архитектурно согласованно.
На практике это означает три вещи.
сайт закрывает максимум значимых интентов, включая те, которые будут извлекаться не только классическим поиском, но и AI-интерфейсами;
каждый интент маппится не в “какой-нибудь материал”, а в конкретный page type с понятной ролью в архитектуре;
система поддерживается как живой слой: обновляется, валидируется, масштабируется и не превращается в археологию из URL, которые когда-то делали “под SEO”.
Сегодня ниша существует сразу в трех плоскостях:
классический поиск;
архитектура самого сайта;
AI-поиск и LLM-интерфейсы, которые вытаскивают определения, сравнения, сущности и короткие ответы.
Поэтому быть “просто в индексе” уже недостаточно. Нужна такая структура и такое представление сущностей на сайте, чтобы ими было удобно пользоваться и поисковику, и человеку, и модели, которая решила внезапно пересказать половину вашего контента без спроса.

Одна из самых дорогих ошибок в SEO выглядит очень профессионально: открыть сервис, выгрузить десять тысяч запросов и с серьёзным видом назвать это стратегией. Но таблица запросов — это ещё не модель спроса. Это сырой вход, а не архитектурное решение.
В ней ещё не видно, какие сущности вообще составляют рынок, какие у них атрибуты, что влияет на выбор, где проходят границы между пользовательскими сценариями и почему одни группы запросов должны жить на одной странице, а другие — на разных слоях структуры.
Поэтому до сбора семантики нужен не ещё один сервис, а более взрослый этап: описать рынок как систему:
какие базовые сущности в нем есть;
какие есть подтипы;
какие атрибуты влияют на выбор;
какие сценарии коммерческие, какие исследовательские, а какие информационные;
где важна география;
где возникают бренды, сравнения и FAQ‑ветки.
Например, если ниша — беговые кроссовки, то рынок состоит не только из запроса “купить беговые кроссовки”. Внутри него есть поверхность бега, дистанция, уровень подготовки, амортизация, бренд, пол, сценарии выбора, сравнения моделей, локальный спрос и post-purchase вопросы. То есть будущий сайт — это уже не “категория плюс блог”, а многослойная система page types.
И именно здесь особенно хорошо видно, сколько SEO-проектов годами подменяли архитектурное решение фразой “ну мы потом допишем контент”.

Каждый интент должен вести к своему типу страницы: категория, сравнение, гайд или геостраница.
Как только появляется модель спроса, следующим шагом становится карта интентов. Это и есть слой преобразования рынка в архитектуру.
Если пользователь хочет купить — нужен коммерческий page type. Если сравнивает две сущности — страница сравнения. Если пытается понять различия, критерии выбора и сценарии применения — guide, FAQ или экспертный материал. Если спрос завязан на регионе — локальная ветка.
На этом этапе формируется базовый page-type layer:
категории;
подкатегории;
страницы фильтров;
брендовые страницы;
региональные страницы;
страницы сравнения;
FAQ;
гайды;
хабы и обзорные страницы.
Главная идея простая: структура сайта не должна рисоваться «по вдохновению». Она должна быть следствием карты интентов. Если в системе нет явного этапа, где спрос преобразуется в типы страниц, дальше почти неизбежно начинаются конфликтующие URL, каннибализация, дублирование и тот жанр архитектурного сюрреализма, который потом вежливо называют “исторически сложилось”.
Чтобы не оставаться на уровне абстракции, возьмем условную нишу беговых кроссовок.
Вот несколько запросов:
купить беговые кроссовки;
беговые кроссовки для асфальта;
лучшие беговые кроссовки для марафона;
сравнение nike pegasus и adidas boston;
как выбрать беговые кроссовки;
беговые кроссовки москва;
мужские беговые кроссовки;
беговые кроссовки с амортизацией.
Если смотреть на это как на “набор ключей”, рука сама тянется раскидать всё по нескольким текстам и назвать это контент-планом. Но если смотреть на это как на спрос, быстро становится видно, что перед нами разные типы страниц:
общая коммерческая категория;
фильтры по поверхности или амортизации;
гендерные подкатегории;
локальная страница;
страница сравнения;
гайд по выбору;
возможно, отдельная подборка под марафон.
То есть один рынок уже на старте требует не текстов, а архитектурных решений. А значит, нужен pipeline, который умеет принимать такие решения не интуитивно, а системно и воспроизводимо.
Когда карта интентов собрана, можно переходить к pipeline. Именно он превращает сырой спрос в структуру сайта, а не в очередную красивую таблицу, которую никто не откроет через месяц.
В моем варианте пайплайн выглядит так:
Intake — прием сырых данных
Preprocessing — нормализация и базовая чистка
Semantic parsing — извлечение сущностей, атрибутов и модификаторов
Intent classification — определение интента
Clustering — объединение запросов в кластеры
Page typing — выбор целевого page type
H1 / Title generation — создание человекочитаемых названий
URL matching — сопоставление с существующей архитектурой сайта
Conflict detection — поиск каннибализации и конфликтов
Content brief generation — подготовка брифа для контента
Human review — ручная проверка спорных кейсов
Сразу зафиксирую: это не “AI-pipeline”. Сегодня AI-pipeline называют всё, что не собирается вручную в Excel. Здесь речь не про магию моделей, а про pipeline принятия решений. На одних этапах работают правила, на других — embeddings и similarity logic, на третьих — LLM, а в конце всё равно нужен человек, который смотрит сложные кейсы и не даёт системе окончательно уверовать в собственную гениальность.

На вход система получает сырой материал из нескольких источников:
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.

Следующий слой — очистка. Это тот самый этап, который почти всегда недооценивают, потому что он выглядит не эффектно. Никаких векторных чудес, никакой “когнитивной оркестрации” — просто приведение данных в состояние, в котором с ними вообще можно принимать решения.
На этапе предобработки система:
приводит регистр к единому виду;
убирает мусорные символы;
нормализует пробелы;
выносит очевидные дубли;
выделяет гео‑модификаторы;
помечает нерелевантные и шумовые фразы;
формирует базовые токены.
Это как раз тот слой, где правила почти всегда полезнее, чем немедленный забег к 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” система уже умеет вычистить значимую долю мусора, разметить рискованные кейсы и построить очередь ручной валидации.

Вот здесь LLM начинает приносить реальную пользу. Не как генератор вдохновляющих абзацев, а как структурный парсер с structured output.
Задача этого слоя — превратить запрос в машиночитаемый объект с набором полей, пригодных для дальнейших решений в pipeline:
основную сущность;
тип сущности;
атрибуты;
модификаторы;
географию;
первичную гипотезу по интенту;
предварительный page_type_candidate
Например, для запроса купить зимние шины r17 в москве система должна вернуть не размышление в духе “этот запрос, вероятно, относится к автомобильной тематике”, а структурированный объект, который можно валидировать, сохранять, пересчитывать и безопасно передавать на следующий этап.
{
"entity": "зимние шины",
"entity_type": "product_category",
"attributes": ["r17"],
"modifiers": ["купить"],
"geo": "Москва",
"intent_candidate": "commercial",
"page_type_candidate": "category-filter-geo",
"confidence": 0.92
}На этом слое нужен не “умный текст”, а валидируемый structured output. Только такой результат можно сохранять, сравнивать, ревизовать и использовать в production.
Здесь особенно хорошо работает связка Python + retrieval + LLM. Python собирает объект запроса, подтягивает релевантные справочники, исторические кейсы, нишевые исключения и внутренние правила. LLM получает не голую строку, а уже обогащённый объект. В реальной системе это почти всегда выигрывает у “чистого” LLM-вызова, которому предлагают догадаться обо всём с нуля.
Отдельный слой — скоринг. И он полезен почти везде: в чистке, intent classification, clustering, page typing, URL matching и conflict resolution. Можно отдельно считать confidence по сущности, надёжность интента, вероятность объединения, качество сопоставления со старым URL и приоритет отправки в ручной review.
Проблема только в одном: хорошая скоринговая база под конкретную нишу не возникает по щелчку. Она собирается через исторические кейсы, ручную разметку, накопленные ошибки, обратную связь от редакторов и SEO-специалистов и живые данные конкретного рынка. То есть за красивой идеей scoring pipeline обычно стоит довольно прозаичная вещь — длинное накопление доменной базы признаков.
Наивная версия SEO-анализа выглядит так: “ну тут же и так видно, коммерческий это запрос или нет”. Иногда видно. На живых данных довольно быстро выясняется, что нет, не всегда.
Поэтому intent classification полезно выделять в самостоятельный слой.
Обычно система определяет:
commercial
informational
comparison
navigational
local
transactional
mixed / ambiguous
Это не усложнение ради красоты. Интент напрямую влияет на page_type. Один и тот же корень может вести в категорию, гайд, страницу сравнения или вообще не требовать отдельного URL.
Здесь хорошо работает гибрид:
словари и явные маркеры;
rule-based логика;
LLM-классификация на спорных кейсах;
SERP-проверка на наиболее ценных кластерах.
И это хороший момент напомнить: если ваш “AI SEO tool” не умеет явно работать с интентом, есть неплохой шанс, что это просто перекрашенный генератор заголовков.

Кластеризация — любимое место для SEO-оккультизма. Именно здесь обычно появляются фразы в духе “мы просто скормим всё векторным представлениям и посмотрим, что получится”. Обычно получается что-то вдохновляющее в интерфейсе и довольно бесполезное в архитектуре.
На деле кластеризация — это компромисс между смысловой близостью, интентом, бизнес-логикой и будущей архитектурой. Если объединять слишком грубо, коммерческие и информационные запросы начинают жить на одной странице. Если дробить слишком агрессивно, получается кладбище тонких и бессмысленных URL.
Поэтому рабочая кластеризация почти всегда гибридная:
грубая группировка по сущности;
уточнение по атрибутам;
проверка интента;
смысловая близость по векторам;
LLM для спорных случаев объединения и разделения;
ручная проверка наиболее ценных конфликтов.
На выходе должен появляться не “кластер похожих слов”, а осмысленная единица спроса и страницы: либо отдельный URL-кандидат, либо сознательно отвергнутый слой спроса.
И здесь скоринг снова оказывается полезен — не как серебряная пуля, а как второй слой принятия решений. Можно отдельно считать близость по сущности, совместимость по интенту, совпадение по атрибутам, конфликтность по гео, риск каннибализации и силу исторического совпадения с уже утверждёнными кластерами. Когда такие сигналы собраны аккуратно, кластеризация перестаёт быть шаманством “похожи слова или нет” и превращается в процедуру с понятными confidence coefficients.
Но есть нюанс: универсального scoring setup для всех ниш почти не существует. То, что отлично работает в шинах, может посредственно работать в медицине. То, что хорошо для e-commerce, может быть бесполезно для SaaS или вакансий. Поэтому любая по-настоящему сильная система оценок — это всегда доменная работа: разметка, переоценка, исправление ошибок, пересборка правил, проверка на живых кейсах. Именно поэтому хорошие нишевые pipeline редко рождаются быстро, зато потом работают заметно стабильнее любой модной автокластеризации “в один клик”.

После кластеризации система должна ответить на вопрос: что это за страница вообще?
В удивительно большом количестве SEO-процессов этот шаг формально существует, но нигде не зафиксирован как отдельное решение. Решение как будто принимается, но нигде не фиксируется и не формализуется. В итоге команда разработки получает ТЗ в стиле “сделайте ещё вот такую SEO-страницу, она вроде нужна”, и на этом уровень архитектурной точности обычно заканчивается.
Типовые варианты типа страницы:
category
subcategory
filter_page
brand_page
geo_page
comparison_page
guide_page
faq_page
hub_page
no_page_needed
Последний пункт особенно важен. Сильная система умеет не только создавать страницы, но и не создавать их. Это редкий навык в индустрии, где любое ключевое слово до сих пор иногда воспринимается как благословение на новый URL.
Когда кластер и тип страницы уже определены, у системы появляется соблазн нажать на большую красную кнопку Generate SEO Title. И в этот момент часто рождаются конструкции в духе “Купить зимние шины R17 в Москве недорого цена”. Выглядит как привет из 2011-го, зато очень искренне.
Поэтому генерация заголовков должна быть управляемой. Нормальный pipeline не просит LLM “придумай красиво”. Он передаёт жёсткий входной объект и понятные ограничения:
тип страницы;
canonical label кластера;
stylistic constraints;
запрет на спам и повторения;
формат вывода.
На выходе появляются:
recommended_h1
recommended_title
slug_candidate
meta_description_draft
Очень полезно также хранить происхождение решения: что было собрано правилами, а что уточнила модель. Иначе потом невозможно понять, почему в production внезапно появилось “Лучшие лучшие кроссовки для лучших бегунов”.

Пока структура рисуется “с нуля”, всё выглядит красиво. Настоящая жизнь начинается в момент, когда новые кластеры нужно сматчить с существующим сайтом: со старой архитектурой, историческими slug-ами, кривыми категориями, забытыми фильтрами и каким-нибудь /catalog/new-final-2/.
Задача слоя url_matching:
проверить существующие страницы;
учесть синонимы и морфологию;
сравнить атрибуты;
поймать совпадения по брендам, фильтрам и гео;
посчитать match_confidence;
выдать решение: reuse_existing_url / create_new_url / needs_review.
Вот здесь pipeline впервые начинает выглядеть как реальный продукт, а не как слайд с модными словами про “векторную близость”.
Один из лучших признаков зрелой системы — наличие слоя, который ищет не только возможности, но и противоречия.
Поиск конфликтов нужен, чтобы ловить:
два кластера на один URL;
конфликтующее page_type assignment для одного кластера;
пересечение H1;
конфликт slug-ов;
каннибализацию parent/child-страниц;
смешение geo и non-geo логики;
смешение informational и commercial интентов.
То есть система не только предлагает, что стоит сделать, но и защищает проект от собственной же самоуверенности. По меркам индустрии это уже почти роскошь.
Слишком часто контент-процесс запускают раньше, чем вообще становится понятна роль будущей страницы. В итоге тексты пишутся до того, как ясно, где они будут жить и какую функцию выполнять.
В нормальном pipeline бриф появляется только после того, как зафиксированы:
тип страницы;
интент;
целевой кластер;
обязательные сущности;
родительская логика внутри структуры;
существующий или новый URL.
Тогда бриф становится рабочим документом, а не сочинением на тему “напишите экспертно и с пользой”. В нём уже можно явно указать:
цель страницы;
обязательные блоки;
ключевые вопросы пользователя;
где нужен FAQ;
где нужны коммерческие факторы;
где полезна structured data;
где не надо лить пять тысяч знаков текста просто потому, что кому-то так спокойнее.

Сильный pipeline не обещает магической автономности. Он обещает сократить ручную рутину и отдать человеку только те кейсы, где его решение действительно стоит дороже автоматизации.
На ручную проверку обычно уходят:
кластеры с низким confidence;
подозрение на merge / split конфликт;
спорный page_type;
слабый URL match;
потенциальная каннибализация;
слишком SEO-шные H1;
критичные бизнес-страницы.
Это и есть нормальный human-in-the-loop контур. Человек не занимается бессмысленным ручным перекладыванием тысяч фраз. Он включается там, где цена ошибки реально высокая.

Это главный антихайповый тезис всей статьи: LLM не должен заменять pipeline. Он должен быть встроенным модулем внутри pipeline принятия решений.
Где LLM особенно полезен:
извлечение сущностей и атрибутов;
классификация спорных интентов;
предварительный page_type assignment;
генерация канонического названия кластера;
генерация H1 в заданных ограничениях;
выявление конфликтов в сложных случаях;
построение контентного брифа.
Где лучше сначала использовать правила:
дедупликация;
базовая чистка;
выделение очевидных geo-модификаторов;
первичный шум и стоп-слова;
техническая нормализация;
контроль ограничений по формату.
Если очень коротко, стратегия выглядит так:
сначала правила;
потом LLM там, где он действительно добавляет value;
потом человек там, где цена ошибки слишком высока.
Все остальные истории в стиле “мы полностью автоматизировали SEO через AI” обычно требуют одного дополнительного абзаца мелким шрифтом: “а потом три недели руками разгребали результат”.

Ниже — не магические заклинания и не “секретная формула агентного SEO 2026”. Это production-шаблоны с жёстким structured output. Их задача не впечатлять креативностью модели, а давать результат, который можно валидировать, логировать, сравнивать и безопасно прогонять массово.
Эти промпты хороши не тем, что они “хитрые”, а тем, что они скучно надёжные.
Системный промпт:
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
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 }
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 }
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 }
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
Мне важно, чтобы эту систему можно было не только прочитать, но и руками прогнать по шагам.
Базовый сценарий локального запуска такой:
Клонируете репозиторий.
Устанавливаете зависимости.
Прописываете ключ LLM-провайдера в .env.
Запускаете пайплайн на демо-датасете.
Открываете демо-админку и смотрите, как сырой список запросов превращается в кластеры, типы страниц, H1, URL-кандидаты и очередь ручной проверки.
Здесь логика важнее конкретного стека. Смысл не в том, чтобы показать ещё один фреймворк, а в том, чтобы руками пройти весь путь: от сырых запросов к нормализованным запросам, от них — к сущностям и интентам, дальше — к кластерам, page_types, структуре сайта, конфликтам и контент-брифам.
Это сильно лучше любой абстрактной диаграммы на шесть прямоугольников со стрелками и словом "AI" посередине.
Отдельно важно показать не только код, но и интерфейс. Потому что в SEO слишком много процессов до сих пор живут в виде пачки таблиц, понятных ровно одному человеку, который их однажды и собрал.

В демо-админке будут такие разделы:
обзорная панель;
импорты и batch-загрузки;
сырые запросы;
смысловой разбор;
кластеры;
структура сайта;
сопоставление URL;
студия промптов;
очередь проверки;
контент-брифы.
Это не попытка изобразить еще один AI SEO-сервис, которых и так уже достаточно, чтобы отдельным стеком отапливать небольшой коворкинг. Демо нужно как инженерное сопровождение статьи: чтобы читатель мог не только согласиться с идеей, но и руками пройти путь от сырых запросов до структуры страниц.
Если посмотреть на эту систему со стороны, становится видно, что речь уже давно не про “оптимизацию текстов”. Мы обсуждаем систему преобразования спроса в продуктовые решения.
Хороший SEO-pipeline всё больше похож на внутреннюю поисковую операционную систему:
собирает данные;
приводит их к структурированному виду;
принимает решения по page_types;
проверяет конфликты;
управляет приоритетами;
помогает разработке и контенту работать от одной картины мира.
Именно поэтому разговор о будущем SEO уже нельзя вести только в терминах текстов, ссылок и метатегов. На первый план выходят структура, сущности, архитектура, quality control и способность соединять классический поиск с AI-видимостью.
Если pipeline собран нормально, команда получает не абстрактную “семантику”, а вполне конкретные рабочие сущности:
карту интентов;
кластеры;
page_types;
H1 и slug-кандидаты;
матчи с существующими URL;
backlog новых страниц;
список конфликтов;
контент-брифы;
очередь ручной валидации.

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