Проектирование структуры каталога товаров 1С-Битрикс
Самая дорогостоящая ошибка в e-commerce проекте на Битрикс — это неправильная структура каталога, обнаруженная через 6 месяцев после запуска. Переделка структуры инфоблоков с данными, настроенным обменом с 1С и работающим сайтом — это не «доработка», это фактически новый проект с миграцией. Поэтому проектирование структуры каталога выполняется до написания первой строчки кода и до настройки обмена с 1С.
Модули, задействованные в каталоге
Каталог товаров в Битрикс — это не один модуль, а взаимодействие нескольких:
-
iblock— хранение товаров и их свойств -
catalog— торговая логика: цены, остатки, скидки, типы товаров (b_catalog_product,b_catalog_price,b_catalog_store_amount) -
sale— корзина и оформление заказа -
search— полнотекстовый поиск
Структура каталога проектируется с учётом всех модулей, а не только iblock. Например, если планируется мультискладской учёт — в b_catalog_store нужно описать склады, и это влияет на то, как отображаются остатки на карточке товара.
Схема «один инфоблок» vs. «несколько инфоблоков»
Классическая дилемма. Несколько инфоблоков для разных категорий товаров выглядят привлекательно (у каждой категории свои свойства), но создают проблемы:
- Фильтр не может работать по свойствам из разных инфоблоков
- Обмен с 1С настраивается отдельно для каждого инфоблока
- Поиск по всему каталогу требует объединения результатов
Один инфоблок для всего каталога — правило по умолчанию. Свойства, специфичные для категорий, добавляются в общую схему и остаются пустыми у товаров других категорий. Это «расточительно» только на первый взгляд: пустые значения в b_iblock_element_property не хранятся.
Исключение: каталог с принципиально разной структурой данных (например, физические товары и цифровые услуги в одном магазине) — тогда два инфоблока оправданы, но с единой системой поиска и отдельными компонентами.
Иерархия разделов и глубина вложенности
Разделы каталога (b_iblock_section) — это дерево категорий. Проектируется с учётом:
- SEO: URL вида
/catalog/electronics/smartphones/или/catalog/smartphones/ - Навигации: сколько уровней в меню отображается пользователю
- Фильтрации: на каком уровне применяется фасет
Практическое правило: не более 4 уровней вложенности. Глубже — проблемы с построением ЧПУ, хлебными крошками и управлением в административной панели.
Разделы vs. свойства для классификации: если товар относится к нескольким категориям (например, «Кабель HDMI» — и в «Кабели», и в «Телевизионное оборудование») — привязка только к одному разделу теряет вторую классификацию. В таких случаях дополнительная классификация хранится в свойстве-справочнике, а не в разделах.
Торговые предложения (SKU): когда и как
Торговые предложения нужны, когда товар имеет варианты с разными ценами или остатками. Реализация в Битрикс: родительский элемент основного инфоблока + связанный инфоблок офферов, привязанный через настройку Catalog.Offers в модуле catalog.
Важное проектное решение: какие свойства принадлежат товару, а какие — торговому предложению. Цвет и размер — свойства предложения (у каждого варианта своё). Бренд и описание — свойства родительского товара. Нарушение этой логики приводит к ошибкам в фильтрации: фильтр по цвету должен работать на уровне офферов.
Цены, скидки, типы цен
Структура ценообразования проектируется на старте:
- Сколько типов цен нужно (
b_catalog_price_type): базовая, оптовая, дилерская? - Как применяются скидки: правила скидок (
b_catalog_discount) или накопительные программы (b_catalog_discount_coupon)? - Как цены связаны с группами пользователей?
Для B2B-магазина с индивидуальными ценами для каждого клиента стандартная система типов цен не подходит — нужна кастомная логика через обработчики событий модуля catalog.
Кейс: проектирование каталога для производителя мебели на заказ
Производитель корпусной мебели. Особенность: товар — не стандартный продукт, а конфигурируемое изделие (высота, ширина, материал фасада, фурнитура). Цена зависит от конфигурации.
Стандартная схема SKU не подходила: комбинаций слишком много для предварительного создания офферов.
Проектное решение:
- Инфоблок «Коллекции» — родительские элементы (шкаф-купе «Модерн», кухня «Классика»)
- HL-блок
hl_materials— 48 вариантов материалов с ценовыми коэффициентами (UF_PRICE_COEF) - HL-блок
hl_hardware— 120 вариантов фурнитуры - Компонент конфигуратора — кастомный, строит итоговую цену на JS на основе данных HL-блоков через REST API Битрикс
- В корзину добавляется элемент с составом конфигурации в виде JSON в свойстве заказа
Каталог работает 3 года, объём — 240 коллекций, структура не менялась.
Состав работы по проектированию структуры каталога
- Анализ ассортимента и бизнес-требований
- Схема инфоблоков: основной каталог, офферы, вспомогательные
- Проектирование иерархии разделов
- Схема свойств с типами и участием в фасете
- Проектирование торговых предложений
- Структура цен и типов цен
- Схема обмена с 1С: маппинг полей, периодичность, направление
- Оценка объёма и прогноз нагрузки
Срок: от 1 недели для стандартного каталога до 3–4 недель для сложных конфигурируемых продуктов или мультибрендового маркетплейса.