Сортировка товаров в каталоге Битрикс: порядок вывода и выбор покупателя

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

Что определяет порядок вывода товаров по умолчанию

Базовый механизм сортировки в Битриксе завязан на поле SORT у каждого элемента инфоблока. Это обычное числовое поле, и по умолчанию новый товар получает значение 500. Чем меньше число, тем выше товар в списке, если сортировка идёт по возрастанию. На практике это значит: если вы добавили тридцать товаров подряд и никто не менял SORT вручную, все они окажутся с одинаковым весом, и реальный порядок среди них определит уже вторичный критерий, обычно ID или дата создания.Менять SORT можно двумя способами. Первый - зайти в карточку товара в админке и вписать число руками, это удобно для одной-двух позиций. Второй - открыть список товаров инфоблока и включить режим сортировки перетаскиванием: там элементы можно перетащить мышкой, и система сама пересчитает значения SORT с нужным шагом. Для каталога из пары тысяч позиций перетаскиванием, конечно, не наиграешься, поэтому для массовых правок обычно делаю выгрузку в Excel, меняю столбец с весами там и загружаю обратно через мастер импорта.

Параметры компонента, которые задают сортировку каталога

Вывод товаров на сайте почти всегда идёт через компонент bitrix:catalog.section, и у него есть четыре параметра, которые управляют порядком: SORT_BY1, SORT_ORDER1 - первый критерий и направление, SORT_BY2, SORT_ORDER2 - второй критерий, который применяется, если значения первого совпали. В качестве SORT_BY можно указать «sort» (то самое поле SORT), «name», «price», «timestamp_x» (дата изменения), «id», «rand» для случайного порядка на витрине акций, а также «properties_ИМЯ_СВОЙСТВА», если сортировать нужно по кастомному полю вроде рейтинга или количества продаж.

Сортировка по цене и наличию

Частый запрос - «сначала дешёвые, но чтобы в наличии были выше». Здесь пригодится связка двух критериев: первым ставится SORT_BY1 со значением, которое отражает наличие (либо поле остатков, либо булево свойство «Есть в наличии»), а вторым SORT_BY2 со значением цены товара или через свойство, привязанное к цене. Важный нюанс: если в каталоге используются торговые предложения (SKU), цена у элемента-родителя может не совпадать с ценой конкретного предложения, и сортировка «по цене» иногда берёт цену не того уровня, который ожидает клиент. Это всегда стоит проверять на реальных карточках, а не на тестовых трёх товарах.

Составная сортировка для акционных разделов

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

Как поднять товар в выдаче без переворачивания всего каталога

Часто нужно не пересортировать весь раздел, а точечно поднять несколько позиций: новинки, товары с истекающим сроком акции, партнёрские SKU. Решаю это через отдельное свойство инфоблока, например «Приоритет» с числовым или булевым типом, и добавляю его первым критерием сортировки перед основным. Так проще следить за логикой: SORT_BY1 отвечает за приоритет, SORT_BY2 за обычный порядок, и админ, который выставляет приоритет одному товару, не ломает сортировку всего раздела.Ещё один вариант, который использую для крупных каталогов, где приоритеты меняются часто, это отдельный highload-блок с весами товаров и внешним источником данных, например если приоритет считается по продажам за последнюю неделю через связку с 1С или отдельным скриптом на n8n, который раз в сутки пересчитывает веса и обновляет свойство в инфоблоке. Ручного труда становится в разы меньше, а витрина сама подстраивается под то, что реально продаётся.

Сортировка, которую покупатель выбирает сам

Переключатель «по цене», «по популярности», «сначала новинки» над сеткой товаров реализуется поверх того же компонента catalog.section. Механика простая: на странице стоит выпадающий список или набор ссылок с GET-параметром, например ?sort=price_asc, PHP-обработчик перед вызовом компонента считывает $_REQUEST[‘sort’] и в зависимости от значения подставляет нужные SORT_BY1 и SORT_ORDER1 в массив параметров компонента. Никакой магии здесь нет, это обычная развилка на уровне шаблона страницы, а не что-то, чего в платформе не хватает.Из практики: два момента, о которые часто спотыкаются. Первый - при разных значениях sort страница остаётся по факту той же самой, поэтому на неё стоит поставить canonical на базовый URL раздела, иначе поисковик может воспринять варианты сортировки как отдельные страницы с дублирующимся контентом. Второй - выбранная сортировка должна переживать пагинацию и фильтр, то есть параметр sort нужно прокидывать во все ссылки пагинатора и в форму фильтра, иначе после перехода на вторую страницу выбор покупателя слетает и это стабильно раздражает пользователей.

Частые ошибки при настройке сортировки каталога

• Всем новым товарам оставляют одинаковый SORT, и тогда в рамках одного веса порядок определяется побочным критерием вроде ID, а это выглядит как случайный набор карточек
• Сортировку по цене настраивают без учёта торговых предложений, из-за чего каталог с SKU показывает порядок, не соответствующий реальным ценам предложений
• Забывают про canonical и склейку параметров при нескольких вариантах сортировки, отчего в индекс попадают дублирующиеся адреса одной и той же страницы
• Приоритет товаров прописывают прямо в шаблоне компонента жёстким списком ID вместо свойства инфоблока, и любое изменение ассортимента требует правки кода вместо правки данных в админке

Как проверить, что сортировка отработала верно

Перед сдачей задачи всегда смотрю на три вещи. Сначала открываю раздел каталога и вручную сверяю первые пятнадцать-двадцать позиций с ожидаемой логикой: если сортировка «сначала в наличии», среди них не должно быть товаров с нулевым остатком. Дальше проверяю поведение при смене сортировки покупателем: переключаю все варианты из выпадающего списка и смотрю, что URL и разметка меняются согласованно, без потери фильтра. И в конце прогоняю раздел с включённой отладкой компонентов, чтобы увидеть реальный SQL-запрос с ORDER BY, это быстрее всего показывает, если один из параметров SORT_BY тихо не подхватился из-за опечатки в имени свойства.Если сортировка каталога живёт и меняется вместе с ассортиментом, а не настраивается один раз и забывается, такие задачи обычно веду в рамках отдельной технической поддержки каталога: туда попадают и точечные правки приоритетов, и синхронизация весов из внешних источников, и разбор новых жалоб на порядок вывода после очередного обновления модуля каталога.

1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Как изменить сортировку товаров в каталоге Битрикс без программиста

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

Почему товары без указанного SORT показываются вперемешку

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

Можно ли сортировать каталог сразу по нескольким полям

Да, для этого в компоненте catalog.section есть пары параметров SORT_BY1/SORT_ORDER1 и SORT_BY2/SORT_ORDER2. Первая пара задаёт основной критерий, вторая работает как правило для товаров, у которых значения первого критерия совпали, например «сначала по наличию, а внутри одинакового наличия по цене».

Как сделать сортировку, которую покупатель переключает сам

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