Błędy ads.txt w WordPressie i Adgora

Gdy problem dotyczy WordPressa, a nie zawartości ads.txt

Czasem plik jest na miejscu, a ostrzeżenie i tak nie znika. I właśnie to jest najbardziej irytujące. Problem nie zawsze leży w tekście wewnątrz pliku; w WordPressie często awaria jest o poziom niżej — w tym, jak witryna dostarcza ten plik robotowi indeksującemu.

Jeśli dodałeś już ads.txt, a Adgora nadal zgłasza problem, najpierw pomyśl o zachowaniu WordPressa: routingu URL, przekierowaniach, wersjach z pamięci podręcznej, regułach hostingu i filtrach bezpieczeństwa. Wydawca może mieć poprawny plik na dysku, a mimo to widzieć błąd ads.txt WordPress, bo żądanie nie trafia do właściwej odpowiedzi.

To częste na stronach, gdzie jednocześnie działa kreator motywu, CDN i wtyczka cache’ująca. Jedno ustawienie zmienia odpowiedź, inne ją buforuje, a trzecie sprawia, że przeglądarka wygląda na działającą poprawnie, podczas gdy robot dostaje coś innego — dlatego Adgora ads.txt nie działa, choć na pierwszy rzut oka wszystko wygląda dobrze.

Nie zaczynaj od przepisywania pliku. Zacznij od sprawdzenia ścieżki, hosta i kodu odpowiedzi. To oszczędza czas.

Najpierw ustal dokładny rodzaj błędu w Adgora

Adgora może wskazywać różne typy problemów, a każdy z nich mówi coś konkretnego. Brakujący plik to nie to samo co przestarzały odczyt, a niezgodny host to nie to samo co pętla przekierowań.

Przeczytaj ostrzeżenie dokładnie. Jeśli Adgora mówi, że plik nie istnieje, to bezpośredni problem z pobraniem. Jeśli pisze, że plik istnieje, ale status jest nieprawidłowy, wtedy problem może leżeć w cache’u albo dostarczaniu odpowiedzi. Jeśli ostrzeżenie podaje konkretną wersję domeny, ta wskazówka jest ważniejsza niż jakakolwiek ogólna lista rozwiązywania problemów z ads.txt.

Szybki test w przeglądarce nie wystarczy. Twoja przeglądarka może pokazywać plik wczytany z lokalnej pamięci podręcznej, podczas gdy robot Adgora pobiera świeżo żywy adres URL. Ta różnica wyjaśnia wiele fałszywych alarmów.

Zapisz 4 rzeczy, zanim cokolwiek zmienisz: dokładny tekst ostrzeżenia, adres URL oczekiwany przez Adgora, aktualny działający adres URL oraz to, czy plik był aktualizowany w ciągu ostatnich 24 godzin. Te dane szybko zawężają źródło problemu.

Jeśli panel pokazuje jeden host, a Twoja witryna odpowiada pod innym, nie masz jednego problemu. Masz dwa punkty końcowe.

Sprawdź, jak WordPress obsługuje domenę główną i popularne warianty

WordPress może udostępniać tę samą stronę pod kilkoma adresami: z www i bez www, przez HTTP i HTTPS, a czasem także pod domeną mapowaną w konfiguracji multisite. Adgora może sprawdzać jedną wersję, podczas gdy Ty testujesz inną.

Ma to znaczenie, bo ads.txt jest wykrywany w katalogu głównym. Żądanie do https://example.com/ads.txt nie jest tym samym co https://www.example.com/ads.txt, nawet jeśli strona główna wygląda identycznie. Jedno przekierowanie jest normalne; dwa albo trzy mogą zmylić robota, zwłaszcza jeśli łańcuch kończy się na stronie, która w ogóle nie jest tym plikiem.

Sprawdź kanoniczną wersję witryny w ustawieniach WordPressa, a potem porównaj ją z adresem URL używanym przez Adgora. Jeśli adres WordPressa i adres witryny są różne, odnotuj tę różnicę. Może ona wysłać żądanie do złego hosta, zanim plik w ogóle zostanie uwzględniony.

Ważna może być też końcówka ze slashem. Przekierowanie z /ads.txt do /ads.txt/ nie jest idealne, ponieważ robot oczekuje zwykłego pliku tekstowego w katalogu głównym, a nie ścieżki wyglądającej jak katalog. Mały szczegół, duża irytacja.

W instalacjach z mapowaniem domen domena przypisana może działać dla wpisów, podczas gdy host główny nie radzi sobie z żądaniami plików. Zdarza się to na sieciach multisite częściej, niż ludzie przypuszczają.

Sprawdź warstwy cache, które mogą podawać starą albo pustą wersję

