YML-фид не обновляется: почему площадка видит старые цены, остатки и товары

Цена или остаток уже изменены в CMS, то есть в системе управления магазином, а рекламная площадка продолжает показывать прежнее значение. Иногда старые данные видны даже по прямому адресу выгрузки, иногда сам файл актуален, но кабинет получателя не меняется. Повторная ручная загрузка помогает не всегда, потому что она не устраняет источник задержки.

YML-фид — это товарный документ в формате XML, который магазин публикует по URL для автоматического импорта. XML — текстовый язык разметки со строгой вложенностью элементов. Если данные «застряли», проблема обычно находится на одном из трёх уровней:

1. CMS или система учёта не передала свежие данные генератору.
2. Генератор не пересобрал YML-файл либо сервер отдаёт старую копию из кеша — временного хранилища готовых ответов.
3. Файл обновился, но площадка ещё не скачала его или отклонила новую версию при импорте.

Ниже — порядок проверки от источника до получателя. Он помогает быстро определить владельца проблемы и не очищать все кеши подряд без доказательств.

Диагностика за несколько минут

Возьмите один контрольный товар, который недавно и заметно изменился: например, цена стала 4 990 вместо 5 490 рублей или остаток перешёл из «есть» в «нет». Нужен стабильный признак для поиска — offer id, артикул или точное название. Проверять весь каталог на первом шаге не требуется.

1. Откройте прямой URL фида. Используйте именно адрес, сохранённый в кабинете площадки. Проверьте его без авторизации и, желательно, в приватном окне браузера.
2. Найдите контрольный товар. Ищите по offer id, артикулу или названию. Сравните цену, наличие и другие изменённые поля с CMS.
3. Проверьте источник данных. Если в XML уже старое значение, убедитесь, что оно обновилось не только на витрине магазина, но и в базе или учётной системе, из которой читает генератор.
4. Посмотрите дату генерации. Некоторые выгрузки передают её в атрибуте date корневого элемента. Это полезная подсказка, но не абсолютное доказательство: генератор может поменять дату, не обновив товары.
5. Скачайте файл дважды. Сравните размер и контрольную сумму до и после ожидаемого запуска. Неизменная сумма при реальном изменении товара означает, что опубликованная версия не поменялась.
6. Проверьте HTTP-ответ. HTTP-код — числовой результат запроса сервера, например 200 для успешной отдачи. Также важны конечный URL после редиректов и заголовки кеширования.
7. Проверьте XML. Новая версия может содержать свежие цены, но быть оборванной или синтаксически неверной. Тогда площадка сохранит последнюю корректно обработанную копию.

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

Что проверить в HTTP-ответе

Браузер показывает содержимое, но скрывает часть сетевой картины. Несколько команд curl дают достаточно информации без сложной диагностики. Подставьте реальный публичный адрес вместо https://example.test/feed.xml; не добавляйте в команду пароль или секретный токен, если результат будете пересылать.

curl -sS -L -o /dev/null \
  -w 'HTTP %{http_code}\nURL %{url_effective}\nTime %{time_total}s\n' \
  https://example.test/feed.xml

Команда следует по редиректам, не сохраняет тело ответа и выводит итоговый код, конечный адрес и полное время запроса. Ожидаемый результат — код 200 и тот URL, который вы действительно хотите отдавать площадке. Долгое время ответа повышает риск тайм-аута у получателя.

curl -sSIL https://example.test/feed.xml

Здесь видна вся цепочка заголовков. Проверьте Content-Type: сервер должен отдавать XML, а не HTML-страницу ошибки. Last-Modified сообщает заявленное время изменения, ETag идентифицирует версию ответа, а Cache-Control задаёт правила кеширования. Отсутствие этих заголовков само по себе не доказывает ошибку, но одинаковые ETag и Last-Modified после ожидаемого обновления требуют проверки.

curl -sS -L https://example.test/feed.xml -o feed.xml
sha256sum feed.xml
xmllint --noout feed.xml

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

Основные причины старых данных

Генерация не началась или завершилась ошибкой

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

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

CMS обновилась, а исходная система ещё нет

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

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

Старая версия остаётся опубликованной после сбоя

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

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

Кеш на уровне приложения, Nginx, CDN или прокси

Кеш может находиться сразу в нескольких местах. Приложение сохраняет готовый XML или результат запроса к каталогу; Nginx и обратный прокси кешируют HTTP-ответ; CDN хранит копию ближе к внешнему клиенту. Очистка браузера не влияет на эти уровни.

Сравните ответ с разных сетей и варианты запроса с уникальным параметром, например ?check=20260802, только для диагностики. Если параметр возвращает новую версию, а обычный URL — старую, источник почти наверняка в кеше. Исправьте правила кеширования для фида и сбрасывайте соответствующий ключ после успешной публикации. Не меняйте постоянный URL в кабинете площадки ради каждого обновления.

