Фильтры каталога в SEO и AEO: как разделить параметры на контуры и закрыть мусорные URL

TopG 24 октября 2026 11 минут

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

Проблема: как фасетная навигация расходует краулинговый бюджет и создаёт миллионы пустых URL

Масштаб комбинаторики и краулинговый бюджет

Любой фильтр, добавляющий параметр к адресу, умножает число доступных URL. В официальной документации Google фасетная навигация прямо названа одним из главных источников избыточного обхода (overcrawling) и замедления обнаружения новых страниц (slower discovery). Робот не знает заранее, приносит ли новая комбинация параметров самостоятельную пользу, пока не запросит её у сервера.

Оценим масштаб на условной арифметике. Допустим, в магазине 100 категорий. В каждой — фильтры по 10 брендам, 8 цветам, 6 размерам и 4 вариантам сортировки. Даже при выборе по одному значению каждого признака математическое пространство перестановок исчисляется десятками тысяч URL на категорию. Если система разрешает множественный выбор цветов и не фиксирует порядок параметров в строке запроса (?color=black&size=m и ?size=m&color=black), число формально разных адресов переходит в миллионы.

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

Риск нестабильного остатка и пустых выборок

Отдельный риск — нестабильность товарного остатка. Срез из трёх узких фильтров сегодня может содержать две позиции, завтра — ни одной, а через неделю — одну карточку, полностью совпадающую с соседним подразделом. Если такие адреса открыты для обхода и отдают код 200 OK с надписью «Товаров не найдено», сайт сам предлагает поисковой системе индексировать пустые оболочки.

Почему rel=«canonical» и noindex не решают проблему на уровне обхода

Ресурсы тратятся до чтения HTML

Распространённое решение: оставить все URL фильтров открытыми, но прописать rel=«canonical» на основную категорию или добавить метатег noindex. На небольшом сайте это может долго не вызывать сбоев. На развитом каталоге возникают две системные проблемы.

Во-первых, теги внутри HTML-кода срабатывают уже после того, как робот скачал страницу. В серии материалов Crawling December инженеры Google специально подчеркнули: rel=«canonical» и rel=«nofollow» на внутренних ссылках плохо подходят для долгосрочного сдерживания краулинга фасетных URL, поскольку роботу всё равно приходится тратить ресурсы на запрос и обработку адресов, чтобы увидеть сигналы уровня страницы.

Канонический — подсказка, а не приказ

Во-вторых, rel=«canonical» для поисковика является сильной подсказкой, а не безусловным приказом. Если срез фильтра имеет собственный заголовок, уникальный набор карточек и внутренние ссылки, а канонический адрес указывает на общую категорию с совсем другим составом товаров, сигналы вступают в противоречие. Поисковая система может проигнорировать тег при несовпадении содержимого.

Поэтому задачи нужно разделять по этапам обработки документа:

Управление обходом решает, должен ли робот вообще запрашивать данный класс адресов у сервера.
Консолидация дублей (canonical, склейка параметров) объединяет технически неизбежные варианты одного документа, которые уже доступны роботу.
Индексация посадочных срезов создаёт самостоятельные страницы там, где комбинация характеристик отвечает отдельному поисковому интенту.

Классификация параметров: служебные, динамические и устойчивые атрибуты спроса

До редактирования robots.txt или постановки задачи разработчикам полезно провести ревизию всех параметров, которые генерирует каталог. Предлагаю делить их не по техническому способу реализации в CMS, а по роли в задаче покупателя и устойчивости ассортимента.

Группа 1: Служебные и интерфейсные параметры (никогда не нужны в поиске)

Сюда входят порядок сортировки (sort=price_asc, sort=popular), вид сетки или списка (view=list), количество элементов на странице (limit=48), идентификаторы сессий, валюта отображения и маркетинговые метки. Они меняют порядок или оформление тех же самых товаров, но не создают новой тематической выборки.

Группа 2: Динамические и нестабильные фильтры (нужны пользователю, но вредны для индексации)

Это произвольные диапазоны цены (price_min=1350&price_max=4890), фильтр «только со скидкой», «доставка сегодня к 18:00», а также глубокие пересечения из трёх, четырёх и более характеристик. Покупателю внутри интерфейса они необходимы, но как статические поисковые страницы такие URL несостоятельны: их состав меняется каждый час, а поисковый спрос на точное числовое значение ползунка отсутствует.

Группа 3: Устойчивые атрибуты спроса (кандидаты в индексируемые посадочные страницы)

Это базовые характеристики, которыми люди действительно формулируют запрос: категория + бренд, категория + основной материал, категория + назначение или типоразмер.

Критерии пригодности комбинации фильтров для индексации

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

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

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

