Как проверить YML-фид: 10 частых ошибок и способы их исправить

29.07.2026 9 минут чтения 8 просмотров

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

В этой статье разберем, как проверить XML-фид спокойно и без лишней магии: сначала убедиться, что документ является корректным XML, затем проверить структуру YML, после этого пройтись по данным офферов и внешним ссылкам. Такой порядок экономит время: пока XML не парсится, обсуждать цены, категории и наличие бессмысленно.

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

Структура YML-фида

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

Базовая логика YML: справочники объявляются отдельно, а предложения ссылаются на них по идентификаторам.

Минимальный фрагмент валидного XML может выглядеть так:

<?xml version="1.0" encoding="UTF-8"?>
<yml_catalog date="2026-07-29 12:00">
  <shop>
    <name>Demo Shop</name>
    <currencies>
      <currency id="RUB" rate="1"/>
    </currencies>
    <categories>
      <category id="10">Кофе</category>
    </categories>
    <offers>
      <offer id="sku-100" available="true">
        <name>Кофе зерновой 1 кг</name>
        <price>1290</price>
        <currencyId>RUB</currencyId>
        <categoryId>10</categoryId>
      </offer>
    </offers>
  </shop>
</yml_catalog>

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

10 частых ошибок YML-фида

1. Невалидный XML

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

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

2. Незакрытые или перепутанные теги

XML строг к вложенности. Нельзя открыть <offer>, затем <name>, а закрыть сначала </offer>. В HTML браузер иногда прощает такие вещи, но YML-парсер не обязан угадывать намерение. Особенно часто ошибка появляется при сборке фида строками: условие добавило начало блока, но не добавило закрывающий тег.

Лучшее исправление простое: генерировать XML через штатный XML-писатель или шаблон, который всегда закрывает блоки симметрично. Если в проекте уже есть общий генератор XML, чините его, а не каждый экспорт отдельно.

3. Неэкранированные символы &, < и >

Названия товаров, бренды и описания часто содержат амперсанд, знаки сравнения и технические обозначения. Для XML это служебные символы. В тексте товара они должны быть экранированы: амперсанд как &, знак меньше как <, знак больше как >. Иначе обычное название вроде "чай & кофе" ломает весь документ.

Важно: не экранируйте один и тот же текст дважды. Двойное экранирование не ломает XML, но портит карточку товара: покупатель увидит служебные последовательности вместо нормального названия.

4. Неверная кодировка

Если в декларации указано UTF-8, файл действительно должен быть в UTF-8. Несовпадение дает странные символы в названиях и может привести к отказу импорта. Ошибка часто всплывает после переноса старого каталога, импорта CSV из Windows-приложения или склейки данных из нескольких источников.

Проверка YML-фида на кодировку должна быть автоматической: генератор пишет UTF-8, HTTP-заголовок не противоречит содержимому, а тестовая выгрузка содержит кириллицу, кавычки, длинное тире и спецсимволы. Так вы ловите не только синтаксис, но и реальный пользовательский текст.

5. Дублирующийся offer id

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

Исправление: выберите один источник истины для идентификатора и проверьте уникальность до генерации XML. Если товарные вариации продаются отдельно, id должен различать вариации. Менять id без необходимости тоже опасно: площадка может воспринять товар как новый и потерять накопленную историю.

6. Ссылки categoryId на несуществующие категории

Каждый categoryId в оффере должен ссылаться на объявленную категорию. Если категория удалена, переименована или выгружается только для части дерева, предложения остаются с висячими ссылками. Такая ошибка может не нарушать XML, но ломает смысл фида.

Проверяйте два набора: список объявленных category id и список использованных categoryId. Разница сразу показывает товары без валидной категории. Для больших каталогов это быстрее и надежнее ручного просмотра.

7. Ошибки цены, валюты и наличия

Цена должна быть числом в ожидаемом формате, валюта должна быть объявлена в блоке currencies, а наличие должно соответствовать реальному статусу продажи. Нулевые цены, отрицательные значения, старая валюта или текст вместо числа часто появляются из-за промо-правил, ручных скидок и ночной синхронизации складов.