Несколько адресов ведут к разным файлам

Проверьте HTTP и HTTPS, домен с www и без него, а также конечный адрес после всех перенаправлений. Один вариант может обслуживаться старым виртуальным хостом, другим CDN или каталогом на диске. Площадка продолжит ходить по сохранённому адресу, даже если вы проверяете новый.

Оставьте один канонический HTTPS-URL и настройте предсказуемый постоянный редирект со всех дублей. После изменения проверьте цепочку из внешней сети и убедитесь, что редирект не ведёт на страницу входа, HTML-заглушку или архивный XML.

Сервер отвечает нестабильно или слишком медленно

Ответы 403 и 429 означают запрет или ограничение частоты, а 500 и 503 — внутреннюю ошибку либо временную недоступность сервиса. Причиной может быть защита от ботов, лимит запросов, перегруженный PHP-процесс или генерация фида прямо во время скачивания. Ручная проверка один раз может пройти, тогда как плановый запрос площадки попадёт в сбой.

Посмотрите журналы за время импорта, измерьте продолжительность ответа несколько раз и проверьте правила firewall. Публичный фид должен скачиваться без cookie, сессии и интерактивной проверки. Если формирование занимает долго, генерируйте файл заранее, а по URL отдавайте готовую версию статическим ответом.

Новая версия не проходит обработку площадкой

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

Смотрите отчёт именно последнего импорта: когда он начался, какой URL скачан, сколько предложений принято и какие ошибки получены. Не считайте успешное скачивание успешным обновлением каталога — после HTTP-запроса ещё идут XML-разбор и бизнес-проверки.

Почему нельзя записывать новый фид непосредственно поверх старого

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

Безопасная публикация выполняется в пять шагов:

1. Новая версия создаётся во временном файле в том же каталоге и на той же файловой системе.
2. Проверяется, что файл не пустой и имеет ожидаемый размер.
3. XML-парсер должен прочитать документ до конца; затем выполняются основные проверки структуры и контрольного товара.
4. Только успешная версия атомарно переименовывается в публичный feed.xml.
5. При ошибке временный файл удаляется, рабочая версия остаётся, а сбой записывается в журнал и передаётся в систему уведомлений.

target=/var/www/public/feed.xml
tmp=$(mktemp "${target}.tmp.XXXXXX")
trap 'rm -f "$tmp"' EXIT

generate_feed > "$tmp"
test -s "$tmp"
xmllint --noout "$tmp"
mv "$tmp" "$target"

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

Как понять, что проблема находится на стороне площадки

Переносить ответственность можно только после проверки своей части цепочки. Признаки проблемы на стороне получателя:

• по точному URL из кабинета стабильно возвращается HTTP 200;
• после всех редиректов открывается ожидаемый адрес;
• контрольный товар содержит новую цену или остаток;
• контрольная сумма и, при наличии, дата генерации изменились;
• XML полностью читается и проходит проверки;
• сервер не показывает 403, 429, 500, 503 или долгие ответы во время запросов площадки;
• в кабинете есть ошибка последнего импорта либо очередная загрузка ещё не выполнялась.

Сделайте свежую копию файла и приложите к обращению время проверки, конечный URL, HTTP-заголовки, контрольную сумму и offer id. Так поддержка сможет сравнить скачанную версию с вашей. Частоту обновления нельзя угадывать: она зависит от площадки, типа подключения и настроек. Сверяйте расписание и ограничения с актуальной официальной документацией получателя.

Как контролировать свежесть фида автоматически

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

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

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

Итоговый чек-лист

• URL открывается извне без авторизации, cookie и интерактивной защиты.
• Сервер стабильно возвращает HTTP 200 и ожидаемый Content-Type.
• Нет неожиданного редиректа на другой домен, HTML-страницу или архивный файл.
• Контрольный offer содержит актуальные цену, остаток и состояние доступности.
• Размер и контрольная сумма меняются после реального обновления каталога.
• Документ является корректным XML и полностью читается парсером.
• cron запускает генерацию по расписанию, а успешное завершение видно в журнале.
• Новая версия сначала создаётся во временном файле и только затем заменяет публичную.
• При ошибке остаётся предыдущая рабочая версия, но сбой не проходит без журнала и уведомления.
• Настроен автоматический контроль доступности, времени ответа и свежести.

Главное правило диагностики простое: двигайтесь от контрольного товара в источнике к файлу по URL, затем к HTTP-ответу и отчёту импорта. Первое расхождение показывает, где исправлять процесс. Проверьте YML-фид сейчас, а для регулярных проверок сохраните его в ФидСтороже.