Когда клиент с каталогом на 15 000 позиций жалуется, что Яндекс?
Маркет не принимает фид, а прайс-агрегаторы видят только половину товаров — дело почти всегда в стандартной YML-выгрузке 1С-Битрикс. Настройка YML-выгрузки 1С-Битрикс для больших каталогов требует особого подхода. YML (Yandex Market Language) — это XML-формат для передачи данных о товарах. Согласно документации, YML является стандартным форматом для обмена данными с Яндекс.Маркетом. Мы с таким сталкиваемся постоянно: штатный профиль модуля catalog генерирует XML, который подходит только для витрины, но не для внешних площадок.
Задача не в том, чтобы просто включить экспорт. Нужно: настроить фильтрацию по остаткам, правильно формировать названия торговых предложений, выгружать все изображения, добавить теги для скидок и доставки. И сделать так, чтобы файл обновлялся автоматически и оставался валидным. Наша команда с опытом более 7 лет и 150+ проектов на Битрикс решает это под ключ за 1–2 дня.
Настройка YML-выгрузки 1С-Битрикс под ключ
Кастомный профиль генерирует фид в 2-3 раза быстрее стандартного для каталогов 30 000 товаров, при этом решая критические проблемы.
Почему стандартная YML-выгрузка не подходит для больших каталогов?
Стандартный профиль экспорта (Магазин → Настройки → Экспорт каталога) генерирует простой YML, но у него есть несколько критических ограничений:
- Торговые предложения. Если у товара есть SKU (инфоблок торговых предложений), то
создаётся для каждой вариации, а берётся из названия предложения, а не из основного товара. В результате вместо «Кроссовки Nike Air Max» вы получаете «Кроссовки Nike Air Max — Белый, 42». Для Яндекс.Маркета это допустимо, но для ряда агрегаторов — нет. - Множественные фото. Стандартный экспорт берёт только DETAIL_PICTURE. Дополнительные изображения из свойства MORE_PHOTO нужно явно подключать в настройках профиля. Каждое фото — отдельный тег
, и если этого не сделать, фид будет содержать лишь одну картинку на товар. - Фильтрация по остаткам. Нет возможности выгружать только товары с положительным остатком. Выгружаются все активные элементы. Деактивировать товары без остатка — плохая идея (страдает SEO). Единственный выход — дорабатывать профиль.
- Спецсимволы. Символы &, <, > в описаниях ломают XML. Стандартный профиль экранирует их, но если в свойствах инфоблока есть «сырой» HTML — фид может стать невалидным. Проверка через xmllint или онлайн-валидатор YML обязательна.
Как мы настраиваем YML-выгрузку: кастомный профиль
Мы не редактируем /bitrix/modules/catalog/load/yandex_run.php напрямую — изменения сотрутся при обновлении. Вместо этого копируем файл в /bitrix/php_interface/include/catalog_export/, даём новое имя и регистрируем как кастомный профиль.
Типичные доработки:
- Фильтр по остаткам. Добавляем в arFilter условие >CATALOG_QUANTITY => 0. Для мультискладовости используем CCatalogStoreProduct::getQuantity.
- Свой формат
. Формируем название как «Бренд + Модель + Ключевое свойство» вместо стандартного NAME. -
для скидок. Стандартный профиль не выгружает зачёркнутую цену. Подставляем значение из другого типа цены (например, «Розничная до скидки»). -
. Тег с условиями доставки для Яндекс.Маркета. Генерируем на основе настроек модуля «Доставка». - <sales_notes>. Примечание для покупателя (до 50 символов), например, «Минимальная сумма заказа: 1000 руб.».
| Характеристика | Стандартный профиль | Кастомный профиль |
|---|---|---|
| Фильтрация по остатку | Нет | Да |
| Выгрузка дополнительных фото | Только основное | Все из MORE_PHOTO |
| Нет | Да | |
| Нет | Да | |
| Кастомный формат названия | Нет | Да |
| Производительность для 50 000+ товаров | Падает | Оптимизирована (пошаговая генерация) |
Кастомный профиль решает все перечисленные проблемы и обеспечивает валидность фида. По нашим замерам, скорость генерации для каталога в 30 000 товаров увеличивается в 2–3 раза за счёт оптимизации запросов. Экономия от устранения ошибок некорректной выгрузки может составлять до 40 000 руб. в месяц. Стоимость создания кастомного профиля — от 15 000 руб.
Как ускорить генерацию YML для 50 000 товаров?
Для каталогов свыше 50 000 позиций стандартная генерация может длиться 3–5 минут и часто падает по таймауту. Решение — пошаговая генерация с разбивкой на части по N элементов за итерацию. Мы используем агенты Битрикс, которые запускаются каждые 30–60 секунд и обрабатывают по 1000 товаров за шаг. Это позволяет уложиться в max_execution_time и не нагружать сервер.
Cron-задача для фоновой генерации:
*/30 * * * * /usr/bin/php /var/www/bitrix/modules/catalog/load/yandex_run.php PROFILE_ID
Либо через агент в настройках профиля — опция «Периодический экспорт». Интервал — 30–60 минут для большинства магазинов.
Подробнее о поддерживаемых тегах YML
Кастомный профиль может выгружать теги:
Процесс работы
- Аналитика — изучаем текущий каталог, структуру инфоблоков, типы цен, наличие торговых предложений.
- Проектирование — согласовываем список тегов и формат выгрузки с требованиями площадок.
- Реализация — создаём кастомный профиль, добавляем фильтры, теги, настраиваем кэширование тегированное.
- Тестирование — проверяем валидность через xmllint, тестируем на площадках-песочницах.
- Деплой — настраиваем cron/агент, подключаем мониторинг (проверка даты обновления файла).
Сроки
| Этап | Время |
|---|---|
| Базовая настройка стандартного профиля | 30 мин |
| Кастомный профиль с фильтрацией и доп. тегами | 3–5 ч |
| Профиль + cron + мониторинг валидности | 1 день |
Стоимость рассчитывается индивидуально — зависит от сложности каталога (количество инфоблоков, свойств, типов цен).
Что входит в работу
- Полностью настроенный YML-фид с нужными тегами.
- Кастомный профиль экспорта с фильтрацией и форматированием.
- Подключение автоматической генерации (cron/агент).
- Мониторинг валидности и даты обновления.
- Документация по профилю и инструкция для вашего администратора.
- 2 недели поддержки после запуска (исправление ошибок, доработка тегов).
Получите консультацию по настройке YML-выгрузки — оценим ваш проект за один день. Закажите настройку под ключ — сроки от 1 дня.
Экономия на устранении ошибок может быть существенной, а правильная архитектура фида позволяет избежать значительных потерь ежемесячно из-за неконсистентности данных.