YML-фид для Яндекса: как не смешать Поиск, Директ и Маркет

YML — XML-формат для передачи товарных данных сервисам Яндекса. В нём магазин описывает предложения, категории, цены, валюты, ссылки, изображения и другие свойства. Но выражение «загрузить фид в Яндекс» слишком расплывчато: органический Поиск по товарам, рекламные кампании Директа и маркетплейс Маркет решают разные задачи, проверяют разные поля и дают разный результат.

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

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

Чем отличаются Поиск, Директ и Маркет

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

Яндекс Директ использует фид как вход для рекламных инструментов: на его основе автоматически создаются товарные объявления для Поиска, РСЯ и товарной галереи в рамках настроенной кампании. Здесь есть бюджет, ставки, стратегия, модерация и правила рекламы. Оплата продвижения не делает товар органическим результатом, а состояние рекламного фида ничего не говорит о присутствии магазина в Маркете. Практика настройки канала разобрана в статье о рекламе в Директе.

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

Поэтому в отчёте пишут не «Яндекс принял 9 000 товаров», а точнее: какой сервис, какой файл, какая дата проверки и какой статус. Для органического канала рядом фиксируют доступность страниц и данные Яндекс Вебмастера; для рекламы — модерацию и активность кампании; для Маркета — состояние ассортимента в кабинете. Стратегию магазина при этом оценивают шире, чем один источник, по принципам SEO интернет-магазина.

Как устроить единый источник данных

Назначьте мастер-систему для каждого поля. ERP или учётная система обычно отвечает за SKU, остаток и базовую цену; PIM — за название, бренд, характеристики и изображения; CMS — за канонический URL и видимый текст; служба доставки — за регионы и сроки. Генератор фида соединяет эти данные по устойчивому ключу, но не должен самостоятельно придумывать скидку, наличие или категорию при пропуске.

Для поля храните владельца, допустимую задержку и правило конфликта. Если ERP сообщает нулевой остаток, а CMS ещё показывает кнопку покупки, безопаснее временно исключить предложение или передать реальный статус, чем публиковать старое «в наличии». Если цена на странице обновляется позже фида, определите очередность релиза. Покупатель должен увидеть ту же сумму и возможность заказа, которые переданы сервису.

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

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

У процесса есть владелец со стороны каталога и дежурный со стороны разработки. Они получают сигнал о провале генерации, старом файле или резком уменьшении ассортимента. Регламент удобно включить в общий SEO-мониторинг сайта: фид проверяется вместе с кодами страниц, индексируемостью и изменениями шаблонов. Сам факт успешного cron ещё не означает, что XML доступен снаружи и содержит актуальные товары.

Из чего состоит корректный YML

YML основан на XML. В начале размещают декларацию, затем корневой yml_catalog с датой формирования, внутри — shop, справочники и список offers. Категории и валюты объявляют до использования в предложениях. Точный перечень элементов проверяйте в документации выбранного продукта: общий каркас похож, но обязательность и допустимые значения у Поиска, Директа и Маркета различаются.

<?xml version="1.0" encoding="UTF-8"?>
<yml_catalog date="2026-07-24T10:00:00+03:00">
  <shop>
    <name>Магазин</name>
    <currencies><currency id="RUR" rate="1"/></currencies>
    <categories><category id="120">Кофемолки</category></categories>
    <offers>
      <offer id="KM-1042" available="true">
        <url>https://example.ru/coffee/km-1042</url>
        <price>7990</price>
        <currencyId>RUR</currencyId>
        <categoryId>120</categoryId>
        <picture>https://example.ru/img/km-1042.jpg</picture>
        <name>Кофемолка ручная, стальная</name>
      </offer>
    </offers>
  </shop>
</yml_catalog>

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

XML чувствителен к синтаксису. Амперсанд в URL записывают как &, текст кодируют в заявленной кодировке, теги закрывают, идентификаторы справочников объявляют до ссылок на них. Файл обязан отдаваться целиком с успешным ответом сервера; HTML ошибки приложения внутри ответа разрушит разбор. Проверку кодов и перенаправлений удобно вести по справочнику HTTP-ответов.

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

Как сохранить идентификаторы и категории

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

