Меню придумали, страницы нарисовали, а посетитель всё равно не понимает, где искать нужную услугу. Такое затруднение стоит разбирать с карты задач и переходов. Мы в «Гуси-Лебеди» предлагаем сначала определить, какую информацию человек должен найти, и только затем выбирать названия разделов. Разберём, как составить структуру сайта, связать её с поисковым спросом и проверить после запуска.
Дальше используем учебный пример поставщика промышленного оборудования. Это модель для объяснения решений, а не описание нашего клиентского проекта.
Что такое структура сайта и какие у неё уровни
Структура сайта описывает состав страниц, их иерархию и связи. Она помогает ответить на вопросы: где находится нужная информация и как до неё добраться. Меню показывает часть этой системы, а карта разделов помогает обсуждать её целиком.
Информационная архитектура отвечает на вопрос, какие сущности есть на сайте: услуги, товары, отрасли, инструкции, проекты. Навигация определяет способы доступа к ним: меню, каталог, поиск, фильтр, связанные материалы. URL задают адреса. Структура отдельной страницы организует её содержание: заголовок, условия, характеристики, доказательства и действие.
Эти уровни связаны, но не обязаны повторять друг друга буквально. Один товар может быть доступен из нескольких подборок и иметь один основной адрес. Изменение положения раздела в меню не всегда требует смены URL. Схема блоков лендинга не заменяет карту страниц многостраничного сайта.
Для проекта полезны два документа: дерево разделов для обсуждения логики и реестр страниц для разработки. Красивое дерево без идентификаторов, адресов, статусов и ответственных быстро расходится с реальным сайтом.
| Модель | Где полезна | Что проверить |
|---|---|---|
| Иерархия: раздел → подраздел → объект | Каталог товаров или библиотека документов | Понятны ли названия и границы категорий |
| Последовательность шагов | Оформление заявки, подбор решения, обучение | Возврат назад, сохранение данных, необязательные этапы |
| Сеть контекстных связей | База знаний, статьи, связанные решения | Есть ли понятная точка входа и следующий шаг |
| Фасетная навигация | Подбор по нескольким независимым характеристикам | Комбинации фильтров, пустые результаты, правила индексации |
Мы предлагаем сочетать модели под задачи проекта. У поставщика оборудования каталог иерархический, подбор по параметрам фасетный, оформление запроса последовательное, а инструкции связаны между собой. Не нужно искусственно делать весь сайт линейным или запрещать полезные перекрёстные ссылки ради чистоты схемы.
Как составить структуру по задачам и запросам
Соберите исходные данные: фактический ассортимент и услуги, обращения клиентов, поиск по сайту, поисковые запросы, данные аналитики и Вебмастера. Для действующего проекта добавьте выгрузку URL из CMS, Sitemap, обхода и аналитики. Эти источники дополняют друг друга: краулер не найдёт страницу без ссылок, а CMS может содержать неопубликованные записи.
Для проектирования сайта-каталога структура должна опираться на способ выбора: категории, свойства, совместимость и доступность. Меню не обязано повторять внутреннюю классификацию учётной системы.
У каждой потребности зафиксируйте задачу пользователя, предполагаемый тип ответа и подтверждение. Например, «купить винтовой компрессор» предполагает выбор предложения; запрос «как рассчитать производительность» требует объяснения метода; запрос «обслуживание компрессора» требует условий сервиса. Общая тема не делает эти запросы одной страницей.
Измеренный спрос храните вместе с регионом, периодом и способом подсчёта. Широкая частотность темы не равна количеству будущих посетителей конкретной страницы. Подробный сбор и группировка разобраны в материале про семантическое ядро.
Здесь мы задаём три вопроса: отличается ли задача пользователя, есть ли самостоятельное предложение или содержательный ответ и можно ли поддерживать страницу актуальной. Если различается только порядок слов, две страницы, вероятно, не нужны. Если различаются условия работы, объект и критерии выбора, разделение может быть оправдано.
Сравнение выдачи помогает уточнить гипотезу: какие типы страниц показываются по запросам, совпадают ли документы, что пользователь ожидает увидеть. Но совпадение нескольких доменов не является автоматическим решением. У одного сайта разные страницы могут отвечать на разные намерения, а смешанная выдача требует ручной оценки.
| Учебная потребность | Решение | Обоснование |
|---|---|---|
| Выбрать винтовой компрессор | Категория каталога | Список моделей, параметры выбора и условия покупки |
| Посмотреть конкретную модель | Карточка товара | Характеристики, комплектация и доступные действия |
| Узнать доставку по Москве | Общий раздел условий и краткий блок в карточке | Если правила одинаковы, не требуется копия для каждой модели |
| Заказать сервис | Страница услуги | Другой результат, состав работ и процесс обращения |
| Рассчитать потребление воздуха | Руководство или инструмент | Информационная задача перед подбором оборудования |
Региональные страницы требуют той же проверки. Если компания работает в Москве и области, это не обосновывает десятки одинаковых страниц с заменой названия города. Отдельный документ должен объяснять реальные местные условия, доступность услуги или другой полезный для клиента контекст.
Пример структуры каталога: разделы, фильтры и связи
Предположим, учебный поставщик продаёт компрессоры, обслуживает их и помогает с подбором. Верхний уровень включает «Оборудование», «Сервис», «Подбор», «Проекты», «База знаний» и сведения о компании. Названия отражают задачи клиента, а не внутренние отделы вроде «Коммерческая дирекция».
В каталоге основное деление строится по типу оборудования. Производительность, давление и питание становятся характеристиками фильтра. Не каждую характеристику нужно превращать в новый уровень дерева: иначе один товар окажется в десятках пересекающихся веток.
Карточка содержит ссылку на совместимую услугу обслуживания и инструкцию по выбору. Статья о расчёте помогает перейти к подходящей категории или запросу подбора. Страница сервиса объясняет ограничения: какое оборудование обслуживается и какие данные нужны для обращения. Связи возникают из следующей задачи пользователя.
Заранее определите владельцев информации. За характеристики отвечает тот, кто проверяет данные оборудования; за условия сервиса отвечает ответственная команда; за редакционное руководство отвечают автор и проверяющий. Если у страницы нет источника данных и владельца, расширение структуры увеличит объём устаревающей информации.
Пусть в учебном каталоге есть 5 вариантов мощности, 4 диапазона давления и 6 типов комплектации. Уже простое сочетание по одному значению из каждой группы даёт 5 × 4 × 6 = 120 комбинаций. Множественный выбор, сортировки и служебные параметры могут увеличить число адресов ещё сильнее. Это иллюстрация комбинаторики, а не число страниц реального проекта.
Разделите удобные состояния интерфейса и самостоятельные посадочные страницы. Для индексируемой подборки нужны осмысленный спрос, стабильный состав предложения, полезное содержание и постоянный адрес. Случайная комбинация с одним временно доступным товаром не обязательно заслуживает отдельной страницы в поиске.
Техническая политика должна описывать пустые результаты, сортировки, пагинацию, повторяющиеся комбинации и канонические адреса. Не назначайте всем страницам фильтра canonical на родительскую категорию без проверки эквивалентности. Не сочетайте механически запрет обхода с ожиданием, что робот прочитает директиву внутри закрытой страницы.
Решения фиксируют по типам URL и проверяют на примерах. Для каждой группы нужны ожидаемый HTTP-ответ, возможность обхода, метаданные, canonical, присутствие в Sitemap и внутренние ссылки. Детали директив разобраны отдельно в статье про robots.txt.
Как проверить меню и навигацию
В рекомендациях W3C по дополнительной навигации разобраны хлебные крошки, карта страниц и поиск. Они дают разные способы добраться до материала. Выбирайте их под объём и задачи сайта, затем проверяйте работу с клавиатурой и на телефоне.
Самостоятельное выполнение задачи поможет проверить тестирование удобства сайта. Мы предлагаем наблюдать реальный выбор раздела, не подсказывая его название заранее.
Меню не должно содержать все страницы сайта. Оно показывает основные точки входа, а локальная навигация помогает внутри раздела. Названия вроде «Решения» и «Продукты» могут быть понятны команде и неоднозначны клиенту. Проверяйте их на задачах, а не голосованием сотрудников.
Если продукт представляет собой базу знаний или документацию, обсудите разработку технического сайта с версиями материалов и понятной навигацией. Для публичных объясняющих материалов создание информационного сайта требует отдельно продумать рубрики, авторство и обновление устаревших страниц.
В тесте дерева структуры человеку дают задание без подсказки названия раздела: «Найдите, какие данные нужны для заказа обслуживания». Затем наблюдают первый выбор, возвраты и конечный ответ. Записывайте не только успешность, но и причину ошибки: непонятный термин, пересечение категорий, отсутствующий документ.
Правило «всё за три клика» не является универсальным критерием качества. Несколько понятных шагов могут быть удобнее перегруженного меню. При этом важные страницы не стоит прятать за длинной цепочкой малозначимых переходов. Измеряйте глубину доступа и успешность задач отдельно.
Хлебные крошки обычно показывают положение документа в иерархии, а не историю посещённых страниц браузера. У товара с несколькими входами нужна согласованная логика основного раздела. Обычная ссылка должна оставаться доступной и на мобильном экране, и при навигации клавиатурой.
Что передать разработчику и как менять действующий сайт
Для каждой страницы задайте постоянный внутренний ID, тип шаблона, основной URL, родительский раздел, пользовательскую задачу, необходимые блоки, источник данных, входящие переходы и критерий готовности. ID полезен при переименовании: название меняется, а связь с задачами и миграцией сохраняется.
ID: CAT-01
Тип: категория оборудования
URL: /catalog/vintovye-kompressory/
Задача: выбрать модель по рабочим условиям
Входы: каталог, подбор, тематическая статья
Блоки: список, параметры, условия, помощь в выборе
Проверка: доступны модели и понятен следующий шагЭто учебная запись. В реальном проекте добавьте техническую политику URL и статус контента. Отдельно отмечайте «спроектировано», «есть материал», «реализовано» и «проверено на публичном сайте»: это разные состояния.
Сначала сопоставьте старые URL с новыми сущностями. Если страница остаётся той же по назначению, рассмотрите сохранение адреса. Если документы объединяются, определите релевантный итоговый URL и необходимые фрагменты содержания. Массовый редирект всех удалённых страниц на главную не восстанавливает прежний пользовательский ответ.
Проверьте внутренние ссылки, canonical, хлебные крошки, Sitemap, формы, аналитику и внешние рекламные назначения. При переносе категории карточка не должна случайно получить новый адрес во всех ветках. Процесс изменения адресов подробно разобран в руководстве по миграции сайта.
Как проверить структуру после запуска
Сопоставьте реестр с публичным обходом: есть ли все запланированные страницы, нет ли лишних дублей, доступны ли важные документы по обычным ссылкам. Яндекс отдельно рекомендует понятную ссылочную структуру и навигацию; ориентиром служат официальные рекомендации по структуре сайта.
Проведите ручные сценарии с главной, из поиска и по прямому адресу. Проверьте пустой фильтр, возврат назад, мобильное меню и переход от статьи к услуге. XML-карта помогает обнаружению URL, но не заменяет навигацию для человека и не гарантирует включение страницы в поиск.
После запуска наблюдайте отдельные группы страниц: обход и индексацию, поисковые запросы, переходы между разделами, завершение целевых действий. Рост или падение трафика нельзя автоматически приписать одной структуре: одновременно могут меняться сезонность, контент, ассортимент и реклама. Для нас в Гуси-Лебеди результат проектирования состоит в понятной карте задач, поддерживаемых страницах и проверенных переходах между ними.