коммерческого спроса обеспечено целевой страницей
Семантика и архитектура сайта
Исследуем, как аудитория формулирует задачи, объединяем запросы по намерению и выдаче и принимаем решение для каждой группы: создать страницу, усилить существующую, объединить или не публиковать. На выходе — карта URL, типов страниц, шаблонов и приоритетов.
Стоимость: от 100 000 ₽Для предварительной оценки нужны тип бизнеса, ассортимент или услуги, география, текущий сайт либо описание будущего продукта.- Не таблица ключей, а решения по страницам и шаблонам.
- Отдельно фиксируем объединения, исключения и риски пересечения.
- Результат понятен маркетингу, редакции, дизайну и разработке.
Результаты наших клиентов
Результаты проектирования архитектуры
пересечение страниц по намерению
потенциальные дубли
новых посадочных страниц создано
С какими объемами работаем
Охват проекта
- до 500 000 исходных запросов
- до 3 500 кластеров
- 790 решений по страницам
Глубина и рабочий ритм
- 24 типа страниц
- 56 регионов
- 20 рабочих дней
Другие результаты
- 62 — слабые страницы объединены
- 166 — нецелесообразных страниц исключено из разработки
Когда проектировать семантику и структуру
Архитектура нужна, когда бизнесу предстоит принять решения о страницах, навигации и масштабировании. Если структура уже реализована и задача — найти технические ошибки, правильнее начать с аудита.
Новый сайт
Меню, типы страниц и шаблоны можно связать со спросом до начала разработки.
SEO для нового сайтаРастущий каталог
Категории, фильтры и посадочные создаются без единых правил и начинают пересекаться.
Новые регионы или сегменты
Нужно отделить самостоятельную ценность от механических копий страниц.
Редизайн
Существующие URL нужно сопоставить с новой моделью до миграции.
SEO-сопровождение миграцииПересечение страниц
Несколько документов конкурируют за одну задачу или один URL перегружен разными намерениями.
Разрозненный контент
Материалы выходят по темам, но не поддерживают коммерческие узлы и путь пользователя.
Почему списка запросов недостаточно
Семантическое ядро отвечает на вопрос «как формулируют спрос». Архитектура определяет, какой документ нужен, где он находится, какие данные и шаблон его поддерживают и как не создать дубли.
Список запросов
Показывает формулировки, но без бизнес-контекста содержит шум и не определяет приоритет.
Кластеры
Объединяют близкий спрос, но без проверки намерения не доказывают необходимость отдельной страницы.
Решения по страницам
Фиксируют, что создать, усилить, объединить, исследовать или не публиковать — и почему.
Правила шаблонов
Объясняют, какие данные и состояния нужны для безопасного масштабирования.
Архитектура
Связывает спрос, сущности бизнеса, тип документа, URL, навигацию и критерии готовности.
Что изучаем до сбора запросов
Поисковый спрос — только один слой. Сначала фиксируем реальные продукты, задачи клиентов, географию, ограничения поставки и бизнес-приоритеты. Иначе карта будет оптимизирована под слова, которые компания не может обслужить.
Продукты и связи
Номенклатура, услуги, характеристики, бренды и отношения между сущностями.
Экономика и ограничения
Приоритеты, маржинальность и ограничения предложения — если бизнес готов раскрыть данные.
Роли и сценарии
Кто выбирает, сравнивает, согласует и покупает продукт.
География
Филиалы, доставка, локальные условия и реальная зона обслуживания.
Факты действующего сайта
URL, меню, аналитика, внутренний поиск, система продаж и вопросы отдела продаж.
Возможности реализации
CMS, модель данных, ресурсы редакции и разработки, план изменений.
Как формируем и очищаем карту спроса
Сбор начинается с маркерных групп по продуктам, задачам, характеристикам, аудиториям и регионам. Источники комбинируем, потому что ни один сервис не представляет весь спрос. Для каждой группы сохраняем дату, регион, источник и ограничения.
Поисковые подсказки
Связанные формулировки, вопросы и уточнения пользователей.
Инструменты спроса
Яндекс Вордстат и Планировщик ключевых слов Google — при доступе и с учетом назначения данных.
Данные сайта
Google Search Console, Яндекс Вебмастер, аналитика и внутренний поиск.
Конкурентное поле
Страницы прямых конкурентов используем как источник сущностей и форматов, а не для копирования.
Язык клиентов
Вопросы продаж, поддержки, тендеров, спецификации и продуктовая терминология.
Очистка
Исключаем навигационные, нерелевантные, чужие и невозможные для бизнеса формулировки, сохраняя причину.
Как объединяем запросы
Запросы объединяем не только по похожим словам. Сравниваем задачу пользователя, тип результата и сходство документов в выдаче. Коммерческие, информационные и навигационные намерения могут требовать разных страниц даже при общей теме.
- 01
Смысл и объект
Что именно человек выбирает или какую задачу решает.
- 02
Стадия выбора
Узнать, сравнить, рассчитать, заказать, внедрить или исправить.
- 03
Формат результата
Категория, карточка, услуга, статья, инструмент или локальная страница.
- 04
Сходство выдачи
Какие документы появляются по представительным запросам в нужном регионе.
- 05
Геозависимость
Есть ли отдельный локальный спрос и реальная локальная ценность.
- 06
Неопределенность
Спорные группы помечаем для повторной проверки, а не распределяем принудительно.
Создать, объединить, усилить или не публиковать
Каждая группа получает решение и объяснение. Частотность сама по себе не является основанием для новой страницы: нужны самостоятельная задача, подходящий формат и отличимое предложение бизнеса.
Есть самостоятельная задача, полезный формат, отличимое предложение и место в навигации.
URL, тип и место в навигацииПодходящая страница уже есть, но не закрывает задачу, условия или доказательства.
пробелы содержания и приоритетВыдача и путь пользователя показывают один документ, а отдельные страницы будут конкурировать.
целевой URL и перенос ценностиНет самостоятельной ценности, продукта или условий — получится тонкая копия.
причина исключенияДанных недостаточно или результаты нестабильны; фиксируем гипотезу и условие проверки.
гипотеза и условие проверкиПокажем, где сайту нужна отдельная страница, а где — объединение
Бесплатно разберем исходную структуру, оценим масштаб и предложим состав проекта без продажи количества ключевых слов.
Как спрос превращается в типы документов
Архитектура описывает не только список URL, но и повторяемые типы страниц. Для каждого типа определяем задачу, обязательные данные, навигацию, правила индексирования и состояния.
Категория
Ассортимент, фильтры и правила пустых состояний.
Карточка
Характеристики, наличие, варианты, документы и связи.
Услуга или решение
Аудитория, проблемы, состав, процесс, доказательства и действие.
Отрасль или регион
Отдельный URL только при самостоятельном спросе и содержании.
Сравнение или инструкция
Информационная задача и маршрут к коммерческому действию.
Фильтровая страница
Условия генерации, индексирование, каноническая ссылка, содержание и лимиты.
Как пользователь и робот находят нужную страницу
Короткий URL сам по себе не решает задачу. Важнее понятная иерархия, контекстные ссылки, устойчивые правила и управляемые фильтры.
Узловые страницы
Объединяют самостоятельные дочерние задачи и дают обзор, а не повторяют их тексты.
Конечные страницы
Закрывают конкретную задачу и связываются с родителем и смежными решениями.
Меню
Отражает главные сценарии, но не обязано содержать каждую поисковую страницу.
Хлебные крошки и ссылки
Показывают реальную иерархию и продолжают путь пользователя по смыслу.
Стабильные URL
Изменение существующих адресов оценивается как миграционный риск.
Поиск и фильтры
Дополняют навигацию, но не создают бесконтрольную индексируемую поверхность.
Как работаем с дублями намерения
Новую архитектуру не накладываем поверх старой. Сопоставляем текущие URL, их спрос, ссылки, трафик, конверсии и роль — затем решаем, что сохранить, усилить, объединить, перенаправить или удалить.
Сначала исследуем
Одинаковый кластер у нескольких URL — сигнал для проверки, а не команда удалить страницу.
Разводим разные задачи
Предложением, структурой и внутренними ссылками, а не только заголовком страницы.
Объединяем с сохранением ценности
Выбираем целевой URL, переносим полезное содержание и ссылки, настраиваем перенаправление.
Не маскируем дубли
Каноническая ссылка не заменяет продуктового решения, если навигация продолжает вести на повторные страницы.
Фиксируем решение
Для каждого URL сохраняем аргумент, ответственного и зависимость от разработки или контента.
Что получает команда
Передаем результат в согласованном формате, который можно связать с планом задач и CMS. Карта получает версию, дату и правила обновления, чтобы решения не устарели сразу после передачи.
Корпус спроса
Очищенные формулировки с источниками, регионами, датами и статусами.
Кластерная карта
Намерение, тип документа, основной и дополнительный спрос, комментарий к решению.
Реестр страниц
Текущий и целевой URL, действие, родитель, шаблон, приоритет и ответственный.
Карта архитектуры
Иерархия, хлебные крошки, навигационные связи и внутренние маршруты.
Правила шаблонов
Обязательные поля, фильтры, метаданные, пустые состояния и индексирование.
Реестр исключений
Что не создавать или объединить, где есть риск пересечения страниц.
Передача в реализацию
Презентация решений, открытые вопросы и задания для дизайна, разработки и редакции.
Как проходит проект и от чего зависит цена
Работа идет итерациями: от модели бизнеса и корпуса спроса — к решениям по страницам, архитектуре и правилам. Спорные узлы выносим на рабочую сессию, финальную версию проверяем на бизнес-реализуемость.
- 01
Погружение
Фиксируем модель бизнеса, продукты, аудитории, географию, ограничения и критерии решения.
- 02
Маркеры
Собираем исходные группы по сущностям, задачам, характеристикам и регионам.
- 03
Корпус спроса
Объединяем источники, очищаем шум и сохраняем происхождение данных.
- 04
Кластеры
Определяем намерение, формат ответа и сходство документов в выдаче.
- 05
Решения
Защищаем спорные группы и фиксируем действие для страницы с аргументом.
- 06
Архитектура
Проектируем типы документов, иерархию, URL, навигацию и правила шаблонов.
- 07
Проверка и передача
Сверяем реализуемость с бизнесом и командой, передаем версии и приоритеты.
Точный объем определяем после оценки структуры и доступных данных.
- Число продуктовых сущностей, языков и регионов.
- Масштаб существующих URL и сложность каталога.
- Глубина правил для шаблонов и фильтров.
- Доступность данных и число итераций согласования.
- Состав участия команды в реализации.
Кто проектирует и где подход уже применялся
Сергей Торкунов первым проверяет бизнес-модель и ключевые архитектурные решения. Стратег, технический SEO-специалист и аналитик отвечают за карту спроса, реализуемость и приоритеты.

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

