Поисковое проектирование
Нужно спроектировать будущую архитектуру до дизайна и разработки или перестроить существующую систему URL.
Услуга / веб-бюро Дениса Богданова
Поисковое проектирование сайта: SEO + GEO
Проектируем поисковую архитектуру до дизайна и разработки: семантика, интенты, SERP, структура разделов, URL, перелинковка, шаблоны и требования к контенту.
Проектируем поисковую архитектуру до дизайна и масштабной разработки: определяем спрос, интенты, роли URL, типы страниц, связи и требования к реализации, чтобы SEO не пришлось встраивать в готовый сайт задним числом.
01 / роль услуги
Зачем это бизнесу и какое место занимает на сайте
Поисковое проектирование — это этап между исследованием спроса и производством сайта. Его задача — превратить бизнес-модель, семантику и фактическую выдачу в карту страниц, где у каждого URL есть самостоятельная роль и понятная причина существования.
Это не просто «собрать семантическое ядро». Большой список запросов без решений по интентам, шаблонам, URL и перелинковке не защищает от каннибализации, лишних страниц и дорогой перестройки после запуска.
02 / выбор формата
Чем этот вариант отличается от соседних решений
Клиенту важно понимать не только что мы делаем, но и почему ему нужен именно этот формат, а не более простой или более сложный.
SEO-продвижение
Архитектура в целом уже существует, а задача — регулярно развивать видимость, страницы, контент и техническую базу.
Аудит и стратегия
Сначала нужно понять, в чём проблема текущего сайта и оправдана ли вообще перестройка архитектуры.
Создание сайта
Нужен не только проект архитектуры, но и полный цикл от исследования до готового работающего продукта.
03 / применимость
Когда услуга нужна — и когда лучше выбрать другой путь
Не предлагаем услугу по умолчанию. Сначала проверяем, соответствует ли она реальной задаче и текущему состоянию проекта.
Подходит, если
- Новый сайт должен получать органический трафик и масштабироваться после запуска.
- У бизнеса много услуг, категорий, продуктов, отраслей или информационных тем.
- Существующая структура выросла хаотично и страницы начали конкурировать друг с другом.
- Нужно заранее определить, какие URL являются коммерческими, информационными, навигационными и служебными.
- Дизайн или разработка ещё не начались, и архитектурные решения можно принять без дорогой переделки.
Не стоит начинать с этого, если
- Нужна одна простая рекламная посадочная без планов на поисковое масштабирование.
- Задача локальная: исправить конкретную техническую ошибку или небольшой блок существующей страницы.
- Бизнес пока не определил продукты и аудитории настолько, чтобы проектировать устойчивую структуру.
- Нужен только разовый список ключевых слов без дальнейших решений по сайту — это не формат поискового проектирования.
04 / состав работ
Что именно делаем внутри проекта
Состав не собирается из абстрактного прайса. Каждый блок включается потому, что решает конкретную часть задачи.
Исследование бизнеса
Фиксируем направления, продукты, аудитории, географию, ограничения и роль органического поиска в модели привлечения.
Карта спроса
Собираем и очищаем релевантные запросы, отделяем коммерческий спрос от информационного и определяем приоритетные темы.
Проверка интентов
Сравниваем фактическую выдачу и типы ранжирующихся страниц, чтобы не объединять разные задачи только из-за похожих слов.
URL ownership
Для каждого значимого кластера определяем страницу-владельца и фиксируем, какие темы нельзя размножать между соседними URL.
Шаблоны и сущности
Определяем типы страниц, обязательные поля, связи, масштабируемые шаблоны и правила появления новых документов.
Перелинковка и требования
Проектируем тематические связи и формулируем требования к метаданным, индексации, structured data, контенту и реализации.
05 / процесс
Как проходит работа от первого разбора до результата
Этапы уменьшают риск дорогих переделок: сначала принимаем решения, затем оформляем и реализуем их.
01. Контекст
Разбираем бизнес, текущий или будущий продукт, ограничения и цели поиска.
02. Спрос
Собираем семантику, чистим нерелевантное, группируем по задачам и интентам.
03. SERP-проверка
Проверяем спорные границы по фактической выдаче и конкурентным типам страниц.
04. Архитектура
Формируем дерево сущностей, URL, роли страниц, шаблоны и правила масштабирования.
05. Связи
Проектируем навигацию, хлебные крошки, контекстную перелинковку и связи коммерческого с экспертным контуром.
06. Передача в реализацию
Фиксируем требования к дизайну, разработке, CMS и контенту и проверяем, что они однозначно читаются командой.
06 / результат
Что получает клиент, кроме «работы выполнены»
Результат описываем через конкретные артефакты и рабочие части системы, а не через обещания позиций или абстрактный «рост».
Карта спроса
Очищенные кластеры с разделением коммерческих, информационных и вспомогательных интентов.
Карта URL
Список будущих или переработанных страниц с назначением, приоритетом и владельцем поисковой темы.
Модель шаблонов
Типы страниц и требования к полям, блокам, сущностям и масштабированию.
Правила антиканнибализации
Зафиксированные границы между соседними страницами и условия, при которых темы объединяются или разделяются.
Перелинковочная модель
Логика переходов между услугами, решениями, материалами и уровнями структуры.
Требования к реализации
Технические и контентные условия для CMS, метаданных, индексации, schema и контроля после запуска.
07 / связанные контуры
SEO, аналитика, интеграции и развитие — где они входят в задачу
Эти части не добавляются декоративно. Показываем их роль только там, где они действительно влияют на результат.
SEO
Проектирование создаёт фундамент: регулярное SEO затем развивает уже определённую систему страниц, а не пытается исправить архитектуру по ходу.
GEO и AI-поиск
Закладываем ясные сущности, авторство, прямые ответы и доступный текстовый контент. Не создаём отдельный искусственный «AI-слой», оторванный от сайта.
CMS и разработка
Архитектура переводится в требования к моделям данных, шаблонам и правилам генерации URL, чтобы решения были воспроизводимы технически.
Контент
Контентные задания формируются после определения роли страницы: сначала зачем URL существует, затем что на нём должно быть.
08 / оценка проекта
От чего зависят сроки и бюджет
Не ставим искусственную универсальную цену там, где объём определяется архитектурой, контентом и интеграциями. Сначала фиксируем состав — затем считаем.
Факторы оценки
Размер и сложность спроса
Количество направлений, семантических кластеров и спорных интентов определяет глубину исследования.
Тип проекта
Сайт услуг, B2B, производство, e-commerce и мультирегиональная структура требуют разной модели сущностей и шаблонов.
Текущее состояние
Проектирование с нуля проще инвентаризации большого действующего сайта, где нужно учитывать накопленные URL, трафик и ограничения.
Глубина передачи
Можно ограничиться архитектурой либо дополнить её прототипами, контентными требованиями и сопровождением разработки.
Что нужно от клиента
- Описание продуктов, услуг, аудиторий и приоритетов бизнеса.
- Текущий сайт и доступные данные поиска/аналитики, если проект уже работает.
- Планы расширения по продуктам, регионам и языкам, если они уже известны.
- Ограничения CMS, разработки, сроков запуска и внутренних процессов, которые нельзя игнорировать при проектировании.
09 / границы и риски
Где такие проекты чаще всего теряют смысл и деньги
Заранее проговариваем типовые ошибки и ограничения, чтобы клиент понимал не только преимущества, но и условия хорошего результата.
Страница под каждый ключ
Механическое размножение URL создаёт дубли, тонкий контент и конкуренцию собственных страниц.
Меню вместо архитектуры
Навигационное дерево не заменяет решения по интентам, шаблонам, индексируемости и отношениям между сущностями.
SEO после дизайна
Когда ключевые типы страниц и сценарии уже зафиксированы макетами, исправление архитектуры становится дороже и конфликтует с готовым интерфейсом.
Семантика без бизнеса
Частотность не знает маржинальность, ограничения компании и реальную продуктовую модель — поэтому данные спроса нельзя использовать без бизнес-контекста.
После основного этапа
Что происходит дальше
- Проверяем, что реализованные URL, canonical, robots, sitemap, навигация и перелинковка соответствуют проекту.
- Сопоставляем фактические показы и запросы с назначенными страницами-владельцами.
- Новые кластеры добавляем по данным, не разрушая границы уже работающих страниц.
- При изменении бизнеса обновляем архитектурные правила, а не только отдельные тексты.
пример результата
Не обещание, а материал, который можно открыть
Статус примера указан прямо: собственный проект, демо или гипотетический сценарий не выдаётся за клиентский кейс.
10 / альтернативы
Если эта услуга не подходит — куда смотреть
Страница должна помогать выбрать правильный путь, а не удерживать клиента внутри одного продукта.
Аудит и стратегия
Если сначала нужно понять, есть ли архитектурная проблема и какие изменения вообще оправданы.
Перейти к аудиту ↗SEO-продвижение
Если основная архитектура уже работает и требуется системное развитие видимости.
Перейти к SEO ↗Создание сайтов
Если архитектуру нужно не только спроектировать, но и реализовать в готовом продукте.
Перейти к созданию сайта ↗11 / связанные решения
Где эта услуга работает как часть более крупной задачи
Не обязательно собирать проект из отдельных услуг самостоятельно. Решения объединяют их вокруг бизнес-ситуации.
01
Новый сайт как система роста
Когда бизнесу нужен не просто новый дизайн, а сайт, в котором заранее связаны спрос, структура, SEO, GEO, контент, аналитика и дальнейшее развитие.
03SEO как система роста, а не список работ
Когда нужно расширять органическую видимость через архитектуру, релевантные посадочные, техническую базу, контент и регулярное развитие — в одной логике.
05B2B-сайт для сложной продажи
Когда решение выбирают долго, в покупке участвуют несколько ролей, а сайт должен одновременно объяснить продукт, снять технические вопросы и дать основание доверять компании.
12 / вопросы до старта
Ответы на вопросы, которые обычно влияют на решение
Если вашего вопроса здесь нет, его лучше вынести в разбор до оценки проекта, а не выяснять после старта.
Это то же самое, что семантическое ядро?
Нет. Семантика — исходные данные. Поисковое проектирование принимает решения: какие страницы нужны, какие запросы принадлежат каждой странице, как устроены URL, шаблоны и связи и как всё это должно быть реализовано.
Нужно ли делать страницу под каждый запрос?
Нет. Страница создаётся под самостоятельную задачу, сущность или устойчиво отдельный интент, а не под каждую словоформу.
Можно выполнить проектирование отдельно от разработки?
Да. Результат можно передать внутренней команде или другому подрядчику, если документация и границы ответственности за реализацию заранее определены.
Что делать, если разные инструменты кластеризации дают разные группы?
Автоматическая кластеризация — сигнал, а не окончательное решение. Спорные границы проверяются по смыслу, продуктовой модели и фактической выдаче.
Нужно ли проектировать журнал до запуска?
Если информационный спрос важен для стратегии — да, хотя публиковать весь объём сразу не обязательно. Полезно заранее определить рубрики, типы материалов и связи с коммерческими страницами.
Помогает ли такая архитектура AI-поиску?
Она создаёт ясную структуру сущностей и полезный текстовый контент, что является хорошей базой и для генеративных поисковых функций. Отдельной специальной разметки, гарантирующей AI-видимость, не существует.
Следующий шаг
Сначала понять задачу. Потом выбирать состав работ.
Опишите бизнес-контекст, текущий сайт и то, что хотите изменить. На первичном разборе определим, подходит ли эта услуга, нужна ли другая или разумнее начать с более узкого шага.
Разобрать сайт / задачу