Smart Filter в Битрикс: как невалидные URL раздувают кеш и вредят SEO, и как настроить корректный 404

23 мая 2026

Дмитрий М.

Smart Filter в Битрикс: как невалидные URL раздувают кеш и вредят SEO, и как настроить корректный 404

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

Но именно smart.filter часто становится источником сразу двух серьезных проблем:

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

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

Для SEO это очень плохо. Для производительности — тоже.

Как работает smart filter

В режиме SEF smart.filter формирует URL не через длинную строку параметров, а через ЧПУ. Например:

Копировать код

/catalog/plastikovye-konteynery/brand-is-tara_ru/
/catalog/plastikovye-konteynery/prop_shirina-from-330/
/catalog/lineynye-svetilniki/prop_dlina-from-2250/

По сути каждая часть такого URL интерпретируется как отдельное условие фильтра:

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

После этого Битрикс строит фильтр, применяет его к каталогу и рендерит страницу списка товаров.

Где появляется проблема

Проблема в том, что URL smart.filter можно генерировать практически неограниченно.

Например, можно запросить:

Копировать код

/catalog/plastikovye-konteynery/prop_shirina-from-330/
/catalog/plastikovye-konteynery/prop_shirina-from-331/
/catalog/plastikovye-konteynery/prop_shirina-from-332/

И так далее.

Точно так же можно подставлять:

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

Если проект не проверяет валидность такого URL, он часто ( если не произвести настройки ) все равно отвечает 200 OK и показывает:

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

В результате появляются тысячи страниц:

с одинаковым или почти одинаковым содержимым,
с разными URL,
с индексируемым 200 OK статусом.

Почему это плохо для SEO

С точки зрения поисковых систем это создает сразу несколько рисков:

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

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

Почему это плохо для производительности

У производительности здесь тот же корень проблемы.

Каждый новый URL smart.filter:

инициирует обработку запроса,
строит фильтр,
рендерит страницу списка товаров,
и при определенных настройках может создать отдельный кеш catalog.section.

Поэтому SEO-проблема и проблема роста кеша здесь тесно связаны.

Что именно происходило на проекте

На проекте было видно, что smart.filter:

участвует в генерации большого количества URL каталога,
допускает обращения к несуществующим комбинациям,
в ряде случаев не переводит такие страницы в 404,
оставляет их с 200 OK,
тем самым увеличивает и число индексируемых URL, и число потенциальных кеш-ключей.

Отдельно это усиливалось за счет диапазонных значений from/to, где число вариаций практически бесконечно.

Какое решение выбрали

Мы добавили собственную проверку для URL smart.filter до построения выдачи каталога товаров.

Идея простая:

если URL явно не соответствует допустимому формату smart.filter,
или содержит сегменты, которые не могут быть фильтрующими,
такой запрос не должен отдавать 200 OK,
вместо этого он должен переходить на штатную 404 страницу сайта.

Это решает сразу две задачи:

прекращает размножение мусорных SEO-страниц,
не дает системе обслуживать часть бессмысленных запросов как валидные страницы каталога.

Принцип проверки

Проверка была вынесена в отдельный helper, который анализирует хвост URL внутри каталога.

Логика в упрощенном виде:

Определить, относится ли запрос к каталогу.
Выделить хвост после /catalog/<section>/.
Разбить его на сегменты.
Проверить, что сегменты соответствуют допустимым шаблонам smart filter.
Если нет — вернуть `404`.

Пример идеи:

Копировать код

public static function handleCatalogSmartFilterRequest(): void
{
    $requestPath = self::getRequestPath();

    if (!preg_match('~^/catalog/[^/]+/(.+?)/?$~u', $requestPath, $matches)) {
        return;
    }

    $tail = trim($matches[1], '/');
    if ($tail === '') {
        return;
    }

    $segments = self::splitSmartFilterSegments($tail);

    if (self::hasSmartFilterHints($segments) && !self::validateSmartFilterSegments($segments)) {
        self::processSmartFilter404();
    }
}

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

Копировать код

public static function isSmartFilterProp(string $property): bool
{
    return preg_match('/(?:-is-|^prop_[^\/]+|^price-[^\/]+)/u', $property) > 0;
}

Если URL не проходит проверку, запрос переводится на штатную 404-страницу:

Копировать код

private static function processSmartFilter404(): void
{
    if (!defined('ERROR_404')) {
        define('ERROR_404', 'Y');
    }

    \Bitrix\Iblock\Component\Tools::process404(
        '',
        true,
        true,
        true,
        '/404.php'
    );
    die();
}

Почему было важно использовать штатную 404 Битрикса

Задача была не просто оборвать выполнение, а сделать это корректно с точки зрения сайта:

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

Именно поэтому решение было завязано на стандартный механизм Tools::process404(..., '/404.php'), а не на ручной die() без окружения.

Как это повлияло на SEO

После внедрения проверки проект перестал отдавать 200 OK для большого числа несуществующих URL smart.filter.

Это дало сразу несколько эффектов:

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

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

Как это связано с кешем

Хотя основная цель этой доработки была SEO и контроль валидности URL, она напрямую помогает и производительности.

Каждый URL, который перестает считаться валидным:

больше не участвует в выдаче каталога как обычная страница,
не претендует на создание нового кеша,
не провоцирует разрастание catalog.section.

Поэтому в реальном проекте борьба с невалидными smart filter URL и борьба с ростом кеша — это не две отдельные задачи, а две части одной технической проблемы.