Структура корпоративного сайта: карта разделов, навигация и проверка

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

Структура корпоративного сайта: какую задачу она решает

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

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

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

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

Карта разделов как рабочий документ

Карта разделов — основной артефакт этапа. Минимальный состав карты: разделы верхнего уровня, подразделы, типовые страницы, назначение элементов, ответственные за наполнение и статус (нужен сейчас, отложен, не нужен).

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

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

Ещё одна колонка, которая экономит время, — пример адреса. Она не обязательна на старте, но если её заполнить, сразу становятся видны неудобные случаи: слишком длинные адреса, повторы, разделы с одинаковыми названиями.

Верхний уровень: что вообще должно быть на сайте

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

Типовой набор для корпоративного сайта выглядит так:

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

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

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

Услуги и информационные материалы: где граница

Частая задача — определить, нужна ли услуге отдельная страница или достаточно блока внутри существующей. Критериев несколько.

Отдельная страница оправдана, если у услуги свой сценарий: свои вопросы, свой состав работ, свой ответственный и своя логика обсуждения. Если же это вариант внутри одного направления — например, разные комплектации одной и той же работы, — логичнее оставить блок на странице направления.

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

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

Логическая и физическая структура

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

Логическая структура

Логическая структура — это дерево разделов и страниц, которое видит посетитель. Она строится на заголовках разделов: именно заголовок задаёт место раздела в дереве и участвует в построении цепочки навигации. Название страницы при этом формируется отдельно, из её собственного заголовка.

Отсюда практический вывод: заголовки разделов — не косметика. Если раздел назван невнятно, невнятной будет и цепочка навигации, и меню, и карта сайта.

Физическая структура

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

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

Наследование свойств раздела

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

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

Перенос страницы

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

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

Навигация: меню, хлебные крошки, карта сайта

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

Меню

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

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

Хлебные крошки

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

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

Карта сайта

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

Практический смысл карты в том, что она служит ещё и проверкой: если раздел не попал в карту, значит, он не попал и в меню, из которого карта строится.

Таблица решений: куда отнести новый материал

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

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

Проверка навигации по сценариям

Структуру проверяют не по дереву, а по сценариям. Дерево может выглядеть логично и при этом не работать, если посетитель идёт другим путём.

Базовый набор сценариев:

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

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

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

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

Учебный пример: карта разделов для условной компании

Учебный пример. Данные условные и не описывают реальную компанию.

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

Шаг первый — верхний уровень. Получается: «О компании», «Направления», «Отрасли», «Проекты», «Материалы», «Документы», «Контакты». Восемь пунктов — на границе разумного, поэтому «Документы» решено убрать внутрь «О компании», а «Отрасли» оставить, потому что отраслевые страницы будут наполняться.

Шаг второй — подразделы. Внутри «Направлений» — три подраздела по числу направлений. Внутри «Отраслей» — два подраздела. Внутри «Материалов» — рубрики «Инструкции» и «Разборы». Внутри «Проектов» — список без дополнительной вложенности.

Шаг третий — распределение материалов по таблице решений. Описания услуг уходят в подразделы направлений. Черновики статей — в рубрики материалов. Документы — в список внутри «О компании». Фотографии объектов — в проекты, с пометкой, по каким объектам есть согласие на публикацию.

Шаг четвёртый — ответственные. За «Направления» отвечает инженер, за «Материалы» — маркетолог, за «Проекты» — менеджер, за «Документы» — руководитель. Это важно зафиксировать в карте: раздел без ответственного быстро превращается в свалку.

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

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

Как принять работу: чек-лист

• Карта разделов существует в одной актуальной версии и согласована с заказчиком
• У каждого раздела указано назначение и ответственный
• Верхний уровень не перегружен и пункты не дублируют друг друга
• Адреса читаемые и не меняются без причины
• Пункты меню добавлены после проверки адресов разделов
• Хлебные крошки отражают реальный путь по разделам
• Карта сайта собирает все разделы, которые должны быть видны
• Пройдены сценарии посетителя и сценарий контент-менеджера
• Проверено поведение при переносе страницы: новый адрес и ссылки на неё
• Удаление раздела выполняется только после проверки ссылок и при наличии свежей резервной копии
• Права на создание и удаление разделов распределены между ролями
• Все изменения сначала проверены на копии, а не на рабочем сайте

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

Типичные ошибки и ограничения

Ошибка первая — пункт меню раньше раздела. Ссылка появляется в навигации, а страницы ещё нет; посетитель попадает на ошибку.

Ошибка вторая — слишком глубокое дерево. Чем больше уровней, тем сложнее найти нужное и тем чаще материалы кладут не туда. Обычно достаточно двух–трёх уровней; более глубокая вложенность требует обоснования.

Ошибка третья — дублирующиеся разделы. Например, «Услуги» и «Направления» с одинаковым содержимым. Посетитель не понимает разницы, а контент-менеджер не знает, куда добавлять новое.

Ошибка четвёртая — переименование адресов без решения о перенаправлении. Старые ссылки начинают вести на ошибку, и это обнаруживается не сразу.

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

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по структуре, нужен не «сайт целиком», а конкретный набор данных:

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

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