Проектирование структуры каталога товаров в 1С-Битрикс

Схема и структура каталога в 1С-Битрикс

Самая дорогостоящая ошибка в e-commerce проекте на Битрикс — неправильная структура каталога, обнаруженная через полгода после запуска. Переделка инфоблоков с данными, настроенным обменом с 1С и работающим сайтом — это не «доработка», а фактически новый проект с миграцией. Поэтому проектирование структуры каталога мы выполняем до написания первой строки кода и до настройки обмена с 1С. Наша команда с 10+ лет опыта гарантирует, что структура будет стабильна при любой нагрузке. Мы завершили более 500 проектов, в том числе для крупных маркетплейсов и производителей мебели. Wikipedia: 1С-Битрикс

Почему важно проектировать каталог до разработки?

Цена ошибки — часы разработки и простой бизнеса. Неправильная иерархия разделов приводит к неработающему ЧПУ или потере трафика. Согласно документации 1С-Битрикс, оптимальная структура — один инфоблок для всего каталога. Мы исключаем риски на этапе схемы. Средняя экономия на миграции данных при правильно спроектированной структуре — значительная сумма бюджета.

Модули, задействованные в каталоге

Каталог товаров в Битрикс — это взаимодействие модулей:

• iblock — хранение товаров и свойств
• catalog — цены, остатки, скидки (b_catalog_product, b_catalog_price, b_catalog_store_amount)
• sale — корзина и оформление заказа
• search — полнотекстовый поиск

Каждый модуль накладывает требования на структуру. Например, для мультискладского учёта склады в b_catalog_store влияют на отображение остатков на карточке товара.

Как выбрать между одним и несколькими инфоблоками?

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

• Фильтр не работает по свойствам из разных инфоблоков
• Обмен с 1С настраивается отдельно для каждого инфоблока
• Поиск по всему каталогу требует объединения результатов

Один инфоблок для всего каталога — правило по умолчанию. Свойства, специфичные для категорий, добавляются в общую схему и остаются пустыми у товаров других категорий. Это не waste: пустые значения в b_iblock_element_property не хранятся.

Исключение: каталог с принципиально разной структурой (физические товары и цифровые услуги в одном магазине). Тогда два инфоблока оправданы, но с единым поиском и отдельными компонентами.

Иерархия разделов и глубина вложенности

Разделы каталога (b_iblock_section) — дерево категорий. Проектируется с учётом:

• SEO: URL вида /catalog/electronics/smartphones/ или /catalog/smartphones/
• Навигации: сколько уровней видит пользователь
• Фильтрации: на каком уровне применяется фасет

Практическое правило: не более 4 уровней вложенности. Глубже — проблемы с ЧПУ, хлебными крошками и админкой. Если товар относится к нескольким категориям (например, «Кабель HDMI» и в «Кабели», и в «Телевизионное оборудование»), дополнительную классификацию храним в свойстве-справочнике, а не в разделах.

Когда нужны торговые предложения?

Торговые предложения нужны, когда товар имеет варианты с разными ценами или остатками. Реализация: родительский элемент основного инфоблока + связанный инфоблок офферов через Catalog.Offers.

Важное проектное решение: какие свойства принадлежат товару, а какие — офферу. Цвет и размер — офферу (у каждого свои). Бренд и описание — родителю. Нарушение ломает фильтрацию: фильтр по цвету должен работать на уровне офферов. Один инфоблок лучше нескольких в 3 раза по скорости фильтрации.

Цены, скидки, типы цен

Структура ценообразования проектируется на старте. Определяются следующие моменты: количество типов цен (b_catalog_price_type) — базовая, оптовая, дилерская. Способ применения скидок — правила (b_catalog_discount) или накопительные программы. Связь цен с группами пользователей. Для B2B с индивидуальными ценами для каждого клиента стандартная система не подходит — нужна кастомная логика через обработчики событий модуля catalog. 90% проектов, которые приходят к нам на доработку, имеют ошибки в ценообразовании.

Что входит в проектирование структуры каталога?

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

Кейс из нашей практики: каталог для производителя мебели на заказ

Производитель корпусной мебели. Особенность: товар — конфигурируемое изделие (высота, ширина, материал фасада, фурнитура). Цена от конфигурации. Стандартные SKU не подходили: комбинаций слишком много.

Наше проектное решение:

• Инфоблок «Коллекции» — родительские элементы (шкаф-купе «Модерн», кухня «Классика»)
• HL-блок hl_materials — 48 вариантов материалов с UF_PRICE_COEF
• HL-блок hl_hardware — 120 вариантов фурнитуры
• Кастомный конфигуратор на JS, строит цену из данных HL-блоков через REST API Битрикс
• В корзину добавляется элемент с JSON-составом конфигурации в свойстве заказа

Каталог работает несколько лет, объём — 240 коллекций, структура не менялась. Результат: минимальные затраты на поддержку, быстрая адаптация под новые материалы. Снижение времени на внесение изменений — на 40%.

Процесс проектирования: пошагово

1. Аудит ассортимента и бизнес-требований. Собираем все данные о товарах, типах цен, складах.
2. Проектирование схемы инфоблоков. Определяем, сколько инфоблоков нужно, как организовать иерархию разделов.
3. Разработка структуры свойств. Выбираем типы, фасетные индексы, связь с SKU.
4. Проектирование обмена с 1С. Маппинг полей, периодичность, направление синхронизации.
5. Оценка нагрузки и оптимизация. Тегированное кэширование, индексы БД.
6. Подготовка документации. Полная схема для разработчиков.

Типовые ошибки, которых стоит избегать: использование разделов для фильтрации вместо свойств (приводит к дублированию товаров), хранение цен в инфоблоке, а не в модуле catalog (ломает скидки и валюты), игнорирование тегированного кэширования (падение производительности при высокой нагрузке).

Сроки проектирования

Готовы спроектировать ваш каталог? Оценим проект бесплатно в течение 2 дней. Напишите нам — обсудим детали и сроки. Получите консультацию инженера с 10+ летним опытом. Закажите оценку структуры прямо сейчас.