Почему Adgora видит проблему ads.txt в WordPress

Когда проблема связана с WordPress, а не с содержимым ads.txt

Иногда файл на месте, а предупреждение всё равно не исчезает. Вот в чём и раздражение. Проблема не всегда в тексте внутри файла; в WordPress сбой часто находится на уровень ниже — в том, как сайт отдаёт этот файл краулеру.

Если вы уже добавили ads.txt, а Adgora всё ещё жалуется, в первую очередь подумайте о поведении WordPress: маршрутизации URL, редиректах, кэшированных копиях, правилах хоста и фильтрах безопасности. У издателя может быть корректный файл на диске, но при этом сохраняться ошибка ads.txt в WordPress, потому что запрос не доходит до правильного ответа, и даже ситуация, когда Adgora не видит ads.txt, часто объясняется именно этим.

Это типично для сайтов, где одновременно работают конструктор темы, CDN и плагин кэширования. Один параметр меняет ответ, другой его кэширует, а третий делает так, что в браузере всё выглядит нормально, хотя краулер получает совсем другое.

Не начинайте с переписывания файла. Сначала проверить ads.txt в WordPress стоит по пути, хосту и коду ответа. Это сэкономит время.

Сначала определите точный тип сбоя в Adgora

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

Внимательно прочитайте предупреждение. Если Adgora пишет, что файл отсутствует, это прямая проблема получения. Если сказано, что файл есть, но статус неверный, тогда дело может быть в кэшировании или доставке ответа. Если в предупреждении указан конкретный вариант домена, этот намёк важнее любого общего чек-листа по устранению неполадок ads.txt.

Быстрой проверки в браузере недостаточно. Ваш браузер может показывать файл, загруженный из локального кэша, тогда как краулер Adgora запрашивает живой URL заново. Именно этот разрыв и объясняет многие ложные срабатывания.

Запишите 4 пункта, прежде чем что-либо менять: точный текст предупреждения, URL, который ожидает Adgora, текущий живой URL и то, обновлялся ли файл за последние 24 часа. Эти детали быстро сузят круг поиска.

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

Проверьте, как WordPress отдаёт корневой домен и распространённые варианты

WordPress может отдавать один и тот же сайт по нескольким адресам: с www и без, по HTTP и HTTPS, а иногда и через привязанный домен в конфигурации multisite. Adgora может проверять один вариант, а вы тестировать другой.

Это важно, потому что ads.txt определяется в корне. Запрос к https://example.com/ads.txt — не то же самое, что https://www.example.com/ads.txt, даже если главная страница выглядит одинаково. Один редирект — нормально; два или три уже могут запутать краулер, особенно если цепочка приводит вовсе не к файлу.

Проверьте канонический вариант сайта в настройках WordPress, а затем сравните его с URL, который использует Adgora. Если WordPress Address и Site Address различаются, отметьте это. Из-за этого запрос может уйти на неверный хост ещё до того, как файл вообще будет рассмотрен.

Поведение со слешем в конце тоже может иметь значение. Перенаправление с /ads.txt на /ads.txt/ — не лучший вариант, потому что краулер ожидает обычный текстовый файл в корне, а не путь, похожий на каталог. Мелочь, а раздражает сильно.

На сайтах с привязкой домена к сети multisite привязанный домен может нормально работать для записей, а запросы к файлам на корневом хосте — нет. Такое в multisite-сетях случается чаще, чем многие думают.

Проверьте, нет ли кэш-слоёв, которые отдают старую или пустую версию

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

Начните с самого близкого к посетителю кэша. Если перед WordPress стоит CDN, сначала очистите его. Затем очистите кэш хостинга, потом кэш плагина, затем браузер. Очерёдность важна, потому что закэшированная 404-страница может пережить корректную загрузку файла на часы.

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

Команды, занимающиеся монетизацией WordPress, часто забывают, что правила кэша могут по-разному обрабатывать /ads.txt и обычные страницы. Кэш страницы может пропускать HTML, но правило сервера или edge-кэш CDN всё ещё может выдавать старый текстовый ответ. Именно так маленький файл вызывает большую задержку.

Если ваш хостинг предлагает edge-кэширование, уточните, кэшируются ли текстовые файлы отдельно. У одних — да. У других — нет. Прежде чем считать файл сломанным, нужно знать ответ.

Проверьте, не переписывается ли файл и не скрывается ли он инструментами WordPress

Несколько инструментов WordPress могут мешать корректному ответу ads.txt. Плагины безопасности могут блокировать прямой доступ к файлу. Плагины производительности могут сжимать или переписывать статические пути. Плагины мультиязычности могут пытаться локализовать URL, который должен оставаться простым и точным.

