Sitemap XML: jednakowy lastmod na wszystkich adresach URL czyni plik bezużytecznym

Plik sitemap XML mówi wyszukiwarkom, które adresy URL istnieją i które się zmieniły. Pierwszą z tych funkcji pełni niemal każdy CMS. Druga wymyka się sporej ich części, i to niezauważalnie: plik jest poprawny, Search Console czyta go bez błędu, a mimo to nie wnosi już żadnej informacji o tym, co się ruszyło. Przyczyna tkwi w jednym polu, lastmod, i w sposobie, w jaki jest ono wypełniane.

Co Google naprawdę robi z polem lastmod

Stanowisko Google jest zapisane czarno na białym w dokumentacji o budowaniu pliku sitemap: wartość lastmod jest wykorzystywana, „jeśli jest spójna i weryfikowalna”, na przykład przez porównanie jej z rzeczywistą ostatnią modyfikacją strony. Google dodaje, że pola priority i changefreq są ignorowane. Z trzech opcjonalnych pól formatu liczy się jedno, i to tylko wtedy, gdy mówi prawdę.

Z punktu widzenia wyszukiwarki rachunek wygląda tak. Robot dysponuje ograniczonym budżetem crawlowania na witrynę. Gdy ponownie czyta plik sitemap, porównuje zadeklarowane daty z tymi, które zapamiętał. Adres URL, którego data przesunęła się do przodu, zasługuje na nowe odwiedziny; adres, którego data się nie ruszyła, może poczekać. Jeśli przy każdym odczycie wszystkie daty przesuwają się jednocześnie, wyszukiwarka nie odróżni już strony rzeczywiście zaktualizowanej od strony niezmienionej. W końcu przestaje ufać temu polu i wraca do własnych heurystyk, zwykle wolniejszych.

Typowy defekt: data przebudowy

Wiele generatorów stron statycznych i niemało systemów CMS wpisuje w lastmod datę, w której witryna została przebudowana. W witrynie publikującej codziennie wszystkie adresy URL noszą wtedy datę bieżącego dnia, łącznie z artykułami sprzed trzech lat, których nikt nie tknął. Plik sitemap bez przerwy ogłasza, że zmieniło się wszystko.

Sprawdziliśmy ten defekt latem 2026 roku na kilku witrynach produkcyjnych, łącznie na ponad trzystu adresach URL: w każdym przypadku jedna jedyna wartość lastmod dla całego pliku sitemap, równa godzinie ostatniej przebudowy. Żadna z tych witryn nie wysyłała przy tym na swoich stronach nagłówka HTTP Last-Modified ani ETag i żadna nie odpowiadała na żądania warunkowe robotów. Wyszukiwarka nie miała więc jak się dowiedzieć, co przeładować.

Diagnoza w trzech kontrolach

Kontrola zajmuje kilka minut i wystarczy do niej zwykły terminal.

1. Policzyć odrębne wartości lastmod. Pobrać plik sitemap, wyciągnąć znaczniki lastmod i policzyć wartości unikalne. Zdrowy plik sitemap witryny liczącej kilkaset stron ma ich kilkadziesiąt. Jedna wartość, albo garstka wartości z tego samego dnia, świadczy o defekcie.
2. Porównać lastmod ze stroną. Wziąć stary adres URL z pliku sitemap, otworzyć stronę i porównać datę modyfikacji widoczną w artykule lub w jego danych strukturalnych z wartością lastmod. Rozbieżność rzędu kilku miesięcy potwierdza, że lastmod nie opisuje strony.
3. Przetestować nagłówki HTTP. Poprosić o stronę żądaniem HEAD i sprawdzić, czy serwer odsyła Last-Modified albo ETag. Następnie powtórzyć to samo żądanie z If-Modified-Since ustawionym na otrzymaną datę. Serwer, który odpowiada 304 Not Modified, potrafi powiedzieć, że strona się nie zmieniła; serwer, który za każdym razem odsyła 200, zmusza robota do pobrania wszystkiego od nowa.

Te trzy testy nie wymagają żadnego płatnego narzędzia. Należą do kontroli, które zalecamy przed jakąkolwiek rozmową o indeksowaniu serwisu medialnego.

Dlaczego dla serwisu medialnego jest to groźniejsze niż dla witryny wizytówkowej

Witryna wizytówkowa licząca dwadzieścia stron i tak zostanie odwiedzona przez roboty w całości. Serwis medialny, który publikuje kilka artykułów tygodniowo, a inne poprawia, żyje z wiarygodnego sygnału świeżości: to on podnosi zaktualizowany artykuł i to on oszczędza robotowi wydawania budżetu na strony zamrożone. Gdy sygnał jest zepsuty, po kilku tygodniach pojawiają się dwa objawy:

• Nowe artykuły potrzebują więcej czasu na zaindeksowanie, bo toną w pliku sitemap, w którym wszystko wygląda na nowe.
• Poprawki w starych artykułach nie są uwzględniane, bo nic nie odróżnia strony poprawionej od strony, którą po prostu odtworzyła przebudowa.

W serwisie medialnym, który celuje także w silniki generatywne, problem płaci się po raz drugi: dziedziczą go roboty wyszukiwarek AI, opierające się na tych samych plikach sitemap. Treść zmieniona po to, by poprawić jedną liczbę, przez tygodnie jest nadal serwowana w starej wersji.

Kryterium poprawki

Poprawienie defektu polega na tym, by lastmod niosło datę ostatniej zmiany redakcyjnej każdej strony, i nic więcej. Konkretnie:

Kryterium odbioru jest takie samo jak kryterium diagnozy: po poprawce liczba odrębnych wartości lastmod ma odzwierciedlać rzeczywistą historię serwisu, a dwie kolejne przebudowy bez zmiany redakcyjnej mają dać dwa identyczne pliki sitemap. Jeśli plik sitemap zmienia się, choć nic nie zostało napisane, poprawka nie jest zrobiona.

Szczególny przypadek serwisu w podkatalogu

Gdy serwis medialny jest hostowany pod ścieżką witryny głównej, na przykład jako blog serwowany pod /blog/ z innej platformy, dochodzi druga trudność: plik robots.txt deklarujący sitemap jest czytany wyłącznie w katalogu głównym hosta. Plik robots.txt umieszczony w podkatalogu nigdy nie zostaje pobrany, a zawarte w nim wiersze Sitemap dla wyszukiwarek nie istnieją, o czym przypomina dokumentacja Google o robots.txt. Trzeba wtedy zadeklarować sitemap serwisu w pliku robots.txt witryny głównej albo przesłać go bezpośrednio w Search Console. Google wycofało w 2023 roku możliwość „pingowania” pliku sitemap zwykłym żądaniem HTTP: bez wyraźnej deklaracji serwis w podkatalogu nie ma żadnego kanału odkrycia.

Oba te defekty, jednakowe lastmod i nieodkryty sitemap, poprawia się raz na zawsze na poziomie narzędzia publikacyjnego. To rodzaj szczegółu, który CMS pomyślany dla serwisu medialnego ma rozwiązywać z założenia, bo żadna redakcja nie sprawdzi go ręcznie przy każdej publikacji. Co do pozostałych sygnałów świeżości, czyli widocznej daty aktualizacji i danych strukturalnych, odsyłamy do naszego artykułu „Świeżość: datować, aktualizować, udowodnić”.