Cache jest świetny — dopóki przestaje być. CDN, cache hostingu, cache wtyczki i cache przeglądarki mogą każdy z osobna podawać starszą kopię pliku albo w ogóle nie podawać pliku, nawet po naprawieniu wersji na żywo.

Zacznij od cache’u najbliżej odwiedzającego. Jeśli przed WordPressem stoi CDN, wyczyść go jako pierwszy. Potem opróżnij cache hostingu, następnie cache wtyczki, a na końcu cache przeglądarki. Kolejność ma znaczenie, bo zbuforowany błąd 404 może utrzymywać się godzinami mimo poprawnego wgrania pliku.

Zbierz dowody, zanim wszystko wyczyścisz. Zapisz jeden zrzut ekranu pliku w przeglądarce, jeden zrzut ostrzeżenia w Adgora i jedną sygnaturę czasu ostatniej aktualizacji. Te trzy rzeczy pomagają wykazać, czy robot widział przestarzałą kopię podczas sprawdzania.

Zespoły zajmujące się monetyzacją WordPressa często zapominają, że reguły cache mogą traktować /ads.txt inaczej niż zwykłe strony. Cache strony może pomijać HTML, ale reguła serwera albo cache na brzegu CDN nadal może zwracać stara odpowiedź tekstową. To właśnie tutaj niewielki plik powoduje duże opóźnienie.

Jeśli hosting oferuje cache na brzegu, zapytaj, czy pliki tekstowe są buforowane osobno. Niektóre tak. Inne nie. Potrzebujesz odpowiedzi, zanim uznasz, że plik jest uszkodzony.

Sprawdź, czy WordPress nie przepisuje pliku ani go nie ukrywa

Wiele narzędzi WordPressa może zakłócać poprawną odpowiedź ads.txt. Wtyczki bezpieczeństwa mogą blokować bezpośredni dostęp do pliku. Wtyczki wydajnościowe mogą kompresować lub przepisywać ścieżki statyczne. Wtyczki wielojęzyczne mogą próbować lokalizować adres URL, który powinien pozostać prosty i dokładny.

Dodatkowym ryzykiem są narzędzia do wdrażania ze stagingu na produkcję. Wdrożenie może nadpisać katalog główny starszą wersją pliku albo opublikować tylko wybrane ścieżki i pominąć ads.txt. Reguły hostingu zarządzanego też mogą przenosić plik lub chronić katalog główny, co łatwo przeoczyć, bo panel wygląda wtedy zupełnie normalnie.

Sprawdź, czy któraś wtyczka ma funkcję ochrony plików. Wyłącz każde ustawienie, które przepisuje żądania do katalogu głównego dla plików tekstowych. Potem sprawdź ponownie. Jedno ustawienie może zniweczyć dziesięć minut starannej pracy.

Przyjrzyj się też zadaniom planowanym. Niektóre wtyczki optymalizacyjne odtwarzają pliki według harmonogramu. Jeśli ads.txt się zmienia, a godzinę później wraca do poprzedniej wersji, możliwe, że zadanie cron przywraca starą kopię.

Jeśli witryna używa warstwy wielojęzycznej, upewnij się, że ads.txt nie jest serwowany przez folder językowy ani przetłumaczoną ścieżkę. Powinien pozostać w katalogu głównym, a nie pod /en/ ani żadnym innym podścieżką.

Użyj bezpośrednich testów odpowiedzi, aby sprawdzić, co naprawdę otrzymują roboty

Otwarcie pliku w przeglądarce mówi tylko tyle, co zobaczyła Twoja przeglądarka. Nie dowodzi, co zobaczył robot. Lepsze są bezpośrednie testy odpowiedzi, bo pokazują dokładny wynik HTTP dla żądania.

Sprawdź /ads.txt i zanotuj, czy odpowiedź ma kod 200, 301, 302, 403 czy 404. 200 to cel. 301 albo 302 oznacza, że plik jest przenoszony, zanim zostanie odczytany. 403 oznacza blokadę. 404 oznacza, że żądanie nie znalazło użytecznego pliku.

Sprawdź też treść odpowiedzi. Jeśli body zawiera HTML, stronę motywu albo komunikat o konserwacji, robot nie dostał zwykłego pliku ads.txt. To właśnie dlatego samo testowanie w przeglądarce może wprowadzać w błąd.

Użyj jednego bezpośredniego adresu URL i jednego wariantu z prefiksem www. Jeśli jeden działa, a drugi nie, problem nie dotyczy zawartości pliku. Problem dotyczy obsługi hosta.

To moment, w którym wiele zespołów przestaje zgadywać i zaczyna mierzyć. Dobra decyzja.

Co zapisać podczas bezpośredniego sprawdzenia

• Dokładny adres URL, włącznie z wariantem z www lub bez www.
• Kod statusu HTTP.
• Każdy cel przekierowania.
• Pierwsze 5 linii treści odpowiedzi.
• Nazwę serwera lub CDN z nagłówków.

