Структура сайта для целей компании и сценариев аудитории

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

После редизайна меню часто выглядит аккуратно, но менеджер всё ещё не понимает, с какой страницы пришла заявка, редактор не знает, куда поставить новый материал, а посетитель ищет нужную модель через внутреннее название отдела. Единого дерева для всех компаний нет. Есть структура, в которой цели компании поддержаны маршрутами разных аудиторий: потенциальных покупателей, действующих клиентов, партнёров, кандидатов или специалистов. Её связь с пользовательскими сценариями раскрывает UX/UI-дизайн.

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

Симптомы обычно видны раньше, чем их называют информационной архитектурой. Один и тот же товар лежит в трёх категориях без понятной причины. Услуги называют внутренними сокращениями, которые клиент не ищет. Статьи пишутся, но не ведут к соответствующей услуге. Менеджер получает заявку и не понимает, с какой страницы пришёл человек. Редактор боится создать новую страницу, потому что неясно, куда её поставить.

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

Сначала назовите цель: продать, объяснить, собрать обращение, дать сервисную информацию, поддержать репутацию или разгрузить команду. Затем разложите её по сценариям аудиторий. Потенциальный покупатель ищет совместимость детали, сроки поставки или стоимость внедрения; действующий клиент — инструкцию, статус заказа или поддержку; партнёр — документы и условия работы. Соберите реальные формулировки из заявок, звонков, поиска по сайту, переписки и продаж. Они показывают, что должно быть доступно без знания внутренней оргструктуры.

Опишите, чем бизнес действительно управляет: товаром, моделью, услугой, специалистом, объектом, филиалом, кейсом, документом, событием. Для каждой сущности определите обязательные свойства, источник данных и владельца. Если карточка товара создаётся вручную из текста, а характеристики хранятся в другом месте, структура быстро перестаёт быть правдой.

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

Дерево должен уметь поддерживать не только дизайнер. Кто добавляет новую услугу? Где появится документ? Кто решает, что кейс устарел? Как страницы связаны с ценами и CRM? Если у раздела нет владельца, он постепенно наполнится случайными блоками или перестанет обновляться. Это особенно заметно, когда команда не собрала контент до проектирования.

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

Отдельная страница обычно оправдана, если у неё есть самостоятельный предмет, условия, доказательства и действие. Блок подходит, когда человек не ищет тему отдельно и содержание не требует собственной навигации. Фильтр полезен для сочетаний свойств в большом каталоге, но не должен заменять понятную категорию и карточку.

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

В главное меню выносите не каждую страницу, а самые частые и стратегические маршруты. Остальное раскрывается через раздел, контекстные связи и поиск. Хлебные крошки помогают человеку понять место страницы в иерархии; поисковые системы тоже используют связи между навигационными страницами и контентом, чтобы лучше понимать относительную важность и структуру.

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

Хорошее дерево не делает сайт мелким; оно даёт каждому важному объекту понятное место и следующий шаг.

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

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

Перед разработкой проверьте дубли: не существует ли две страницы, которые отвечают на один вопрос разным текстом; не спорят ли фильтры с категориями; не потерялась ли критичная информация в PDF или подвале. Отдельно определите место для оферты на сайте и материалов о доставке, оплате и возврате. Затем закрепите правила добавления: кто может создать раздел, какие поля обязательны и кто отвечает за связи.

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

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

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

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

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

Для каждой сущности зафиксируйте идентификатор, обязательные поля, связь с другими сущностями и источник данных. Тогда становится видно, почему «у нас просто карточка» не работает: на самом деле карточка должна связывать характеристики, варианты, документы, наличие и применение.

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

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

Фасетная навигация полезна в каталоге, но быстро создаёт тысячи комбинаций. До запуска определите, какие свойства действительно нужны для выбора, какие комбинации получают отдельную страницу, какие закрыты от индексации и кто отвечает за корректность значений. Здесь нет универсальной настройки: она зависит от ассортимента, спроса и технической реализации. Важно, чтобы фильтр помогал выбрать, а не создавал пустые или повторяющиеся страницы.

Первая — сценарная. Человек без знания внутренней терминологии должен найти нужное и объяснить, почему выбрал этот путь. Вторая — контентная: редактор пытается добавить новую сущность по правилам и видит, где не хватает шаблона или владельца. Третья — поисковая: специалист проверяет, есть ли понятный URL, навигационные связи и риск дублей для важных групп страниц.

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

На выходе должен быть не только mind map. Запросите таблицу страниц и сущностей, схему навигации, список шаблонов, правила URL, модель фильтров, владельцев контента и список старых адресов с решением по каждому. Попросите показать пять ключевых задач на схеме, а затем повторить их на прототипе. Это даёт основание оценивать архитектуру до визуального дизайна и разработки.

Производитель оборудования часто начинает с внутренней структуры: «отдел насосов», «отдел автоматики», «комплектующие». Покупатель же приходит с задачей: подобрать систему для объекта, понять совместимость и получить документ для закупки. В рабочем дереве могут сосуществовать продуктовые категории, решения по применению, карточки моделей, документы и подбор. Они не конкурируют, если у каждой страницы своя задача: категория — сравнить класс товаров, карточка — проверить конкретную модель, решение — понять применение, документ — подтвердить параметры.

Такой пример показывает, почему одна папка «каталог» не отвечает на все вопросы. Но он не означает, что каждому бизнесу нужны все типы разделов. Например, сервис обслуживания кондиционеров может вести человека от услуги к зоне выезда, цене и записи — без карточек моделей и технических документов. Объём дерева следует из предмета и пути клиента.

Семантика полезна, когда помогает увидеть не названный спрос и подобрать слова, которыми пользуются клиенты. Она становится вредной, когда каждая вариация запроса превращается в отдельный URL без новой ценности. До создания страницы спросите: отличается ли задача, отличается ли ответ, есть ли уникальные данные, будет ли у страницы самостоятельный вход и владелец.

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

Хороший результат можно передать разработке и редакции: карта сущностей, список шаблонов, таблица URL, правила именования, границы фильтров, обязательные связи и владельцы. Если итогом остаётся только красивая схема без этих решений, она не помогает ни оценить смету, ни наполнить сайт, ни проверить релиз.

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

Структура работает, когда новый объект можно добавить по правилу, а не после спора о том, в какое меню его спрятать.