Индустрия за 15 лет натренировала SEO‑специалистов собирать ключевые слова: ядро как документ с тысячами строк в Excel превратилось в ритуал. Хотя при правильном подходе семантика становится незаменимым инструментом проектирования.

Продакшн‑директор агентства performance‑маркетинга KINETICA Артём Первухин разбирает, почему это проблема и как выстроить семантику, которая работает, в том числе для ИИ‑поиска.

Два правила семантической архитектуры

Типичная ситуация: клиент приходит с задачей на SEO‑продвижение. Запрашиваем семантическое ядро и получаем файл Excel на 30 000 строк, отфильтрованный по частотности, с колонками «кластер» и «посадочная». Это называют «готовой семантикой». Далее начинается работа с контентом — тексты, оптимизация, ссылки.

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

Собрать ядро ≠ собрать структуру

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

Кластеризатор скажет: «Эти 47 запросов идут на одну страницу». Но он не понимает, нужна ли вообще эта страница, не дублирует ли она другую, ведёт ли пользователя к следующему шагу воронки или в тупик. Это решает человек. И желательно, чтобы он принял решение прежде чем разработчики начнут верстать шаблоны.

Кластеризация запросов и проектирование структуры сайта — не одно и то же.

Хорошая семантическая архитектура — это граф, где каждый узел (тип страницы) связан с другими через осмысленные переходы, а не случайные ссылки из списка. Инструменты просто группируют запросы по признаку совпадения в ТОПе. Специалист знает, какие группы станут узлами, полезными для бизнеса. И строит граф до того, как написана первая строка контента.

Где логика встречается с опытом пользователя

Семантическое и контентное проектирование — не последовательные этапы, а две стороны одной системы

Определить тип интента ≠ определить формат контента

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

Разберём на конкретном примере — ниша «промышленное оборудование»:

Верхний тип	Микроинтент	Пример запроса	Тип страницы
Информационный	Диагностика проблемы	«почему греется редуктор»	Гайд с диагностикой
Информационный	Сравнение вариантов решения	«редуктор vs вариатор что лучше»	Сравнительная статья
Коммерческий	Оценка вендоров	«производители редукторов рейтинг»	Категорийная + обзорная
Коммерческий	Расчёт стоимости	«редуктор 5 кВт цена»	Карточка / фильтр каталога
Транзакционный	Прямая покупка	«купить редуктор НМШ Екатеринбург»	Посадочная с формой / CTA
Транзакционный	Сервис / обслуживание	«ремонт редуктора цена»	Сервисная страница

Каждый микроинтент требует свои формат, структуру блоков и CTA. Гайд по диагностике не должен заканчиваться кнопкой «Купить» — это разрыв пользовательского сценария. Он должен вести к сравнительной статье или к категорийной странице. А карточка товара не обязана объяснять, чем отличается редуктор от вариатора — она должна закрывать конкретный транзакционный шаг.

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

Архитектура до контента: как строить иерархию страниц

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

Уровень 1 — Тематические домены. Это главные смысловые блоки сайта, которые соответствуют крупным темам из семантики. Для интернет‑магазина промышленного оборудования это могут быть «Редукторы», «Приводы», «Насосное оборудование», «Запчасти и сервис». Каждый домен получит свою Pillar‑страницу.

Уровень 2 — Типы страниц внутри домена. Каждый домен содержит несколько типов страниц, которые закрывают разные микроинтенты. Это категорийные страницы, фильтры каталога, страницы сравнений, сервисные страницы, гайды, кейсы.

Уровень 3 — Отдельные единицы контента. Карточки товаров, статьи блога, лендинги под конкретные задачи.

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

Как архитектура исключает фантомные страницы и каннибализацию

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

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

2. Каннибализация — несколько страниц конкурируют за один и тот же запросный кластер. Поисковик не может выбрать победителя, обе страницы проседают. Это лечится переработкой структуры — дорого и долго. Если выявить на этапе проектирования, достаточно объединить или перераспределить кластеры.

Что такое каннибализация ключевых слов в SEO и как её избежать

Способ диагностики на этапе проектирования

Для каждой предполагаемой страницы задайте два вопроса:

Какой конкретный интент эта страница закрывает?
Есть ли другая страница в структуре с перекрывающимся интентом?

Если на первый вопрос нет ответа — страница не должна существовать вообще. Если на второй ответ «да» — нужно решить конфликт на уровне структуры, а не контента.

Pillar‑Cluster: механика, которую используют неправильно

Модель Pillar‑Cluster стала популярной как способ построения тематического авторитета. Идея правильная:

есть «столп» — развёрнутая страница на широкую тему;
и есть «кластер» — страницы, глубоко раскрывающие частные аспекты этой темы.

Все они связаны взаимными ссылками.

Что такое тематический авторитет: подробный гайд

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

Как это должно работать на самом деле:

Pillar‑страница даёт ответ на широкий запрос («редукторы для промышленности») и явно обозначает подтемы, которые раскрываются на кластерных страницах. Это не просто ссылки, а навигация по теме.
Кластерная страница закрывает конкретный узкий интент («планетарный редуктор для конвейера») и даёт обратную ссылку на Pillar. Причём не просто в виде кнопки «Назад», а с переходом к следующему смысловому уровню («Хочешь сравнить с другими типами — вот обзор»).
Горизонтальные связи внутри кластера — недооценённый инструмент. Страницы одного кластера должны ссылаться друг на друга там, где это логично с точки зрения пользовательского сценария («сравнение типов» ссылается на «характеристики конкретного типа», «гайд по выбору» ссылается на «расчёт мощности»).

