Сортировка товаров в Битрикс: наличие, цена и приоритет каталога

Сортировка товаров в Битрикс — это управляемое правило порядка выдачи в каталоге. Она задаётся сочетанием поля сортировки у элементов, параметров компонента, который выводит список, и пользовательского выбора на странице. Чтобы получить предсказуемый порядок, сначала согласуют приоритеты (наличие, цена, новизна, ручной вес), отдельно решают, как считать цену у товара с торговыми предложениями, а затем проверяют результат на тестовой копии магазина. Сортировка не меняет состав выдачи: скрытый или отсутствующий товар она не вернёт, но может опустить его ниже в списке. При этом сортировка не фильтрует товары по условиям отбора.

Что решает сортировка товаров в Битрикс и где её границы

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

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

Порядок в Битрикс задаётся на нескольких уровнях, и их важно не путать:

• поле сортировки у элемента каталога и у торгового предложения — это ручной вес, который проставляет контент-менеджер;
• параметры сортировки в компоненте, который выводит список, — здесь задаётся правило по умолчанию для страницы;
• выбор пользователя на странице — когда посетитель сам переключает порядок (например, «сначала дешёвые» или «сначала в наличии»).

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

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

Какие исходные данные и правила согласуют до настройки

Прежде чем что-то менять, соберите входные данные. Без них настройка превращается в перебор вариантов, а результат невозможно проверить.

Что нужно зафиксировать:

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

Правила лучше записать коротким документом, чтобы их можно было проверить. Формулировки вроде «сначала показывать хорошие товары» не работают: непонятно, что считать хорошим и как убедиться, что порядок соответствует задумке. Рабочее правило выглядит так: «в разделе X товары в наличии идут выше отсутствующих; внутри каждой группы — по возрастанию цены; при равной цене — по ручному весу». Такое правило можно проверить на конкретной странице, сверившись с данными.

Отдельно проговорите, что делать с равными значениями. Когда у нескольких товаров совпадает и наличие, и цена, порядок между ними должен быть предсказуемым. Обычно для этого оставляют дополнительный критерий — ручной вес или идентификатор. Без такого критерия порядок равных позиций может «плавать» между обновлениями, и это выглядит как случайная перетасовка каталога.

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

Выбор сценария зависит от того, что для покупателя важнее в конкретном разделе. Ниже — основные варианты и их логика.

Наличие вперёд

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

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

Цена как основной критерий

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

Ручной приоритет каталога

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

Новизна и популярность

Подходит для разделов с частыми поступлениями. Новизна опирается на дату, популярность — на косвенные признаки активности. Оба варианта требуют, чтобы соответствующие данные действительно заполнялись и обновлялись.

Пользовательский выбор

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

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

Порядок настройки и распределение ответственности

Работу удобно вести по шагам, чтобы не потерять договорённости.

1. Согласовать правила сортировки по разделам и записать их. 2. Сделать копию сайта или тестовый стенд — менять порядок сразу на рабочем каталоге рискованно. 3. Проверить, как заполнено поле сортировки у товаров и предложений. 4. Настроить правило по умолчанию в компоненте вывода списка. 5. При необходимости добавить пользовательский выбор порядка. 6. Проверить результат на тестовой копии по чек-листу. 7. Опубликовать изменения и понаблюдать за поведением каталога.

Ответственные распределяются так. Контент-менеджер отвечает за ручной вес и актуальность данных о наличии. Разработчик — за настройку компонента, пользовательский выбор и корректность вывода. Руководитель проекта — за согласование правил и приёмку результата. Если правило меняется, его снова согласуют и проверяют, а не правят «на глаз».

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

Таблица сценариев и ожидаемых результатов

Таблица помогает выбрать сценарий до начала работ. Сравнивайте по критериям: что важно покупателю, что нужно настроить и какие есть ограничения.

Таблица не заменяет согласование: она лишь фиксирует, какой сценарий выбран и почему. Если по строке «Ограничение» есть сомнения, это повод проверить данные до настройки.

Учебный пример: каталог с наличием и торговыми предложениями

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Условная компания «Пример-Техно» ведёт каталог бытовой техники на Битрикс. В разделе «Кофемашины» около 120 товаров, у части из них есть торговые предложения по цвету и комплектации. Учёт количества ведётся, часть позиций периодически отсутствует. Цены заданы в нескольких типах. Покупатели жалуются, что наверх попадают товары, которых нет в наличии.

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

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

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

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

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

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

Проверка должна быть воспроизводимой: один и тот же набор шагов для каждого раздела. Ниже — применимый чек-лист.

• Правило сортировки записано и согласовано по каждому разделу.
• Работы ведутся на копии, а не на рабочем каталоге.
• Поле сортировки у товаров и предложений заполнено осмысленно.
• Для товаров с предложениями определено, по какому предложению считается цена и наличие.
• Порядок проверен на первой, второй и последней странице раздела.
• Отдельно проверен товар с несколькими предложениями, часть которых недоступна.
• Проверены позиции с равными значениями — порядок между ними предсказуем.
• Отсутствующие товары остаются доступными, но ниже.
• Пользовательский выбор порядка (если есть) работает и не сбивает базовое правило.
• Сохранён план возврата к прежним настройкам.
• После публикации порядок перепроверен на рабочем сайте.

Если какой-то пункт не проходит, не стоит публиковать изменения: сначала разберитесь с причиной. Чаще всего проблема в данных, а не в настройке.

Типичные ошибки и ограничения

Ошибки в сортировке почти всегда повторяются. Полезно знать их заранее.

• Правило задано в одном месте, а ожидается на всех уровнях. Компонент, поле сортировки и пользовательский выбор нужно согласовывать вместе.
• Цена у товара с предложениями берётся непоследовательно. На одной странице сравнивается минимальное предложение, на другой — первое по списку, и порядок становится непредсказуемым.
• Ручной вес проставлен давно и не обновляется. Каталог показывает неактуальные позиции наверху.
• Равные значения не разведены дополнительным критерием. Порядок между ними «плавает».
• Наличие в системе не совпадает с реальным. Сортировка по наличию тогда вводит в заблуждение.
• Изменения внесены сразу на рабочем каталоге без копии и плана возврата.

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

Если каталог большой и правила различаются по разделам, поддерживать порядок вручную становится тяжело. В таких случаях помогает продуманная Структура каталога интернет-магазина: чем логичнее разделы, тем проще задать для них отдельные правила. А когда в каталоге много вариантов товара, отдельного внимания требуют торговые предложения Битрикс — именно на них чаще всего ломается правило по цене и наличию.

Что делать дальше

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

Если каталог сложный, с торговыми предложениями и несколькими типами цен, разумно заложить время на проектирование правил и настройку компонентов. Здесь помогает разработка интернет-магазина на Битрикс: чем аккуратнее устроен вывод, тем предсказуемее порядок и тем проще его поддерживать.