unavailable_after w praktyce: czyli harmonogram dla Googlebota

Dyrektywa, która brzmi jak automat, a działa jak prośba

Wyobraź sobie serwis ogłoszeniowy: 5000 stabilnych URL’i w indeksie jako baza, i do tego 10 000 nowych ogłoszeń miesięcznie, z których każde żyje od 24 do 72 godzin. Klasyczny problem takiej architektury: co zrobić z URL’em, gdy ogłoszenie wygasa? Zostawić go, żeby zbierał 404 na masową skalę i psuł statystyki crawlowania? Nie, bo można to rozwiązać czysto – dosłownie 1 dyrektywą, która z góry informuje Googlebota, że treść ma ograniczoną datę ważności.

unavailable_after jest harmonogramem, który Googlebot sprawdza tylko wtedy, gdy sam zdecyduje się zajrzeć na daną stronę – a kiedy to nastąpi zależy od zupełnie innych mechanizmów niż data zapisana w nagłówku.

Co dyrektywa faktycznie robi

unavailable_after to dyrektywa dostępna w <meta name="robots"> i w nagłówku X-Robots-Tag. Prosi wyszukiwarkę żeby nie pokazywała danej strony w wynikach wyszukiwania PO wskazanej dacie i godzinie. To wszystko.

Nie usuwa strony z serwera, nie wymusza kodu odpowiedzi 404 czy 410, nie zmienia niczego w samej treści. To czysta instrukcja adresowana do mechanizmu selekcji wyników wyszukiwania.

Format daty ma znaczenie

Dokumentacja dopuszcza kilka standardów: RFC 822, RFC 850 oraz ISO 8601. To dość szerokie pole manewru ale reguła jest ignorowana, jeśli nie da się z niej odczytać poprawnej daty. Nie ma tu żadnego mechanizmu ostrzegawczego. Google nie zgłosi błędu w Search Console, po prostu zignoruje regułę tak, jakby jej nie było. Dla systemu generującego tę wartość automatycznie, na podstawie pola daty w bazie danych CMS’a, to jest realne ryzyko:

• błąd w formacie strefy czasowej
• złe ustawienia lokalne przy renderowaniu daty
• literówka w nazwie miesiąca w formacie RFC 822

Każda z tych rzeczy sprawia, że dyrektywa przestaje działać. Brak dyrektywy oznacza brak ograniczenia czasowego, czyli treść może pozostawać w wynikach bezterminowo. unavailable_after jest rozwiązaniem opt-in – trzeba dodać je świadomie, nic nie dzieje się automatycznie.

Googlebot ma obniżyć częstotliwość crawlowania konkretnego adresu URL po przekroczeniu podanej daty i godziny. W sumie to jedyny fragment, który mówi cokolwiek o zachowaniu Googlebota PO wygaśnięciu terminu. To zdanie zestawiłem z inną informacją (o której za chwilę), tworzy paradoks przesuwanej daty.

3 mylne założenia, które prowadzą do błędnych wdrożeń

Czym NIE JEST dyrektywa unavailable_after

1. To nie zamiennik dla 404 czy 410 – strona nadal odpowiada kodem 200 i zostaje w pełni dostępna. Jedyne, co się zmienia, to sygnał wysyłany do mechanizmu decydującego, czy dany URL ma prawo pojawiać się w wynikach wyszukiwania. Dlatego jeśli dany zasób już nie wróci, to właściwym kodem będzie 404 lub 410
2. To nie oszczędza crawl budgetu’ – Googlebot musi najpierw pobrać pełną treść strony. Nie zmniejsza to liczby ani kosztu wizyt. Zmienia tylko to, co dzieje się z URL’em w indeksie PO takiej wizycie. Szerzej opisałem to w sekcji mitu szybkiego sprawdzenia
3. To nie usuwa z wyników o podanej dacie i godzinie – przekroczenie daty jest sygnałem „można to teraz zrzucić z indeksu”, realizowanym dopiero przy najbliższej wizycie crawlera. Dla treści żyjącej określony czas może oznaczać kilkudniowe opóźnienie między formalnym wygaśnięciem, a realnym zniknięciem z wyników

Te trzy założenia doprowadziły do pytania, które padło publicznie wprost do zespołu Google Search, a które stało się kanwą dla najciekawszej części tego artykułu 🔥

