Выгрузка из Битрикса в маркетплейсы: где фид ломается чаще всего

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

Материал написан для «1С-Битрикс: Управление сайтом» с модулями «Торговый каталог» и «Интернет-магазин», ядро 22.x-24.x. Названия пунктов меню меняются от версии к версии, поэтому сверяйтесь с документацией своей редакции. Комиссии и правила площадок здесь не разбираются: они меняются часто, актуальные условия смотрите в кабинете продавца.

Четыре способа выгрузки и цена каждого

Фид - это файл, чаще всего XML, который площадка периодически скачивает по ссылке. YML - формат такого файла, придуманный для Яндекс Маркета: корневой элемент yml_catalog, внутри магазин, дерево категорий и список offer.

Дальше речь в основном о первом и третьем способах: на них ломается большая часть выгрузок. API нужен в отдельных случаях, о них в разделе «Когда что выбирать».

Шесть ошибок, из-за которых фид отклоняют

1. Кодировка не совпадает с декларацией

Многие сайты на Битриксе до сих пор живут в windows-1251. Если фид прошёл через конвертацию или кастомный скрипт, первая строка может обещать UTF-8, а байты окажутся в другой кодировке. Площадка увидит ошибку разбора или кракозябры в названиях. Та же группа проблем: неэкранированный амперсанд и управляющие символы в описаниях, скопированных из Word. Проверка делается одной командой, ниже, в пункте 4.

2. Торговые предложения склеены в один offer

У товара с размерами или цветами в каталоге Битрикса есть родительский элемент и торговые предложения. Если в фид уходит только родитель, площадка получает одну позицию без размеров и без остатков по ним. Нужен отдельный offer на каждое торговое предложение с собственным идентификатором и параметром. Для категорий вроде одежды Маркет просит ещё и группировать варианты атрибутом group_id. Фрагмент упрощён, обязательный набор полей зависит от категории: сверяйтесь со справкой Маркета.

<!-- Неверно: один offer на весь товар, размеры потеряны -->
<offer id="1001" available="true">
  <url>https://example.com/catalog/kurtka/</url>
  <price>5990</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <picture>https://example.com/upload/kurtka.jpg</picture>
  <name>Куртка демисезонная</name>
</offer>

<!-- Верно: отдельный offer на каждое торговое предложение -->
<offer id="1001-42" group_id="1001" available="true">
  <url>https://example.com/catalog/kurtka/?size=42</url>
  <price>5990</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <picture>https://example.com/upload/kurtka.jpg</picture>
  <name>Куртка демисезонная</name>
  <param name="Размер">42</param>
</offer>
<offer id="1001-44" group_id="1001" available="true">
  <url>https://example.com/catalog/kurtka/?size=44</url>
  <price>5990</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <picture>https://example.com/upload/kurtka.jpg</picture>
  <name>Куртка демисезонная</name>
  <param name="Размер">44</param>
</offer>

3. Цена и остаток не те, что на витрине

Покупатель видит одно, площадка получает другое. Типичные причины:

• В профиле выбран не тот тип цены: базовая вместо розничной или цены для нужной группы пользователей.
• На витрине работают правила скидок, а в фид уходит цена без них. Сравните цену одного и того же товара на сайте и в файле, а в настройках профиля найдите, как он обращается со скидками.
• Базовая валюта каталога не рубль, и цена пересчитывается по курсу из модуля валют. Устаревший курс даёт неверную цену.
• Остаток считается по всем складам сразу, хотя площадка работает с одним. Резервы под заказы тоже легко потерять.
• Товар с нулевым остатком остаётся в фиде как доступный, и покупатель оформляет заказ, который вы не выполните.

4. Площадка не может скачать файл или картинку

Фид открывается у вас в браузере, но это ничего не доказывает. Робот приходит без cookie и с чужого адреса. Его режут антибот-защита, WAF и базовая авторизация, а длинная цепочка редиректов с http на https и с www на без www заканчивается ошибкой. Отдельная пара: в путях картинок остался относительный адрес вместо полного с доменом, либо файлы слишком тяжёлые или в формате, который площадка не принимает. Требования к изображениям сверяйте в справке самой площадки. Посмотрите на фид глазами робота:

