Информационная архитектура каталога: как сгруппировать категории

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

Эта статья — о том, как спроектировать информационную архитектуру каталога на 1С-Битрикс: как сгруппировать категории под реального покупателя, какую глубину дерева держать, чем структура витрины отличается от номенклатуры в 1С и как всё это ложится на инфоблоки и торговые предложения. Порядок в данных при этом начинается в учёте, поэтому по ходу мы затронем аудит и оптимизацию 1С как фундамент чистого каталога.

Почему структура каталога решает больше, чем дизайн

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

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

Что такое информационная архитектура каталога

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

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

Данные учёта против структуры для покупателя

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

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

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

Принципы группировки категорий

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

• Взаимоисключаемость. Пользователь не должен гадать, в какой из двух похожих разделов заглянуть. Границы категорий делают чёткими.
• Полнота. Любой товар из ассортимента должен иметь очевидное место в структуре, без раздела «Прочее» как свалки.
• Сопоставимый объём. Плохо, когда в одном разделе три товара, а в соседнем — три тысячи. Крупные категории дробят, мелкие — объединяют.
• Язык покупателя. Названия берут из речи клиентов и поисковых запросов, а не из внутренних терминов и артикульных обозначений.

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

Глубина дерева и число пунктов на уровне

Два параметра определяют, насколько легко человеку в каталоге: глубина вложенности и ширина каждого уровня. Их держат в балансе.

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

По типу, по назначению или гибрид

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

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

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

Инфоблоки и торговые предложения под структуру

В 1С-Битрикс каталог живёт в инфоблоках: разделы инфоблока — это категории дерева, элементы — товары, а вариации (размер, цвет, фасовка) выносятся в торговые предложения. От того, как вы разложите данные по этой модели, зависит и навигация, и фильтр.

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

Вариации одного товара выносят в торговые предложения, а не в отдельные элементы каталога, — иначе каталог засоряется десятками почти одинаковых карточек. Правильная модель инфоблоков и торговых предложений напрямую влияет на производительность и на то, как каталог отдаёт данные при высокой нагрузке — эту тему мы разбираем в материале D7 и ORM в 1С-Битрикс.

Дерево разделов и умный фильтр вместе

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

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

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

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

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

Реализация в 1С-Битрикс пошагово

Сборка структуры каталога в 1С-Битрикс проходит понятной последовательностью. Названия пунктов зависят от редакции, но логика общая:

1. Соберите данные о спросе. Частотные запросы, язык клиентов, сценарии выбора — на этой основе проектируют дерево, а не на номенклатуре 1С.
2. Спроектируйте дерево разделов. Два-три уровня, взаимоисключающие категории, сопоставимый объём, понятные названия.
3. Разведите разделы и свойства. Решите, что делать разделом дерева, а что — свойством для умного фильтра.
4. Настройте инфоблок и торговые предложения. Разделы, элементы и вариации разложите по модели каталога, вариации — в торговые предложения.
5. Опишите сопоставление при обмене. Свяжите номенклатурные группы 1С с разделами витрины, чтобы товары раскладывались автоматически.
6. Подключите умный фильтр. Включите значимые свойства в фасеты внутри разделов.
7. Проверьте на пользователях и данных. Карточная сортировка, аналитика путей, внутренний поиск — и корректировка по результатам.

Частые ошибки группировки

• Копирование номенклатуры 1С. Учётные группы переносят на витрину как есть — появляются «Прочее» и деление по поставщикам, непонятные покупателю.
• Слишком глубокое дерево. Пять уровней вложенности, до которых почти никто не доходит.
• Разделы вместо свойств. Признаки, которым место в фильтре, разносят по десяткам мелких разделов — дерево раздувается.
• Пустые и почти пустые категории. Разделы с одним-двумя товарами создают ощущение бедного ассортимента.
• Внутренние термины в названиях. Категории названы языком компании, а не покупателя.
• Дубли товара без канонической ссылки. Один товар в нескольких разделах плодит дубли URL и вредит SEO.
• Структура «навсегда». Дерево не пересматривают годами, хотя ассортимент и спрос давно изменились.

Чек-лист внедрения

1. Дерево спроектировано под покупателя. На основе спроса и языка клиентов, а не номенклатуры 1С.
2. Глубина и ширина в норме. Два-три уровня, пять-девять пунктов на уровне, сопоставимый объём разделов.
3. Разделы и свойства разведены. Понятно, что навигация, а что — фасеты умного фильтра.
4. Модель каталога настроена. Инфоблок, разделы, элементы и торговые предложения разложены корректно.
5. Сопоставление при обмене работает. Товары из 1С автоматически попадают в нужные разделы витрины.
6. Данные учёта чистые. В 1С нет дублей номенклатуры, свойства заполнены единообразно.
7. Каноникал у товаров. При привязке к нескольким разделам у товара один основной URL.
8. Структура проверена на людях. Карточная сортировка, аналитика путей, внутренний поиск учтены.

Вывод

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

И помните, что чистая структура на сайте держится на порядке в данных учёта: единые свойства, отсутствие дублей, корректный обмен. Наведите порядок в 1С, спроектируйте дерево под покупателя — и каталог начнёт работать на продажи, а не против них. Продолжить тему производительности каталога стоит с материалов про хостинг и инфраструктуру для 1С-Битрикс и CI/CD и деплой изменений.