Czy lastmod w sitemapie mówi prawdę? Audyt wielu domen

Automatyczny lastmod w sitemapie, który zmienia się przy każdym zapisie w CMS, niszczy wartość sygnału świeżości na całej domenie. Gary Illyes z Google (lipiec 2026) wprost powiedział na Bluesky, że serwisy z nieprawidłowymi datami lastmod powinny je usunąć całkowicie. John Mueller wcześniej nazwał praktykę aktualizowania lastmod bez zmian treści „lazy” i ostrzegł, że Google może zacząć ignorować ten sygnał całkowicie. W Semgence audytowaliśmy lastmod na projektach klienckich na różnych CMS-ach – wyniki potwierdzają: większość zmian lastmod nie odpowiada rzeczywistej zmianie treści.

Carlo Cuman opisuje ten problem dosadnie: „AI widzi updated yesterday na 200 stronach, crawluje je oczekując świeżej treści, nie znajduje nic nowego i uczy się nie ufać Twoim sygnałom świeżości. Gdy publikujesz naprawdę nową treść, zostaje zdepriorytyzowana, bo erodowałeś algorytmiczne zaufanie latami fałszywych sygnałów.”

Metodologia: audyt lastmod na projektach klienckich na Shoper i WordPress. Porównanie lastmod z sitemapy z rzeczywistą zmianą treści głównej (diff HTML pobrany przez Crawl4AI). Dane z GSC URL Inspection (lastCrawlTime) na kontrolnej próbie. Logi serwera (BingBot, GPTBot) jako dodatkowy sygnał. Eksperyment przeprowadził Paweł Gontarek (Zgred) z agencji Semgence.

Jak CMS-y generują fałszywe sygnały lastmod?

Problem jest systemowy, nie incydentalny. Większość CMS-ów aktualizuje lastmod przy każdym zapisie rekordu w bazie danych – niezależnie od tego, czy zmieniła się treść widoczna dla użytkownika i crawlera.

CMS	Kiedy lastmod się zmienia	Czy treść się zmienia	Efekt
WordPress	Każdy klik „Zaktualizuj”, zmiana kategorii, tagu, miniaturki	Często nie	Masowe fałszywe sygnały
Shopify	Każda edycja metafieldów, zmiana kolekcji	Często nie	Poza kontrolą sprzedawcy
Shoper	Każda zmiana ceny wariantu, stanu magazynowego	Częściowo (cena tak)	Mieszany sygnał
PrestaShop	Każda zmiana atrybutu, pozycji w kategorii	Często nie	Masowe fałszywe sygnały
Custom CMS	Zależy od implementacji	Zależy	Brak kontroli = brak zaufania

Na dużym serwisie e-commerce (10 000+ URL-i) ten mechanizm generuje falę fałszywych sygnałów codziennie. Robot widzi 500 URL-i z „zmienioną” datą w sitemapie, crawluje je, nie znajduje zmian w treści głównej – i obniża priorytet całej domeny. LinkSurge w strategii sitemap z 2026 podkreśla: „buduj lastmod wokół wykrywania rzeczywistych zmian, nie wokół timestampów CMS”.

Shoper jest ciekawym przypadkiem: zmiana ceny wariantu to rzeczywista zmiana treści widocznej na stronie. Ale zmiana pozycji produktu w sortowaniu kategorii – nie. Problem polega na tym, że CMS nie rozróżnia tych dwóch zdarzeń. Oba aktualizują lastmod identycznie. Robot nie ma możliwości odróżnienia prawdziwego sygnału od szumu.

InstantSitemap wyjaśnia, jak Google określa budżet crawlu: nie przez priority i changefreq z sitemapy (Google oficjalnie ich nie używa), ale przez własne obserwacje: autorytet i profil linkowy serwisu, obserwowana częstotliwość zmian (ile razy faktycznie zmieniła się treść między kolejnymi crawlami) i czas odpowiedzi serwera. Jeśli Google wielokrotnie pobiera stronę z nową datą i nie znajduje zmian treści, obserwowana częstotliwość zmian spada do zera – nawet jeśli lastmod twierdzi, że strona zmienia się codziennie.

Co mówią Google, Bing i patenty o wartości lastmod?

Gary Illyes z Google na Bluesky (lipiec 2026) powiedział wprost: serwisy z nieprawidłowymi datami lastmod powinny je usunąć całkowicie – lepiej nie mieć lastmod niż mieć nieprawdziwy. John Mueller wcześniej nazwał aktualizowanie lastmod bez zmian treści „lazy” i ostrzegł, że Google może zacząć ignorować cały sygnał z sitemapy takiej domeny.

Wrodium w przewodniku o Knowledge Freshness Signals radzi: „oddziel daty Published/Modified od timestampów systemowych CMS. Świeżość napędza cytowania AI, gdy jest spójna, weryfikowalna i powiązana z rzeczywistą konserwacją redakcyjną.” Jeśli lastmod kłamie, system AI uczy się ignorować Twoje sygnały świeżości – a gdy faktycznie aktualizujesz treść, system już nie ufa Twojej dacie.

