Яндекс Товары отклонил YML-фид: как разобрать ошибки offer
Содержание 9 разделов
Сообщение об отклонении YML-фида не всегда означает, что весь XML сломан. Яндекс может получить файл, разобрать магазин и категории, но исключить отдельные предложения из-за содержимого offer или несоответствия карточке товара. Возможна и противоположная ситуация: предложения корректны, однако источник отдаёт не тот HTTP-код, закрыт авторизацией или периодически возвращает пустой файл.
Поиск причины лучше вести слоями — от доставки файла к конкретному товару. Если начать исправлять названия и цены до проверки URL фида, можно потратить время на данные, которые робот вообще не получает. Перед изменением сохраните проблемную версию, время проверки и примеры отклонённых предложений: после регенерации исходное доказательство часто исчезает.
Первый слой: Яндекс должен стабильно получить файл
Откройте точный URL фида без административной сессии, из другого браузера или сервера. Ответ должен быть успешным, без перенаправления на страницу входа, HTML-заглушки, проверки браузера и ошибки CDN. В официальном перечне проблем Яндекс выделяет недоступный источник и ответ, отличный от 200. Проверять нужно не только вручную: ночная генерация, ограничение по IP или кратковременный сбой способны проявляться в другое время.
Запишите код ответа, тип содержимого, размер, время загрузки и контрольную сумму. Резкое уменьшение размера — признак пустой выгрузки или пропавшей категории, даже если XML формально открывается. Если фид собирается долго, безопаснее генерировать временный файл, проверять его и затем атомарно заменять рабочий. Тогда робот не скачает документ в середине записи.
Второй слой: структура XML и обязательные элементы
Файл проверяют валидатором и сопоставляют с актуальной схемой Яндекса. Типовые причины — отсутствующий обязательный элемент, неподдерживаемый тег, незакрытая конструкция, неверная кодировка или символ, который не был экранирован. Ошибка одной позиции может нарушить разбор следующих, поэтому полезно получить номер строки и проверить исходные данные товара, а не исправлять выгруженный XML вручную.
Ручная правка результата исчезнет при следующей генерации. Исправление должно находиться в источнике: CMS, PIM, учётной системе или преобразователе фида. Для каждой ошибки сохраняют идентификатор предложения, правило, исходное значение и результат преобразования. Так повторяющиеся проблемы одной группы можно устранить одним изменением.
Третий слой: атрибуты и содержание offer
У каждого предложения должен быть устойчивый уникальный id. Официальная документация требует сохранять его для одного и того же предложения во всех версиях фида. Атрибут available сообщает о возможности купить товар, но он не отменяет требования к цене, ссылке и странице. Нельзя подставлять случайный новый идентификатор при каждой выгрузке: история предложения разрывается.
Проверьте обязательные элементы выбранного типа описания, ссылку на товар, цену, наличие и категорию. Название должно описывать сам товар, без рекламных обещаний и служебных пометок. Изображение должно относиться к предложению и открываться роботу. Яндекс отдельно указывает на плохое предложение, неверную информацию, проблемы названия и картинки — это уже качество данных, а не синтаксис XML.
| Симптом | Где искать | Контроль после исправления |
|---|---|---|
| Источник недоступен | Хостинг, CDN, редиректы, права, расписание генерации | 200, стабильный размер, загрузка без cookie |
| XML не разбирается | Кодировка, экранирование, структура и поддерживаемые теги | Валидатор проходит на готовом файле |
| Отклонены отдельные offer | Обязательные поля, цена, наличие, URL, название, изображение | Сверка с карточкой и повторная диагностика |
| Товары пропали массово | Число offer, фильтры выгрузки, категории, остатки | Сравнение с предыдущей успешной версией |
Цена и наличие должны совпадать с сайтом
Яндекс проверяет данные предложения относительно страницы товара и условий покупки. Цена в фиде должна быть реальной для пользователя, а наличие — соответствовать возможности оформить заказ. Если сайт показывает старую цену после загрузки, добавляет обязательную услугу только в корзине или не позволяет купить заявленное предложение, синтаксически правильный offer всё равно может быть признан некорректным.
Сверку делают по одному и тому же источнику времени. Частая ошибка возникает, когда сайт читает цену напрямую из CMS, а фид строится из ночной копии. Между ними появляется окно расхождения. Варианты исправления: единый источник, более частая генерация, событие на изменение цены или правило, которое не публикует предложение до согласованного обновления обоих каналов.
Карточка товара — часть проверки фида
Ссылка должна вести на отдельную доступную страницу конкретного предложения, а не на поиск, список категории или промежуточное окно. Робот должен увидеть название, цену, возможность покупки и основную информацию без входа. Мобильная и географическая версия сайта не должны неожиданно показывать другую карточку или заглушку.
Официальная документация Яндекса предупреждает: если в проверенной выборке доля некорректных предложений превышает 25 процентов, источник может быть отключён. Это ещё одна причина не отправлять большую непроверенную выгрузку. Сначала проверяют небольшую репрезентативную группу: доступный и отсутствующий товар, скидку, вариант, разные категории и региональные условия.
Как разбирать отчёт об ошибках
- Зафиксируйте версию. Сохраните файл, время генерации и отчёт Яндекса.
- Разделите общие и товарные ошибки. Недоступный URL влияет на весь источник; неверная цена может касаться одной позиции.
- Сгруппируйте по правилу. Десять предложений без картинки обычно имеют одну причину в исходных данных.
- Проверьте примеры вручную. Сопоставьте offer, карточку сайта и запись в CMS или PIM.
- Исправьте генератор. Изменение рабочего файла без изменения источника не считается решением.
- Соберите тестовую версию. Проверьте XML, ссылки, цены, остатки и число предложений.
- Опубликуйте и наблюдайте. Не меняйте одновременно идентификаторы, URL и структуру без необходимости: иначе трудно понять, что помогло.
Что проверять автоматически до передачи Яндексу
- HTTP-код, тип содержимого, размер и время обновления файла;
- корректность XML и количество элементов
offer; - уникальность и стабильность
id; - наличие обязательных полей для выбранного формата;
- положительную цену и согласованность наличия;
- доступность выборки карточек и изображений;
- резкие изменения числа товаров, категорий и средней цены.
Порог уведомления задают относительно нормального состояния конкретного магазина. Исчезновение двух товаров из каталога в десять позиций важно, а в каталоге из ста тысяч может быть обычным изменением. При этом пустой файл, нарушение XML или недоступность источника требуют немедленной реакции независимо от размера.
Как проводить повторную проверку
Перед отправкой убедитесь, что исправленная версия уже доступна по рабочему URL и не зависит от кэша администратора. Возьмите несколько предложений из отчёта и несколько ранее корректных. Проверьте, что исправление не удалило цену, категорию или изображение у соседних позиций. Затем запустите предусмотренную Яндексом проверку и сохраните результат.
Если ошибка возвращается, сравните файл, который видите вы, с тем, который фактически отдаётся внешнему запросу. Разные узлы CDN, региональные ответы и генерация по расписанию могут оставлять старую копию. Контрольная сумма и заголовок времени обновления помогают отличить повторную ошибку данных от доставки прежней версии.
Правильно настроенный процесс не ограничивается разовой починкой. Он обнаруживает пустой или устаревший фид до обхода, показывает конкретные предложения и сохраняет историю изменений. Тогда отклонение становится обычной диагностируемой задачей, а не внезапной потерей всего товарного трафика.