Каталог — это фундамент любого интернет-магазина или B2B-портала на 1С-Битрикс. Можно вложить деньги в дизайн, рекламу и контент-маркетинг, но если клиент не может быстро найти нужный товар среди тысяч позиций, весь остальной бюджет работает вхолостую. Модуль «Каталог» в 1С-Битрикс — один из самых мощных инструментов среди российских и казахстанских CMS, но именно поэтому в нём легко наделать ошибок: слишком много настроек, слишком много вариантов архитектуры инфоблоков, слишком много соблазна сделать «как получится» вместо «как правильно».
В этой статье разберём, как грамотно настроить каталог 1С-Битрикс: от структуры инфоблоков и свойств товаров до умного фильтра и модуля сравнения. Материал рассчитан на владельцев бизнеса и менеджеров, которые уже работают на 1С-Битрикс или выбирают эту платформу для интернет-магазина и хотят понимать, за что они платят подрядчику и какие вопросы задавать на этапе технического задания.
Архитектура каталога: инфоблоки, разделы и элементы
Модуль «Каталог» в 1С-Битрикс построен поверх модуля «Информационные блоки» (инфоблоков) — универсального механизма хранения структурированных данных. Каждый товар — это элемент инфоблока, у которого есть стандартные поля (название, описание, картинка) и произвольные свойства, которые вы задаёте сами: цвет, материал, бренд, вес, гарантия и что угодно ещё, специфичное для вашей ниши.
Первое архитектурное решение, которое нужно принять до начала настройки каталога 1С-Битрикс, — это структура разделов. Разделы инфоблока формируют дерево категорий, которое видит покупатель в меню и хлебных крошках. Здесь есть характерная ошибка, которую допускают компании, переносящие ассортимент «как в 1С»: бухгалтерская иерархия товарных групп почти никогда не совпадает с тем, как товар ищет покупатель. 1С группирует по внутренней логике учёта, а сайт должен группировать по логике спроса — с ориентацией на то, какие категорийные страницы вообще имеют шанс собирать трафик из поиска.
Второе решение — использовать ли для каталога один инфоблок или несколько (например, отдельно «Товары» и «Предложения» для торговых предложений с разными характеристиками — размер, цвет и так далее). Для B2B-компаний с сложной номенклатурой чаще оправдана связка «Товары + Торговые предложения»: карточка товара показывает общую модель, а конкретное предложение отвечает за цену, остаток и характеристики конкретного варианта. Это напрямую влияет на то, как будет работать фильтр и сравнение позже — если структура задана неверно на старте, переделка после запуска обходится дорого и почти всегда требует остановки индексации в поисковых системах на время миграции.
Свойства товаров: основа для фильтрации и сравнения
Умный фильтр и модуль сравнения в 1С-Битрикс работают не «по описанию товара», а строго по свойствам инфоблока. Это значит, что прежде чем настраивать фильтры битрикс, нужно спроектировать список свойств так, чтобы он одновременно решал две задачи: помогал покупателю сузить выбор и давал материал для содержательной таблицы сравнения.
На практике свойства для каталога 1С-Битрикс делятся на несколько типов:
- Список (справочник) — для характеристик с ограниченным набором значений: бренд, материал, тип. Именно этот тип чаще всего используется в умном фильтре, потому что позволяет строить чекбоксы с точным количеством товаров в каждом значении.
- Число — для диапазонных характеристик: вес, мощность, объём. В фильтре они превращаются в слайдер «от — до», что критично для товаров, где покупатель мыслит диапазонами, а не точными значениями.
- Привязка к элементам или разделам — используется реже, но незаменима, если один товар логически связан с другими (аксессуары, совместимые модели).
- Строка и текст — подходят для описательных характеристик, но почти бесполезны для фильтрации: строковые свойства с произвольным текстом умный фильтр обрабатывает плохо, потому что не может сгруппировать значения.
Частая ошибка на этапе настройки каталога 1С-Битрикс — заводить характеристику как строку там, где нужен справочник. Например, свойство «Цвет» со значениями «синий», «Синий», «синий металлик», «Синий металлик» из выгрузки 1С превращается в фильтре в четыре разных пункта вместо одного. Перед подключением умного фильтра стоит провести ревизию значений справочников и нормализовать их — это час работы контент-менеджера, который экономит недели переделок после запуска.
Умный фильтр: настройка и подводные камни
За фильтрацию в 1С-Битрикс отвечает компонент «Умный фильтр» (bitrix:catalog.smart.filter). В отличие от старого фильтра по свойствам, умный фильтр автоматически пересчитывает количество товаров по каждому значению при изменении других параметров и умеет строить ЧПУ-адреса для комбинаций фильтра — а значит, потенциально может приводить трафик из поиска на страницы вида «/catalog/nasosy/filter/brand-is-grundfos/apply/».
Чтобы фильтр работал корректно и не создавал проблем с SEO, нужно настроить несколько вещей:
- Индекс умного фильтра. Bitrix строит отдельные таблицы для быстрого подсчёта количества товаров по фильтру. После любого массового изменения цен, остатков или свойств этот индекс нужно пересчитывать — либо вручную через административную панель, либо по расписанию через агент. Забытый неактуальный индекс — частая причина, когда фильтр показывает «0 товаров» на самом деле доступной позиции.
- Ограничение количества индексируемых комбинаций. Умный фильтр с ЧПУ может сгенерировать тысячи технических URL по комбинациям значений. Без канонических тегов и без разумного ограничения, какие именно свойства участвуют в построении ЧПУ (в настройках компонента это поле «Свойства для детального URL»), поисковые роботы начинают индексировать дубли и размывать бюджет обхода сайта. Практическое правило: в ЧПУ выносить одно-два ключевых свойства (например, бренд), остальные оставлять только в GET-параметрах без индексации.
- Канонические URL и meta robots для страниц фильтра. Страницы с редкими комбинациями фильтров (три и более значения одновременно) стоит закрывать от индексации или проставлять canonical на страницу раздела — иначе объём малополезных страниц-дублей начинает конкурировать с целевыми страницами каталога в глазах Google и Яндекса.
- Скорость отклика фильтра. Умный фильтр использует AJAX-запросы, и на каталогах с десятками тысяч товаров без должной индексации в MySQL/MariaDB (или переезда тяжёлых выборок на Elasticsearch/Sphinx) отклик фильтра может занимать секунды — а это прямой удар по конверсии, потому что покупатель на мобильном устройстве не станет ждать.
Отдельно стоит сказать про порядок отображения значений в фильтре: по умолчанию Bitrix сортирует их по алфавиту или ID, но для реального удобства покупателя стоит настраивать сортировку вручную — например, размеры одежды должны идти по возрастанию (S, M, L, XL), а не в алфавитном порядке (L, M, S, XL).
Модуль сравнения товаров: логика и настройка
Сравнение товаров — компонент, который часто недооценивают на этапе технического задания, а зря: для категорий с высоким чеком и осознанным выбором (техника, оборудование, B2B-товары) страница сравнения нередко даёт более высокую конверсию, чем обычная карточка товара, потому что снимает последнее сомнение покупателя между двумя-тремя вариантами.
В 1С-Битрикс за это отвечает связка модуля «Каталог» и компонента compare.list. Логика следующая: пользователь добавляет товары в список сравнения (хранится в сессии для гостя и в базе для авторизованного пользователя), а на странице сравнения система автоматически строит таблицу, где строки — это свойства товара, отмеченные галочкой «Показывать в сравнении» в настройках свойства инфоблока.
Здесь и кроется главная тонкость настройки: таблица сравнения будет содержательной только если для сравнения отмечены именно те свойства, которые реально влияют на выбор покупателя, а не все подряд. Практика показывает, что оптимальная таблица сравнения — это 6–10 характеристик, а не 30. Когда в сравнение выводится каждое техническое поле из 1С, включая служебные, таблица превращается в нечитаемую простыню, и покупатель закрывает вкладку, не дойдя до решения.
Второй момент — сравнивать товары имеет смысл только внутри одного раздела или, точнее, внутри товаров с одинаковым набором свойств. Если в разделе «Насосы» смешаны погружные и поверхностные насосы с разным набором характеристик, таблица сравнения получится дырявой — часть ячеек будет пустой, что выглядит непрофессионально и подрывает доверие к каталогу.
Из технических нюансов: количество товаров в списке сравнения по умолчанию не ограничено, но с точки зрения UX стоит искусственно ограничивать сравнение 4–5 позициями — иначе таблица перестаёт помещаться на экране, особенно на мобильных устройствах, где через сравнение проходит основная масса трафика.
Обмен с 1С и производительность каталога при росте ассортимента
Для большинства компаний, использующих 1С-Битрикс как витрину, номенклатура не вводится вручную на сайте — она приходит через модуль обмена CommerceML из 1С:Управление торговлей, 1С:УНФ или отраслевой конфигурации. Именно на стыке обмена и каталога чаще всего возникают проблемы, которые не видны на этапе технического задания, но проявляются через полгода-год работы, когда номенклатура вырастает с сотен позиций до нескольких тысяч.
Первая типичная проблема — полная перезаписи каталога при каждом обмене вместо частичного обновления изменённых позиций. Если обмен настроен «в лоб», без разделения на выгрузку цен/остатков и выгрузку карточек товаров, каждый цикл синхронизации пересчитывает индекс умного фильтра целиком, создавая пиковую нагрузку на базу данных. На каталоге в 1 000–2 000 товаров это незаметно, но при 15–20 тысячах позиций обмен может занимать часы и накладываться на рабочее время, когда на сайте одновременно идёт трафик.
Решение — разносить обмен на два независимых потока: быстрый обмен цен и остатков (без пересчёта индекса фильтра на каждой позиции) и более редкий обмен полной карточки товара со свойствами, который запускает пересчёт индекса. Такой подход снижает нагрузку в разы и позволяет обновлять цены хоть каждые 15 минут, не трогая при этом тяжёлые структуры фильтра.
Вторая проблема — рост количества элементов инфоблока напрямую влияет на скорость выборок в умном фильтре, если не настроено кеширование компонентов и композитный режим сайта. На каталогах свыше 10 000 товаров без композитного кеширования страницы категорий начинают формироваться заметно дольше секунды, а поисковые роботы получают более низкий приоритет обхода из-за медленного ответа сервера — что напрямую бьёт по скорости индексации новых карточек товаров. Для таких объёмов имеет смысл заранее закладывать в архитектуру переход тяжёлых текстовых выборок (поиск по каталогу, автодополнение) на внешний индекс — Sphinx или Elasticsearch, — а не рассчитывать, что штатный поиск по MySQL справится с ростом ассортимента в 5–10 раз за пару лет.
Третий момент, который редко фигурирует в техническом задании, но экономит бюджет на хостинг, — правильная индексация полей MySQL, по которым строится фильтр. Умный фильтр по умолчанию создаёт собственные служебные таблицы, но если модуль каталога работает поверх кастомных компонентов или доработок, разработчику важно убедиться, что выборки по этим таблицам используют индексы, а не идут полным сканированием. Это тот случай, когда 30 минут работы DBA на этапе аудита экономят тысячи долларов на апгрейде тарифа хостинга в будущем.
Пример из практики: каталог оптового поставщика
Один из показательных случаев — каталог поставщика промышленного оборудования на 1С-Битрикс с номенклатурой около 8 000 позиций, выгружаемой из 1С:Управление торговлей. На старте у клиента был фильтр «из коробки»: 40 с лишним свойств инфоблока, из которых для фильтрации использовались все, включая артикул поставщика и внутренние технические коды. Индекс умного фильтра не пересчитывался с момента установки — обновление цен и остатков шло раз в сутки через обмен с 1С, но агент пересчёта индекса не был настроен.
Итог для пользователя: фильтр показывал устаревшее количество товаров, часть значений вроде «Диаметр: 50мм» и «Диаметр: 50 мм» (с пробелом и без) фигурировали как разные пункты, а сравнение выводило служебные поля, из-за которых таблица растягивалась на два экрана.
Что было сделано при пересборке каталога: список свойств для фильтра сократили до 7 ключевых характеристик, значения справочников нормализовали через обработку в 1С перед выгрузкой (а не вручную на сайте — это важно, чтобы правки не терялись при следующем обмене), настроили агент пересчёта индекса сразу после завершения обмена с 1С, а не по расписанию «в среднем раз в час». Для сравнения оставили 8 характеристик, реально влияющих на выбор — производительность, напор, мощность, тип питания, гарантию, страну производства, диаметр присоединения и вес. В ЧПУ умного фильтра вынесли только бренд, остальные комбинации оставили с canonical на страницу раздела.
Результат — не только более быстрый и понятный фильтр для покупателя, но и рост числа проиндексированных и содержательных категорийных страниц в Google Search Console вместо роста мусорных URL-комбинаций, которые раньше конкурировали за индексацию с целевыми страницами каталога.
Как выстроить процесс, чтобы каталог не деградировал со временем
Настройка каталога 1С-Битрикс — не разовая задача, а процесс, который требует поддержки при каждом добавлении новой товарной группы или изменении структуры справочников в 1С. Несколько практических правил, которые стоит закрепить в регламенте работы с сайтом:
- Любое новое свойство, которое заводится в 1С и должно попасть в фильтр, сначала описывается как справочник, а не как произвольная строка — так проще на стороне сайта.
- Нормализация значений (регистр, пробелы, единицы измерения) выполняется на стороне учётной системы до выгрузки, а не руками на сайте — иначе правки теряются при следующем обмене.
- Агент пересчёта индекса умного фильтра запускается сразу после завершения обмена с 1С, а не по фиксированному расписанию, которое может не совпадать по времени с реальным обновлением данных.
- Раз в квартал стоит проверять Google Search Console и Яндекс.Вебмастер на предмет резкого роста количества проиндексированных URL каталога — это почти всегда сигнал, что умный фильтр начал генерировать дубли быстрее, чем на них проставляются canonical.
- Список свойств для сравнения пересматривается при добавлении новой товарной категории, а не наследуется автоматически от «похожей» категории — иначе в сравнении появляются нерелевантные поля.
Грамотно настроенный каталог с продуманным фильтром и лаконичным сравнением — это не только про удобство покупателя. Это ещё и один из немногих элементов интернет-магазина, который одновременно работает на конверсию и на SEO: правильные ЧПУ фильтра расширяют семантическое ядро сайта за счёт страниц вида «бренд + категория», а чистая структура свойств снижает нагрузку на сервер и ускоряет отклик каталога при росте трафика.
Частые вопросы
Сколько свойств стоит выводить в умный фильтр?
Оптимально — от 4 до 8 ключевых характеристик на раздел. Больше усложняет UX и увеличивает число технических комбинаций URL, которые нужно контролировать для SEO.
Можно ли использовать умный фильтр без ЧПУ?
Да, фильтр можно настроить полностью на GET-параметрах без ЧПУ — это упрощает контроль индексации, но лишает сайт трафика по запросам вида «купить [бренд] [категория]». Выбор зависит от того, есть ли реальный поисковый спрос по таким комбинациям в вашей нише.
Почему умный фильтр показывает неверное количество товаров?
Чаще всего это устаревший индекс умного фильтра. Индекс нужно пересчитывать после каждого массового обновления цен, остатков или свойств товаров — вручную в административной панели или через настроенный агент.
Сколько товаров можно добавить в сравнение одновременно?
Технически ограничения в 1С-Битрикс нет, но с точки зрения удобства пользователя стоит ограничивать сравнение 4–5 товарами — иначе таблица становится нечитаемой, особенно на мобильных экранах.
Нужно ли отдельно настраивать каталог для мобильной версии сайта?
Отдельный каталог не нужен, но фильтр и таблицу сравнения стоит тестировать именно на мобильных сценариях: раскрывающиеся блоки фильтра, скорость AJAX-запросов и горизонтальная прокрутка таблицы сравнения — три места, где мобильный UX чаще всего страдает при типовой настройке.
Что делать, если каталог уже настроен неправильно и работает несколько лет?
Полная переделка с нуля нужна редко. Обычно достаточно провести аудит: проверить актуальность индекса умного фильтра, найти дублирующиеся значения справочников, оценить количество проиндексированных URL фильтра в Search Console и Яндекс.Вебмастере, сократить список свойств для сравнения до содержательного минимума. Такой аудит и точечные правки почти всегда обходятся дешевле и быстрее, чем миграция на новую структуру инфоблоков, а результат по скорости и точности фильтра ощущается уже в первые недели после внедрения.