Информационная архитектура сайта: структура, карточная сортировка и tree testing

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

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

Ниже — рабочий процесс целиком: что входит в информационную архитектуру, на каких принципах она держится, как провести инвентаризацию контента, карточную сортировку и tree testing, как превратить результат в меню и метки, что это даёт SEO и ИИ-поиску. В конце — пример, таблица ошибок и чек-лист.

Что такое информационная архитектура сайта?

Информационная архитектура (information architecture, IA) — это то, как содержимое сайта организовано, сгруппировано и названо, чтобы человек мог найти нужное и понять, где находится. Она отвечает на три вопроса пользователя: где я, что здесь есть и куда идти дальше. Результат работы — не картинка, а набор решений: какие разделы существуют, что в них лежит, как они называются и как связаны между собой.

Термин часто путают с соседними понятиями. Разница важна, потому что от неё зависит, кто за что отвечает в команде и что именно проверять.

Понятие	Что это	Чем отличается от IA
Информационная архитектура	Организация, группировка и названия контента	—
Карта сайта (sitemap)	Схема разделов и страниц в виде дерева	Один из артефактов IA, а не вся архитектура: в ней нет меток, связей и логики поиска
Навигация	Меню, хлебные крошки, фильтры, ссылки — то, что видит пользователь	Видимый слой поверх IA. Одну архитектуру можно показать разными видами навигации
Пользовательский сценарий (user flow)	Последовательность шагов для одной задачи	Описывает движение, а IA — пространство, в котором это движение происходит
UX-дизайн	Весь опыт взаимодействия с продуктом	IA — его часть, вместе с исследованиями, интерфейсом, текстами и доступностью

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

Из каких систем состоит информационная архитектура?

Классическое описание дают Луис Розенфельд и Питер Морвиль в книге «Information Architecture for the World Wide Web» (её называют «книгой с белым медведем»). Они выделяют четыре системы, и каждая отвечает за свою часть поиска информации.

1. Система организации. По какому принципу контент делится на группы: по темам, задачам, аудиториям, времени, алфавиту. От неё зависит, какие разделы вообще появятся.
2. Система маркировки (labeling). Как называются разделы, пункты меню, кнопки, заголовки. Одна и та же группа под названием «Решения» и под названием «Услуги для бизнеса» работает по-разному.
3. Система навигации. Как человек перемещается: главное меню, локальная навигация внутри раздела, хлебные крошки, связанные материалы, подвал, контекстные ссылки в тексте.
4. Система поиска. Как работает поиск по сайту: что индексируется, как выглядят результаты, какие есть фильтры и что показывается, если ничего не найдено.

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

На каких принципах строится информационная архитектура?

Удобнее всего опираться на восемь принципов, которые сформулировал Дэн Браун (Dan Brown) в статье для бюллетеня ASIS&T в 2010 году. Это не правила оформления, а критерии, по которым можно спорить о структуре предметно.

Принцип	Суть	Как применить
Объекты	Контент — живые объекты со своим жизненным циклом и атрибутами	Описать типы контента: статья, услуга, товар, кейс — и их поля
Выбор	Меньше осмысленных вариантов лучше, чем много похожих	Не дробить меню на пункты, которые пользователь не различает
Раскрытие	Показывать столько, сколько нужно, чтобы решить, идти ли глубже	Краткие описания под пунктами, превью разделов
Примеры	Содержимое категории понятнее по примерам, чем по названию	Показывать 2–3 типичных элемента внутри пункта меню или карточки раздела
Входные двери	Половина посетителей приходит не на главную	Каждая страница объясняет, где человек и куда можно пойти
Множественная классификация	Люди ищут по-разному	Несколько путей к одному контенту: по задаче, по аудитории, поиском
Сфокусированная навигация	Не смешивать разные типы навигации в одном меню	Отдельно — разделы, отдельно — служебные ссылки, отдельно — акции
Рост	Контента станет больше	Проверить, куда лягут материалы через год, без переделки меню

