Каталог — это не список товаров, а маршрут покупателя к покупке. Если человек за пару кликов не понимает, где искать нужное, он уходит — и никакой дизайн кнопок это не спасёт. Проблема почти всегда одна: структуру каталога проектировали «от учётной системы» и здравого смысла разработчика, а не от того, как реальный клиент ищет и сравнивает товар.
Эта статья — о том, как спроектировать каталог на 1С-Битрикс, в котором товар легко найти: как выстроить дерево разделов, распределить характеристики между свойствами инфоблока и торговыми предложениями, настроить умный фильтр и поиск и не потерять скорость на большом ассортименте. Порядок в номенклатуре при этом начинается в учётной системе — здесь помогает аудит и оптимизация 1С.
Коротко
- Проектируйте каталог от сценариев выбора покупателя, а не от структуры учётной базы.
- Держите дерево разделов на два-три уровня, глубже — отсекайте умным фильтром.
- Правильно разделяйте свойства инфоблока (для фильтра) и торговые предложения (варианты товара).
- Скорость каталога закладывается на этапе проектирования: фасетный индекс, кэш, композитный сайт.
Почему покупатель не находит товар
Провал каталога редко выглядит как «поломка». Товар есть, страницы открываются, но конверсия низкая, а в метрике видно: люди заходят в каталог, перебирают разделы или открывают поиск — и уходят без добавления в корзину. Причина в том, что каталог отвечает не на те вопросы, которые задаёт покупатель.
Типичные корни проблемы одинаковы почти на всех проектах:
- Структура «от 1С». Разделы повторяют группы номенклатуры в учёте, которые удобны бухгалтеру, а не покупателю.
- Фильтр из всего подряд. В умный фильтр вывели все свойства, включая служебные, и покупатель тонет в фасетах.
- Характеристики в названии. Цвет и размер зашиты в наименование, а не в торговые предложения, поэтому по ним нельзя отфильтровать.
- Слабый поиск. Поиск не понимает синонимы и артикулы, выдаёт пустоту или мусор.
Всё это лечится не косметикой, а проектированием: сначала логика выбора, потом структура данных, и только потом интерфейс.
Проектируем от сценариев выбора
Хороший каталог начинается с вопроса: как именно покупатель принимает решение в вашей категории? В одних нишах выбирают по бренду, в других — по совместимости, в третьих — по размеру и цене. Эти признаки и должны стать основой навигации и фильтра.
Соберите сценарии в явном виде до того, как трогать инфоблоки:
- По каким признакам сравнивают. Что покупатель держит в голове, когда выбирает: мощность, объём, материал, совместимость.
- Что он уже знает. Приходит с названием, артикулом или только с задачей («нужно что-то для…»).
- Какие вопросы задаёт перед покупкой. Ответы на них должны быть в карточке, иначе он уйдёт искать в другом месте.
Дерево разделов и глубина вложенности
Разделы каталога в 1С-Битрикс — это разделы инфоблока торгового каталога. Дерево должно вести покупателя к нужной группе товаров быстро и предсказуемо. Оптимум — два-три уровня вложенности: глубже пользователь теряется на промежуточных страницах, площе — тонет в тысячах позиций одного раздела.
Несколько принципов проектирования дерева:
- Разделы — по логике покупателя. Называйте их так, как думает клиент, а не как называется группа в 1С.
- Один товар — одна логика попадания. Если товар честно относится к нескольким разделам, используйте привязку к нескольким разделам, но не плодите дубли.
- Дальше — фильтр, а не подразделы. Когда в группе десятки товаров, отсев делает умный фильтр, а не новые уровни дерева.
- Хлебные крошки и меню — из одного дерева. Навигация должна быть единой, чтобы пользователь не терял контекст.
Свойства инфоблока и торговые предложения
Ключевое проектное решение — как распределить характеристики между свойствами товара и торговыми предложениями. От этого зависит и карточка, и фильтр, и обмен с 1С.
| Что это | Свойство инфоблока | Торговое предложение (SKU) |
|---|---|---|
| Назначение | Характеристика товара для фильтра | Конкретный вариант товара |
| Примеры | Бренд, материал, назначение, мощность | Размер, цвет, фасовка, объём |
| Своя цена и остаток | Нет (общие у товара) | Да, у каждого варианта |
| Роль в умном фильтре | Фасет для отбора | Отбор по варианту (размер, цвет) |
| Источник в 1С | Свойство номенклатуры | Характеристика/вариант |
Правило простое: то, что отличает варианты одного товара и имеет свою цену и остаток, — это торговые предложения; то, что описывает товар целиком и по чему сравнивают разные товары, — свойства инфоблока. Ошибка распределения приводит к кривой карточке и бесполезному фильтру, а переделка после наполнения каталога дорога.
Умный фильтр и фасеты
Умный фильтр (компонент catalog.smart.filter) — главный инструмент отсева на большом ассортименте. Полезным его делает не количество фасетов, а их осмысленность.
- Только значимые свойства. В фильтр выводят характеристики, по которым реально выбирают, а не все подряд. У свойства включается флаг участия в умном фильтре.
- Чистые значения. Значения свойств приводят к единому виду: не должно быть одновременно «красный» и «Красный», «5 кг» и «5кг».
- Понятные диапазоны. Для числовых характеристик — ползунки и диапазоны, а не десятки отдельных чекбоксов.
- Скрытие пустых фасетов. Фильтр не должен предлагать варианты, по которым нет товаров в текущем разделе.
Умный фильтр в Битрикс работает на фасетном индексе — предрассчитанной таблице соответствий «значение свойства — товары». Индекс нужно держать актуальным (переиндексировать после массовых изменений), иначе счётчики и выдача врут. О влиянии индекса на скорость — ниже.
Поиск, подсказки и синонимы
Часть покупателей не пользуется деревом разделов — они сразу идут в поиск. Для них поиск должен быть быстрым и понимающим. Штатный поиск 1С-Битрикс работает на морфологии, но его полезность зависит от настройки.
- Морфология и синонимы. «Холодильник» и «холодильники» должны находить одно; для профессиональных терминов заводят словарь синонимов.
- Поиск по артикулу. Коды ищут точным совпадением, а не морфологией — это отдельный механизм поверх обычного поиска.
- Автоподсказки. По мере ввода показываются подходящие товары и разделы, чтобы сократить путь.
- Обработка пустой выдачи. Если ничего не найдено, покупателю предлагают альтернативы, а не пустой экран.
Поиск, фильтр и REST-подсказки часто завязаны на асинхронные запросы к каталогу. Как безопасно строить такие точки доступа, мы разбирали в материале про REST, вебхуки и безопасность в Битрикс.
Карточка товара как точка решения
Дерево и фильтр приводят покупателя к карточке — и именно на ней принимается решение. Карточка должна закрывать вопросы, которые покупатель задавал при выборе, без ухода на сторонние сайты.
- Характеристики в таблице. Те самые свойства, по которым сравнивают, — структурированно, а не сплошным текстом.
- Варианты рядом. Выбор размера и цвета (торговые предложения) с ценой и наличием конкретного варианта.
- Наличие и сроки. Честный остаток и срок поставки для позиций под заказ.
- Сопутствующие и аналоги. Кросс-продажи и замены для товара, которого нет в наличии.
Карточка — это и главная SEO-страница каталога: под неё оптимизируют заголовки, характеристики и контент. Проектируя каталог, закладывайте карточку так, чтобы она одновременно продавала и работала на поисковый трафик.
Листинг: сортировка и просмотр
Страница списка товаров (листинг раздела и результатов фильтра) — это витрина, по которой покупатель бегает глазами. Здесь важны мелочи, которые ускоряют выбор:
- Информативная плитка. В карточке товара на листинге — ключевая характеристика, цена, наличие и быстрое действие.
- Полезная сортировка. По цене, популярности, новизне — то, что реально помогает выбирать в вашей нише.
- Понятная пагинация или подгрузка. Постраничный вывод либо «показать ещё» с сохранением состояния фильтра.
- Сохранение фильтра. При возврате из карточки покупатель должен вернуться в тот же отфильтрованный список.
Связь каталога с данными 1С
На большинстве проектов каталог наполняется не вручную, а обменом CommerceML из 1С: разделы, свойства, цены, остатки и торговые предложения приходят из учётной системы. Поэтому структуру свойств на сайте нельзя проектировать в отрыве от номенклатуры в 1С — иначе обмен будет плодить дубли и «плавающие» значения.
Что важно согласовать между сайтом и учётом:
- Стабильные коды. Идентификаторы товаров и разделов не должны меняться от выгрузки к выгрузке.
- Единые справочники значений. Бренды, цвета, единицы измерения ведутся в одном месте, а не набираются руками с вариациями.
- Согласованные свойства. Свойство на сайте соответствует полю номенклатуры в 1С, чтобы обмен ложился без ручной правки.
Часть этой работы лежит на стороне учётной системы: чистка номенклатуры, справочников и правил выгрузки. Здесь помогает автоматизация на 1С, а для товарных остатков и складского контура — автоматизация продаж и склада на 1С. Инфраструктурную часть обмена и стабильность площадки мы разбирали в статье про хостинг и инфраструктуру BitrixVM.
Скорость каталога и фасетный индекс
Каталог на десятки и сотни тысяч позиций должен оставаться быстрым, иначе фильтр «думает» секундами и покупатель уходит. Скорость закладывается на этапе проектирования, а не чинится потом.
- Фасетный индекс. Умный фильтр работает по предрассчитанному индексу; его держат актуальным и переиндексируют после массовых изменений.
- Кэширование компонентов. Списки, разделы и фильтр кэшируются с корректной инвалидацией по изменению товаров.
- Композитный сайт. Статическая часть страниц каталога отдаётся мгновенно, динамика (цена группы, наличие) догружается.
- Оптимальные выборки. Запросы к каталогу строят на D7 ORM, выбирая только нужные поля, без «выбрать всё и отфильтровать в PHP».
Про современный слой доступа к данным и почему он важен для тяжёлых каталогов — в статье про D7 ORM в Битрикс. Если каталог развивается в сторону агрегатора или площадки с несколькими продавцами, полезен разбор разработки модуля маркетплейса на Битрикс.
Частые ошибки проектирования
- Структура повторяет 1С. Разделы удобны учёту, а не покупателю — навигация не работает.
- Всё в свойствах инфоблока. Цвет и размер не вынесены в торговые предложения, по ним нельзя ни фильтровать, ни выбрать вариант.
- Перегруженный фильтр. В умный фильтр выведены служебные свойства, покупатель тонет в фасетах.
- Грязные значения свойств. Дубли «красный/Красный» ломают фасеты и счётчики фильтра.
- Слишком глубокое дерево. Пять уровней разделов вместо фильтра — пользователь теряется.
- Игнор скорости. Фасетный индекс и кэш не настроены, фильтр тормозит на большом каталоге.
- Карточка без ответов. Нет характеристик, наличия и вариантов — покупатель уходит искать в другом месте.
Чек-лист внедрения
- Сценарии выбора описаны. Ясно, по каким признакам покупатель сравнивает товары в вашей нише.
- Дерево разделов спроектировано. Два-три уровня, названия — по логике покупателя, без дублей.
- Свойства и предложения распределены. Характеристики для сравнения — в свойствах, варианты — в торговых предложениях.
- Умный фильтр настроен. Только значимые фасеты, чистые значения, скрытие пустых, актуальный фасетный индекс.
- Поиск работает. Морфология, синонимы, поиск по артикулу, автоподсказки, обработка пустой выдачи.
- Карточка закрывает вопросы. Характеристики, варианты, наличие, аналоги и кросс-продажи.
- Обмен с 1С согласован. Стабильные коды, единые справочники, свойства сайта соответствуют номенклатуре.
- Скорость заложена. Фасетный индекс, кэш компонентов, композитный сайт, выборки на D7.
Вывод
Каталог, в котором легко найти товар, — результат проектирования, а не удачного шаблона. Сначала вы разбираете, как покупатель ищет и сравнивает, затем переносите эту логику в структуру разделов, свойства инфоблока и торговые предложения, настраиваете умный фильтр и поиск и закладываете скорость на большом ассортименте.
Всё это держится на чистых данных из 1С: стабильных кодах, единых справочниках и согласованных свойствах. Наведите порядок в номенклатуре и обмене — и каталог перестанет терять покупателей на пути к корзине, а станет вашим главным инструментом продаж.
