Каталог товаров в Битриксе завязан на три сущности, которые работают вместе: инфоблоки задают структуру карточек и разделов, свойства описывают характеристики от цвета до веса упаковки, а торговые предложения решают задачу вариаций, когда один товар продаётся в разных размерах или комплектациях. Настраивал каталоги и на небольших магазинах на пару сотен позиций, и на проектах с десятками тысяч SKU, и почти всегда основные проблемы вылезают не из-за ограничений CMS, а из-за структуры, которую заложили на старте и потом больно ломать на живом сайте.
Как устроен каталог товаров в Битриксе: инфоблоки и разделы
Ядро каталога это информационный блок, инфоблок - сущность, на которой в Битриксе построены не только товары, но и новости, портфолио, вакансии, вообще любая структурированная сущность с карточками и разделами. Для магазина инфоблок создают с включённой опцией «Торговый каталог»: тогда к обычным полям элемента (название, картинка, описание) добавляются поля из модуля торгового каталога - цена, валюта, остаток, единица измерения.
Разделы инфоблока это категории каталога, они вложенные на любую глубину. На практике стараюсь не делать больше 3-4 уровней вложенности: глубже пользователю в фильтре неудобно кликать, а хлебные крошки превращаются в длинную ленту ссылок.
Отдельный инфоблок обычно заводят под каждый принципиально разный тип каталога, например «Одежда» и «Электроника» с разным набором свойств, а не сваливают всё в один инфоблок с полусотней полей, половина из которых у конкретного товара пустая. Демонстрационный магазин, который ставится вместе с редакцией CMS, показывает базовую структуру, от неё удобно оттолкнуться, но для боевого проекта я обычно пересобираю набор свойств с нуля под конкретную номенклатуру.
Свойства инфоблока: какие типы бывают и как их выбирать
Свойство в инфоблоке это поле карточки товара сверх стандартных название, цена, картинка. Тип свойства определяет, как оно хранится и как с ним можно работать в фильтре и в выгрузках.
| Тип свойства | Когда использую |
|---|---|
| Список | Цвет, бренд, материал - значения из фиксированного набора, для фильтра подходит лучше всего |
| Число | Вес, объём, диаметр - когда нужна сортировка или диапазон в фильтре |
| Строка | Артикул поставщика, произвольный текст без вариантов выбора |
| Привязка к элементам | Сопутствующие товары, аксессуары к модели, ссылка на другой элемент того же или другого инфоблока |
| Привязка к разделам | Товар относится сразу к нескольким категориям без дублирования карточки |
| Файл | Сертификаты, инструкции, дополнительные изображения |
У каждого свойства есть галка «Использовать для фильтра» - именно она включает поле в компонент умного фильтра, который строит фасетную навигацию по разделу. Для характеристик с несколькими значениями сразу, например «Совместимость с моделями», делаю свойство множественным, а не плодю дубли товара под каждое сочетание.
После массового добавления или изменения свойств фильтр может показывать неактуальные значения, пока не отработает переиндексация каталога в разделе поиска - об этом легко забыть, и тогда клиент видит в фильтре опции, которых по факту уже нет в наличии.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Торговые предложения (SKU): когда одному товару нужно несколько карточек
Торговые предложения - механизм Битрикса для товаров с вариациями: один товар, например «Кроссовки Model X», продаётся в нескольких размерах и цветах, у каждой комбинации своя цена, остаток и штрихкод, а карточка на сайте при этом одна. Технически это второй инфоблок, привязанный к первому: у элемента-предложения есть свойство типа «Привязка к элементам» со значением CML2_LINK, которое ссылается на родительский товар.
Настраивать связку вручную не обязательно - в панели администратора есть мастер создания торговых предложений: он сам заводит второй инфоблок, переносит нужные свойства на уровень предложения и включает для первого инфоблока тип каталога «товары с предложениями».
Нужны торговые предложения не всегда. Для одежды, обуви, техники с разными комплектациями - почти всегда да. Для услуг, инфопродуктов и товаров без вариаций, вроде книги или кружки с одним дизайном, лишний инфоблок только усложняет структуру: там достаточно обычного товара с ценой прямо в карточке.
Привязка свойств к товару и к торговому предложению
Частая ошибка - выбрать не тот уровень для свойства. На уровне товара, родительского элемента, держат то, что общее для всех вариаций: бренд, материал, страну производства, развёрнутое описание. На уровне торгового предложения - то, что как раз и создаёт вариацию: размер, цвет, объём упаковки, штрихкод.
Если положить размер на товар, а не на предложение, умный фильтр отработает некорректно: пользователь выберет размер 42 и увидит карточки, где сорок второй это просто один из вариантов среди прочих, без привязки к конкретной цене и остатку. В настройках компонента каталога есть опция «Показывать цены по торговым предложениям» - без неё на карточке отображается диапазон или цена первого предложения, что визуально нормально, но сбивает логику фильтрации по цене и наличию.
Импорт и синхронизация каталога: 1С, YML, REST API
Обмен с 1С - штатная функциональность Битрикса, а не доработка поверх CMS: мастер обмена в административной панели использует протокол CommerceML и синхронизирует товары, цены, остатки и заказы напрямую из 1С без промежуточных файлов и ручной выгрузки.
Для витрин вроде Яндекс Маркета каталог выгружают в YML - тоже штатный инструмент экспорта, настраивается через сопоставление свойств инфоблока с категориями площадки.
Если источник данных не 1С, а API поставщика или прайс в произвольном формате, синхронизацию собираю на n8n: HTTP-нода забирает прайс по расписанию, следующая нода раскладывает поля по свойствам инфоблока, а методы REST API Битрикса вроде catalog.product.add и catalog.product.update записывают изменения на сайт. Для каталога в несколько тысяч позиций такой воркфлоу в n8n отрабатывает за несколько минут при ежедневном запуске.
Типичные ошибки при проектировании каталога
На проектах, которые приходят ко мне на доработку, чаще всего встречаются одни и те же проблемы:
- Все товары в одном инфоблоке с общим набором из сорока и более свойств, из которых для конкретной категории заполнено 5-7 - фильтр и админка становятся медленными и неудобными
- Размер и цвет вынесены на уровень товара, а не торгового предложения - фильтр по цене и наличию работает некорректно
- Каталог на 100 000+ позиций держат на обычных инфоблоках без вынесения тяжёлых выборок в highload-блоки - админка и страницы разделов тормозят
- После массового добавления свойств забывают запустить переиндексацию - умный фильтр показывает старые значения ещё несколько дней
Если каталог уже разросся и часть из этого пришлось терпеть годами, обычно дешевле не переписывать магазин с нуля, а точечно перестроить структуру свойств и предложений - это как раз то, чем занимается доработка и поддержка 1С-Битрикс, которую я делаю на существующих проектах без миграции на другую CMS.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Сколько стоит настройка каталога в Битриксе под ключ?
Зависит от объёма номенклатуры и от того, нужны ли торговые предложения и обмен с 1С. Точечная доработка структуры каталога на существующем магазине идёт почасово, от 3 000 ₽/час, а интернет-магазин под ключ - от 80 000 ₽.
Нужны ли торговые предложения, если у товара нет вариаций?
Нет, если у товара одна цена и один артикул, торговые предложения только добавят лишний инфоблок и лишнюю сущность в фильтре. Достаточно обычного товара с ценой прямо в карточке.
Как перенести каталог из WooCommerce или Tilda в Битрикс?
Выгружаю товары в CSV или через API исходной площадки, дальше сопоставляю поля с инфоблоком и свойствами и загружаю в Битрикс через REST API или штатный импорт из файла. Для WooCommerce отдельно переношу атрибуты вариаций в торговые предложения, для Tilda - товарные поля из её каталога.
Что делать, если каталог тормозит на большом количестве товаров?
Сначала проверяю индексацию умного фильтра и настройки кеширования компонентов - часто дело именно в них. Если каталог перевалил за несколько десятков тысяч SKU, тяжёлые выборки переношу в highload-блоки - это штатный инструмент Битрикса для больших объёмов данных.