YML-фид для Яндекс Директа: требования, частые ошибки и как проверить файл перед загрузкой

YML открывается в браузере, XML-парсер не сообщает об ошибке, товары внутри есть — но Яндекс Директ всё равно отклоняет файл или использует только часть ассортимента. Это не противоречие. Браузер, XML-парсер и рекламная площадка проверяют разные свойства одного документа.

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

Ниже — практический разбор именно для Яндекс Директа: из чего состоит файл, где заканчиваются общие правила XML, какие ошибки чаще всего мешают загрузке и как проверить документ до отправки на площадку.

1. Что такое YML-фид в Яндекс Директе

Фид передаёт Директу структурированные сведения о товарах или услугах. По официальной справке об управлении фидами, площадка анализирует содержимое и использует предложения при создании товарных объявлений, объявлений для страниц каталога в Единой перфоманс-кампании и товарных кампаний. То есть файл не просто хранится: из его полей должны получиться пригодные рекламные объекты.

В YML отдельный товар описывает элемент <offer>. Директ читает его идентификатор, тип, категорию, ссылку, название либо связку производителя и модели, цену, изображения и другие поддерживаемые данные. Требования зависят от типа предложения и места показа: поле может быть рекомендованным в одном сценарии и необходимым в другом.

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

Базовое устройство формата разобрано отдельно в статье «YML-фид: что это такое, как создать и проверить». Здесь сосредоточимся на требованиях Директа и последовательности диагностики.

2. Из чего состоит YML-фид

Компактная схема товарного YML выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<yml_catalog date="2026-08-15 12:30">
  <shop>
    <name>Магазин</name>
    <currencies>
      <currency id="RUB" rate="1"/>
    </currencies>
    <categories>
      <category id="10">Кофемашины</category>
    </categories>
    <offers>
      <offer id="sku-123" available="true">
        <name>Кофемашина Barista Mini</name>
        <url>https://shop.example/catalog/barista-mini</url>
        <price>34990</price>
        <currencyId>RUB</currencyId>
        <categoryId>10</categoryId>
        <picture>https://shop.example/images/barista-mini.jpg</picture>
      </offer>
    </offers>
  </shop>
</yml_catalog>

Корень <yml_catalog> содержит дату генерации. Внутри <shop> сначала объявлены справочники валют и категорий, затем список предложений. Оффер ссылается на справочники через currencyId и categoryId. Если ссылка указывает на несуществующую запись, XML остаётся читаемым, но каталог теряет связность.

Требования Директа к YML задают для атрибута date формат YYYY-MM-DD hh:mm. Валюты и категории должны располагаться до блока offers. Порядок элементов внутри предложения также лучше сохранять таким, как он описан в документации: это упрощает сравнение файла со справкой и диагностику.

3. Почему правильный XML может быть неправильным фидом

Уровень	Что проверяется	Пример проблемы
XML	Теги, вложенность, сущности, кодировка, один корень	Неэкранированный & ломает чтение документа
YML	Расположение блоков, справочники и связи предложений	categoryId отсутствует в categories
Яндекс Директ	Тип оффера и поля для рекламного сценария	У vendor.model нет vendor или model

Согласно странице «Валидация файла», при чтении Директ проверяет наличие обязательных элементов, правильность их названий и отсутствие повторов там, где элемент допустим только один раз. Нарушение на уровне файла приводит к отклонению.

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

4. Частые ошибки YML-фида для Директа

Нет уникального offer id

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

Ошибка

<offer available="true">...</offer>

Исправление

<offer id="sku-123" available="true">...</offer>

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

Тип оффера не совпадает с набором полей

Если атрибут type не передан, Директ считает предложение упрощённым и ожидает <name>. Для type="vendor.model" обязательны <vendor> и <model>. Нельзя объявить один тип и оставить структуру другого.

Ошибка

<offer id="sku-124" type="vendor.model">
  <name>Кофемашина Barista Pro</name>
</offer>

Исправление

<offer id="sku-124" type="vendor.model">
  <vendor>Barista</vendor>
  <model>Pro</model>
</offer>

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

Категория не объявлена или имеет неверный ID

categoryId должен ссылаться на категорию из блока categories. В требованиях Директа указано, что идентификатор категории — положительное целое число длиной не более 18 символов, а одному предложению назначают одну категорию.

Ошибка

<categories>
  <category id="10">Кофемашины</category>
</categories>
...
<categoryId>99</categoryId>

Исправление

<categoryId>10</categoryId>

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

Цена записана как текст для человека

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

Ошибка

<price>34 990,00 ₽</price>

Исправление

<price>34990.00</price>

Форматируйте значение специально для машинного экспорта. Визуальное представление с пробелами и валютой должно формироваться уже на сайте, а не попадать в числовое поле фида.

Ссылка содержит неэкранированный амперсанд

В XML символ & начинает сущность, поэтому параметры URL нужно экранировать. Иначе документ может оборваться именно на ссылке, хотя сама страница товара открывается в браузере.

Ошибка

<url>https://shop.example/product?id=123&color=blue</url>

Исправление

<url>https://shop.example/product?id=123&amp;color=blue</url>

Для Директа ссылка должна использовать HTTP или HTTPS, соответствовать RFC 3986, не содержать пробелы и укладываться в лимит 2048 символов. Подробный разбор незакрытых тегов, сущностей и кодировки есть в статье об ошибках XML в YML-фиде.

Изображение недоступно роботу

