Умный фильтр в 1С-Битрикс: настройка свойств и вывода товаров

Умный фильтр в Битрикс - это компонент bitrix:catalog.smart.filter, который перестраивает список доступных значений под остаток в каталоге: если по какой-то характеристике товаров сейчас нет, значение исчезает или становится неактивным, а не просто выдаёт пустую страницу. За последние несколько лет я настраивал умный фильтр битрикс в десятке проектов - от нишевых каталогов на 300-400 позиций до магазинов с торговыми предложениями на 30-40 тысяч SKU, и почти всегда причина жалоб клиента одна и та же: свойства товаров заведены как попало, индекс не пересчитывается после импорта, а на фронте фильтр либо тормозит на 3-4 секунды, либо ломает ЧПУ-урлы.

Чем умный фильтр отличается от обычного списка свойств

Старый компонент bitrix:catalog.filter просто выводит все значения свойства, которые вы ему передали в настройках инфоблока, независимо от того, есть ли под них товары. Пользователь ставит галочку «цвет: бирюзовый» и получает пустую выдачу - с точки зрения конверсии это прямой путь к отказу. Умный фильтр строит список значений на лету, опираясь на индекс каталога: он знает, сколько товаров реально попадает под каждую комбинацию свойств с учётом уже выбранных фильтров и текущего раздела.

На проекте с мебельным каталогом на 12 000 товаров переход со статичного меню свойств на умный фильтр сократил среднее число кликов до карточки товара с 4 до 2 - это данные из «Вебвизора» и карты скроллов за месяц до и после. Но выигрыш заметен только если свойства подготовлены под фильтрацию правильно, иначе индекс просто не с чем строить.

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

Перед тем как выводить фильтр, я всегда прохожу по разделу «Свойства» инфоблока и смотрю на три флажка: «Показывать в фильтре», «Является хешируемой величиной» и «Единица измерения». Если первый флажок не стоит, свойство в компоненте smart.filter вообще не появится, сколько бы кода в шаблоне ни писали.

table:Тип свойства|Как участвует в умном фильтре|Комментарий из практики
Список (перечисление)|Чекбоксы или радиокнопки, недоступные значения скрываются|Основной тип для цвета, бренда, материала
Число|Диапазон «от - до» со шагом|Годится для цены, объёма, мощности, площади
Привязка к элементам справочника / HL-блок|Чекбоксы по значениям справочника|Для длинных списков вроде производителей - если их не десятки, а сотни
Да/Нет (флажок)|Одиночный чекбокс типа «в наличии» или «новинка»|Часто вешают отдельно от CATALOG_AVAILABLE, что дублирует логику
Строка / текст|В смарт-фильтре не участвует|Такие свойства годятся только для карточки товара, не для листинга

Отдельно слежу за свойствами торговых предложений (SKU) - если фильтр должен учитывать размер или цвет конкретного варианта, а не товара-родителя, свойство заводится именно на уровне SKU-инфоблока, и в настройках компонента каталога должна быть включена конвертация цен и остатков по торговым предложениям. Забытый на этом шаге чекбокс - источник половины багов «фильтр показывает размер, а товара в нём нет».

Настройка компонента bitrix:catalog.smart.filter

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

• HIDE_NOT_AVAILABLE - скрывать значения без остатка вместо простого disabled-состояния; на B2C-магазинах включаю почти всегда, на B2B иногда оставляю видимыми под заказ
• SAVE_IN_SESSION - запоминать последние выбранные фильтры пользователя между переходами по разделу
• FILTER_VIEW_MODE - вертикальный список слева или горизонтальная панель сверху, для мобильной версии почти всегда делаю отдельный шаблон с раскрывающимися блоками
• CACHE_TIME - здесь ловушка: слишком большое значение на каталоге с частым обновлением остатков даёт фильтр, который «врёт» о наличии товара

AJAX-режим (AJAX_MODE = Y) обычно включаю сразу - без перезагрузки страницы фильтр ощущается быстрее, но требует, чтобы шаблон компонента каталога тоже был на AJAX, иначе список товаров и панель фильтра начинают жить порознь и пагинация после применения фильтра съезжает.

Индексация и производительность фильтра на больших каталогах