Отдельно проверьте, что available не противоречит цене и ссылке на товар. Если товар недоступен на сайте, но во фиде помечен доступным, рекламная система может отправлять пользователя на пустую или закрытую карточку. Это уже не только ошибка YML-фида, но и потеря бюджета.

8. Недоступные URL товаров и изображений

Фид может быть синтаксически идеальным, но бесполезным, если ссылки отдают 404, закрыты robots.txt, требуют авторизацию или ведут через долгую цепочку редиректов. Изображения особенно чувствительны: слишком маленькая картинка, временный CDN-URL или блокировка по user-agent приводят к отклонению карточек.

Проверяйте URL выборочно при малом каталоге и пакетно при большом. Достаточно HEAD или легкого GET-запроса с таймаутом, проверкой статуса, типа контента и финального адреса после редиректов. Не пытайтесь скачать гигабайты изображений во время каждой проверки.

9. Пустые поля, обязательные для конкретной площадки

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

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

10. Слишком большой или долгий фид

Большой каталог ломается не только из-за ошибок данных. Генерация может не успеть до таймаута, сервер может отдать частичный файл, кэш может смешать старые и новые блоки, а площадка может скачать фид в момент перезаписи. Симптом выглядит как случайная XML-ошибка в конце документа.

Решение обычно скучное и правильное: генерировать файл во временное имя, проверять его локально, затем атомарно заменять публичную версию. Для очень больших каталогов добавьте мониторинг размера, времени генерации и количества офферов. Если вчера было 120 000 товаров, а сегодня 4 000, это должно стать сигналом до загрузки в рекламный кабинет.

Пример: сломанный и исправленный XML

Ниже короткий пример, который показывает сразу две типовые проблемы: незакрытый тег и неэкранированный амперсанд в названии.

<offer id="sku-7" available="true">
  <name>Кофе & чай</name>
  <price>850</price>
  <currencyId>RUB</currencyId>

Исправленный вариант закрывает offer и передает амперсанд как текстовое значение:

<offer id="sku-7" available="true">
  <name>Кофе &amp; чай</name>
  <price>850</price>
  <currencyId>RUB</currencyId>
</offer>

Удобный порядок проверки: сначала XML, затем справочники, офферы, ссылки и правила конкретной платформы.

Что проверять автоматически и вручную

Проверка	Автоматически	Вручную
XML-синтаксис и кодировка	Да, при каждой генерации	Только при расследовании
Уникальность offer id и ссылки categoryId	Да, по всему файлу	Нет смысла при большом каталоге
Цены, валюты, наличие	Да, правилами диапазонов	Точечно для спорных товаров
Качество названий и описаний	Частично: пустые и слишком короткие	Да, для важных категорий
Требования площадки	Да, если правила формализованы	Да, после изменения документации

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

Финальный чеклист перед загрузкой

Фид скачивается по тому же URL, который передан площадке, без авторизации и неожиданных редиректов.
XML полностью валиден, кодировка UTF-8 не противоречит содержимому и заголовкам.
Все служебные символы в текстах экранированы, но данные не экранированы дважды.
Все offer id уникальны и стабильны для одного и того же предложения.
Каждый categoryId ссылается на существующую категорию.
Цены положительные, валюты объявлены, наличие соответствует сайту и складу.
URL товаров и изображений доступны внешнему клиенту и отдают корректные статусы.
Поля проверены по требованиям конкретной платформы, а не только по общей схеме YML.
Количество офферов, размер файла и время генерации похожи на нормальные значения.
После исправления ошибок фида запущена повторная проверка, а не только ручная правка одной строки.

Если нужно быстро проверить внешний файл, вставьте ссылку в ФидСторож: сервис выполнит проверку YML-фида, подсветит ошибки YML-фида и поможет понять, как планировать исправление ошибок фида. Проверить фид по URL.

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

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

Вернуться в блог