Отдельно стоит развенчать миф «в меню не больше 7±2 пунктов». Он опирается на исследование кратковременной памяти Джорджа Миллера, но меню не нужно запоминать — его видно на экране. Ограничивать число пунктов стоит по другой причине: каждый лишний пункт увеличивает время выбора и вероятность ошибки. Восемь понятных пунктов лучше, чем пять размытых.

Как сгруппировать контент: какие схемы организации бывают?

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

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

Схема	Когда подходит	Пример
По месту (Location)	Важна география	Филиалы клиники, пункты выдачи, города доставки
По алфавиту (Alphabet)	Человек знает точное название	Справочник лекарств, глоссарий, список брендов
По времени (Time)	Важна хронология или свежесть	Новости, расписание, архив выпусков
По категории (Category)	Объекты различаются по типу	Каталог: ноутбуки, телефоны, аксессуары
По шкале (Hierarchy)	Объекты сравнивают по величине	Тарифы от базового к максимальному, сортировка по цене
По задачам	Люди приходят решить конкретную проблему	«Подключить», «Оплатить», «Перенести номер»
По аудиториям	У групп разные потребности и мало пересечений	«Частным лицам», «Бизнесу», «Партнёрам»

Деление по аудиториям выглядит логично, но опасно: человек не всегда знает, к какой группе относится (ИП — это «частное лицо» или «бизнес»?), а одинаковый контент приходится дублировать. Используйте его, только если наборы задач действительно разные. Чаще всего сайт сочетает схемы: верхний уровень — по задачам или категориям, внутри — по шкале или времени.

Как спроектировать информационную архитектуру сайта: пошаговый процесс

Процесс одинаков для нового сайта и для перестройки старого; разница только в том, что у старого сайта есть данные о поведении, которые нужно использовать. Шаги идут по порядку, но между 4-м и 7-м обычно бывает 2–3 итерации.

1. Цели и аудитория. Запишите, кто приходит на сайт, с какими задачами и какие действия нужны бизнесу. Источники — интервью, обращения в поддержку, звонки отдела продаж, поисковые запросы, аналитика.
2. Инвентаризация контента. Полный список того, что уже есть или будет: страницы, документы, типы объектов. Для действующего сайта — выгрузка всех URL с трафиком и входящими ссылками.
3. Список задач пользователей. 10–20 главных задач в формулировках пользователей, с пометкой, какие из них самые частые и самые важные для бизнеса.
4. Карточная сортировка. Узнаём, как сами пользователи группируют контент и как называют группы.
5. Черновик структуры. Дерево разделов в таблице или схеме: уровни, названия, что лежит внутри.
6. Tree testing. Проверяем, находят ли люди нужное в этом дереве без дизайна.
7. Доработка и метки. Исправляем места, где люди ошибались, уточняем названия, добавляем перекрёстные ссылки.
8. Навигация и шаблоны. Переводим дерево в меню, хлебные крошки, фильтры и шаблоны страниц, затем — в прототип.

Как провести инвентаризацию контента

Инвентаризация — самый скучный и самый недооценённый шаг. Без неё структура рисуется «из головы», а потом выясняется, что в неё не помещаются 200 старых статей или раздел с документами, о котором никто не вспомнил. Для действующего сайта выгрузите все URL краулером и сведите в таблицу.

Поле таблицы	Зачем
URL и заголовок	Однозначно идентифицировать страницу
Тип контента	Понять, какие шаблоны нужны: услуга, статья, кейс, документ
Задача пользователя	Связать страницу с задачей из списка
Трафик и входы из поиска	Не потерять страницы, которые кормят сайт
Входящие ссылки	Учесть ссылочный вес при переносе
Решение	Оставить, объединить, переписать, удалить

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

Как провести карточную сортировку?

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

Вид	Как проходит	Когда использовать
Открытая	Участник сам создаёт группы и придумывает им названия	Новый сайт или полная перестройка — нужно узнать, как люди думают
Закрытая	Группы заданы заранее, участник только раскладывает карточки	Структура уже есть, нужно проверить, понятно ли, что куда относится
Гибридная	Группы заданы, но можно добавить свои	Основа понятна, но есть сомнения в отдельных разделах

Подготовка карточек и участников