Wpływ na monetyzację WordPressa: kiedy traktować ostrzeżenie jako ryzyko dla przychodów

Nie każde ostrzeżenie o ads.txt oznacza, że pieniądze tracą się tu i teraz. Czasem ostrzeżenie jest nieaktualne, a plik jest już poprawny. Czasem to fałszywy alarm po poprzednim odczycie robota.

Mimo to traktuj problem poważnie, gdy ostrzeżenie utrzymuje się dłużej niż jeden cykl odczytu albo gdy kilka narzędzi po stronie kupującego zgłasza niezgodność. Wtedy zaufanie kupujących i procesy monetyzacji mogą zacząć cierpieć, zwłaszcza jeśli korzystasz z wielu źródeł reklam i opierasz się na weryfikacji ads.txt, aby utrzymać przejrzyste ścieżki dostaw.

W przypadku witryny powiązanej z subskrypcjami, sponsoringiem lub popydem programmatic ten plik nie jest ozdobą. To element konfiguracji przychodów. Jedna uszkodzona odpowiedź może przerwać sprawdzanie zakupu, opóźnić akceptację albo skłonić kupującego do zakwestionowania ścieżki zasobów.

Umieść tę naprawę wysoko na liście kontrolnej monetyzacji WordPressa, jeśli ostrzeżenie pojawia się na działającej domenie głównej i pozostaje po wyczyszczeniu cache’u. Jeśli ostrzeżenie pojawia się i znika, obserwuj je przez 24 godziny, zanim uznasz problem za rozwiązany.

Nie każde powiadomienie jest kosztowne. Niektóre są po prostu hałaśliwe. Ale to, które utrzymuje się mimo 2 czystych sprawdzeń, zasługuje na natychmiastową uwagę.

Jeśli zarządzasz też innymi formatami reklam, oddziel problem z plikiem od planowania kampanii. Na przykład zespoły pracujące nad reklamami push w sieci kryptoreklam często skupiają się na ruchu i CTR, a pomijają problem dostarczania na poziomie głównym, który w tle wpływa na każdą weryfikację kupującego.

Ścieżka eskalacji dla nierozwiązanych przypadków specyficznych dla WordPressa

Jeśli plik jest poprawny, a ostrzeżenie nadal nie znika, wyślij do wsparcia zwięzły pakiet dowodów. Nie wysyłaj tylko zrzutu ekranu. To spowalnia wszystkich.

Dołącz działający adres URL, łańcuch przekierowań, nagłówki odpowiedzi, status cache i jeden lub dwa zrzuty ekranu. Jeśli testowałeś zarówno www, jak i bez www, podaj oba warianty. Jeśli bierze udział CDN, nazwij go. Jeśli wtyczka przepisuje plik, też ją nazwij.

Zespoły wsparcia mogą szybciej zweryfikować problem, gdy widzą dokładną ścieżkę. Niejasna notatka typu „nadal nie działa” uruchamia kolejną rundę pytań. Notatka typu https://example.com/ads.txt zwraca 302 do https://www.example.com/ads.txt, a potem 403 z cache hostingu, jest znacznie bardziej użyteczna.

Jeśli prowadzisz wiele stron zależnych od poprawnego dostarczania reklam, udokumentuj tę samą ścieżkę także dla innych zasobów. Witryna WordPress, która źle obsługuje /ads.txt, może też źle obsługiwać inne pliki z katalogu głównego, a to ma znaczenie dla operacji reklamowych.

Co wysłać do Adgora lub hostingu

• Dokładny działający adres URL, który powinien obsługiwać ads.txt.
• Kopię łańcucha przekierowań, jeśli istnieje.
• Kod statusu odpowiedzi i nagłówki.
• Sygnaturę czasu ostatniego czyszczenia cache’u.
• Dwa zrzuty ekranu: wynik w przeglądarce i ostrzeżenie Adgora.

Jeśli chcesz głębiej porównać szersze opcje konfiguracji reklam, przewodnik po opcjach targetowania w sieci kryptoreklam może pomóc rozdzielić problemy z dostarczaniem od problemów z odbiorcami, co jest przydatne, gdy zgłoszenie do wsparcia zaczyna mieszać te dwa obszary.

W przypadku wydawców obsługujących kilka produktów reklamowych jednocześnie nawet poprawny plik może zostać przeoczony, jeśli witryna ma jeden wadliwy węzeł brzegowy albo jedną regułę bezpieczeństwa. Dlatego ostatnim sprawdzeniem zawsze powinno być rzeczywiste HTTP response na żywo, a nie widok edytora w WordPressie.

A jeśli odpowiedź jest błędna, najpierw napraw odpowiedź.