Фид для Яндекс Директа: как создать, загрузить и обновлять без ручных ошибок

Когда нужен фид, а когда достаточно товаров с сайта

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

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

Для интернет-магазина Директ рекомендует YML-фид. Допустимы и другие поддерживаемые форматы, но формат выбирают не по привычке разработчика, а по типу бизнеса и полям, которые нужно передать. Актуальный список форматов опубликован в официальной справке Директа ↗.

<offer id="123" available="true">
  <url>https://example.ru/catalog/item-123/</url>
  <price>45900</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <name>Название товара и ключевой параметр</name>
</offer>

Сначала источник данных: цена, наличие, URL и идентификатор

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

Для сравнения условий полезен материал Товарная галерея Яндекса: как запустить товары и понять, почему нет показов.

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

Минимальная структура YML-фида без лишней сложности

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

<?xml version="1.0" encoding="UTF-8"?>
<yml_catalog date="2026-08-27 10:00">
  <shop>
    <name>Интернет-магазин</name>
    <currencies><currency id="RUB" rate="1"/></currencies>
    <categories><category id="10">Категория</category></categories>
    <offers>
      <offer id="sku-1042" available="true">
        <name>Тип товара и ключевой параметр</name>
        <url>https://example.ru/catalog/item/</url>
        <price>25900</price>
        <currencyId>RUB</currencyId>
        <categoryId>10</categoryId>
        <picture>https://example.ru/img/item.webp</picture>
      </offer>
    </offers>
  </shop>
</yml_catalog>

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

Загрузка файлом или по ссылке: что выбрать для обновлений

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

Если хочется сравнить этот сценарий с соседним, загляните в Товарный фид: ошибки, которые ломают автогенерацию объявлений.

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

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

Валидация: почему статуса «файл принят» недостаточно

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

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

Общие требования к фидам и идентификаторам собраны в справке Яндекс Директа ↗.

Регламент после запуска: что контролировать каждый день и каждую неделю

Ежедневно достаточно автоматически проверять доступность файла, время его формирования, объём и долю доступных предложений. Резкое падение количества товаров, нулевой файл или старая дата должны создавать уведомление до начала активных показов.

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

Ответственный должен быть назначен не только за рекламу, но и за источник. Специалист по Директу видит проблему на уровне кампании; разработчик отвечает за генерацию; владелец каталога — за правила цены и наличия. Без разделения ролей любой сбой превращается в спор о том, кто должен был заметить его первым.