• Количество карточек. Обычно 30–60: меньше — мало данных о связях, больше — участники устают и раскладывают небрежно. Если контента сотни единиц, берите репрезентативную выборку из каждого типа.
• Формулировки. Карточка описывает содержание простыми словами, а не повторяет название будущего раздела. «Как вернуть товар, если не подошёл размер» вместо «Возврат». Иначе люди группируют по совпадающим словам, а не по смыслу.
• Участники. Для открытой сортировки ориентир — около 15 человек на каждую заметно отличающуюся группу аудитории. Эту цифру часто связывают с исследованием Томаса Таллиса и Ларри Вуда 2004 года: при 15 участниках результаты уже сильно совпадают с результатами большой выборки.
• Формат. Онлайн-сортировка без модератора даёт количественные данные быстро. Модерируемая сессия на 30–60 минут медленнее, но объясняет, почему человек положил карточку именно сюда, — эти комментарии часто ценнее самих групп.

Как анализировать результаты

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

Названия групп из открытой сортировки — готовый словарь для меток. Если десять человек из пятнадцати назвали группу «Доставка и оплата», а у вас в меню «Логистика», это повод переименовать раздел. Но помните: сортировка показывает, как люди группируют, а не как будут искать. Это проверяет следующий метод.

Как проверить структуру с помощью tree testing?

Tree testing (тестирование дерева, «обратная карточная сортировка») — проверка того, находят ли люди нужную информацию в структуре сайта без визуального дизайна. Участнику показывают только текстовое дерево разделов и дают задание: «Где вы будете искать…?». Он кликает по уровням, пока не выберет конечный пункт. Так видно, работает ли сама структура, а не красивая вёрстка поверх неё.

Как составить задания

1. Берите главные задачи. 8–10 заданий на участника, начиная с самых частых и самых важных для бизнеса, плюс те места, где сортировка показала разброс.
2. Не подсказывайте словами меню. Если раздел называется «Доставка», задание «Найдите информацию о доставке» ничего не проверяет. Лучше: «Вы заказали диван. Узнайте, привезут ли его в субботу».
3. Один правильный ответ — заранее. Для каждой задачи отметьте, какие конечные пункты считаются успехом. Иногда их несколько — это нормально.
4. Перемешивайте порядок. К концу сессии участник уже знает дерево; случайный порядок заданий снижает этот эффект.
5. Начните с разминки. Одно простое задание в начале, которое не идёт в анализ, помогает понять механику.

Для количественных выводов нужно больше людей, чем для юзабилити-теста: обычно несколько десятков участников, часто ориентируются примерно на 50 — тогда разница между вариантами структуры уже не похожа на случайность. Для быстрой качественной проверки можно начать с меньшего числа, но тогда смотрите на поведение, а не на проценты. Методика подробно описана в статье NN/g о tree testing.

Какие метрики смотреть

Метрика	Что показывает	Как читать
Успешность (success rate)	Доля участников, выбравших правильный пункт	Низкая успешность по задаче — раздел не там или назван не так
Прямота (directness)	Доля тех, кто дошёл без возвратов назад	Высокая успешность при низкой прямоте — люди находят, но после блужданий; метки неоднозначны
Время на задачу	Сколько ушло на поиск	Сравнивайте между задачами и вариантами, а не с абстрактной нормой
Первый клик	Куда человек пошёл сначала	Если первый клик неверный, вероятность найти ответ резко падает — самый ценный диагностический сигнал
Пути (pietree)	Все маршруты участников по дереву	Показывают, какой «ложный» раздел притягивает людей

Порог «хорошо» зависит от продукта, поэтому полезнее сравнивать: старое дерево против нового, вариант А против варианта Б. Если нужен внутренний ориентир, задайте его до теста — например, 70–80 % успешности для ключевых задач — и разбирайте каждую задачу ниже этой планки. После исправлений тест повторяют на новых участниках — те же люди уже запомнили дерево.

Как превратить структуру в навигацию и понятные метки?

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

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

Метки проверяют отдельно. Хорошая метка короткая, описывает содержание словами пользователя и не пересекается с соседними. «Решения», «Продукты» и «Услуги» в одном меню — классический пример пересечения: люди не понимают разницы и угадывают. Внутренний жаргон («Портал самообслуживания», «Кабинет B2C») заменяйте на слова из карточной сортировки и поисковых запросов.