Patent US7346839B2 (Google, 2008) opisuje mechanizm, w którym system może porównywać deklarowaną datę modyfikacji z rzeczywistą zmianą treści. Zmiany elementów mało istotnych (boilerplate, reklamy, JavaScript, znaczniki daty) mogą otrzymywać małą wagę lub zostać pominięte. Patent US20130144858A1 opisuje harmonogramowanie crawli na podstawie przewidywanej wartości zasobu – jeśli robot wielokrotnie pobiera stronę z nową datą i nie znajduje zmian, może obniżyć priorytet crawlu tej strony.

Wzorce z audytów: gdzie lastmod kłamie najczęściej?

Na projektach klienckich Semgence powtarza się jeden schemat: procent prawdziwych zmian lastmod zależy od typu strony, nie od CMS-a. Karty produktów z cenami zmieniającymi się regularnie mają najwyższy odsetek uzasadnionych zmian lastmod – bo zmiana ceny to rzeczywista zmiana treści widocznej dla użytkownika. Kategorie i listingi mają najniższy – sortowanie, dodanie tagu lub zmiana kolejności produktów aktualizuje timestamp w bazie, ale nie zmienia treści, którą widzi crawler. Blog jest pośredni: zmiana kategorii lub tagu posta to fałszywy sygnał, ale edycja treści artykułu – prawdziwy.

Ten podział per typ strony jest ważniejszy niż podział per CMS. WordPress, Shoper i PrestaShop generują fałszywe lastmod z tych samych powodów – bo traktują każdy zapis rekordu w bazie identycznie, bez sprawdzania, czy zmieniła się treść główna. Różnią się tylko częstotliwością: sklep z 3 000 produktów na Shoper z aktualizacją stanów co godzinę generuje dziesiątki tysięcy fałszywych sygnałów dziennie (opisany poniżej), podczas gdy blog na WordPress z 200 postami – kilkanaście tygodniowo.

Przypadek negatywny: gdy prawdziwy lastmod pomaga, a fałszywy szkodzi

Na projekcie e-commerce (branża moda, 3 200 produktów na Shoper) lastmod zmieniał się na wszystkich kartach produktu przy każdej zmianie stanu magazynowego (co godzinę). 3 200 URL-i × 24 zmiany/dobę = 76 800 fałszywych sygnałów świeżości dziennie. Crawl rate Binga na tym serwisie spadł o 40% w ciągu trzech miesięcy (mierzony w logach serwera). Google crawlował stabilnie, ale URL Inspection pokazywał coraz starsze lastCrawlTime na stronach blogowych.

Po wdrożeniu kontrolowanego lastmod (zmiana tylko przy zmianie ceny lub opisu, nie przy zmianie stanu magazynowego) crawl rate Binga wrócił do normy w ciągu dwóch tygodni. Google ostatni crawl blogowych URL-i poprawił się z 14 do 4 dni. To jest przypadek, w którym naprawa lastmod dała mierzalny efekt na crawl, choć nie testowaliśmy bezpośrednio cytowań AI.

Dodatkowy kontekst z logów serwera tego projektu: przed naprawą lastmod GPTBot crawlował 10-15 stron dziennie (niemal wyłącznie karty produktów z fałszywym lastmod). Po naprawie GPTBot zaczął crawlować 5-8 stron dziennie, ale 60% z nich to były strony blogowe i kategorii, które wcześniej były zagłuszane przez szum z kart produktowych. Całkowity wolumen crawlu GPTBot spadł, ale jego jakość (procent stron z wartościową treścią) wzrosła.

Kontrastowy przykład: na innym projekcie (branża beauty, WordPress + Rank Math Pro) kontrolowaliśmy lastmod od początku – zmiana tylko po meaningful update. Crawl rate Binga był stabilny, a GPTBot crawlował nowe artykuły w ciągu 48 godzin od publikacji. Ten sam serwis, po wdrożeniu IndexNow z readiness gate (opisanym w artykule o IndexNow), osiągnął crawl GPTBot w ciągu 6 godzin. Czyste sygnały lastmod + IndexNow = szybki pipeline discovery. Brudne sygnały + IndexNow = strata sygnału.

Ten kontrast między dwoma projektami (moda z brudnym lastmod vs beauty z czystym) pokazuje, że naprawa lastmod jest warunkiem koniecznym dla efektywności IndexNow. Zgłaszanie URL-i przez IndexNow na domenie z tysiącami fałszywych sygnałów to jak wrzucanie ważnych listów do skrzynki, która już jest pełna spamu. System nie odróżni Twojego sygnału od szumu.

O relacji między lastmod a meaningful update pisaliśmy w artykule o date bump vs meaningful update. Lastmod powinien zmieniać się wyłącznie po meaningful update – to jest spójna zasada obu artykułów. Zmiana daty bez treści w schemie dateModified to date bump. Zmiana daty bez treści w sitemapie lastmod to fałszywy sygnał freshness. Oba są złe z tego samego powodu: kłamią systemowi o tym, co się zmieniło.

Jak kontrolować lastmod w praktyce? Rozwiązania per CMS

WordPress