# Скачиваем фид без браузера, следуя редиректам, и печатаем код ответа, тип содержимого и размер
curl -sS -L -o feed.xml -w "%{http_code} %{content_type} %{size_download}\n" "https://example.com/bitrix/catalog_export/yandex.php"

# Проверяем, что XML целый и разбирается без ошибок
xmllint --noout feed.xml

Ожидаете код 200, тип с xml и размер, похожий на правду. Если вместо этого пришла HTML-страница с ошибкой или заглушка защиты, проблема не в профиле. Путь /bitrix/catalog_export/ здесь использован как пример: реальное имя и каталог файла смотрите в настройках вашего профиля. xmllint входит в пакет libxml2 и ловит как битую кодировку, так и неэкранированные символы.

5. Свойства уходят кодами, а не значениями

Бренд, цвет, материал часто хранятся в справочниках. В фиде вместо «Nike» может оказаться идентификатор или XML_ID записи справочника, и площадка отклонит карточку из-за неизвестного бренда. Артикул и штрихкод тоже не появятся сами: их нужно сопоставить в профиле. Отдельный случай - Ozon и Wildberries. У них свои форматы загрузки и обязательные атрибуты по каждой категории, которые стандартный YML-профиль закрыть не может. Какие способы загрузки поддерживает конкретная площадка, смотрите в её справке.

6. Файл генерируется долго и отдаётся недописанным

По умолчанию агенты Битрикса выполняются на хитах, то есть в момент чьего-то захода на сайт. На большом каталоге генерация упирается в max_execution_time PHP и обрывается на середине. Хуже, если робот площадки забирает файл в тот момент, когда он ещё пишется: получает обрезанный XML и ошибку разбора. Тяжёлые профили переводят на запуск по cron, подробности ищите в документации по агентам. Свой генератор должен писать результат во временный файл и переименовывать его в итоговый только после завершения: переименование в пределах одной файловой системы не оставляет читателю полупустой файл.

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

Когда что выбирать

• Только Яндекс Маркет, карточки без сложных наборов обязательных атрибутов: штатный профиль. Это самый дешёвый в поддержке вариант, пока его хватает.
• Несколько площадок и нет своего разработчика: сторонний модуль. Перед покупкой прогоните его фид через xmllint на копии сайта и выясните, как он ведёт себя после обновления ядра.
• Нестандартная логика (отдельная цена под площадку, наценка, свои категории) и есть кому поддерживать код: собственный генератор.
• Остаток критичен, а отмена заказа из-за его отсутствия бьёт по рейтингу или грозит санкциями площадки (условия смотрите в правилах): API. Фид обновляется по расписанию, API позволяет передавать изменения по мере их появления.

Что ломается после запуска

Фид, который работал в день настройки, ломается тихо. Три частых повода:

• Обновление ядра или смена шаблона: пути, права и обработчики событий могут измениться, а профиль продолжит отчитываться об успехе.
• Новое свойство или раздел в каталоге: категория не попала в дерево категорий фида, и товары в ней пропали у площадки.
• Пересоздание товара вместо редактирования: у него новый ID, и для площадки это другой товар без истории продаж. Какой идентификатор уходит в offer id, смотрите в настройках профиля и держите его стабильным.

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

1. Поставьте на cron ежечасную проверку: curl и xmllint из примера выше, с уведомлением на почту при ошибке.
2. Замерьте время генерации фида и его размер. Если время растёт быстрее каталога, пора переводить профиль на cron или писать свой генератор.
3. Раз в неделю сверяйте долю отклонённых позиций в отчёте площадки. Рост этой доли - первый признак, что что-то поменялось на сайте.
4. Если остатки не успевают за продажами, оцените переход на API хотя бы для остатков и цен, оставив фид для описаний.