Как устроить навигацию на маленьком экране, где помещается четыре-пять пунктов, мы разбирали в статье о навигации в мобильном приложении. Для сервисов с авторизацией, где структура строится вокруг статусов и действий клиента, полезен материал про UX личного кабинета.

Какие документы получаются на выходе проектирования?

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

Документ	Что в нём	Кто пользуется
Карта сайта	Дерево разделов и страниц с уровнями и шаблонами	Дизайнеры, разработчики, SEO-специалист
Модель контента	Типы объектов (услуга, врач, статья, товар) и их поля, обязательные и необязательные	Разработчики CMS, редакция
Словарь меток	Утверждённые названия разделов и понятий, запрещённые синонимы	Редакция, дизайнеры, поддержка
Карта связей	Какие разделы и типы контента ссылаются друг на друга и где	Редакция, SEO-специалист

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

Как улучшить архитектуру действующего сайта по данным?

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

1. Поиск по сайту. Журнал запросов показывает, что люди не нашли через меню. Если в топе запросов «доставка» или «цены», а эти разделы есть в навигации, значит, они плохо видны или неудачно названы.
2. Аналитика переходов. Страницы с высокой долей возвратов назад и короткими визитами часто означают, что человек пришёл не туда, куда ожидал по названию пункта.
3. Обращения в поддержку. Вопросы «где найти…» и «как узнать…» — прямой список задач, которые структура не решает.
4. Поисковые запросы. Формулировки, по которым приходят из поисковиков, — готовый словарь для меток и подсказка, каких страниц не хватает.

По этим данным составляют список проблемных задач и проверяют их закрытым tree testing на текущем дереве. Это даёт исходную точку: после перестройки тот же тест на новом дереве покажет, стало ли лучше, и избавит от споров о вкусе.

Как информационная архитектура влияет на SEO и ИИ-поиск?

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

1. Одна страница — одна задача. Если структура разводит темы чётко, не возникает двух страниц под один запрос, которые отбирают друг у друга позиции.
2. Понятные URL. Адрес повторяет логику разделов: /uslugi/remont-krovli/, а не /page?id=482. Но не делайте URL слишком глубоким — четыре-пять уровней вложенности уже мешают и людям, и роботам.
3. Хлебные крошки с разметкой. BreadcrumbList в JSON-LD помогает поисковику показать путь в сниппете.
4. Хабы разделов. Страница раздела — не пустой список ссылок, а полноценная страница с описанием и связями. Она собирает общий запрос и передаёт вес вложенным страницам.
5. Нет страниц-сирот. Страница, на которую не ведёт ни одна внутренняя ссылка, плохо индексируется. Инвентаризация и карта связей ловят такие страницы до запуска.

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

Чем отличается информационная архитектура приложения от архитектуры сайта?

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

Параметр	Сайт	Мобильное приложение
Глубина	3–4 уровня допустимы	1–2 уровня на виду, глубже — через поиск и связи
Точки входа	Любая страница из поиска	Главный экран, пуш-уведомления, глубокие ссылки
Главный принцип	Полнота и находимость	Частота задач и скорость повторного действия
Навигация	Меню, крошки, подвал, поиск	Таб-бар, стек экранов, жесты, поиск

Методы исследования не меняются: карточная сортировка и tree testing одинаково работают для обоих случаев.

Пример: структура сайта многопрофильной клиники

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

Исследование: инвентаризация, задачи и сортировка

Инвентаризация. Выгрузка дала 640 URL: 180 страниц услуг, 90 врачей, 210 статей, 40 акций (из них 31 — истёкшие), документы и вакансии. Половину входов из поиска дают страницы услуг и врачей; статьи приводят трафик, но почти не ведут к записи.

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

Карточная сортировка. 45 карточек, открытая онлайн-сортировка, 32 участника из двух групп — пациенты-взрослые и родители. Выяснилось, что «отделения» и «направления» люди не различают и называют одним словом — «Услуги». Детские услуги родители ищут отдельно, а не внутри каждого направления.

