Фасетные фильтры в каталоге: как спроектировать, чтобы каталог индексировался и не тормозил

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

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

Сколько адресов порождает один каталог

Возьмём типичную категорию: 6 материалов, 8 цветов, 5 размеров и 12 брендов. Если каждая комбинация получает собственный URL, то только в этой категории их 2 880 — 6 × 8 × 5 × 12. При 40 категориях каталог отдаёт поисковым системам 115 200 адресов, при том что товаров в нём, скажем, две тысячи.

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

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

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

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

Что обычно проходит отбор:

• бренд + категория — «резиновые коврики EVA»: у бренда есть спрос и свои характеристики;
• категория + ключевой параметр — материал, тип, назначение, если по нему ищут отдельно;
• категория + диапазон цены, когда бюджет — реальный критерий выбора;
• категория + совместимость для автокаталогов и комплектующих: марка и модель — это отдельный спрос.

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

Стратегия вторая: закрыть обход остального

Всё, что не прошло отбор, должно быть недоступно роботу. Здесь есть тонкость, на которой ломаются чаще всего: noindex и запрет в robots.txt несовместимы. Если адрес закрыт в robots.txt, робот не загружает страницу и не видит мета-тег noindex — страница может остаться в индексе «по внешним данным». Поэтому выбирают одно: либо страница открыта для обхода и отдаёт noindex, либо закрыта в robots.txt и не должна была попадать в индекс ранее.

В той же документации Google отмечено, что canonical и rel="nofollow" — способы заявить предпочтение, но в долгую они менее надёжны, чем управление обходом на уровне URL. Практика это подтверждает: canonical, поставленный на все фасеты сразу, склеивает их в выдаче, но обход не прекращает — робот по-прежнему ходит по ссылкам, пока они есть в разметке.

Рабочая схема для legacy-каталога выглядит так:

1. Посадочные комбинации получают «человеческие» адреса: /katalog/kover/rezinovye/, а не /katalog/?material=12&brand=7.
2. Остальные параметры не попадают в ссылки в HTML — фильтр применяется скриптом, адрес меняется через history API без создания новых ссылок для робота.
3. Шаблоны параметрических адресов, которые всё же остались, закрываются в robots.txt по маске.
4. Отобранные посадочные попадают в sitemap, остальное — нет.

Что должно быть на фасетной посадочной

Страница «резиновые коврики» — это не только отфильтрованная сетка. Минимальный набор: H1 с названием комбинации, 300–600 слов по теме подборки, хлебные крошки, self-canonical, перелинковка с соседними фасетами и родительской категорией, пагинация внутри подборки с корректными rel="next"/"prev" или обычными ссылками. Если текста нет и страница отличается от категории только галочкой — она не нужна в индексе, это тот же дубль.

Отдельно про количество: 20–50 посадочных на каталог — нормальный порядок. 2 000 — это уже не каталог, а генератор URL, и почти всегда такие страницы не приносят трафика. Посмотреть, как это выглядит на практике, можно в портфолио сайтов-каталогов — например, в проекте дистрибьютора Hörmann, где навигация строится вокруг категорий и характеристик, а не вокруг каждой комбинации параметров.

Скорость: где каталог реально тормозит

Фильтры влияют на скорость не «в целом», а через три конкретных места.

Счётчики фасетов. Строка «Найдено 1 248 товаров» и число рядом с каждой галочкой — это COUNT по соединению таблиц. При 15–20 фасетах на странице получается 15–20 тяжёлых запросов, и именно они, а не выборка товаров, съедают время ответа. Лечится кэшем агрегатов: счётчики считаются фоновым процессом и обновляются раз в 5–15 минут, а не на каждый запрос пользователя.

Структура базы. Классическая ошибка — хранить характеристики в текстовом поле карточки и фильтровать по LIKE. Нужна нормализованная связка «товар — атрибут — значение» и составные индексы в порядке убывания селективности: сначала категория, затем самый избирательный фасет. Тогда запрос идёт по индексу, а не по всей таблице.

Выдача и фронтенд. LIMIT с большим OFFSET на глубине каталога, картинки без размеров и ленивой загрузки, десятки скриптов фильтра — всё это видно в Core Web Vitals. Ориентиры по метрикам: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1, причём считается 75-й перцентиль реальных пользователей, а не среднее. Как это измерять и что чинить в первую очередь, разобрано в статье как ускорить сайт.

Ещё один фактор, который часто упускают: версия PHP. На 3 ноября 2026 года поддержка безопасности PHP 8.2 заканчивается 31 декабря 2026 года, у 8.3 — 31 декабря 2027-го, у 8.4 — 31 декабря 2028-го. Каталог, который живёт на 7.4, не только медленнее, но и перестал получать патчи безопасности — это отдельная работа в смете, а не «мелочь хостера».

Сколько это стоит и что входит

В Web-2A разработка сайта-каталога идёт тремя комплектациями: «Стандарт» — 45 000 ₽ (каталог, строка поиска, галерея, наполнение до 20 страниц), «Оптима» — 75 000 ₽ (плюс корзина, индивидуальный дизайн, Метрика, наполнение до 50 страниц), «ТОП» на АТОМ — 95 000 ₽ (плюс поиск по параметрам, сравнение, избранное, первичная SEO-оптимизация, хостинг на 1 год). Проектирование фильтров и поиска по параметрам входит в этап вёрстки и программирования, но объём фасетов и число посадочных лучше зафиксировать в ТЗ — иначе спор о «ещё одном фильтре» всплывёт на приёмке.

Чек-лист перед запуском

• Составлен список посадочных комбинаций, у каждой есть спрос и текст;
• посадочные получили ЧПУ, а не параметры;
• остальные комбинации не порождают ссылок в HTML;
• на каждый адрес — ровно один вариант закрытия: либо noindex, либо robots.txt;
• в sitemap только посадочные и категории;
• счётчики фасетов кэшируются, а не считаются на каждый запрос;
• на индексы в базе проверены EXPLAIN для 3–5 самых тяжёлых запросов;
• LCP и INP измерены на мобильном интернете, а не в офисном Wi-Fi.

Если каталог уже работает и вопрос не в проектировании, а в том, чтобы разобрать существующий клубок URL, начинают с инвентаризации: выгрузка всех адресов из индекса и логов, разметка на «нужные / дубли / мусор», и только потом правки. Порядок работ и стоимость обсуждаем на созвоне — контакты в разделе контакты, телефон +7 (863) 226-56-27, офис в Ростове-на-Дону.