Техническая реализация блокировки нецелевых параметров в Google и Яндексе

Когда список нецелевых параметров утверждён, задача — не пустить робота в бесконечный перебор. Google и Яндекс поддерживают разные технические механизмы, поэтому единой строчки в настройках недостаточно.

Инструменты для Google Search

В руководстве по фасетной навигации Google предлагает два основных способа исключить обход ненужных фильтров. Первый — запретить сканирование соответствующих шаблонов URL в файле robots.txt. Второй — передавать состояние клиентских фильтров через фрагмент адреса после символа решётки (#, например /shoes#color=green&size=42), поскольку поисковый робот Google не использует часть адреса после # для обхода отдельных страниц.

Выбирая между этими вариантами, учитывайте архитектуру фронтенда. Если магазин генерирует обычные ссылки

<a href="?sort=price_asc">

в HTML-коде, одного запрета в robots.txt мало для чистоты архитектуры: лучше вообще не выводить такие элементы как индексируемые ссылки

<a href>

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

Инструменты для Яндекса: Clean-param и настройка GET-параметров

В Яндексе помимо стандартного Disallow есть профильный механизм для динамических параметров, не меняющих суть документа, — директива Clean-param в robots.txt. Она указывает роботу Яндекса, какие GET-параметры следует отбрасывать при обходе и приводить адрес к базовому виду. Например, правило

Clean-param: sort&view /catalog/

сообщает роботу, что адреса с сортировкой и переключением вида внутри каталога не являются отдельными страницами. Важно помнить технические ограничения из справки: директива чувствительна к регистру символов, длина строки не должна превышать 500 символов, а робот Google её не поддерживает.

Второй способ в экосистеме Яндекса — интерфейсный раздел «Индексирование → Настройка GET-параметров» в Яндекс Вебмастере. Он показывает параметры, которые робот уже нашёл на сайте, и позволяет отметить в столбце «Учитывать параметр?» значение «Да» или «Нет» (для всего сайта или выбранного префикса пути). Согласно документации, изменения вступают в силу в течение недели, а при противоречии между настройками в интерфейсе Вебмастера и правилами в robots.txt приоритет всегда отдаётся правилу, которое запрещает индексацию URL с параметром.

Практическая рекомендация: фиксировать базовые правила для служебных параметров и сортировок в robots.txt (и через Disallow для шаблонов, которые не должны обходиться ни одной системой, и через Clean-param для Яндекса), потому что файл находится в системе контроля версий вместе с кодом проекта. А таблицу GET-параметров в Яндекс Вебмастере использовать для регулярного аудита — чтобы вовремя замечать новые параметры, которые разработчики или внешние модули добавили на сайт без согласования с SEO-специалистом.

Проектирование индексируемых посадочных страниц и требования AEO/GEO

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

Архитектурные правила URL для открытых срезов

Строгий канонический порядок параметров и сегментов пути. Если в системе разрешено индексировать пересечение двух признаков (например, бренд и материал), они должны формировать ровно один адрес независимо от того, в какой последовательности пользователь нажимал флажки в интерфейсе. Итоговый URL должен строиться по единому алфавитному или приоритетному правилу.
Стандартные разделители. Если индексируемые срезы используют параметры запроса, применяйте стандартный формат ключ=значение и разделитель амперсанд (&). Нестандартные конструкции вроде вложенных скобок, запятых вместо разделителей пар или кодирования нескольких параметров внутри одной нечитаемой строки мешают поисковым системам корректно разбирать структуру адреса.
Никаких фрагментов # для индексируемых выборок. То, что помогает скрыть технические фильтры от обхода, полностью блокирует индексацию полезных посадочных страниц. Если адрес фильтра выглядит как
```
/catalog/laptops#brand=asus
```
, поисковик видит только базовую категорию
```
/catalog/laptops
```
.
Честный код ответа для пустых выборок. Если в индексируемой комбинации закончились все товары и страница не предлагает реального содержимого, Google прямо рекомендует возвращать статус 404 Not Found (или 410 Gone при окончательном выводе линейки), а не отдавать пустую страницу с кодом 200 OK и не перенаправлять все пустые пересечения на главную страницу.

Пагинация внутри индексируемых фильтров

Отдельно проверьте связку фильтров с пагинацией. Если внутри открытого для индексации среза много товаров и список делится на страницы (?page=2, ?page=3), каждая страница последовательности должна иметь собственный URL и собственный канонический адрес на саму себя. Назначать rel=«canonical» со второй и третьей страницы на первую страницу фильтра — ошибка, о которой прямо предупреждает руководство Google по пагинации: это мешает роботу находить и поддерживать в индексе карточки товаров, расположенные глубже первой страницы списка.

Наконец, открытый фильтр не попадёт в индекс, если о нём не знает внутренняя перелинковка. Белый список индексируемых срезов должен быть связан с картой категорий, блоками популярных подборок в разделе и отдельной картой сайта (sitemap.xml), куда попадают только проверенные адреса с ненулевым ассортиментом и кодом 200 OK.

Работа фильтров в AEO и GEO: риски и реальность

В разговоре про оптимизацию под генеративные ответы (GEO) и ответные системы (AEO) — термины, которые в отрасли пока не имеют единого стандарта, — вокруг каталогов часто возникает соблазн: «Давайте сгенерируем десятки тысяч страниц фильтров под каждую длинную фразу, чтобы попадать в ответы ИИ».

Документация Google Search Central по функциям ИИ (AI Overviews и AI Mode) описывает важный механизм: при обработке сложных и многосоставных вопросов система может использовать технику веера запросов (query fan-out), параллельно выполняя серию связанных подзапросов по разным аспектам темы и источникам данных. Это действительно позволяет узкоспециализированным и релевантным страницам попадать в число подтверждающих ссылок. Однако на той же странице и в руководстве по генеративному поиску Google делает жёсткое предупреждение: попытки массово штамповать малоценные или шаблонные страницы специально под вариации подзапросов веера не дают преимущества и несут прямой риск нарушения политики в отношении масштабного спама (scaled content abuse).

Как применить это правило к фильтрам каталога на практике:

Доступность для базового индекса — первичное условие. Для попадания в AI Overviews и AI Mode не существует специальной разметки или отдельных тегов: страница должна быть проиндексирована в основном поиске Google и иметь право на показ со сниппетом. Если ценный продуктовый срез случайно закрыт в robots.txt вместе с мусорными параметрами, он не сможет стать источником и для ответной системы.
Проверяемая фактура вместо шаблонного текста. Портянка сгенерированного текста на три тысячи знаков в подвале страницы фильтра не помогает ни покупателю, ни ответной системе. Полезный срез каталога отличается ясным заголовком, точными характеристиками представленных позиций, актуальным диапазоном цен, наличием и понятными условиями выбора.
Границы бизнес-выводов. Даже если страница подборки или фильтра появилась среди ссылок в ответе ИИ, сам факт присутствия в блоке не равен переходу на сайт, оформленной корзине или оплаченному заказу. Оценивать эффективность открытых срезов нужно по связке поискового спроса, реальных визитов и конверсий, а не только по факту упоминания домена.

Чек-лист приёмки и мониторинга после релиза

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

Контур 1. Проверка правил на тестовом стенде до выкатки

Единственность адреса: выберите два разрешённых фильтра в разном порядке — система должна сформировать идентичный URL.
Разделение ссылок в DOM: убедитесь, что сортировки, переключение вида и выбор из трёх и более фильтров не генерируют открытых ссылок
```
<a href>
```
для поискового робота.
Согласованность robots.txt и настроек Вебмастера: запреты в файле и настройки GET-параметров в Яндексе не должны противоречить друг другу по отношению к целевым разделам.
Коды ответа пустых выборок: проверьте, что индексируемые срезы без товаров отдают 404/410, а не 200 OK с пустым контейнером.
Пагинация: на второй и третьей страницах открытого среза rel=«canonical» указывает на саму себя, а не на первую страницу.
Карта сайта: в sitemap.xml попадают только URL из белого списка с кодом 200 и ненулевым количеством товаров.

Контур 2. Мониторинг в продакшене (первые 2–4 недели)

Динамика краулингового бюджета в Google Search Console (отчёт «Статистика сканирования») и Яндекс Вебмастере — доля запросов к техническим параметрам должна упасть до единиц процентов.
Количество проиндексированных страниц каталога — не должно резко падать за счёт закрытия мусорных URL, но и не должно расти за счёт дублей.
Появление целевых посадочных страниц в выдаче по коммерческим запросам «категория + бренд», «категория + материал» и аналогичным.
Отсутствие ошибок «Soft 404» и «Просканировано, но не проиндексировано» на новых адресах фильтров.
Проверка случайных выборок через инструмент проверки URL в обоих вебмастерах — корректность канонических, наличие в индексе, рендеринг контента.

Грамотно настроенные фильтры каталога в SEO — это не выбор между «открыть всё» и «запретить всё». Задача решается разделением параметров на два контура до того, как робот начнёт обход: пользовательские переключатели отсекаются на входе, а коммерчески значимые срезы проектируются как полноценные индексируемые документы. Официальная документация поисковых систем сверена 24 октября 2026 года. Матрица классификации параметров и регламент приёмки — авторские рекомендации; числовые расчёты комбинаторики и сценарии каталога являются условными примерами, а не данными клиентских проектов.

Поиск