Case study: pytanie, którego nie ma w dokumentacji

Historia zaczyna się od posta na LinkedIn, zaadresowanego wprost do Johna Muellera, Gary’ego Illyesa i Martina Splitta.

#seo #google Hi Google Search team, John Mueller Gary Illyes Martin Splitt
I manage a classifieds site with a very high content rotation. We have a stable base of about 5,000 indexed URLs, but every month we generate around 10,000 new listings with very short lifespans (typically 24 to 72 hours).
To prevent massive 404 errors and manage our crawl budget, we want to implement the unavailable_after meta tag across all short-lived listings. However, users can renew their ads, which means our system would dynamically push the unavailable_after date further into the future on the fly.
My question is: Are there any negative SEO implications if Googlebot sees the unavailable_after date constantly shifting forward on the same URL? Will Googlebot eventually start ignoring the tag due to these frequent changes, or is it completely fine to use it dynamically to manage indexation life-cycles in a high-turnover environment?
Thanks!

Po przetłumaczeniu na język polski

#seo #google Witam zespół Google Search: Johna Muellera, Gary’ego Illyesa i Martina Splitta
Zarządzam serwisem ogłoszeniowym, w którym treści zmieniają się bardzo szybko. Mamy stabilną bazę około 5,000 zindeksowanych adresów URL, ale co miesiąc generujemy około 10,000 nowych ogłoszeń o bardzo krótkim okresie ważności (zazwyczaj od 24 do 72 godzin).
Aby zapobiec masowemu występowaniu błędów 404 i zarządzać naszym budżetem indeksowania, zamierzamy wdrożyć metatag „unavailable_after” we wszystkich ogłoszeniach o krótkim okresie ważności. Użytkownicy mogą jednak przedłużyć swoje ogłoszenia, co oznacza, że nasz system będzie dynamicznie przesuwał datę „unavailable_after” w przyszłość w czasie rzeczywistym. Moje pytanie brzmi: czy istnieją jakieś negatywne konsekwencje dla SEO, jeśli robot Googlebot zauważy, że data „unavailable_after” w tym samym adresie URL nieustannie się przesuwa w przyszłość? Czy robot Googlebot w końcu zacznie ignorować ten tag z powodu tych częstych zmian, czy też jego dynamiczne stosowanie w celu zarządzania cyklem życia indeksacji w środowisku o dużej rotacji treści jest całkowicie dopuszczalne?
Dziękuję!

Pytanie: czy dynamiczne przesuwanie daty w przód, wielokrotnie na tym samym URL’u może mieć negatywne konsekwencje SEO i czy Google może zacząć ignorować dyrektywę z powodu częstych zmian.

To pytanie nie ma odpowiedzi w żadnym oficjalnym dokumencie Google. Dokumentacja opisuje unavailable_after jako mechanizm ze statyczną, jednorazową datą – nigdzie nie odnosi się do scenariusza, w którym ta data jest ruchoma, aktualizowana za każdym razem, gdy użytkownik klika „odnów ogłoszenie”.

Gary Illyes odpisał:

„that’s a great question… I have no idea, I have to check. my gut feeling is that it’s fine to push forward the unavailable_after date BUT you need to keep in mind that we’ll need to crawl the page again to 'see’ the new date. it doesn’t have implications on anything but index selection, where it acts as a 'you can drop this now’ signal”

Po przetłumaczeniu na język polski

To świetne pytanie… Nie mam pojęcia, muszę to sprawdzić. Mam przeczucie, że przesunięcie daty „unavailable_after” w przyszłość jest w porządku, ALE trzeba pamiętać, że będziemy musieli ponownie przeszukać stronę żeby zobaczyć” nową datę. Nie ma to wpływu na nic poza wyborem indeksu, gdzie działa to jako sygnał „można to teraz usunąć”

Odpowiedź jest o tyle ciekawa, że widzę tu 3 bardzo ważne elementy:

1. „I have no idea, I have to check” – Gary przyznaje, że nie zna odpowiedzi i musi ją sprawdzić wewnętrznie. Dynamiczne przesuwanie daty przy odnawianych ogłoszeniach nie jest udokumentowanym, przetestowanym przypadkiem użycia po stronie Google. To obszar szarej strefy nawet dla Google 😀
2. „my gut feeling is that it’s fine to push forward the unavailable_after date” – warto zwrócić uwagę, że „gut feeling”, czyli przeczucie (intuicja zawodowa?), a nie fakt oparty na zweryfikowanych danych czy dokumentacji wewnętrznej
3. „we’ll need to crawl the page again to 'see’ the new date” – nowa data nie jest automatycznie zauważana przez Google w momencie jej zmiany na serwerze. Musi nastąpić ponowna wizyta crawlera na danym URL’u ale to logiczne. Googlebot wchodzi, czyta i aktualizuje dane.
4. „it acts as a 'you can drop this now’ signal” – brak wpływu na ranking. Działa tylko i wyłącznie jako sygnał dla decyzji o obecności w indeksie

Mit szybkiego sprawdzenia: dlaczego header nie daje przewagi, na którą liczono

Autor posta w komentarzu już napisał, że serwer mógłby odpowiedzieć na lekkie zapytanie HEAD, a wtedy Googlebot odczytałby datę z X-Robots-Tag bez pobierania całego dokumentu. Dopiero jeśli treść jest nadal aktualna, wykonałby pełne zapytanie GET. Oszczędność zasobów po obu stronach. Na co Gary Illyes odpisał, że w Google rzadko widzą żądania HEAD, więc i tak zawartość byłaby pobrana.

W takim razie umieszczenie unavailable_after w nagłówku X-Robots-Tag zamiast w meta tagu HTML nie daje przewagi w kontekście oszczędzania crawl budgetu. Googlebot i tak wykonuje pełne żądanie GET.

To nie neguje sensu stosowania X-Robots-Tag, ponieważ tam gdzie meta tag HTML fizycznie nie może istnieć (np. pliki pdf, obrazy) to właśnie X-Robots-Tag pomaga. W kontekście stron HTML wybór między nagłówkiem, a meta tagiem nie rozwiązuje problemu z crawl budgetem.

Paradoks przesuwanej daty – kiedy mechanizm działa przeciwko sobie

Składając fakt z dokumentacji oraz wypowiedzi jaką dostarczył Gary Illyes od razu nasuwa mi się pewna sekwencja zdarzeń. Fakty:

1. Z dokumentacji – po przekroczeniu daty w unavailable_after, Google obniża częstotliwość crawlowania danego URL
2. Z wypowiedzi – żeby Google zobaczył nową, przesuniętą datę, musi ponownie przecrawlować stronę.

Sekwencja zdarzeń

1. ogłoszenie ma datę wygaśnięcia w piątek
2. użytkownik odnawia je dopiero w poniedziałek, czyli 3 dni po terminie
3. system przesuwa datę o dwa tygodnie do przodu.

Problem jaki tu widzę:

1. Google, widząc że pierwotna data minęła, mógł już zdążyć obniżyć częstotliwość odwiedzin tego URL
2. Nowa data może więc zostać zauważona z opóźnieniem większym niż standardowe, dokładnie dlatego, że mechanizm oszczędzający zasoby crawlowania zdążył już zadziałać na niekorzyść tego konkretnego URL

Dyrektywa zaprojektowana, żeby uprościć zarządzanie cyklem życia treści może doprowadzić do sytuacji, w której odnowiona oferta jest przez dłuższy czas traktowana tak jakby nadal była wygasła 🤷‍♂️

Rekomendacja: dla stron z ogłoszeniami i e-commerce nie polegałbym tylko na zmianie wartości unavailable_after przy odnowieniu po terminie. Wymusiłbym dodatkowo ponowną wizytę Googlebota przez zgłoszenie aktualizacji w Indexing API.

Kiedy używać unavailable_after, a kiedy coś innego

Interaktywna macierz decyzji

Harmonogram dla Googlebota

unavailable_after to zaplanowana, warunkowa wersja noindex. Mówi Google „to kryterium czasowe zostało spełnione, masz teraz prawo usunąć tę treść”, zamiast usuwać ją samodzielnie w precyzyjnym momencie.

Skuteczność tego narzędzia zależy od częstotliwości wizyt Googlebota dla danego adresu URL, a ta zależy od wielu innych czynników, np. ogólnej wartości strony w oczach algorytmów Google, historii crawlowania danego URL, tego czy strona wygasła niedawno czy dawno temu, oraz sygnałów z zewnątrz.