Ссылка из picture может работать для владельца сайта, но возвращать роботу 403, редирект на авторизацию, HTML-заглушку или слишком медленный ответ. Директ принимает изображения по HTTP/HTTPS; в справке перечислены допустимые форматы и ограничения, включая минимальный размер 450 пикселей по каждой стороне и максимальный вес 10 МБ.

Проверяйте не только расширение файла, но и фактический HTTP-ответ, Content-Type, цепочку редиректов и доступ без cookie. Сетевые причины подробно разобраны в материале «YML-фид не загружается».

Дата генерации отсутствует или записана в другом формате

Для YML-фида Директа атрибут date у yml_catalog обязателен и должен иметь вид 2026-08-15 12:30. ISO-строка с буквой T, секундной частью или часовым поясом может быть правильной для другого API, но не соответствовать описанному формату Директа.

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

5. Можно ли использовать один YML для Маркета и Директа

Обе системы работают с YML, но «один формат» не означает «полностью одинаковый контракт». У сервисов разные сценарии, обязательность полей, ограничения и темп изменения документации. Например, справка Директа описывает дату каталога как YYYY-MM-DD hh:mm, а актуальная инструкция Маркета по обновлению каталога требует сверяться с правилами автоматической загрузки и форматом конкретной выгрузки.

Один файл допустим, если он одновременно проходит актуальные требования обеих площадок. Проверять это нужно как пересечение двух контрактов: каждый обязательный элемент присутствует, значения подходят обоим получателям, а URL доступен обоим роботам. Сам факт успешной загрузки в Маркет ничего не доказывает про Директ — и наоборот.

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

6. Почему Директ принимает не все товары

Если файл принят, сравните число элементов offer с количеством предложений, пригодных для выбранного сценария. Не считайте каждый XML-элемент автоматически готовым товаром. Оффер может быть проигнорирован, когда у него нет уникального ID, отсутствует name в упрощённом типе, не заполнены vendor и model в vendor.model, неверна категория или не хватает данных, обязательных для нужного места показа.

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

Проверяйте также бизнес-фильтры генератора: остаток, статус публикации, цену, регион, исключённые категории. Иногда «пропажа» произошла до создания XML, и площадка вообще не получала товар. Методика сравнения этапов описана в статье о товарах, которые не попадают на площадку.

7. Как проверить YML перед загрузкой самостоятельно

1. Скачайте файл так же, как внешний робот. Используйте публичный URL без браузерной сессии. Проверьте конечный HTTP-статус, редиректы, размер ответа и Content-Type.
2. Сохраните фактический ответ. Не анализируйте шаблон генератора вместо результата. На URL может возвращаться HTML-страница ошибки, прокси-заглушка или старая кешированная версия.
3. Проверьте XML целиком. Парсер должен прочитать документ до последнего байта. Исправьте незакрытые теги, лишние корни, неэкранированные символы и повреждённую кодировку.
4. Проверьте каркас YML. Найдите yml_catalog, shop, справочники и offers. Убедитесь, что валюты и категории объявлены до предложений.
5. Сверьте ссылки справочников. Каждый currencyId и categoryId должен существовать в соответствующем блоке.
6. Проверьте каждый тип оффера. Упрощённое предложение требует name; vendor.model — производителя и модель. Не применяйте один набор полей ко всем типам.
7. Проверьте значения. Найдите повторяющиеся ID, нулевые и текстовые цены, слишком длинные или неэкранированные URL, недоступные изображения.
8. Сверьтесь с текущей документацией. Используйте страницы типов фидов, требований и валидации, а не случайный пример из старой статьи.

Если загружаете файл по URL, учитывайте ограничения способа добавления. На странице «Добавление фида» Яндекс описывает загрузку файлом и по HTTP/HTTPS-ссылке, настройки авторизации, статусы и отчёт об ошибках. У URL и локальной загрузки различаются ограничения по размеру, поэтому сверяйте их перед передачей большого каталога.

8. Как помогает ФидСторож

ФидСторож принимает публичную ссылку на фид, скачивает фактический ответ, определяет формат и профиль, затем проверяет XML и структуру YML. Это позволяет быстро отделить сетевую проблему от ошибки документа: видно, был ли файл вообще получен и смог ли парсер разобрать его содержимое.

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

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

Проверить YML-фид по URL можно до добавления в Директ. После исправления сформируйте новую версию и повторите проверку: старый отчёт относится к старому содержимому.

9. Короткий чек-лист перед загрузкой

• URL доступен без cookie, авторизации браузера и ручного подтверждения.
• Ответ имеет ожидаемый HTTP-статус и содержит XML, а не HTML ошибки.
• Документ полностью разбирается XML-парсером и использует корректную кодировку.
• Есть один yml_catalog с датой в формате Директа и один блок shop.
• Валюты и категории объявлены до offers.
• Все offer id уникальны и стабильны.
• Каждый categoryId и currencyId существует в справочнике.
• Набор полей соответствует типу предложения.
• Цена записана числом с точкой, без валюты и пробелов.
• URL экранированы для XML, не содержат пробелов и доступны роботу.
• Изображения открываются напрямую и соответствуют актуальным ограничениям.
• Файл проверен по правилам именно Директа, даже если уже принят Маркетом.

10. Вывод

Надёжная проверка YML-фида для Яндекс Директа идёт снизу вверх. Сначала убедитесь, что робот получает настоящий файл и XML читается целиком. Затем проверьте каркас YML, порядок справочников и связи категорий с предложениями. После этого примените правила Директа к типам офферов, ценам, ссылкам и изображениям.

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

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