Фильтрация и фасетный поиск в маркетплейсе — это то, где большинство проектов теряют и деньги, и позиции в поиске одновременно. Покупатель не находит нужный товар за 2–3 клика — уходит. Поисковик индексирует тысячи мусорных URL от комбинаций фильтров — трафик падает. В этой статье разберём, как построить фасетную фильтрацию правильно: с нормальной архитектурой, без SEO-катастроф и с реальной пользой для конверсии.
Что такое фасетный поиск и чем он отличается от обычного
Обычный поиск — это строка запроса. Пользователь вводит «кроссовки Nike 42 размер», система ищет по тексту. Фасетный поиск работает иначе: он позволяет последовательно сужать выборку через независимые атрибуты (фасеты) — бренд, размер, цвет, цена, рейтинг, наличие на складе. Каждый фасет — отдельное измерение каталога.
Ключевое отличие: фасеты не исключают друг друга и работают параллельно. Выбрав «Nike» и «42 размер», пользователь видит только пересечение этих множеств — и может добавить ещё фильтр по цвету, не сбрасывая предыдущие. Именно это делает фасетный поиск стандартом для маркетплейсов с каталогами от 500+ позиций.
Архитектура фасетной фильтрации: три подхода
Выбор архитектуры определяет всё: скорость работы, нагрузку на базу и SEO-потенциал.
Реляционная база + индексы
Подходит для каталогов до 50–100 тысяч SKU. Фасеты хранятся как атрибуты товаров в отдельных таблицах, запросы строятся через JOIN с индексированными полями. Плюс — простота реализации. Минус — при росте каталога запросы с 5–7 активными фасетами начинают тормозить: время ответа уходит за 800 мс, что уже критично для UX.
Поисковые движки (Elasticsearch, OpenSearch, Typesense)
Стандарт для средних и крупных маркетплейсов. Движок хранит инвертированные индексы и агрегации, отвечает за 20–80 мс даже на миллионных каталогах. Elasticsearch поддерживает агрегации по фасетам «из коробки» — вы сразу получаете счётчики («Nike (234)», «Adidas (187)») без дополнительных запросов. Typesense — более простая альтернатива для стартапов, легче в администрировании.
Гибридная схема
Основной каталог и транзакции — в PostgreSQL, поиск и фильтрация — в Elasticsearch. Синхронизация через очереди (RabbitMQ, Kafka). Это рабочая схема для большинства коммерческих маркетплейсов: каждый инструмент делает то, для чего создан.
| Подход | Каталог | Время ответа | Сложность |
|---|---|---|---|
| Реляционная БД | до 100k SKU | 200–1500 мс | Низкая |
| Elasticsearch | от 50k SKU | 20–80 мс | Средняя |
| Гибридная | любой | 20–100 мс | Высокая |
SEO и фасетная фильтрация: где всё ломается
Это самая болезненная тема. Неправильно реализованная фильтрация генерирует тысячи дублей страниц — поисковик тратит краулинговый бюджет на мусор, а ценные страницы теряют вес.
Типичные ошибки:
- Все комбинации фильтров доступны для индексации. Каталог из 10 фасетов по 10 значений — это потенциально 10 млрд URL. Даже при реальных данных получаются десятки тысяч дублей.
- Параметры фильтров в GET-строке без управления.
?color=red&size=42&brand=nikeи?brand=nike&size=42&color=red— разные URL, одинаковый контент. - Отсутствие canonical. Без него поисковик сам решает, какую страницу считать главной — и решает неправильно.
- Динамические заголовки H1 и title не оптимизированы. Страница «Кроссовки Nike, размер 42, красный» — готовый лонгтейл-запрос, но большинство платформ генерируют её с шаблонным title.
Правильная стратегия:
- Определите, какие комбинации фасетов имеют поисковый спрос (через Wordstat, Ahrefs). Обычно это 1–2 фасета: бренд + категория, категория + материал.
- Для ценных комбинаций создайте статические страницы с уникальными URL, title, H1 и описанием.
- Все остальные комбинации закройте через
noindexилиcanonicalна родительскую категорию. - Параметры фильтров нормализуйте: сортируйте по алфавиту, используйте одну форму записи.
UX фасетной фильтрации: что реально влияет на конверсию
Техническая корректность — необходимое условие, но не достаточное. Вот что отличает хорошо конвертирующий фильтр от просто работающего.
Счётчики результатов в реальном времени
Показывайте рядом с каждым значением фасета количество товаров, которые останутся после его применения. «Adidas (0)» — пользователь не кликнет и не получит пустую выдачу. Это снижает отказы на 15–25% по данным A/B-тестов крупных e-commerce платформ.
Блокировка недоступных значений
Если при выбранных фасетах комбинация не даёт результатов — значение должно быть неактивным (серым), а не скрытым. Скрытие путает пользователя: он думает, что фильтра нет. Серый вариант говорит: «есть, но не сейчас».
Мобильная реализация
На мобильных устройствах фильтры должны открываться в отдельном drawer (боковая панель или bottom sheet), а не перекрывать выдачу. Кнопка «Применить» — обязательна: пользователь должен сам инициировать обновление, а не ждать перезагрузки после каждого клика.
Сброс и «хлебные крошки» фильтров
Активные фильтры должны быть видны над выдачей в виде тегов с крестиком. Кнопка «Сбросить всё» — рядом. Пользователь, который не понимает, что именно отфильтровано, уходит, а не разбирается.
Производительность: как не положить сервер под нагрузкой
Фасетный поиск — дорогая операция. Несколько практических правил:
- Кешируйте агрегации. Результаты подсчёта фасетов для популярных комбинаций кешируйте в Redis на 5–15 минут. Это снимает 60–80% нагрузки на поисковый движок.
- Ограничьте глубину фасетов. Показывайте топ-10 значений с возможностью «показать ещё». Загружать все 500 брендов при открытии страницы — плохая идея.
- Используйте debounce для диапазонных фильтров. Ползунок цены не должен отправлять запрос при каждом пикселе движения. Задержка 300–500 мс после остановки — стандарт.
- Lazy loading агрегаций. Основную выдачу отдавайте сразу, агрегации для боковой панели — отдельным запросом. Пользователь видит товары быстрее.
Часто задаваемые вопросы
Нужен ли Elasticsearch для маркетплейса с каталогом 10 000 товаров?
Не обязательно. При 10 000 SKU хорошо спроектированная PostgreSQL с правильными индексами справится без проблем. Elasticsearch оправдан, когда каталог превышает 50–100 тысяч позиций, нужен полнотекстовый поиск с учётом морфологии и синонимов, или требуются сложные агрегации по множеству фасетов. Преждевременное усложнение стека — частая ошибка стартапов, которая увеличивает стоимость разработки и поддержки без реальной необходимости.
Как фасетная фильтрация влияет на SEO — она помогает или вредит?
Зависит исключительно от реализации. При грамотной настройке — помогает: страницы популярных комбинаций (например, «женские кроссовки Nike») захватывают лонгтейловый трафик и дают дополнительные точки входа. При неправильной — вредит катастрофически: тысячи дублей съедают краулинговый бюджет, размывают ссылочный вес, и сайт теряет позиции даже по основным запросам. Ключ — чёткое разделение: что индексируем, что закрываем через noindex/canonical.
Сколько фасетов оптимально для маркетплейса?
Зависит от категории, но общее правило: показывайте 4–6 наиболее релевантных фасетов по умолчанию, остальные скрывайте под «Дополнительные фильтры». Исследования Nielsen Norman Group показывают, что более 7 одновременно видимых фасетов перегружают пользователя и снижают вероятность их использования. При этом важна контекстность: в категории «Ноутбуки» приоритетны процессор и RAM, в «Одежде» — размер и цвет.
Итог: что важно не упустить
Фильтрация и фасетный поиск в маркетплейсе — это пересечение трёх дисциплин: backend-архитектуры, SEO и UX. Ошибка в любой из них стоит дорого. Выбирайте стек под реальный масштаб, не переусложняйте на старте. Определите SEO-стратегию до начала разработки — переделывать потом в разы дороже. И тестируйте фильтры на реальных пользователях: то, что кажется очевидным разработчику, часто непонятно покупателю.
Если вы планируете запуск площадки или переработку существующего каталога, посмотрите на разработку маркетплейса под ключ — мы проектируем архитектуру фильтрации с учётом SEO и нагрузки с первого спринта. Обсудить задачу можно по телефону +7 (977) 326-69-09 или через форму на сайте — разберём ваш каталог и предложим конкретное решение.