Есть ещё один нюанс, который часто упускают. Анкоры ссылок должны совпадать с семантическими паттернами запросов, которые закрывает целевая страница. «Подробнее» или «Читать далее» — нейтральные анкоры, которые не несут семантической ценности. «Характеристики планетарного редуктора» — практичный и полезный анкор.

Схема перелинковки по модели Pillar‑Cluster

Контентное проектирование: от интента к блокам страницы

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

Рабочая схема для каждой страницы:

Интент + микроинтент — что ищет пользователь, что он хочет понять или сделать.
Контекст прихода — откуда пользователь вероятнее попадёт на страницу: из поиска по конкретному запросу, с Pillar‑страницы, рекламы или email. .
Блок‑схема страницы — последовательность смысловых блоков: ответ на интент → детализация → снятие возражений → следующий шаг.
Следующий шаг — куда пользователь должен пойти с этой страницы. Это определяет CTA и внутренние ссылки.

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

Как спроектировать сайт, который читается AI‑поиском

С появлением AI Overviews в Google и нейроответов в Яндексе семантическая архитектура приобрела ещё одно измерение. AI‑модели при формировании ответа ищут источники, которые воспринимаются как тематически авторитетные — они системно закрывают тему через связанные страницы, а не через отдельные тексты.

Доверие в ИИ‑выдаче: почему люди доверяют нейросетям и кому доверяют сами нейросети

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

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

Используйте Schema.org разметку для явного обозначения отношений между сущностями. Продукт связан с категорией, категория связана с брендом, бренд связан с регионом — всё это должно быть в разметке.
Формулируйте заголовки как прямые ответы на вопросы, а не как ключевые фразы. AI‑модели извлекают ответы на конкретные вопросы — заголовок H2 «Почему редуктор перегревается» цитируют чаще, чем «Причины перегрева».
Добавляйте структурированные определения сущностей — короткий абзац в начале страницы, который сразу поясняет, о чём речь. Это не SEO‑текст, а сигнал для модели, что страница является надёжным источником по теме.
Наращивайте ссылочный авторитет на тему через внешние упоминания, а не только через внутренние ссылки — AI учитывает, как на сайт ссылаются другие тематические ресурсы.

Off‑page SEO: принцип работы и самые эффективные стратегии

Обычный RAG находит похожие фрагменты. Графовый — анализирует связи между сущностями

Рабочий пайплайн с инструментами

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

Этап 1 — Сбор и нормализация семантики

Выгружаем конкурентов, объединяем массивы, чистим от брендовых и нерелевантных запросов. На этом этапе хорошо работает автоматизация через n8n — пайплайн берёт файл, прогоняет через LLM для первичной нормализации и выдаёт очищенный массив. Это убирает 60–70% рутины.

Скриншот пайплайна обработки семантики в n8n

Этап 2 — Кластеризация и выявление интентов

Кластеризуем — например, через Топвизор — с учётом топа поиска. Параллельно классифицируем каждый кластер по микроинтенту вручную или с помощью LLM‑ассистента. Ни один кластеризатор не определит за вас, какие кластеры конфликтуют по интенту — это человеческая работа.

Этап 3 — Проектирование таксономии

Строим иерархию в XMind или Miro. Каждый узел — это тип страницы с описанием интента, который он закрывает, и ссылками на родительский и дочерние узлы. На этом этапе выявляем фантомные страницы и конфликты каннибализации. Результат — документ‑таксономия, который является источником истины для всех команд: разработка, контент, дизайн.

Этап 4 — Генерация ЧПУ и шаблонов метатегов

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

Этап 5 — Контентное проектирование страниц

Для каждого типа страниц описываем блок‑схему: набор блоков, их порядок, CTA и переходы. Для приоритетных страниц — детальное ТЗ с указанием объёма, структуры заголовков, обязательных сущностей для Schema‑разметки.

Чек‑лист приёмки семантической структуры

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

Для каждой страницы в структуре описан конкретный микроинтент — не «информационная», а «диагностика проблемы X» или «сравнение вариантов Y».
Нет страниц без определённого интента («страница о компании» — не интент, это тип страницы; интент — «получить подтверждение надёжности поставщика перед первым заказом»).
Проверена каннибализация: нет двух страниц с перекрывающимися кластерами запросов.
Каждая страница имеет явно обозначенный «следующий шаг» — куда ведёт пользователя после прочтения.
Pillar‑страницы содержат навигацию по кластерным подтемам, кластерные страницы имеют обратные ссылки на Pillar с осмысленным анкором.
Внутри кластеров описаны горизонтальные связи — где и на что ссылаться внутри группы страниц.
Шаблоны URL зафиксированы для каждого типа страниц, включая фильтры и пагинацию.
Для ключевых типов страниц определены сущности для Schema.org разметки.
Структура согласована с разработкой — нет конфликтов с техническими ограничениями CMS.

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

Что запомнить

Семантическая архитектура — фундаментальное проектное решение, которое определяет, насколько эффективным будет сайт через 6–12 месяцев после запуска.

Три вещи, которые важно усвоить:

Кластеризация запросов и проектирование структуры — разные задачи. Первое — аналитика, второе — архитектура. Путать их — значит строить сайт без плана.
Интент нужно детализировать до микроуровня — это определяет тип страницы, её блоки и CTA. «Коммерческий запрос» — слишком грубо для проектирования.
Фантомные страницы и каннибализацию дешевле выявить до запуска, чем лечить через год.

Ещё по теме 👇

От семантики до хлебных крошек: строим SEO‑структуру сайта в высококонкурентной нише

Семантика в ИИ‑поиске: от ключевых слов к сценариям

Как оптимизировать контент, чтобы попадать в ИИ‑обзоры