Умный фильтр читает не инфоблок напрямую, а служебные таблицы индекса - b_catalog_iblock_... и таблицы фасетного индекса. Их нужно пересчитывать после массового импорта, изменения цен по прайс-типам или добавления новых свойств. В админке это делается через «Магазин → Настройки → Индекс → Пересчитать индекс», но на каталоге в 30-40 тысяч SKU ручной пересчёт из браузера почти гарантированно упрётся в max_execution_time и оборвётся на середине.

Я переношу переиндексацию на агент, запускаемый по cron, а не жду её от админки:

0 3 * * * php /home/bitrix/www/bitrix/php_cli.php /home/bitrix/www/local/cron/reindex_catalog.php

Внутри скрипта - вызов CCatalogSearch::RebuildForIBlock() или точечный пересчёт по конкретным разделам, если весь каталог гонять каждую ночь избыточно по времени. На одном проекте с 40 000 SKU и полусотней свойств у торговых предложений полная переиндексация занимала около 38 минут - переносить её на ночь было единственным вариантом не положить сайт в рабочие часы.

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

Вывод фильтра по ЧПУ и без потери SEO

При включённом SEF-режиме (SEF_MODE = Y) умный фильтр генерирует урлы вида /catalog/kholodilniki/filter/proizvoditel-samsung/apply/ - для этого в настройках компонента нужно прописать шаблоны SEF_RULE_TEMPLATES под каждый тип отображения страницы (детальная, фильтр, элемент). Без этого шага компонент либо не откроет страницу по прямой ссылке, либо начнёт добавлять GET-параметры поверх ЧПУ, дублируя контент.

Для многозначных фильтров (когда пользователь выбирает несколько цветов или два бренда сразу) урл превращается в длинную цепочку сегментов - такие страницы я обычно закрываю от индексации через noindex в компоненте SEO или в .htaccess по маске, оставляя проиндексированными только «полезные» комбинации: один бренд, одна категория, диапазон цены. Иначе поисковик получает тысячи почти одинаковых страниц с фильтром по двум-трём атрибутам сразу, и это размывает вес основного раздела каталога.

Canonical на страницах с активным фильтром веду на URL раздела без фильтра, если комбинация значений не входит в список «полезных» - эту логику проще всего зашить в шаблон компонента каталога через проверку $arParams["SMART_FILTER_PATH"] и текущих значений в $arrFilter.

Частые ошибки при настройке умного фильтра

Список того, на чём чаще всего спотыкаются при первой настройке:

• Свойство заведено, но флажок «Показывать в фильтре» не отмечен - фильтр просто игнорирует свойство, никаких ошибок в логах при этом нет
• После импорта 5 000 товаров через 1С обмен индекс не пересчитан - фильтр показывает значения по вчерашним остаткам
• На одной странице выведены два экземпляра компонента smart.filter с одинаковым FILTER_NAME - они начинают конфликтовать через сессию и сбрасывать выбор друг друга
• AJAX включён в фильтре, но не включён в компоненте вывода товаров - после применения фильтра пагинация показывает старое количество страниц
• Кэш компонента настроен на «Автокэширование» с большим временем жизни, а цены меняются по расписанию через агент - покупатель видит старую цену в диапазоне фильтра, хотя товар уже подорожал

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

Частые вопросы

Чем умный фильтр отличается от обычного фильтра каталога?

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

Почему умный фильтр не показывает часть значений свойств?

Чаще всего дело в трёх вещах: у свойства не отмечен флажок «Показывать в фильтре» в настройках инфоблока, индекс каталога не пересчитан после последнего импорта, либо свойство заведено на уровне товара-родителя, а фильтровать нужно по значениям конкретного торгового предложения. Проверяю в этом порядке - обычно причина находится за 10-15 минут.

Как ускорить работу умного фильтра на большом каталоге?

Переношу полную переиндексацию с ручного запуска из админки на агент по cron в ночное время, отключаю автокэширование там, где цены меняются часто, и по возможности выношу справочники с сотнями значений (производители, теги) в highload-блоки - они читаются заметно быстрее обычных элементов инфоблока-справочника при построении фасетного индекса.

Можно ли вывести несколько умных фильтров на одной странице?

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