Проверка дерева и итоговая навигация

Черновик и tree testing. Новое дерево: «Услуги и цены» (по направлениям), «Врачи», «Детям», «Анализы», «Филиалы», «Пациентам». Tree testing на 54 участниках: задача «узнать стоимость первичного приёма невролога» — успешность выросла с 41 % на старом дереве до 83 % на новом. Слабое место — подготовка к анализам: люди искали её в «Пациентам», а не в «Анализах». Добавили перекрёстную ссылку и пункт в обоих разделах.

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

Какие инструменты использовать для проектирования IA?

Задача	Инструменты	Комментарий
Инвентаризация	Screaming Frog, Netpeak Spider, таблицы	Краулер выгружает URL, таблица — для решений по каждой странице
Карточная сортировка	OptimalSort, UXtweak, Maze, Lyssna	Онлайн-сессии, матрица сходства и дендрограмма из коробки
Tree testing	Treejack, UXtweak, Maze, Lyssna	Метрики успешности, прямоты, первого клика и карта путей
Схема структуры	FigJam, Miro, Whimsical, Draw.io	Для обсуждения с командой и заказчиком
Прототип навигации	Figma, Axure	Следующий шаг после утверждённого дерева

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

Какие ошибки чаще всего ломают информационную архитектуру?

Большинство проблем со структурой возникает не из-за сложности контента, а из-за решений, принятых без данных о пользователях.

Ошибка	Чем вредит	Как исправить
Меню повторяет оргструктуру компании	Посетитель не знает, в каком «отделе» его ответ	Группировать по задачам и категориям из сортировки
Структура «из головы» без инвентаризации	Часть контента не помещается, появляются разделы «Разное»	Полный список контента до первого черновика
Пересекающиеся метки	Люди угадывают, куда идти, и ошибаются	Одна метка — одно понятие, проверка tree testing
Внутренний жаргон в названиях	Названия непонятны тем, кто не работает в компании	Слова из сортировки, поисковых запросов и обращений
Слишком глубокая вложенность	Нужное лежит в пяти кликах, роботы и люди туда не доходят	Не глубже 3–4 уровней, хабы разделов, перекрёстные ссылки
Задания tree testing с подсказкой	Высокая успешность, которая ничего не значит	Сценарии своими словами, без слов из меню
Структура без запаса на рост	Через год меню переделывают заново	Проверить, куда лягут новые типы контента
Удаление страниц без редиректов	Потеря трафика и ссылочного веса	Карта редиректов в той же таблице инвентаризации

Чек-лист информационной архитектуры

Пройдите по списку до передачи структуры в прототип и ещё раз — перед запуском.

1. Записаны аудитории, их главные задачи и целевые действия бизнеса.
2. Есть полная инвентаризация контента с решением по каждой странице.
3. Проведена карточная сортировка: открытая для новой структуры, закрытая или гибридная — для проверки существующей.
4. Группы и названия разделов опираются на данные сортировки, а не на оргструктуру.
5. Структура не глубже 3–4 уровней, у каждого раздела есть страница-хаб.
6. Tree testing проведён на задачах без подсказок, слабые задачи доработаны и перепроверены на новых участниках.
7. Метки короткие, не пересекаются и звучат словами пользователей.
8. Определены глобальная и локальная навигация, хлебные крошки, контекстные связи и подвал.
9. У каждой страницы есть внутренние ссылки, страниц-сирот нет.
10. URL повторяют логику разделов, для удаляемых и перенесённых страниц есть редиректы.
11. Понятно, куда лягут новые материалы через год.
12. Карта сайта и словарь меток переданы в ТЗ и доступны всей команде.

После запуска возвращайтесь к структуре по данным: поисковые запросы внутри сайта, страницы с высоким процентом возвратов назад, вопросы в поддержку «где найти…». Они показывают, где архитектура перестала совпадать с тем, как думают пользователи. Измерить эффект перестройки помогут метрики успешности задач — о них в нашей статье про UX-метрики SUS и HEART, а качественную проверку на живом интерфейсе — юзабилити-тест на пяти пользователях.