Как проверить, обновляется ли YML-фид по URL

Цена на сайте изменилась, товар вернулся в наличие, а реклама продолжает показывать старые данные. Открыть адрес фида и увидеть 200 OK недостаточно: сервер мог отдать вчерашний XML, промежуточный кэш — старую копию, а генератор — новый файл без нужного товара.

Проверьте обновление по одной цепочке доказательств: скачайте две версии с точного production-URL, сохраните заголовки ответа и время, посчитайте SHA‑256, затем сравните ожидаемые поля у заранее выбранных offer id. Так можно отделить задержку экспорта от изменений, которые произошли в другой части файла.

Что считать подтверждённым обновлением

Ни один отдельный признак не описывает весь результат. У каждого своя задача.

Требования Яндекс Директа к YML связывают атрибут date корневого элемента <yml_catalog> с датой и временем генерации файла. HTTP-спецификация описывает ETag и Last-Modified как валидаторы представления ресурса. Они полезны для диагностики кэша, но бизнес-изменение подтверждают данные оффера.

Скачайте две версии одного URL

Сначала выберите два-три товара, которые легко проверить в CMS и на сайте. Для каждого сохраните offer id, исходную цену, наличие и ожидаемое изменение. Учебный набор в комплекте статьи использует три ID:

• A-101: цена должна измениться с 899 до 849 BYN;
• B-202: available должен измениться с false на true;
• C-303: контрольный товар должен остаться без изменений.

До изменения скачайте фид с того же URL, который передан рекламной системе. Команды ниже подходят для macOS и Linux:

FEED_URL='https://shop.example/feed.yml'
date -u +'%Y-%m-%dT%H:%M:%SZ' > checked-before.txt
curl --fail --silent --show-error --location \
  --dump-header headers-before.txt \
  --output feed-before.yml \
  "$FEED_URL"
sha256sum feed-before.yml

Флаг --location повторяет переходы по HTTP-редиректам. Дополнительно запишите конечный URL, если он отличается от исходного. Не добавляйте случайный параметр для «сброса кэша»: другой адрес может пройти по другой серверной ветке и перестанет воспроизводить загрузку рекламной системы.

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

date -u +'%Y-%m-%dT%H:%M:%SZ' > checked-after.txt
curl --fail --silent --show-error --location \
  --dump-header headers-after.txt \
  --output feed-after.yml \
  "$FEED_URL"
sha256sum feed-after.yml

Сохраняйте оба тела ответа. Повторное открытие URL в браузере не оставляет надёжной пары для сравнения: содержимое по тому же адресу уже могло измениться.

Сначала сравните транспортные признаки

Откройте headers-before.txt и headers-after.txt. Зафиксируйте HTTP-статус, Content-Type, конечный URL, ETag и Last-Modified. По RFC 9110 ETag различает представления ресурса, а Last-Modified сообщает время, когда исходный сервер считает выбранное представление изменённым.

Если сервер поддерживает ETag, условный запрос позволяет проверить версию без повторной передачи неизменившегося файла. В актуальной справке curl для этого используются --etag-save и --etag-compare. Для разовой редакционной проверки сохранять полное тело всё равно полезно: оно понадобится для хеша и сверки товаров.

Дальше проверьте date у <yml_catalog>. Новое время при старых ценах показывает, что генератор запускался, но не доказывает обновление нужных данных. Старое время при ожидаемом изменении указывает на задержку до генерации или выдачу старой версии.

Затем сравните файл и контрольные товары

SHA‑256 отвечает на узкий вопрос: одинаковы ли байты. Совпадающий хеш после ожидаемого изменения — сильный сигнал, что до URL дошёл прежний файл. Разный хеш означает только наличие каких-то отличий.

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

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

Повторите учебную проверку

В комплекте статьи лежат sample-before.yml, sample-after.yml и compare_feed_versions.py. Скрипт работает со скачанными файлами, считает SHA‑256, читает дату каталога и сравнивает price, currencyId, available, url и name по выбранным ID.

python3 compare_feed_versions.py \
  sample-before.yml sample-after.yml \
  --watch A-101 B-202 C-303 \
  --csv expected-diff.csv

Для учебных файлов результат такой:

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

Для production-фида замените учебные файлы двумя сохранёнными ответами и укажите реальные ID. Если один ID повторяется, скрипт прекращает сравнение: две записи с одинаковым идентификатором нельзя однозначно сопоставить. Отдельный порядок диагностики описан в материале о дублях offer id.

Как читать расхождения

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

Передайте разработчику воспроизводимый пакет

Сообщение «фид не обновляется» заставляет заново собирать исходные данные. Полезный пакет содержит:

1. точный URL и конечный URL после редиректов;
2. время двух GET-запросов с часовым поясом;
3. оба файла и их SHA‑256;
4. ETag, Last-Modified, Content-Type и HTTP-статус;
5. контрольные offer id, ожидаемые и фактические значения;
6. время изменения в CMS и заявленный интервал экспорта;
7. CSV со сравнением.

Если фид генерирует CMS, попросите связать каждый этап по времени: изменение товара, запуск задания, создание файла на origin, обновление CDN и загрузку рекламной системой. Эта линия обычно показывает первый участок, где новая версия перестала двигаться.

Завершите проверку в рекламной системе

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

Для разовой правки используйте отдельный протокол приёмки исправленного товарного фида. Текущая проверка отвечает на другой вопрос: поступает ли новая бизнес-версия к production-URL в ожидаемое время.

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

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.