Умный фильтр в Битрикс генерирует отдельную страницу под каждую комбинацию значений свойств, и без ручной настройки seo страницы умного фильтра битрикс превращаются в мусор для поисковика: тысячи дублей с одинаковым контентом, пустым title и нулевой пользой для трафика. Ниже разбираю, как настраивал ЧПУ и метатеги на реальных каталогах от 500 до 10000+ товаров, что стоит индексировать, а что закрывать сразу, и где типовых настроек компонента не хватает.
Почему умный фильтр без настройки вредит SEO
Компонент bitrix:catalog.smart.filter строит URL из комбинаций значений свойств товара. На каталоге в 3000 позиций с пятью фильтруемыми характеристиками (бренд, цвет, материал, цена, наличие) число теоретических комбинаций легко переваливает за 40000 адресов. Каждый такой URL робот пытается обойти и проиндексировать, хотя контент на 90% страниц отличается только заголовком товарной карточки в списке.
Итог на практике всегда одинаковый: краулинговый бюджет сайта уходит на бесполезные страницы фильтра вместо карточек товаров и статей блога, в индекс Яндекса и Google попадают дубли с почти одинаковым title, а позиции у целевых страниц раздела проседают, потому что поисковик не может выбрать релевантный документ из десятка похожих. На одном проекте с каталогом стройматериалов за два месяца без ограничений в индекс улетело больше 12000 лишних страниц фильтра, и расчистка индекса заняла почти месяц.
ЧПУ для страниц умного фильтра: настройка адресов
ЧПУ фильтра включается через параметры компонента SEF_MODE и SEF_RULE в настройках раздела каталога. Адрес строится по шаблону вида /catalog/santehnika/filter/proizvoditel-grohe/cena-ot-5000-do-15000/apply/, где каждый сегмент после filter соответствует одному примененному свойству. Важно на старте задать человекочитаемые коды значений свойств (символьный код, а не ID), иначе в урле окажутся цифры вроде filter/238-is‑y/, что и для пользователя бессмысленно, и для поисковика выглядит как технический мусор.
Правило для урлов фильтра в компоненте регистрируется автоматически в файле .settings.php модуля, но при ручной правке структуры каталога стоит проверить itemprop правил в urlrewrite.php:
array(
"CONDITION" => "#^/catalog/santehnika/filter/(.*)/#",
"RULE" => "filter=$1",
"ID" => "bitrix:catalog.smart.filter",
"PATH" => "/catalog/santehnika/",
),После смены структуры свойств или разделов кэш ЧПУ фильтра нужно сбрасывать вручную через административный интерфейс, иначе часть новых комбинаций будет отдаваться по старым правилам с 404 или редиректом на корень раздела.
Шаблоны title, description и h1 для страниц фильтра
На вкладке SEO компонента задаются шаблоны BROWSER_TITLE, META_DESCRIPTION и META_KEYWORDS с плейсхолдерами #SMART_FILTER_NAME#, #SECTION_NAME# и #ELEMENT_COUNT#. Без правки шаблон по умолчанию генерирует title вида «Раздел - Каталог», одинаковый для всех комбинаций фильтра, что и создает основную массу дублей в выдаче.
| Шаблон | Результат для страницы «Grohe, до 15000 ₽» | Проблема |
|---|---|---|
| Дефолтный компонента | Сантехника - Интернет-магазин | Одинаковый для всех комбинаций фильтра |
| С плейсхолдерами SEO-вкладки | Сантехника Grohe до 15000 рублей - купить в интернет-магазине | Уникален для комбинации, но требует ручной генерации фраз под падежи |
Когда плейсхолдеров компонента не хватает (например нужно склонять названия брендов или собирать title только для «продающих» комбинаций из 1-2 свойств, а остальные оставлять техническими), обычно переопределяю логику в result_modifier.php шаблона компонента:
if (!empty($arResult["ITEMS"]) && count($arResult["CHAIN"]) <= 2) {
$names = array_map(function ($item) {
return htmlspecialcharsbx($item["NAME"]);
}, $arResult["CHAIN"]);
$APPLICATION->SetTitle("Купить " . implode(", ", $names) . " в интернет-магазине");
}Такие доработки типового компонента под конкретный каталог я обычно веду как отдельную задачу технической доработки сайта, потому что логика фильтров и структура свойств у каждого магазина своя, и универсального решения «из коробки» тут не существует.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Какие комбинации фильтра индексировать, а какие закрывать
Индексировать имеет смысл только страницы с 1, максимум 2 примененными свойствами, у которых стабильно есть спрос по запросам в Яндекс.Wordstat или Google Keyword Planner: бренд, категория товара, иногда цена в популярном диапазоне. Комбинации из 3 и более свойств почти никогда не набирают трафик, зато исправно генерируют дубли.
| Комбинация фильтра | Что делать |
|---|---|
| 1 свойство (бренд или категория) | Индексировать, прописать уникальный title и description |
| 2 свойства с реальным спросом | Индексировать выборочно по данным Wordstat |
| 3+ свойства | noindex, follow через meta robots |
| 0 товаров в результате | SET_STATUS_404 в параметрах компонента, чтобы не плодить пустые страницы |
Закрытие делается на уровне компонента через параметр DISABLE_ROBOTS для «глубоких» комбинаций и через SET_STATUS_404 для пустых выдач. Полностью резать через robots.txt строки фильтра не советую: паттерн /filter/ слишком общий и захватывает вместе с мусорными комбинациями и полезные страницы бренда, которые вы только что вручную прописали в шаблонах.
Канонические адреса и защита от дублей
Для страниц с сортировкой (?sort=price) и пагинацией canonical должен указывать на первую страницу фильтра без GET-параметров - это закрывает основную часть технических дублей. В компоненте это настраивается через CANONICAL_PAGE_URL, но на части проектов проще прописать явную генерацию canonical в шаблоне раздела, отдельно от логики компонента, чтобы не зависеть от обновлений модуля каталога.
Еще одна частая причина дублей - индексация GET-параметров вместо ЧПУ-версии адреса. Если фильтр доступен и по /catalog/santehnika/filter/proizvoditel-grohe/, и по /catalog/santehnika/?PROPERTY_38=238, вторая версия обязана либо редиректить на первую, либо жестко закрываться canonical, иначе в индексе оседают оба варианта с идентичным контентом.
Типичные ошибки при настройке умного фильтра
На практике на разных проектах чаще всего встречаются одни и те же промахи:
- Забыли включить SEF_MODE после переноса каталога на новый шаблон - фильтр откатился на GET-параметры, и Яндекс за пару недель переиндексировал раздел по старым адресам
- Не настроен SET_STATUS_404 - в индексе накапливаются страницы «Ничего не найдено», которые Google считает soft-404 и понижает весь раздел
- Title генерируется одинаковым для комбинаций из разных свойств, потому что шаблон использует только #SECTION_NAME# без #SMART_FILTER_NAME#
- После добавления нового свойства в инфоблок забыли пересобрать ЧПУ фильтра, и новые комбинации отдаются с ошибкой или редиректом на корень раздела
- Сортировка и пагинация индексируются наравне с основной страницей фильтра из-за отсутствия canonical
Проверяю такие вещи через Яндекс.Вебмастер (раздел «Страницы в поиске» и «Исключенные страницы») и краулером вроде Screaming Frog с фильтром по шаблону /filter/ - за один проход обычно видно, сколько дублей title и description реально ушло в индекс, и можно расставить приоритеты, какие комбинации закрывать в первую очередь.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Нужно ли включать ЧПУ для всех страниц фильтра сразу?
Нет, обычно включаю ЧПУ на весь фильтр технически (это настройка компонента, а не выбор отдельных страниц), а индексацию конкретных комбинаций регулирую отдельно через meta robots и SEO-шаблоны. Сначала настраиваю адреса и шаблоны для 5-10 приоритетных брендов или категорий с подтвержденным спросом, остальное держу закрытым до проверки статистики.
Как убрать дубли при сортировке товаров внутри фильтра?
Сортировка добавляет GET-параметр к уже сформированному ЧПУ-адресу фильтра, поэтому такие страницы не должны попадать в индекс отдельно от базовой версии. Прописываю canonical на адрес без параметра сортировки и дополнительно закрываю параметр sort в панели вебмастера Яндекса как незначащий - это ускоряет схлопывание дублей в выдаче на 2-3 недели по сравнению с одним только canonical.
Почему Яндекс индексирует пустые страницы фильтра с 0 товаров?
По умолчанию компонент отдает такие страницы с кодом 200 и текстом «Товары не найдены», и робот воспринимает это как обычный контент. Решается параметром SET_STATUS_404 в настройках bitrix:catalog.smart.filter - страница физически остается доступной для пользователя с сообщением об отсутствии товаров, но отдает статус 404 и не попадает в индекс.
Можно ли использовать умный фильтр без ЧПУ, только с GET-параметрами?
Технически да, и для маленького каталога на 100-200 товаров без серьезной конкуренции в выдаче это иногда оправдано - экономит время на настройку. Но как только каталог растет, GET-версия фильтра генерирует дубли без возможности задать уникальные title и description под комбинацию, и переезд на ЧПУ задним числом всегда сложнее, чем настройка сразу на старте проекта.