Как организовать каталог товаров на Битрикс?

Что нужно определить до наполнения каталога:

• по каким признакам покупатель выбирает товар

• какие категории и подкатегории ему понятны

• что является отдельным товаром, а что — его вариантом

• какие свойства нужны для сравнения и фильтрации

• откуда поступают цены и остатки

• какие данные должны отображаться в карточке

• кто отвечает за обновление каталога

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

В Ameton проектирование каталога начинаем с нескольких реальных задач покупателя. Команда проверяет, как человек найдёт товар, сузит выбор и сравнит варианты. Только после этого структура переносится в 1С‑Битрикс

Каталог нужно строить вокруг выбора покупателя

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

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

Перед проектированием полезно ответить на вопросы:

• С чего покупатель начинает поиск?

• Как он называет нужный товар?

• Какие характеристики исключают неподходящие варианты?

• Нужно ли сравнивать товары между собой?

• Есть ли разные сценарии для розничных и корпоративных клиентов?

• Может ли один товар относиться к нескольким направлениям?

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

Как построить категории и подкатегории

Категории объединяют товары по понятному покупателю признаку. Иерархия должна быть достаточно подробной для навигации, но не настолько глубокой, чтобы путь к товару превращался в последовательность пустых разделов

Хорошая категория отвечает на конкретный запрос и содержит сопоставимые товары. Например, раздел «Насосы» можно разделить по назначению, если именно назначение определяет выбор. Деление по поставщикам будет полезно только тогда, когда покупатели действительно ищут продукцию конкретного производителя

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

Что проверить в структуре разделов:

Один товар можно показывать в нескольких разделах, если это соответствует разным сценариям выбора. При этом на сайте должен сохраняться основной адрес карточки, чтобы не создавать несколько одинаковых страниц

Товар и его варианты нужно разделять

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

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

Как выбрать способ представления:

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

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

Свойства должны быть едиными для одной группы товаров

Свойства используются в карточке, фильтрах, сравнении и обмене данными. Они работают правильно только тогда, когда одинаковая характеристика называется и заполняется одинаково

Значения «нержавеющая сталь», «нерж. сталь» и «стальной нержавеющий» человек может воспринять как одно и то же. Для системы это разные варианты. В результате фильтр разделяет одинаковые товары, а сотрудники не понимают, какое значение использовать при наполнении

Для каждого свойства нужно определить:

• понятное название

• тип значения: число, список, текст или переключатель

• единицу измерения

• допустимые варианты

• обязательность заполнения

• категории, в которых оно используется

• источник данных

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

Если свойство нужно только для внутреннего учёта и не помогает выбрать товар, его необязательно показывать покупателю. Каталог не должен превращать карточку в выгрузку всех полей из 1С

Фильтры должны сокращать выбор

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

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

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

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

В нашей практике набор фильтров согласовываем на примерах реальных запросов. Команда проверяет, сможет ли покупатель получить короткий список подходящих товаров без знания внутренней классификации компании

Что должно быть в карточке товара

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

Что обычно проверяют в карточке товара:

• понятное название и назначение

• изображения или документы

• ключевые характеристики

• доступные варианты товара

• актуальную цену

• наличие или ожидаемый срок поставки

• способы получения

• кнопку заказа, покупки или запроса

• сопутствующие и совместимые позиции

Для товара со сложными характеристиками полезно сначала показать основные параметры, а подробную спецификацию вынести ниже. Если важные данные спрятаны среди десятков второстепенных строк, покупателю сложно сравнить варианты

Цена, остаток и выбранное торговое предложение должны изменяться согласованно. Если пользователь переключил размер или комплектацию, карточка обязана показать данные именно выбранного варианта

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

Цены и остатки должны иметь понятный источник

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

Если основным источником является 1С, сайт получает согласованные цены и остатки через обмен. Если каталог ведётся непосредственно в 1С‑Битрикс, сотрудники должны обновлять данные в административной части или через предусмотренный импорт

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

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

• общий доступный остаток

• наличие по конкретным точкам

• возможность самовывоза

• ожидаемый срок поставки

• статус «под заказ»

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

Как связать каталог с 1С

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

При настройке обмена команда сопоставляет товары по стабильным внешним идентификаторам и определяет, какие поля разрешено обновлять. Из 1С обычно могут поступать товары, варианты, свойства, цены и остатки. Описания, SEO-данные или рекламные материалы при этом можно вести на сайте

Что нужно согласовать перед обменом:

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

Поиск и адреса страниц нужно учитывать заранее

Каталог должен оставаться понятным не только посетителям, но и поисковым системам. Для этого товарам и категориям нужны стабильные адреса, содержательные заголовки и уникальная информация

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

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

При изменении структуры разделов подрядчик должен сохранить рабочие адреса или настроить перенаправления. Иначе покупатели и поисковые системы будут попадать на несуществующие страницы

Как подготовить каталог к дальнейшему развитию

Каталог должен принимать новые товары без постоянного изменения основной структуры. Для этого правила категорий, свойств и вариантов фиксируют до массового наполнения

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

Развитие каталога стоит проверять на нескольких будущих сценариях:

• появление нового бренда

• добавление ещё одного склада

• запуск оптовых цен

• подключение маркетплейса

• появление нового вида товара

• изменение источника данных

1С‑Битрикс позволяет расширять каталог, но каждая новая функция должна использовать единые правила. Несогласованные доработки постепенно создают повторяющиеся свойства, разные способы расчёта наличия и несколько источников одной цены

Ameton рекомендует оформлять правила каталога как отдельный рабочий документ: структура разделов, модель товара, наборы свойств, источники данных и порядок добавления новых позиций

Компетентный разработчик понимает весь путь выбора товара

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

Какие вопросы стоит задать подрядчику:

• Какие сценарии выбора вы изучите до проектирования?

• Как определите границу между товаром и его вариантом?

• Какие свойства попадут в фильтр и сравнение?

• Как будет связан каталог сайта с данными из 1С?

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

Содержательный ответ должен учитывать особенности ассортимента. Для одежды команда разберёт размеры и цвета, для оборудования — характеристики и совместимость, для B2B-каталога — роли покупателей и персональные цены

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

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

Как проверить каталог перед запуском

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

Что нужно проверить перед публикацией:

Отдельно нужно проверить каталог на реальных данных. Демонстрационные товары часто заполнены идеально и не показывают проблем с разными единицами измерения, пропущенными свойствами или неполными изображениями

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

Ameton может начать с анализа ассортимента, структуры 1С и сценариев выбора. Команда подготовит модель каталога, правила свойств и требования к обмену до массового наполнения сайта