У варианта собственный офер. Красная футболка размера M и синяя размера L могут иметь разные остатки, URL-параметры, изображения и цены, поэтому их нельзя бездумно склеивать в один ID. При этом семейство вариантов должно быть понятно на сайте, а ссылка — открывать заявленную конфигурацию. Практическая модель описана в статье о SEO вариантов товара.

Категорийный ID тоже стабилен, но сама иерархия может развиваться. Храните внешний идентификатор отдельно от отображаемого названия, чтобы переименование «Техника для кухни» не переносило тысячи товаров в якобы новую ветку. Каждый categoryId офера должен ссылаться на реально объявленную категорию. Циклы, отсутствующий родитель и дубликаты проверяют до публикации, а не после отказа сервиса.

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

Слияние и разделение SKU требуют отдельной карты миграции. Когда комплект превращается в два самостоятельных товара, старый ID не назначают одному из них наугад. Когда два дубля объединяются, выберите основной офер, исправьте внутренние ссылки и сохраните историю решения. Повторно появившийся тот же товар может вернуть прежний ID, если его коммерческая сущность действительно не изменилась; другая модель под старым ключом недопустима. Контроль ищет не только дубли в текущем файле, но и подозрительное переиспользование идентификаторов из архива.

Как описать товарное предложение

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

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

URL обязан вести на каноническую доступную карточку и сохранять необходимые параметры выбора варианта. Проверьте мобильный ответ, редиректы, robots.txt, canonical и возможность оформить заказ. Структура страницы остаётся самостоятельной задачей: руководство по товарной карточке помогает сделать содержание понятным, а разметка Product и Offer передаёт факты в HTML. YML не отменяет ни страницу, ни Schema.org.

Для каждого канала составьте таблицу «обязательное, рекомендуемое, неподдерживаемое». Не переносите поле только потому, что оно допустимо в другом формате. В частности, документация Яндекс Товаров отдельно описывает отличия от маркетплейсного YML и советует не использовать ряд элементов Маркета, включая служебные ставки и некоторые учётные значения. Устаревшее или лишнее поле может быть проигнорировано либо вызвать ошибку проверки; решает актуальная спецификация назначения.

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

Как синхронизировать цену и наличие

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

Наличие означает возможность оформить именно этот офер, а не присутствие похожего товара на складе. Предзаказ, поставка под заказ и временная недоступность имеют разные пользовательские последствия. В Яндекс Товарах нежелательно полагаться на неопределённое значение available="unknown"; передавайте состояние, которое подтверждается страницей и процессом заказа. Если точности нет, исправьте учёт, а не маскируйте пробел нейтральным словом.

Частоту обновления выбирают по скорости изменений. Магазину с единичными остатками может потребоваться несколько выгрузок в день; стабильному производственному каталогу достаточно реже. Но публикация каждую минуту бесполезна, если ERP обновляется раз в сутки. Рассчитайте полный лаг: продажа → учёт → снимок → генерация → скачивание сервисом → обработка. Он определяет риск, а не только расписание cron.

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

Акции запускайте как согласованное изменение с началом, окончанием и часовым поясом. Если фид обновился в 00:00, а карточка — в 00:15, в течение пятнадцати минут данные расходятся. Сначала проверьте эталонный SKU, затем публикуйте версии в принятом порядке и после завершения снимайте старую цену везде. При досрочной остановке акции аварийное обновление должно пройти тем же контролем, а не обходить валидатор. Журнал временных границ помогает отличить краткий допустимый лаг от зависшей скидки после окончания кампании.

Как учитывать регионы и доставку

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

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

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

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

Зачем нужны отдельные профили каналов

Общий каталог не означает один физический файл. Практичнее иметь базовую нормализованную модель и три экспортных профиля: для Яндекс Товаров, Директа и Маркета. Каждый профиль выбирает допустимые поля, преобразует значения, фильтрует ассортимент и формирует свой отчёт. Исправление исходной цены попадёт во все выходы, а специфичный элемент Маркета не сломает проверку органического фида.