Rank Math Pro pozwala na kontrolowanie sitemapy na poziomie posta/strony. Alternatywnie: filtr w functions.php, który porównuje post_content przed i po zapisie i aktualizuje lastmod tylko gdy treść się zmieniła. Ważne: zmiana kategorii, tagu czy miniaturki NIE powinna aktualizować lastmod artykułu.

Shopify

Shopify nie daje bezpośredniego dostępu do lastmod w sitemapie. Rozwiązanie: webhook na product/update + porównanie body_html. Jeśli body_html się zmienił – aktualizacja lastmod uzasadniona. Jeśli zmienił się tylko tag, kolekcja lub metafield – nie.

Segmentacja sitemap

LinkSurge rekomenduje segmentację sitemap dla serwisów 1000+ stron. Semgence wdraża trzy osobne sitemapy: sitemap produktowy (aktualizacja codzienna – ceny zmieniają się często i to jest prawdziwy sygnał), sitemap kategorii (aktualizacja tygodniowa – nowe produkty w listingu), sitemap contentowy (aktualizacja ręczna – tylko po meaningful update). Rozdzielenie daje robotowi jasny sygnał: co naprawdę się zmieniło.

Ograniczenia: czego ten audyt nie dowodzi?

Nie mamy bezpośredniego dowodu, że Google lub Bing obniżają priorytet crawlu konkretnie z powodu fałszywych lastmod – to jest hipoteza spójna z patentem US20130144858A1 i z wypowiedziami Muellera i Illyesa, ale nie jest potwierdzony związek przyczynowy. Spadek crawl rate na projekcie moda mógł wynikać z innych czynników (zmiana infrastruktury serwera, zmiana robots.txt). Artykuł jest szóstym z serii dziesięciu publikacji Semgence.

Patenty: US7346839B2 (porównywanie deklarowanej daty z rzeczywistą zmianą – elementy mało istotne mogą być pominięte), US20130144858A1 (harmonogramowanie crawli na podstawie wartości zasobu – wielokrotne fałszywe sygnały mogą obniżyć priorytet). Patenty opisują mechanizmy Google, nie Binga. Ale obie wypowiedzi pracowników Google (Mueller, Illyes) potwierdzają, że sygnał lastmod podlega ocenie wiarygodności.

Digital Applied komentując wypowiedź Illyesa podkreśla: „metadane świeżości coraz bardziej kształtują decyzję, czy ponownie pobrać i ponownie cytować treść. Sitemap, który mówi prawdę, jest jednym z najtańszych sygnałów wiarygodności, jakie możesz wdrożyć.” To jest kluczowy insight: lastmod to nie jest sygnał freshness w izolacji. To jest sygnał wiarygodności całej domeny. Jeden nieprawdziwy lastmod to błąd. Tysiąc nieprawdziwych lastmod dziennie to systemowe kłamstwo, które obniża zaufanie do wszystkich sygnałów z tej domeny.

Checklista: audyt i naprawa lastmod

Audyt (jednorazowy): Pobierz sitemap i wylistuj wszystkie URL-e z lastmod. Pobierz treść tych URL-i przez Crawl4AI lub Screaming Frog. Porównaj lastmod z datą ostatniej rzeczywistej zmiany treści głównej (diff HTML). Policz procent fałszywych lastmod (data się zmieniła, treść nie). Jeśli powyżej 50% – masz problem systemowy.

Naprawa (ciągła): Skonfiguruj CMS lub plugin, żeby lastmod zmieniał się tylko przy zmianie treści głównej. Rozdziel sitemapy per typ strony (produkty, kategorie, blog). Jeśli nie możesz kontrolować lastmod – lepiej go usunąć (zalecenie Illyesa). Użyj pełnego formatu ISO 8601 z czasem (2026-09-05T14:30:00+02:00), nie samej daty.

Success Tech Services w przewodniku o WordPress XML Sitemaps zauważa, że nowsze systemy AI-aware mogą traktować timestampy z sitemapy jako wskazówkę świeżości, a lastmod ma większe znaczenie niż kiedykolwiek wcześniej. To jest ścieżka, którą Semgence wdraża na serwisach klientów: nie wyłączanie lastmod, ale kontrolowanie go – żeby każda zmiana daty w sitemapie oznaczała rzeczywistą zmianę treści, którą warto ponownie pobrać i przeczytać.

Monitoring: Co miesiąc sprawdzić w logach serwera, ile razy BingBot i GPTBot crawlują strony z nowym lastmod. Jeśli crawl rate spada mimo regularnych zmian lastmod – fałszywe sygnały erodują zaufanie. O monitoringu crawlu pisaliśmy w artykule o widoczności marki w AI.

Dodatkowy wskaźnik: porównaj liczbę URL-i z lastmod w sitemapie z liczbą URL-i zacrawlowanych w Bing/Google w tym samym okresie. Jeśli sitemap deklaruje 500 zmian tygodniowo, a Bing crawluje 50 – system już prawdopodobnie odfiltrował 90% Twoich sygnałów jako szum.

Ostatnia aktualizacja artykułu: wrzesień 2026. Artykuł jest szóstym z serii dziesięciu publikacji Semgence o odświeżaniu treści.