Как спроектировать структуру сайта

Задача: найти страницу, не угадать метафору

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

Это не оргсхема департаментов. Не список «как у конкурента». Не кластеризация запросов. Поисковая структура — отдельный слой: какие URL отвечают на какие формулировки спроса. Его разбирают в статье как составить структуру сайта под SEO. Ниже — человеческая карта. Её делают раньше прототипа экранов; экраны без карты — набор картинок. Связка с прототипом: зачем нужен прототип сайта.

Собрать задачи, не разделы

Выпишите, зачем люди приходят. Не «ознакомиться с компанией» — это не задача. Задачи звучат так: понять, делаете ли вы X; сравнить X и Y; взять реквизиты; оставить заявку; найти адрес; прочитать условие возврата.

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

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

Иерархия: ширина и глубина

Дерево разделов можно сделать широким (много пунктов на одном уровне) или глубоким (три–четыре клика вниз). Оба края ломаются.

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

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

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

Язык этикеток

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

Одинаковые слова на разных уровнях («услуги» внутри «услуги») сбивают. Синонимы в двух пунктах на одну задачу плодят дубль пути: человек не знает, какой правильный.

Один путь, несколько входов

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

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

Как проверять структуру до дизайна

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

Для большого дерева иногда делают оглавление как текстовую схему, не как макет. Макет слишком рано спорит о фото. Схема спорит о смысле.

Схема, которую можно показать за 10 минут

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

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

Типичные поломки

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

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

Связь с другими слоями, без подмены

Когда карта задач стабильна, её можно сопоставить со спросом: какие узлы станут посадочными под формулировки, какие останутся служебными. Это уже SEO-структура, другой текст. Когда карта стабильна, на неё вешают прототип: порядок блоков на шаблоне услуги. Это уже не IA, а проектирование экрана.

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

Мини-чек перед утверждением

• У каждой важной задачи есть одна главная страница.
• Этикетки понятны без посвящения во внутренний сленг.
• Нет пустых пунктов.
• Контакты и заявка достижимы с типовых страниц.
• Новую услугу можно добавить без перестройки всей шапки.

Если пункт не выполняется, чинить надо дерево, не цвет иконки.