Для Поиска приоритетны индексируемая карточка и согласованные сведения о товаре. Для Директа дополнительно важны структура рекламной кампании, правила отбора и соответствие требованиям объявлений. Для Маркета ассортимент связывается с моделью размещения, логистикой и операциями площадки. Это не три копии одной настройки. У крупного агрегатора архитектура ещё сложнее; полезные принципы есть в статье о SEO агрегаторов и маркетплейсов.

Фильтры профиля должны объясняться. Например, 10 000 SKU в мастер-каталоге могут дать 8 400 подходящих страниц для Товаров, 6 200 позиций рекламной кампании и 7 500 предложений Маркета. Эти множества пересекаются, поэтому их нельзя сложить и объявить 22 100 товарами. В отчёте показывают долю от исходного каталога и причины исключения по каждому каналу.

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

Как публиковать и проверять файл

Генерируйте YML во временное имя, проверяйте XML и бизнес-правила, затем атомарно подменяйте рабочий файл. Если процесс упал посередине, сервис продолжит получать предыдущую целую версию, а не оборванный документ. Способ доставки файла выбирайте по требованиям конкретного продукта: обычно удобен стабильный HTTPS-адрес, а там, где документация допускает защищённый источник, передавайте логин и пароль через настройки сервиса. В любом случае ответ, кодировка и доступность для его робота должны быть корректными.

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

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

Автоматический smoke-тест скачивает публичный URL извне, сверяет размер и контрольную сумму, разбирает XML и открывает несколько посадочных страниц. Перед изменением генератора запускайте SEO-регрессионные проверки. Алерт нужен не только при HTTP 500: файл размером 4 КБ с корректным XML может содержать десять товаров вместо десяти тысяч и технически считаться валидным.

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

Числовой пример аудита фида

Рассмотрим магазин с 10 000 SKU в мастер-каталоге. Канальные фильтры дают 8 400 оферов для Яндекс Товаров, 6 200 для активной рекламы и 7 500 для Маркета. Это перекрывающиеся множества: один SKU может входить во все три. Поэтому правильные показатели — 8 400 / 10 000 = 84%, 6 200 / 10 000 = 62% и 7 500 / 10 000 = 75%, а не сумма 22 100.

В первом профиле для Товаров аудит находит 800 проблемных оферов. Для чистоты расчёта каждый офер относят к одной главной причине: 320 ведут на ошибочный или недоступный URL, 210 показывают другую цену, 145 расходятся по наличию, 95 не имеют доступной основной картинки, 30 повторяют ID. Проверка суммы проста: 320 + 210 + 145 + 95 + 30 = 800. Доля ошибок в этом фиде равна 800 / 8 400 × 100 = 9,52%.

После исправления остаётся 18 + 12 + 9 + 5 + 2 = 46 проблем, или 46 / 8 400 × 100 = 0,55%. Устранено 754 ошибки. Относительное снижение составляет (800 − 46) / 800 × 100 = 94,25%. Это проверяемая оценка качества данных, а не прогноз трафика или продаж: принятый офер ещё должен соответствовать правилам продукта и быть выбран системой для показа.

Команда выпускает исправление партиями. Сначала публикует 100 эталонных SKU из разных категорий и регионов, проверяет файл, посадочные и отчёт сервиса. Затем расширяет охват, не меняя ID. В бизнес-части отдельно смотрит клики, расходы рекламы, заказы и отмены, сохраняя канал происхождения. Так техническое улучшение не объявляется коммерческим успехом без данных.

Как поддерживать YML после запуска

Ежедневно контролируйте свежесть файла, длительность генерации, число оферов, долю исключений, HTTP-ответ и пять главных типов расхождений. Порог учитывает обычную сезонность: падение на 2% после распродажи может быть нормой, исчезновение 40% за один запуск — повод остановить публикацию. Алерт содержит ссылку на версию, канал и пример SKU, иначе дежурный потратит время на повторный поиск причины.

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

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

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

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

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

Главный вывод

Хороший YML-фид — не универсальный билет во все продукты Яндекса, а проверяемое представление товарного каталога для конкретной задачи. Органический Поиск, платный Директ и маркетплейс Маркет требуют раздельных профилей, статусов и метрик. Стабильные ID, единый источник цены и наличия, честные регионы, атомарная публикация и контроль посадочных уменьшают ошибки. Но даже полностью валидный файл не обещает ранжирование, показ объявления или продажу.