Картинка может быть указана в каждом офере, а объявление всё равно останется без нормального изображения: адрес отдаёт 404, сервер возвращает HTML с кодом 200, файл не декодируется, его сторона короче допустимого минимума или один снимок случайно назначен разным товарам. Такие ошибки обнаруживает отдельный проход по picture в YML и image_link в фиде Google.
Сначала проверьте структуру файла в анализаторе товарного фида. Затем скачайте каждое изображение тем же способом, которым его получает робот площадки, и сохраните результат в CSV. Формальная проверка XML не отвечает на вопрос, что сервер вернёт по ссылке через минуту после выгрузки.
Что проверить у каждой ссылки
Для рабочего отчёта достаточно десяти полей: ID офера, название, исходный URL, HTTP-код, конечный URL после редиректов, Content-Type, фактический формат, ширина, высота, хеш файла и итог проверки.
Проверки лучше выполнять в таком порядке:
- Сделать
GETс ограничением времени и переходом по редиректам. - Записать HTTP-код и конечный URL.
- Убедиться, что
Content-Typeначинается сimage/. - Декодировать полученные байты как изображение. Расширение
.jpgсамо по себе ничего не доказывает. - Сравнить ширину, высоту, формат и объём с требованиями выбранной площадки.
- Посчитать SHA-256 и найти точные дубли между разными оферами.
- Просмотреть спорные строки и сверить изображённый товар, цвет и комплектацию с офером и посадочной страницей.
Автоматическая часть отсекает недоступные и технически неверные файлы. Совпадение товара, варианта и комплектации подтверждается просмотром.
Какие требования поставить в проверку
Для Яндекс Директа элемент picture должен содержать URL с http или https. В справке на 5 октября 2026 года указаны форматы JPG, PNG, WebP и GIF, размер от 450 пикселей по каждой стороне и файл до 10 МБ. Яндекс рекомендует несколько ракурсов; при выборе одной картинки система начинает с первой подходящей.
Google требует основной адрес в image_link, прямую ссылку на поддерживаемый файл и доступ для роботов. Справка Google уже предупреждает о минимуме 500×500 пикселей для всех товаров с 31 января 2027 года и рекомендует около 1500×1500. Поэтому порог следует хранить параметром проверки, а дату и площадку — рядом с результатом. Один универсальный минимум быстро устареет.
Технически корректный файл ещё нужно сравнить с товаром. Google требует, чтобы главное изображение показывало именно продаваемый товар, а варианты с разным внешним видом получали соответствующие изображения. Хеш помогает найти одинаковые байты, но не распознаёт разные фотографии одного ошибочно назначенного товара. Для этого остаётся выборочная или сплошная визуальная сверка.
Воспроизводимый пример
В учебном YML — шесть оферов. Локальный сервер специально отдаёт разные ответы, а скрипт формирует CSV. Порог установлен в 450 пикселей по короткой стороне.
python demo_server.py
python check_feed_images.py sample-feed.yml image-check-report.csv --min-side 450Получился такой отчёт:
| Офер | Ответ | Файл | Размер | Результат |
|---|---|---|---|---|
| A-101 | 200 | JPEG | 900×900 | точный дубль A-106 |
| A-102 | 302 → 200 | WebP | 900×900 | проверить постоянство конечного URL |
| A-103 | 404 | — | — | заменить или удалить ссылку |
| A-104 | 200, text/html | — | — | сервер вернул страницу вместо картинки |
| A-105 | 200 | JPEG | 300×300 | меньше порога Яндекс Директа |
| A-106 | 200 | JPEG | 900×900 | точный дубль A-101 |
Редирект не всегда означает ошибку. Он попадает в ручную проверку, потому что промежуточный адрес может зависеть от сессии, срока действия подписи или внешнего CDN. Для фида лучше использовать стабильный публичный URL без авторизации и регулярно проверять конечный ответ.
HTML с кодом 200 опаснее явного 404: простая проверка статуса посчитает ссылку рабочей. Так отвечают страницы защиты, заглушки и некоторые CDN при ограничении доступа. Поэтому отчёт должен учитывать заголовок ответа и успешное декодирование байтов.
Как разобрать отчёт без лишней ручной работы
Сначала исправьте строки FAIL_HTTP, FAIL_NETWORK, FAIL_CONTENT_TYPE и FAIL_DECODE. Робот не сможет получить из них изображение. Затем обработайте нарушения размера и формата под конкретную площадку.
Строки REVIEW_REDIRECT и REVIEW_DUPLICATE требуют решения человека. У редиректа проверьте срок жизни и доступ без cookie. У дубля откройте карточки рядом: одинаковая фотография допустима для одного и того же физического варианта, но подозрительна у разных цветов, моделей и комплектов.
После технической очистки возьмите спорные оферы и проверьте четыре совпадения:
- на изображении показан товар из названия и описания;
- цвет и вариант совпадают с параметрами офера;
- комплект на снимке действительно продаётся вместе;
- главное изображение совпадает с карточкой товара.
Ссылки карточек удобно проверить отдельным проходом по инструкции «Как проверить ссылки из YML-фида перед запуском рекламы». Затем загрузите исправленный файл в анализатор фида и выполните приёмку исправленного товарного фида: повторите обе проверки на той версии, которая реально пойдёт в рекламный кабинет.
Что автоматизация не подтверждает
HTTP-проверка показывает состояние в момент запроса. Она не гарантирует, что CDN будет доступен позже, а робот площадки получит тот же ответ из другой сети. Запускайте проверку перед загрузкой, после массовой смены изображений и по расписанию для активного фида.
Хеш выявляет только полностью одинаковые файлы. Перекодированная, обрезанная или уменьшенная копия получит другой SHA-256. Для поиска визуально похожих картинок нужен perceptual hash, а его совпадения всё равно следует проверять глазами.
Скрипт также не доказывает, что площадка одобрит изображение по содержанию. Текстовые плашки, водяные знаки, неверный товар и лишние предметы требуют проверки по правилам площадки и по самой карточке. Итоговый процесс заканчивается просмотром, а не строкой PASS.
Источники
Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.
Что думаете?
Загружаем комментарии…