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

Разделите выбор посетителя, адрес и поисковую посадочную

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

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

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

Зафиксируйте значения и правила сочетания фильтров

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

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

Проверяйте эти правила на небольшом управляемом наборе. Для сложного ассортимента полезно сначала вручную выписать ожидаемые ID нескольких сочетаний. Это помогает заметить ошибку данных раньше, чем она превратится в спор о SEO-настройках.

Выберите сочетания, которым нужна отдельная посадочная

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

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

Проверьте отличие от категории и соседних подборок. Человек должен понимать, что изменилось в выборе и условиях, а не видеть одинаковую страницу с другим заголовком. Уточните, кто отвечает за актуальность состава, описания и связей. Массовое создание адресов до такой проверки увеличивает объём работы, но не подтверждает полезность страниц.

Составьте ограниченный реестр: сочетание, основная задача, ожидаемая подборка, выбранный URL, источник обоснования и ответственный. Остальные пользовательские состояния не обязаны автоматически попадать в этот реестр. В учебном примере ниже ни одна комбинация не объявлена принятой SEO-посадочной: спрос не исследован.

Назначьте одной выборке согласованное представление URL

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

В рекомендациях Google по фасетной навигации указаны стандартный разделитель параметров &, постоянный логический порядок фильтров в пути и отсутствие повторяющихся фильтров. Для комбинаций без результатов, бессмысленных сочетаний и несуществующих страниц пагинации рекомендован ответ 404 по исходному адресу.

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

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

Составьте пары «входной адрес → ожидаемое представление». Для каждой пары проверьте, сохраняются ли условия, число найденных записей и состав результата. Не начинайте с глобального редиректа всех адресов с вопросительным знаком.

Согласуйте обход, индексацию и канонизацию

У каждого правила должна быть одна понятная цель. Ограничить количество обходов, исключить страницу из поиска и обозначить предпочтительную версию дубля — разные задачи. Общее назначение файлов и тегов подробно разобрано в материале Sitemap, robots.txt и canonical; для каталога важно связать их с конкретными состояниями.

Google отдельно поясняет условие работы noindex: робот должен получить страницу и прочитать правило. Одновременный запрет её обхода через robots.txt мешает этому. Поэтому последовательность изменений для уже обнаруженных адресов требует отдельного плана.

Документация Google о canonical относится к дублирующимся или сходным страницам. Не назначайте разные предпочтительные адреса в разных сигналах. Подборку с самостоятельным содержанием нельзя считать дублем только из-за общего шаблона каталога.

Для Яндекса есть Clean-param: директива позволяет не учитывать параметры, которые не меняют содержание. В собственном каталоге сначала сравните результат с параметром и без него. Не включайте туда характеристику, которая меняет состав подборки, под видом технической очистки. Это механизм Яндекса, а не универсальная настройка всех поисковиков.

Отличайте пустое сочетание от временного отсутствия товаров

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

Для пустых и бессмысленных сочетаний фасетных URL Google рекомендует 404; не перенаправление на общую страницу ошибки. При этом интерфейс может объяснить выбранные ограничения и предложить сбросить часть условий. Полезное сообщение и корректный HTTP-статус не мешают друг другу.

Временное отсутствие ассортимента требует отдельного решения

Ранее принятая самостоятельная страница и случайная нулевая комбинация — не одно и то же. Если товар закончился, выясните, исчезли ли сами записи, ожидается ли возврат ассортимента и какую полезную информацию страница сохраняет. Не применяйте правило пустых пересечений автоматически ко всем сезонным подборкам.

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

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

Проверьте сортировку вместе с пагинацией

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

В рекомендациях Google по пагинации страницы последовательности получают отдельные URL и собственные canonical. Не следует назначать первую страницу канонической для всех последующих. Для обнаружения переходов предусмотрены обычные ссылки a href; нельзя полагаться только на нажатие кнопки роботом.

Перестановка товаров на второй странице меняет выборку

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

Именно это проверено ниже. В учебном каталоге 15 записей, по пять на страницу. Вторая страница исходного порядка и вторая страница сортировки по названию содержат разные наборы. Поэтому сценарий не удаляет сортировку из её канонического адреса автоматически. Это контроль соответствия содержания, а не рекомендация индексировать все варианты сортировки.

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

Соберите матрицу URL до реализации правил

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

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

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

Рабочий пример: 11 HTTP-проверок на каталоге материалов

Для примера использованы 15 реальных metadata-записей блога: ID, заголовок, описание, категория и путь. Это замороженная выборка, не весь текущий архив. Категория «CMS и архитектура» содержит два материала: tilda-ili-wordpress и wordpress-ili-bitrix.

Исполненный сценарий запускает временный HTTP-сервер только на loopback-адресе, отправляет запросы и сохраняет ответы. Базовый путь — /demo/catalog/. Категория обозначена кодом cms; второй селектор выбирает точный ID через slug. Он нужен для контрольного пересечения, а не предлагается как удобный фильтр покупателя. Размер страницы — пять записей.

Весь пример намеренно закрыт noindex. Значения canonical проверяют контракт адресов; они не означают разрешение индексировать демо. Здесь не проверяются спрос, работа Googlebot, товарные остатки или production-настройки сайта.

В таблице адреса указаны относительно базового пути. «Всего / показано» разделяет полный размер выборки и число карточек текущей страницы.

Для двух CMS-записей сортировка по названию сохраняет весь набор на одной странице. Сценарий указывает предпочтительный адрес без сортировки. Для второй страницы общего набора такое упрощение не применяется: контроль ID подтвердил различие. Одинаковое правило оказалось бы неверным для двух разных состояний.

Скачайте сценарий и замороженный набор, распакуйте архив и выполните python3 filter-example.py. Нужен Python 3; дополнительных пакетов нет. Результат появится в evidence/filter-example-result.json. Сценарий проверяет SHA256 исходного набора, не читает общий checkout и не перезаписывает снимок. Запросы направляются только во временный локальный сервер, который завершает работу после проверки.

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

Меняйте старые правила через список конкретных адресов

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

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

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

Как принять фильтры у подрядчика

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

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

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

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

Что проверять после выпуска

После разрешённого выпуска сравните опубликованные ответы с принятым протоколом, затем наблюдайте обход и индексирование через доступные инструменты поисковых систем. Отдельно учитывайте новые адреса, дубли, пустые сочетания и полезные подборки. Локальный тест HTTP не доказывает, что поисковик уже обработал изменение.

Данные использования помогают уточнять приоритеты, но клики по фильтру, переходы из поиска и заявки — разные события. Не называйте рост количества созданных URL улучшением SEO. Оценивайте изменения в согласованном периоде и с понятными ограничениями данных; универсальный процент «правильных» фильтров из чужого проекта здесь не нужен.

Для обсуждения с Бадрик Лаб подготовьте список граней, несколько адресов, ожидаемые подборки и текущую проблему. По этим материалам можно определить, нужна ли правка данных, нормализация адресов или отдельная работа с посадочными. Архитектуру и поисковые решения обсуждаем в рамках SEO-продвижения: сначала проверяем основания и сценарии, затем согласуем состав работ.