Инструменты для развёртывания со staging на production — ещё один риск. При деплое может быть перезаписан корневой каталог на продакшене более старой версией файла, либо могут быть развернуты только выбранные пути, а ads.txt останется позади. Правила управляемого хостинга тоже могут переносить файл или защищать корневую директорию, и это легко пропустить, потому что в панели всё выглядит нормально.

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

Посмотрите и на запланированные задачи. Некоторые плагины оптимизации пересоздают файлы по расписанию. Если ads.txt меняется, а через час откатывается назад, возможно, cron-задача восстанавливает старую копию.

Если сайт использует мультиязычный слой, убедитесь, что ads.txt не отдается через языковую папку или переведённый маршрут. Он должен оставаться в корне, а не в /en/ или любом другом подкаталоге.

Используйте прямые проверки ответа, чтобы понять, что на самом деле получают краулеры

Открытие файла в браузере показывает только то, что увидел ваш браузер. Это не доказывает, что увидел краулер. Прямые проверки ответа лучше, потому что они показывают точный HTTP-результат запроса.

Проверьте /ads.txt и посмотрите, какой ответ возвращается: 200, 301, 302, 403 или 404. 200 — это цель. 301 или 302 означает, что файл перемещают до того, как он прочитан. 403 — это блокировка. 404 означает, что запрос так и не нашёл пригодный файл.

Также проверьте тело ответа. Если в теле HTML, страница темы или уведомление о техобслуживании, значит, краулер не получил обычный файл ads.txt. Именно поэтому одной проверки в браузере недостаточно — она может ввести в заблуждение.

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

Именно в этот момент многие команды перестают гадать и начинают измерять. Правильное решение.

Что записать при прямой проверке

• Точный запрошенный URL, включая www или без него.
• Код HTTP-статуса.
• Любую цель перенаправления.
• Первые 5 строк тела ответа.
• Название сервера или CDN из заголовков.

Влияние на монетизацию WordPress: когда предупреждение стоит считать риском для дохода

Не каждое предупреждение ads.txt означает, что деньги прямо сейчас теряются. Иногда предупреждение устарело, а файл уже корректен. Иногда это ложная тревога от предыдущего обхода.

Но к проблеме всё равно стоит относиться серьёзно, если предупреждение остаётся видимым дольше одного цикла обхода или если несоответствие показывают сразу несколько инструментов, ориентированных на покупателей. Именно тогда может пострадать доверие покупателей и рабочие процессы монетизации, особенно если у вас несколько рекламных источников и вы полагаетесь на проверку ads.txt для чистоты supply path.

Для сайта, завязанного на подписки, спонсорство или programmatic-demand, этот файл — не декорация. Это часть настройки дохода. Один сломанный ответ может прервать проверки закупки, задержать согласования или заставить покупателя усомниться в пути инвентаря.

Поставьте это исправление в начало чек-листа монетизации WordPress, если предупреждение появляется на живом корневом домене и не исчезает после очистки кэша. Если предупреждение то появляется, то исчезает, понаблюдайте за ним 24 часа, прежде чем считать проблему решённой.

Не каждое оповещение дорого обходится. Некоторые просто шумные. Но то, которое сохраняется после 2 чистых проверок, заслуживает немедленного внимания.

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

Путь эскалации для нерешённых случаев, специфичных для WordPress

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

Добавьте живой URL, цепочку перенаправлений, заголовки ответа, статус кэша и один-два скриншота. Если вы проверяли и www, и без www, перечислите оба варианта. Если участвует CDN, укажите его. Если файл переписывает плагин, тоже назовите его.

Команды поддержки быстрее проверяют проблему, когда видят точный путь. Расплывчатая формулировка вроде «всё ещё не работает» порождает новый круг вопросов. А вот запись вроде https://example.com/ads.txt возвращает 302 на https://www.example.com/ads.txt, а затем 403 от кэша хоста, — уже гораздо полезнее.

Если вы запускаете несколько страниц, зависящих от чистой доставки рекламы, зафиксируйте тот же путь и для других ресурсов. Сайт на WordPress, который неправильно обрабатывает /ads.txt, может так же некорректно обрабатывать и другие файлы в корне, а это уже важно для рекламных операций.

Что отправить в Adgora или вашему хостингу

• Точный живой URL, который должен отдавать ads.txt.
• Копию цепочки перенаправлений, если она есть.
• Код статуса ответа и заголовки.
• Метки времени последней очистки кэша.
• Два скриншота: результат в браузере и предупреждение Adgora.

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

Для издателей, которые одновременно ведут несколько рекламных продуктов, даже корректный файл можно пропустить, если на сайте есть один плохой edge-узел или одно правило безопасности. Поэтому последней проверкой всегда должен быть живой HTTP-ответ, а не вид в редакторе WordPress.

И если ответ неверный, сначала исправьте ответ.