Умный фильтр Битрикс: настройка отображения на сайте и матрица фильтров

Умный фильтр Битрикс — это компонент catalog.smart.filter, который строит форму подбора товаров и передаёт выбранные условия в список каталога. Чтобы фильтр работал корректно, нужно настроить свойства, фасетный индекс и ЧПУ. Ниже — порядок действий, матрица фильтров, учебный пример и чек-лист приёмки.

Что решает умный фильтр и где проходят его границы

Компонент подготавливает фильтр для выборки из инфоблока и выводит форму фильтрации элементов. Он относится к модулю «Информационные блоки» и в визуальном редакторе лежит по пути «Контент → Каталог → Умный фильтр». Компонент должен подключаться перед компонентом вывода каталога. Иначе форма появится, но товары фильтроваться не будут.

Границы задачи стоит очертить сразу, чтобы не ждать от инструмента лишнего:

• Фильтр работает только по значениям свойств, а не по смыслу запроса.
• Параметр HIDE_NOT_AVAILABLE скрывает товары с нулевым остатком при включённом количественном учёте.
• Он не создаёт посадочные страницы автоматически. Адреса комбинаций — отдельное решение, и его принимают осознанно.
• Он не гарантирует, что каждая комбинация свойств вообще имеет товары. Пустые сочетания — нормальная ситуация, и к ней нужен понятный сценарий.

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

Какие свойства товаров подходят для фильтра

Отбор свойств — это решение о данных, а не о вёрстке. Ошибка на этом шаге потом дорого стоит: лишнее свойство раздувает форму, а неподходящее по типу ломает фасетный индекс.

Хорошо работают свойства с ограниченным и стабильным набором значений:

• Списки: бренд, цвет, материал, коллекция, сезон.
• Числовые характеристики с понятным диапазоном: диагональ, объём, мощность.
• Цена — отдельный тип, для неё в компоненте есть параметр PRICE_CODE.
• Флаги и признаки: «в наличии», «новинка», «хит», если они заведены как свойство, а не как маркетинговая метка.

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

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

Матрица фильтров: как выбрать комбинации

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

Таблица решений фиксирует тип, роль и решение по каждому свойству для контроля приёмки.

Настройка компонента и отображение на сайте

Основные параметры компонента делятся на три группы: источник данных, внешний вид и адреса.

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

• IBLOCK_TYPE и IBLOCK_ID — тип и конкретный инфоблок, элементы которого фильтруются.
• SECTION_ID или SECTION_CODE — раздел, для которого строится фильтр. Достаточно одного из них.
• FILTER_NAME — имя массива, в который компонент передаёт условия фильтрации. Именно это имя потом использует компонент вывода каталога.
• PREFILTER_NAME — имя массива для дополнительной фильтрации. В префильтре нельзя использовать вызов CIBlockElement::SubQuery.
• HIDE_NOT_AVAILABLE — скрывать или не скрывать недоступные товары.

Внешний вид

• FILTER_VIEW_MODE — вертикальный (VERTICAL) или горизонтальный (HORIZONTAL) вид.
• TEMPLATE_THEME — цветовая схема (например, light, dark, primary).
• DISPLAY_ELEMENT_COUNT — показывать ли количество отобранных элементов во всплывающем блоке.
• POPUP_POSITION — позиция всплывающего блока слева или справа.
• INSTANT_RELOAD — мгновенная фильтрация без перезагрузки страницы.
• SAVE_IN_SESSION — сохранять ли установки фильтра в сессии пользователя.

Шаблоны visual_horizontal и visual_vertical устарели, используйте .default или bootstrap_v4.

Цены и валюта

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

Внешний вид свойств настраивается отдельно от подключения компонента.

Фасетный индекс, скорость и кеширование

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

Практические следствия:

• Чем больше свойств участвует в фильтре и чем больше у них значений, тем объёмнее индекс. Раздутый индекс замедляет выдачу.
• Свойства, которые не должны влиять на фасетный подбор, лучше не включать в фильтр.
• Конвертация валют в умном фильтре работает только при созданном фасетном индексе, поэтому его состояние проверяют после массовых изменений каталога.

Кеширование настраивается параметрами CACHE_TYPE, CACHE_TIME и CACHE_GROUPS. Режим «Авто + Управляемое» обновляет кеш по времени или при изменении данных. Если включено CACHE_GROUPS, при кешировании учитываются права доступа. Для каталогов с частыми обновлениями цен и остатков это влияет на то, насколько свежие данные увидит покупатель.

ЧПУ и адреса комбинаций фильтра

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

Правило строится из шаблонов и обязательно содержит слова-ограничители. В документации приведён пример правила, содержащего идентификатор раздела, слово filter, блок параметров и слово apply. Слова-ограничители можно заменить на другие, но они должны присутствовать.

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

Учебный пример: подбор фильтра для каталога электроники

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Интернет-магазин электроники, около 4000 товаров в одном инфоблоке, есть торговые предложения по цвету и объёму памяти. Свойства: бренд (список, 40 значений), цвет (список, 12 значений), объём памяти (список, 6 значений), диагональ (число), цена (тип цены BASE), наличие (флаг). Задача — дать покупателю подобрать товар за два-три клика и не уронить скорость выдачи.

Действия.

1. Составляем матрицу фильтров. В форму попадают бренд, цвет, объём памяти, диагональ и цена. Служебные метки не выводим. 2. Проверяем, где хранятся цвет и объём памяти — у товара или у предложения. От этого зависит, какие свойства имеет смысл фильтровать. 3. Подключаем компонент перед компонентом вывода каталога, задаём IBLOCK_TYPE, IBLOCK_ID, FILTER_NAME, PRICE_CODE. 4. Включаем HIDE_NOT_AVAILABLE, чтобы не показывать позиции, которые нельзя купить. 5. Настраиваем отображение свойств: порядок, вид, показ количества. 6. Включаем ЧПУ и задаём правило адреса. 7. Проверяем фасетный индекс после загрузки каталога.

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

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

Как проверить результат и принять работу

Приёмка проверяет сценарии, а не факт появления формы.

• Компонент подключён перед компонентом вывода каталога, список действительно фильтруется.
• В форму попадают только свойства из согласованной матрицы фильтров.
• После выбора одного условия значения остальных сокращаются до доступных в выборке.
• Счётчик отобранных элементов совпадает с фактическим числом товаров в списке.
• Недоступные товары скрываются в соответствии с настройкой HIDE_NOT_AVAILABLE.
• Цены отображаются в нужной валюте, конвертация работает при созданном фасетном индексе.
• Адреса с выбранными условиями формируются по заданному правилу ЧПУ.
• Сброс фильтра возвращает исходный список без остаточных условий.
• Кеш обновляется после изменения цен и остатков в разумный срок.
• Решение по индексированию комбинаций зафиксировано и согласовано.

Типичные ошибки и ограничения

• Компонент стоит не перед выводом каталога. Форма есть, фильтрации нет.
• В фильтр включили свойство со свободным текстом. Список значений разрастается, покупатель теряется.
• Забыли про фасетный индекс после массовой загрузки каталога. Значения и счётчики ведут себя непредсказуемо, конвертация валют не работает.
• Открыли для индексирования все комбинации подряд. Получили множество почти одинаковых адресов.
• Использовали неподдерживаемый шаблон visual_horizontal или visual_vertical и удивляются расхождениям в отображении.
• Пытались применить вызов CIBlockElement::SubQuery в префильтре, хотя документация это запрещает.
• Не учли, что часть свойств хранится у торговых предложений, а не у товара.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по умному фильтру, нужен не «сайт в целом», а конкретный набор данных:

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

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