Покупатель зашёл в раздел, где четыреста товаров, и первое, что он видит, — верхние двенадцать позиций. Именно они решают, останется он на странице или уйдёт. И если наверху оказались самые дешёвые аксессуары, товары не в наличии или случайный набор «как легло в базу», вы теряете продажу ещё до того, как человек открыл хоть одну карточку. Сортировка каталога — это не выпадающий список «для галочки», а инструмент, который напрямую двигает конверсию.
В этой статье разберём, какие варианты сортировки действительно нужны интернет-магазину на 1С-Битрикс, что ставить по умолчанию, как считать «популярность», почему наличие важнее выбранного покупателем порядка и как всё это не сломать по скорости. Материал — из практики проектов, где мы наводим порядок в каталоге в связке с аудитом и оптимизацией 1С, откуда в магазин приходят цены и остатки.
Коротко
- Реально нужны 4–5 сортировок: популярность, цена вверх/вниз, новизна, наличие. Остальное — шум.
- По умолчанию ставьте управляемую сортировку (популярность/рекомендуемые), а не «по цене вверх».
- Товары не в наличии опускайте в конец при любой сортировке — иначе покупатель кликает в пустоту.
- Поля сортировки должны быть проиндексированы, а выдача — кэшироваться, иначе большой каталог тормозит.
Зачем вообще думать о сортировке
Сортировка определяет, какие товары покупатель видит первыми, а внимание в каталоге распределяется крайне неравномерно: верхние позиции получают в разы больше кликов, чем нижние. Это значит, что порядок товаров — это, по сути, ваша расстановка приоритетов продаж. Оставить его на волю случая (или «как товары добавлялись в инфоблок») — всё равно что расставить витрину офлайн-магазина вслепую.
Хорошая сортировка решает сразу несколько задач: помогает покупателю быстрее найти подходящее, поднимает вверх ходовые и доступные к покупке товары, снижает число «пустых» кликов по отсутствующим позициям. Плохая — прячет лучшее, выводит вперёд неликвид и заставляет человека вручную перебирать страницы. Разница между ними измеряется в конверсии и среднем чеке.
Какие варианты сортировки реально нужны
Соблазн дать покупателю «побольше вариантов» почти всегда вредит. Длинный список сортировок рассеивает внимание, а половина пунктов дублирует друг друга. На практике исчерпывающий набор для розничного магазина выглядит так.
| Сортировка | Задача покупателя | Нужна почти всем? |
|---|---|---|
| По популярности / рекомендуемые | «Покажи лучшее» — старт по умолчанию | Да |
| Цена по возрастанию | «Ищу подешевле / уложиться в бюджет» | Да |
| Цена по убыванию | «Ищу премиум / топовое» | Да |
| Новинки | «Что появилось недавно» | Часто |
| По наличию | «Только то, что можно купить сейчас» | Часто |
| По рейтингу / отзывам | «Проверенное другими» | Если есть отзывы |
| По скидке | «Где выгода» — на распродажах | Ситуативно |
Всё, что не попало в этот список, стоит проверять на реальную пользу. Сортировка «по названию А–Я» звучит логично, но покупателю почти никогда не нужна — она полезна разве что в справочных каталогах. Правило простое: каждый пункт должен решать понятную задачу и заметно менять выдачу.
Что ставить по умолчанию
Сортировка по умолчанию — самая важная, потому что её видит большинство: значительная часть посетителей вообще не переключает порядок. Поэтому умолчание должно быть управляемым — таким, где наверх поднимаются товары, которые вы хотите продавать: ходовые, в наличии, с хорошей конверсией.
Частая ошибка — поставить умолчанием «по цене по возрастанию». Кажется, что это «честно и удобно», но на деле выдача открывается с самых дешёвых позиций, часто маржинально невыгодных, а иногда — с аксессуаров и расходников вместо основных товаров. Покупатель формирует впечатление о магазине по этой «дешёвой» верхушке. Управляемая сортировка «по популярности» решает эту проблему.
Сортировка по популярности: как её считать
«Популярность» — не магия, а расчётный показатель. Его собирают из сигналов, которые говорят, что товар хорошо продаётся и нравится покупателям. Обычно в формулу входят:
- Продажи за период. Сколько раз товар купили за последние недели — главный сигнал спроса.
- Просмотры и добавления в корзину. Косвенные показатели интереса, полезны для новых товаров без истории продаж.
- Наличие и остаток. Товар без остатка не должен быть «популярным» в верху выдачи.
- Ручной приоритет. Возможность вручную поднять акционные или стратегические позиции.
Ключевой момент: этот показатель нельзя считать «на лету» на каждой загрузке страницы — на большом каталоге это убьёт скорость. Его вычисляют периодически (например, агентом 1С-Битрикс раз в сутки или чаще) и записывают в отдельное индексируемое свойство товара. Дальше сортировка по популярности — это простая и быстрая сортировка по готовому числу.
Наличие как главный модификатор порядка
Какую бы сортировку ни выбрал покупатель, есть правило, которое почти всегда важнее его выбора: товары, которых нет в наличии, не должны быть вверху. Ничто так не бьёт по доверию, как красивая карточка, где вместо кнопки «Купить» — «Нет в наличии».
Разумная стратегия — двухуровневая сортировка: сначала товары делятся на «в наличии» и «нет в наличии», а уже внутри группы «в наличии» применяется выбранный покупателем порядок. Отсутствующие позиции уходят в конец списка (или вовсе скрываются, если это уместно для категории). Так покупатель, выбравший «сначала дешёвые», получает самые дешёвые из доступных, а не самые дешёвые из несуществующих.
Остатки в магазин приходят обменом из учётной системы, поэтому корректность этого механизма упирается в качество интеграции и актуальность данных. Наведение порядка в остатках и их выгрузке мы закрываем услугой автоматизации продаж и склада на 1С — без свежих остатков любая «умная» сортировка врёт.
Как это устроено в 1С-Битрикс технически
В 1С-Битрикс каталог строится на инфоблоках и торговом каталоге, а выдачу товаров формирует компонент catalog.section (внутри bitrix:catalog). Сортировка задаётся параметрами компонента: набор доступных полей и направление. Технически сортировать можно по служебным полям (дата создания, поле SORT), по цене из торгового каталога и по пользовательским свойствам инфоблока — например, по вашему расчётному свойству популярности.
Правильная схема выглядит так: расчётные показатели (популярность, признак наличия для сортировки) хранятся в отдельных свойствах товара, обновляются агентом или обменом, а компонент просто сортирует по готовым индексированным полям. Если у вас нетиповая логика (двухуровневая сортировка «наличие плюс выбор покупателя»), её реализуют доработкой компонента или через D7-запрос к каталогу — про современный подход к данным мы писали в материале о D7 ORM в 1С-Битрикс.
Ручная сортировка и поле SORT
У каждого элемента инфоблока есть поле сортировки SORT (по умолчанию 500). Оно задаёт порядок в сортировке «по умолчанию»: чем меньше число, тем выше товар. Это удобный инструмент для точечных задач:
- Поднять флагман. Поставить ключевому товару SORT 100, чтобы он был вверху категории.
- Опустить неликвид. Задать залежавшимся позициям большое значение, чтобы не мозолили глаза.
- Зафиксировать порядок в подборке. В небольших разделах вручную выстроить логичную последовательность.
Но ручная сортировка не масштабируется. Расставлять SORT для тысяч товаров и поддерживать его актуальным вручную невозможно — на больших каталогах порядок должен считаться автоматически по показателю популярности, а ручное вмешательство остаётся точечным «поверх».
Сортировка и умный фильтр
Сортировка и умный фильтр работают в паре, но отвечают за разное. Умный фильтр (catalog.smart.filter) сужает выборку по характеристикам — цвет, бренд, размер. Сортировка упорядочивает то, что осталось после фильтрации. Порядок операций всегда такой: сначала фильтр отсекает, потом сортировка выстраивает.
Для покупателя это означает, что сортировка должна сохраняться при смене фильтров и не сбрасываться на умолчание при каждом клике. Технически связка «фильтр плюс сортировка» нагружает каталог сильнее всего, поэтому и фасетный индекс фильтра, и поля сортировки должны быть подготовлены. Если после фильтрации остаётся большая выборка, сортировка по непроиндексированному полю резко замедлит страницу.
Производительность и кэш
Сортировка — одна из частых причин медленного каталога. Проблема почти всегда в одном: сортировка идёт по полю, у которого нет индекса в базе, и MySQL вынужден сортировать всю выборку целиком. На каталоге в десятки тысяч товаров это заметные задержки. Что помогает:
- Индексы на полях сортировки. Цена, дата, свойство популярности — по всему, по чему сортируете, должны быть индексы.
- Расчётные показатели заранее. Популярность считается агентом и лежит готовым числом, а не вычисляется в запросе.
- Кэширование выдачи. Комбинации «раздел плюс сортировка плюс страница» кэшируются, чтобы не пересобирать их на каждый заход.
- Композитный сайт и быстрый хостинг. Общая скорость витрины важна не меньше самих запросов.
Скорость каталога держится и на инфраструктуре: настроенное окружение, кэш и правильные ресурсы сервера дают запас под нагрузку. Как выстроить надёжную основу, мы разбирали в статье про хостинг и инфраструктуру на BitrixVM.
Сортировка и маржа: где грань
Сортировку по умолчанию можно и нужно использовать в интересах бизнеса — аккуратно. В показатель «популярности» или «рекомендуемые» допустимо закладывать не только спрос, но и маржинальность, остатки, скорость доставки. Это нормально: вы управляете своей витриной.
Граница проходит по честности явных сортировок. Если покупатель выбрал «сначала дешёвые», он должен получить именно дешёвые, а не то, что выгоднее вам. Подмена явной сортировки скрытым бизнес-приоритетом разрушает доверие: человек быстро замечает, что «дешёвые» на деле не дешёвые, и уходит. Управляйте умолчанием, но не ломайте пользовательский выбор.
Частые ошибки
- Умолчание «по цене вверх». Каталог открывается с самых дешёвых и невыгодных позиций, портя первое впечатление.
- Товары не в наличии вверху. Покупатель кликает, а купить нельзя — прямой удар по конверсии и доверию.
- Слишком много вариантов сортировки. Десяток пунктов, половина из которых дублирует друг друга, рассеивают внимание.
- Популярность считается на лету. Тяжёлый расчёт на каждой загрузке страницы убивает скорость большого каталога.
- Нет индексов на полях сортировки. MySQL сортирует всю выборку целиком, страница тормозит.
- Сортировка сбрасывается при смене фильтра. Покупатель каждый раз заново выбирает порядок и раздражается.
- Подмена явной сортировки маржой. «Дешёвые» на деле не дешёвые — покупатель теряет доверие.
Чек-лист внедрения
- Набор сортировок ограничен. 4–5 вариантов, каждый решает понятную задачу и заметно меняет выдачу.
- Умолчание управляемое. По умолчанию — популярность/рекомендуемые, а не «цена вверх».
- Популярность считается заранее. Показатель обновляется агентом и лежит в индексируемом свойстве.
- Наличие в приоритете. Отсутствующие товары уходят в конец при любой сортировке.
- Поля проиндексированы. По всем полям сортировки есть индексы в базе.
- Выдача кэшируется. Комбинации раздел+сортировка+страница кэшируются.
- Сортировка живёт с фильтром. Выбранный порядок сохраняется при смене фильтров.
- Явные сортировки честные. «Цена вверх» — это буквально цена вверх, без скрытой маржи.
Вывод
Сортировка каталога — это управление вниманием покупателя, а значит, и продажами. Не нужно давать десяток вариантов: четыре-пять понятных сортировок закрывают все реальные сценарии. Главное — сделать управляемое умолчание, всегда опускать вниз товары не в наличии и держать выдачу быстрой за счёт заранее посчитанных показателей и индексов.
За «умной» сортировкой стоят актуальные данные из учётной системы — остатки, продажи, цены. Пока они приходят вовремя и без ошибок, сортировка по популярности и наличию работает на вас. Настройте данные и порядок каталога вместе — и верх выдачи начнёт стабильно продавать, а не отпугивать.
