Чому Adgora не бачить ads.txt у WordPress

Коли проблема пов’язана з WordPress, а не з вмістом ads.txt

Іноді файл уже на місці, а попередження все одно не зникає. У цьому й полягає найбільша прикрість. Проблема не завжди в тексті всередині файла; у WordPress збій часто виникає на один рівень нижче — у тому, як сайт віддає цей файл сканеру.

Якщо ви вже додали ads.txt, а Adgora все ще скаржиться, спершу подумайте про поведінку WordPress: маршрутизацію URL, перенаправлення, кешовані копії, правила хоста та фільтри безпеки. У видавця може бути правильний файл на диску, але все одно з’являтися помилка ads.txt у WordPress, бо запит не доходить до правильного відповіді.

Таке часто трапляється на сайтах, де одночасно активні конструктор тем, CDN і плагін кешування. Одне налаштування змінює відповідь, інше її кешує, а третє робить так, що в браузері все виглядає нормально, тоді як сканер отримує інше. Через це нерідко виникає ситуація, коли Adgora не бачить ads.txt, хоча файл формально присутній.

Не починайте з переписування файла. Спершу перевірте шлях, хост і код відповіді. Це заощадить час.

Спершу точно визначте тип збою в Adgora

Adgora може вказувати на різні типи проблем, і кожен з них говорить про щось конкретне. Відсутній файл — це не те саме, що застарілий результат сканування, а невідповідність хоста — не те саме, що цикл перенаправлень.

Уважно прочитайте попередження. Якщо Adgora каже, що файл відсутній, це пряма проблема отримання. Якщо ж зазначено, що файл існує, але статус неправильний, проблема може бути в кешуванні або доставці відповіді. Якщо у попередженні названо конкретний варіант домену, ця підказка важливіша за будь-який загальний чекліст усунення несправностей ads.txt, а також допоможе зрозуміти, як перевірити ads.txt у WordPress без зайвих припущень.

Швидкої перевірки в браузері недостатньо. Ваш браузер може показати файл, завантажений із локального кешу, тоді як сканер 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/ — не найкращий варіант, бо сканер очікує звичайний текстовий файл у корені, а не шлях, схожий на каталог. Дрібниця, але дуже дратує.

На встановленнях із прив’язкою домену mapped domain може нормально працювати для записів, але кореневий хост може збоїти у запитах до файлів. На multisite-мережах таке трапляється частіше, ніж здається.

Перевірте кеші, які можуть віддавати стару або порожню версію

Кешування корисне, поки не стає проблемою. CDN, кеш хоста, кеш плагіна і кеш браузера можуть кожен окремо віддавати стару копію файла або навіть не віддавати його взагалі, хоча живу версію вже виправлено.

Почніть із кешу, який найближчий до відвідувача. Якщо перед WordPress стоїть CDN, спершу очистьте саме його. Потім очистьте кеш хоста, далі — кеш будь-якого плагіна сторінкового кешування, і насамкінець — кеш браузера. Порядок важливий, бо кешована помилка 404 може жити ще годинами після правильного завантаження файла.

Зберіть докази, перш ніж очищати все підряд. Збережіть один скриншот файла в браузері, один скриншот попередження в Adgora і одну мітку часу останнього оновлення. Ці три речі допомагають довести, чи бачив сканер застарілу копію під час перевірки.

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

Якщо ваш хостинг пропонує edge caching, запитайте, чи кешуються текстові файли окремо. Деякі — так. Деякі — ні. Потрібна чітка відповідь, перш ніж вважати файл зламаним.

Переконайтеся, що 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.

Для сайту, пов’язаного з підписками, спонсорством або програмним попитом, цей файл — не декоративний елемент. Це частина налаштування доходу. Одна зламана відповідь може зірвати перевірки покупки, затримати схвалення або змусити покупця засумніватися в шляху інвентарю.

Поставте це виправлення на початок вашого чекліста монетизації WordPress, якщо попередження з’являється на живому кореневому домені й не зникає після очищення кешу. Якщо попередження то з’являється, то зникає, спостерігайте за ним протягом 24 годин, перш ніж вирішити, що проблему вже усунуто.

Не кожне сповіщення коштує дорого. Деякі просто шумні. Але те, що тримається після 2 чистих перевірок, заслуговує негайної уваги.

Якщо ви також керуєте іншими рекламними форматами, тримайте проблему файла окремо від планування кампаній. Наприклад, команди, що працюють над крипто для веб-пуш реклами, часто зосереджуються на трафіку й CTR, а потім пропускають проблему доставки на рівні кореня, яка впливає на кожну перевірку покупця у фоновому режимі.

Шлях ескалації для невирішених випадків, пов’язаних із WordPress

Якщо файл правильний, а попередження все одно не зникає, надішліть підтримці компактний пакет доказів. Не надсилайте лише скриншот. Це тільки сповільнить усіх.

Додайте живий URL, ланцюжок перенаправлень, заголовки відповіді, статус кешу та один-два скриншоти. Якщо ви тестували і www, і non-www, вкажіть обидва. Якщо задіяно CDN, назвіть його. Якщо плагін переписує файл, теж вкажіть його.

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

Якщо ви керуєте кількома сторінками, які залежать від коректної доставки реклами, задокументуйте той самий шлях і для інших ресурсів. Сайт WordPress, який неправильно обробляє /ads.txt, може так само некоректно працювати й з іншими файлами на кореневому рівні, а це вже важливо для рекламних операцій.

Що надіслати в Adgora або вашому хостингу

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

Якщо хочете глибше порівняти ширші варіанти налаштування реклами, посібник із варіантів таргетингу крипторекламної мережі допоможе зрозуміти, чим проблеми доставки відрізняються від проблем аудиторії, що корисно, коли в тікеті підтримки ці дві речі змішуються.

Для видавців, які одночасно ведуть кілька рекламних продуктів, навіть правильний файл можуть не помітити, якщо на сайті є одна проблемна крайова нода або одне правило безпеки. Саме тому останньою перевіркою завжди має бути живий HTTP-відповідь, а не вигляд у редакторі WordPress.

А якщо відповідь неправильна, спершу виправляйте саме відповідь.