Как проверить ссылки из YML-фида перед запуском рекламы

Ссылка в YML может быть синтаксически корректной, но вести на 404, на главную страницу или на другую модель. До отправки фида проверьте каждый offer: какой HTTP-ответ вернул сервер, куда закончилась цепочка редиректов и совпадает ли конечная карточка с товаром из фида.

Что проверять отдельно от структуры YML

Внутри файла сначала проверьте формальные условия. В справке Яндекс Директа url описан как адрес страницы товара: ссылка должна соответствовать RFC 3986, не содержать пробелов, а специальные символы XML нужно экранировать. Например, параметры ?utm_source=yandex&utm_medium=cpc записываются в YML как ?utm_source=yandex&utm_medium=cpc.

Анализатор фидов WiseLab проверяет структуру, обязательные поля и формат ссылок. Он не обходит по сети все карточки и изображения. Поэтому после разбора файла нужен второй проход по URL.

Для каждой ссылки сохраните минимум шесть полей:

Код 200 относится к успешным HTTP-ответам по стандарту HTTP Semantics. Он не доказывает, что открылась нужная страница: сервер может вернуть 200 для заглушки, главной или карточки другого товара.

Учебный пример: пять ссылок, четыре вида проблемы

В примере пять офферов. Проверяющий скрипт делает GET, следует по редиректам и сравнивает конечный хост и технический маркер товара. Локальный тест воспроизводится без внешних сайтов; файлы примера сохранены вместе с материалом.

Успешный HTTP-ответ — первый фильтр. Для допуска нужны правильный адрес, нужный вариант и совпадающие данные товара.

В реальном магазине техническим маркером может быть SKU в HTML, Product JSON-LD, артикул в DOM или другой стабильный идентификатор. Не ищите товар только по заголовку страницы: название меняется редакторами и может повторяться у вариантов.

Как провести проверку на своём фиде

1. Зафиксируйте точную версию

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

Сначала запустите полную проверку содержимого фида, а затем извлеките пары offer[id] + url. Быстрый режим подходит для первичной диагностики, но итоговый проход должен охватывать все офферы, которые вы собираетесь передать в рекламу.

2. Запрашивайте страницу методом GET

HEAD экономит трафик, однако отдельные сайты обрабатывают его иначе, чем обычное открытие страницы. Для финальной проверки используйте GET, ограничьте размер читаемого ответа и задайте понятный User-Agent.

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

3. Сохраняйте всю цепочку

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

Google рекомендует стабильные ссылки и минимальное число редиректов; конечные адреса должны оставаться в подтверждённом домене аккаунта. Эти требования полезны как международный ориентир, но доступность рекламных программ и правила страны проверяйте в своём аккаунте.

Для Яндекс Директа отдельно проверьте, что url ведёт на страницу именно того товара, который описан в offer. Формальная корректность URL по спецификации ещё не подтверждает содержание страницы.

4. Сверьте товар и вариант

Для каждой конечной страницы проверьте:

• SKU или другой стабильный идентификатор;
• модель, цвет и размер конкретного варианта;
• цену и валюту;
• наличие и возможность заказа;
• отсутствие подмены карточки категорией, поиском или главной страницей.

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

5. Разделите результат на три статуса

PASS ставьте только при успешном ответе, ожидаемом домене и совпавшем товаре. REVIEW оставляйте для объяснимого редиректа внутри сайта или страницы, где идентификатор нельзя проверить автоматически. FAIL используйте для сетевой ошибки, 4xx/5xx, перехода на неожиданный домен, неверной карточки или неподходящего типа содержимого.

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

Как передать результат разработчику

Отчёт в CSV должен содержать исходный URL, конечный URL, статус и причину решения. Добавьте время проверки и версию фида. Формулировка «часть ссылок не работает» почти бесполезна; строка A-103 → 404 → исправить генератор URL воспроизводится.

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

Критерий готовности

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

Источники

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

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