Анна Морозова
Руководитель SEO-стратегииСвязывает поисковый спрос, экономику продукта и план внедрений. Отвечает за стратегию и достижимость прогноза.

Илья Воронцов
Технический SEO-специалистДиагностирует системные ограничения сайта, готовит требования и принимает технические внедрения.

Екатерина Белова
Веб-аналитикНастраивает измерение канала от запроса до квалифицированного лида и оплаченной сделки.
Трансферы по Крыму: управляемая структура вместо всех комбинаций
Для нового проекта команда отобрала коммерчески значимые страницы из большого числа возможных направлений и спроектировала масштабируемые шаблоны.
Посмотреть кейс

Как построить SEO-стратегию и оценить результат
Разбираем связь семантики, архитектуры, приоритетов и бизнес-метрик в единой системе.
Прочитать материалОтветы на вопросы о семантике и архитектуре
Что я получу кроме списка запросов?
Кластерную карту, решения по страницам, целевую иерархию и URL, правила шаблонов и индексирования, приоритеты и комплект для передачи в реализацию. Точный состав фиксируем в предложении.
Сколько запросов войдет?
Количество не является самостоятельной мерой качества. Объем зависит от продуктов, сущностей, регионов и глубины спроса; важнее покрытие бизнес-задач и обоснованные решения.
Обязательно ли создавать страницу под каждый кластер?
Нет. Кластер может усилить существующую страницу, объединиться с другим или получить решение «не публиковать».
Можно работать с существующим сайтом?
Да. Сопоставим текущие URL с целевой моделью и отдельно отметим сохранение, усиление, объединение и миграционные действия.
Входят ли заголовки и описания страниц?
Их можно подготовить для приоритетных страниц или как правила шаблона — после решения по URL и согласования состава услуги.
Как часто обновлять семантику?
По событию: при изменении ассортимента, рынка, географии, выдачи или данных сайта. Универсальная календарная норма без контекста не нужна.
Нужны ли отдельные страницы Москвы и Санкт-Петербурга?
Только при самостоятельном локальном спросе и реальной ценности: условиях, филиале, ассортименте, ценах, кейсах или других отличиях. Простой замены города недостаточно.
Кто реализует структуру?
Обычно команда клиента. Мы можем продолжить контроль в рамках SEO-сопровождения разработки; внедрение в CMS согласуется отдельно.

