Świeżość jest cechą zapytania, a aktualizacja to zmiana strony, nie jej daty. Google ma systemy, które dla części zapytań premiują nowe strony, a jego własni inżynierowie opisują wbudowane przesunięcie na korzyść starych. Odruch z SEO, czyli podbijanie daty według harmonogramu, nie mówi Google niczego, co da się zweryfikować. Wiemy to, bo nasza sitemapa robiła dokładnie to przez miesiące.
Co znaczy świeżość wyników w Google (QDF)
W zeznaniach w procesie antymonopolowym US v. Google Pandu Nayak podał trzy przykłady, cytowane w analizie Hobo z 5 października 2026. Kibic chce stron z dzisiejszego ranka. Kupujący laptop chce recenzji z właściwego rocznika, nie z dzisiaj. Ktoś planujący obiad z indykiem może lepiej trafić na przepis sprzed dziesięciu lat.
Ten trzeci przypadek właściciele WordPressa pomijają. Świeżość nie jest premią, którą zbiera każda strona. Dla dużej części zapytań poprawną odpowiedzią jest starsza, ustalona strona, a jej “aktualizowanie” może tylko zaszkodzić. Zanim ruszysz wpis, sprawdź, czy jego zapytanie w ogóle oczekuje nowości.
Skąd się wzięło query deserves freshness
Nazwa jest starsza niż jakikolwiek wyciek czy proces. 3 czerwca 2007 Saul Hansell opisał ją w The New York Times, w sylwetce Amita Singhala, którego gazeta nazwała mistrzem algorytmu rankingowego Google. Według artykułu Google do tamtej pory wolał strony na tyle stare, że zdążyły zebrać linki, a Singhal zaczął podejrzewać, że ta równowaga jest zła, gdy wyszukiwanie Google Finance nie znajdowało nowego serwisu notowań giełdowych samego Google.
Odpowiedzią jego zespołu, jak relacjonuje Hansell, był model matematyczny, który próbuje ustalić, kiedy użytkownicy chcą nowych informacji, a kiedy nie. Nazwano go QDF, od query deserves freshness. Oceniał, czy temat jest gorący, na podstawie dwóch sygnałów: serwisów informacyjnych i blogów, które aktywnie o nim piszą, oraz własnego strumienia zapytań Google, który Singhal uważał za lepszy wskaźnik. Jego przykładem była awaria prądu w Nowym Jorku, przy której pierwsze artykuły pojawiają się po 15 minutach, a zapytania po dwóch sekundach.
Dwa szczegóły z 2007 roku nadal mają znaczenie. Singhal mówił kolegom, że samo przestawienie formuł tak, by pokazywały więcej nowych stron, w większości przypadków dawało gorsze wyniki, więc świeżość nigdy nie była pomyślana jako ogólna preferencja dla nowych stron. A wyzwalaczem był popyt wokół tematu, nie wiek pojedynczej strony. Wpis w WordPressie nie rozgrzeje swojego zapytania zmianą własnej daty.
Których zapytań dotyczą systemy świeżości Google
Dziś Google opisuje ten pomysł w swoim przewodniku po systemach rankingowych, w liczbie mnogiej: różne systemy “query deserves freshness”, zaprojektowane tak, by pokazywać świeższe treści przy zapytaniach, w których można się tego spodziewać. Przewodnik podaje dwa przykłady. Ktoś, kto szuka filmu, który właśnie wszedł na ekrany, prawdopodobnie chce świeżych recenzji, a nie artykułów z początku produkcji. Zapytanie “trzęsienie ziemi” zwykle zwraca materiały o przygotowaniu się, ale po niedawnym trzęsieniu mogą pojawić się wiadomości i świeższe treści.
Oba przykłady opisują zmianę tego, czego potrzebuje szukający, wywołaną zdarzeniem poza stroną. Żaden nie opisuje strony, która stała się lepsza, bo dostała nową datę. To pasuje do przepisu na indyka z zeznań Nayaka: system zbudowany do wykrywania popytu na nowość nie ma czego nagradzać, gdy tego popytu nie ma. Dla serwisu na WordPressie przydatne pytanie brzmi: które z jego zapytań kiedykolwiek zachowują się jak “trzęsienie ziemi”. Dla większości stron usługowych i poradników odpowiedź brzmi: żadne, i na takich stronach data jest zapisem, a nie dźwignią.
Dlaczego Google potrzebuje systemu świeżości
Powód jest mechaniczny. Google rankuje częściowo na tym, co użytkownicy klikali wcześniej, i Nayak opisał skutek uboczny:
Problem ze świeżością i kliknięciami polega na tym, że kliknięcia narastają z czasem, co oznacza, że starsze strony, potencjalnie nieaktualne, mają zwykle więcej kliknięć niż świeże strony
Pandu Nayak, Google, Hobo Web, tłumaczenie własne
Nowa strona startuje bez kliknięć, stara ma ich lata. Dla zapytań, w których liczy się świeżość, Google musi to skompensować. Dla wszystkich pozostałych zgromadzone kliknięcia robią to, do czego je zbudowano.
Dla właściciela serwisu wynikają stąd dwie rzeczy. System świeżości ma podnosić strony naprawdę nowe, więc jest zbudowany tak, by odpierać tanie sygnały. A świeża strona bez kliknięć startuje z handicapem, którego zmiana daty nie usunie.
Co Google mówi o zmienianiu dat
Hobo przytacza tweet Johna Muellera z 5 lutego 2022, od tamtej pory usunięty:
Kiedy piszesz coś nowego albo istotnie zmieniasz coś istniejącego, zmień datę. Zmiana daty bez robienia czegokolwiek innego to tylko szum i nic nie daje.
John Mueller, Google, Hobo Web, tłumaczenie własne
Tweeta już nie ma, więc to mowa zależna, nie dokumentacja. Ten sam artykuł cytuje pytanie z wytycznych Google o pomocnych treściach:
Czy zmieniasz datę stron, żeby wydawały się świeże, choć treść nie zmieniła się istotnie?
Google, wytyczne o pomocnych treściach, Hobo Web, tłumaczenie własne
Przeczytaj pierwsze zdanie rady Muellera jeszcze raz. Nie mówi, żeby nigdy nie zmieniać daty. Mówi, żeby zmienić ją, gdy coś nowego napisano albo istotnie zmieniono. Data jest twierdzeniem i reguła brzmi: twierdzenie ma być prawdziwe.
To pytanie nie jest wyłącznie relacją z drugiej ręki. Nadal stoi we własnym przewodniku Google o tworzeniu pomocnych, wiarygodnych treści dla ludzi, zaktualizowanym 5 października 2026, a zaraz po nim drugie, wymierzone w ten sam odruch w skali całego serwisu:
Czy dodajesz dużo nowych treści albo usuwasz dużo starszych głównie dlatego, że wierzysz, że to ogólnie pomoże w rankingu, bo serwis w jakiś sposób będzie wyglądał na “świeży”? (Nie pomoże.)
Google Search Central, Tworzenie pomocnych treści, tłumaczenie własne
Odpowiedź w nawiasie jest Google, nie nasza. Obejmuje masowe publikowanie i masowe czyszczenie robione dla wrażenia świeżości, czyli wersję podbijania daty w skali całego serwisu.
Czy treści evergreen trzeba aktualizować
Hobo wymienia kolejne usunięte tweety Muellera, a jeden z nich przyda się każdemu, kto ma poradniki, które nie muszą się zmieniać. Według Hobo brzmiał tak:
Jeśli to treść evergreen, to z definicji nie musisz jej zmieniać. Nie trzeba robić nic specjalnego. Zostaw daty, zrób ją świetną.
John Mueller, Google, Hobo Web, tłumaczenie własne
Tak jak wcześniejszy tweet, jest relacjonowany i nie da się go potwierdzić. Zgadza się jednak z tym, co Nayak powiedział o przepisie na indyka. Stabilny poradnik zachowuje swoją pierwotną datę i nie ma powodu jej tracić. Pokusa, by “odświeżać” go co kwartał, bierze się z błędnego przekonania, że Google nagradza ruch. Google nagradza właściwą odpowiedź na zapytanie, a dla wielu zapytań ta odpowiedź jest już napisana.
Wyciek Content Warehouse API a daty świeżości
Hobo idzie dalej i nakłada zeznania na nazwy pól z wyciekłej dokumentacji Content Warehouse API: osobne daty dla pola autora i daty (byline), dla wzorca w URL-u oraz znacznik ostatniej istotnej aktualizacji. Obraz jest zgrabny i jest wnioskiem autora. Nikt w Google nie potwierdził, że te pola napędzają ranking świeżości tak, jak to opisano. Zeznania i publiczne wytyczne wspierają zasadę, a historia na poziomie pól to odczytanie przecieku.
Praktyczna rada przeżywa bez tego. Strona, której data się przesunęła, a tekst ledwie drgnął, wygląda dla każdego systemu porównującego wersje jak strona, która złożyła obietnicę i jej nie dotrzymała. Czy to nazwane pole, czy ogólne porównanie, taktyka nie potrzebuje przecieku, żeby być złym zakładem.
Ta sama data lastmod dla wszystkich URL-i w sitemapie
24 sierpnia 2026 zmierzyliśmy na produkcji pięć naszych sitemap. W każdej wszystkie wpisy miały jedną i tę samą wartość lastmod, czyli datę builda. Integracja sitemap liczyła bieżącą datę raz i stemplowała nią wszystkie URL-e. Google planuje ponowne wizyty z lastmod tylko dopóki wartość jest weryfikowalnie prawdziwa, więc serwis, w którym każdy URL deklaruje zmianę przy każdym buildzie, uczy robota ignorować to pole. Daty ostatniego crawla w próbkach pojedynczych stron sięgały od trzech tygodni do trzech miesięcy wstecz.
To dokładnie wzorzec daty bez zmiany, zbudowany przez nas, w skali całego serwisu, bez udziału człowieka. Naprawa wzięła datę z updatedDate, a w razie braku z pubDate, i od 29 września URL bez znanej daty treści nie dostaje lastmod wcale, bo brak daty jest lepszy niż fałszywa.
Zmierzona dziś angielska sitemapa bloga ma 329 URL-i i 100 różnych dat lastmod. To kształt serwisu, który zmienia się w różnych momentach. Nie jest to wynik czysty. 130 z tych URL-i ma ten sam dzień, 22 września, i nie sprawdziliśmy, czy te edycje dodały treść. Jeśli nie, odtworzyliśmy problem w mniejszej skali, jeden redaktor naraz.
Co Google uznaje za istotną zmianę dla lastmod
Dokumentacja map witryn Google ustawia poprzeczkę w dwóch zdaniach. Google używa wartości lastmod, jeśli jest konsekwentnie i sprawdzalnie dokładna, na przykład po porównaniu z ostatnią modyfikacją strony, a wartość powinna odzwierciedlać datę i godzinę ostatniej istotnej aktualizacji. Podane przykłady: zmiana treści głównej, danych strukturalnych albo linków na stronie jest zwykle istotna, aktualizacja daty praw autorskich nie jest. Ta sama strona mówi, że Google ignoruje priority i changefreq, więc te dwa pola też nie przeniosą żadnego sygnału świeżości.
Ta definicja jest węższa niż to, co WordPress zapisuje jako modyfikację, i szersza, niż zakłada wielu redaktorów. Nowy link wewnętrzny albo poprawione dateModified w schemie się liczą. Rok w stopce przestawiony przez motyw, ponowny zapis czy wtyczka, która przy aktywacji przepisuje wpisy, się nie liczą. Kluczowe jest słowo “sprawdzalnie”: Google może porównać zadeklarowaną datę z tym, co pobrał ostatnim razem, a nasza pieczątka z datą builda oblała to porównanie na wszystkich URL-ach naraz.
Jak zaktualizować wpis, gdy minął termin
Z tym samym wzorcem mieliśmy drugi kontakt, w treści, nie w sitemapie. Artykuł o oznaczaniu treści generowanych przez AI był napisany jako poradnik przed terminem z art. 50 AI Act (2 sierpnia 2026). W dniu terminu przestał być przestarzały i zaczął mówić rzeczy nieprawdziwe: “zaczną obowiązywać”, “zanim termin stanie się problemem”. Pole lastVerified było świeże, a zdania w czasie przyszłym dalej stały. 7 sierpnia poprawiliśmy to we wszystkich sześciu wersjach językowych w jednym commicie.
Wniosek jest taki, że data weryfikacji nie łapie czasu gramatycznego. Aktualizacją była tu zmiana zdań, nie daty. Przy tekstach z terminem warto więc przy zapisie szukać w treści form przyszłych (“wejdzie w życie”, “do końca miesiąca”, “zanim”) i sprawdzać każdą z nich osobno, bo to one fałszywieją pierwsze, a żadna wtyczka ich nie widzi.
Jak szybko Google odświeża zaktualizowaną stronę
Na wydarzeniu Search Central Live Gary Illyes pokazał wewnętrzne czasy, które Barry Schwartz opisał w Search Engine Roundtable. Odświeżenie znanego URL-a trwa typowo około 30 dni, w najwolniejszych przypadkach tygodnie albo wcale. Przetwarzanie sitemapy to około 24 godziny, do 14 dni albo wcale. Illyes dodał zastrzeżenie:
miejcie na uwadze, że było to ćwiczenie, które miało sprawdzić, czy publiczność odnajdzie się w liczbach, które wyciągnęliśmy wewnętrznie i umieściliśmy na tych slajdach.
Gary Illyes, Google, Search Engine Roundtable, tłumaczenie własne
To rzędy wielkości, nie gwarancje. Mimo to zmieniają ocenę aktualizacji. Jeśli edytujesz wpis w poniedziałek i patrzysz na efekt w środę, nic nie zmierzyłeś. A skoro typowe odświeżenie trwa miesiąc, uczciwy lastmod jest jedynym sposobem, by powiedzieć Google, że ta strona jest warta wizyty wcześniej, niż wynika z jej harmonogramu.
Co jest aktualizacją w WordPressie
WordPress zapisuje post_modified przy każdym zapisie. Literówka, zbiorcza zmiana kategorii i wtyczka zapisująca wpisy ponownie przesuwają tę wartość, a wiele wtyczek SEO przekazuje ją do lastmod i do widocznej linii “zaktualizowano”. Domyślnie platforma publikuje więc twierdzenia, których nikt nie sprawdził.
Aktualizacją wartą nowej daty jest:
- liczba, cena albo wersja, która się zmieniła, razem ze zdaniem wokół niej
- sekcja dodana, bo temat urósł
- rekomendacja odwrócona po nowych dowodach
- termin, który minął, z przepisanym czasem gramatycznym
Aktualizacją nie jest:
- ponowny zapis, by odpalić wtyczkę
- zmiana kolejności akapitów albo podmiana obrazka
- zbiorcza edycja metadanych w wielu wpisach
- ponowne przeczytanie strony i stwierdzenie, że nie ma co zmieniać
W ostatnim przypadku trzymaj osobne pole. Dlatego lastVerified mamy oddzielnie od updatedDate: weryfikacja to fakt wart zapisania, ale nie zmiana treści.
Jak Google wybiera datę pokazywaną w wynikach wyszukiwania
Data pod wynikiem wyszukiwania to osobna sprawa niż lastmod. Przewodnik Google o datach mówi, że Google nie opiera się na jednym czynniku daty, bo każdy może zawieść, i patrzy na kilka, żeby oszacować, kiedy strona została opublikowana albo istotnie zaktualizowana. Nie gwarantuje też, że jakakolwiek data zostanie pokazana.
Przewodnik prosi o datę widoczną dla użytkownika, wyeksponowaną i opisaną tekstem w rodzaju “Opublikowano” albo “Ostatnia aktualizacja”. W danych strukturalnych zaleca podtyp CreativeWork, na przykład Article albo BlogPosting, z datePublished i/lub dateModified. Data widoczna i wartość w danych strukturalnych powinny się zgadzać, strefa czasowa, jeśli jest podana, ma być poprawna, a data ma opisywać publikację albo aktualizację strony, nie datę przyszłą ani datę wydarzenia opisanego na stronie. Jeśli Google uparcie wybiera złą datę, przewodnik radzi usunąć część innych dat ze strony.
W WordPressie oznacza to, że to samo twierdzenie niosą trzy miejsca: widoczna linia “zaktualizowano”, dateModified w schemie drukowanej przez wtyczkę SEO i lastmod w mapie witryny. Jeśli jedno z nich zmienia się przy każdym zapisie, a pozostałe nie, strona przeczy sama sobie. Jeśli wszystkie trzy zmieniają się przy każdym zapisie, strona jest spójna i nadal fałszywa. Poprawka jest ta sama, którą zastosowaliśmy w mapie witryny: jedna data treści, zmieniana tylko przez redaktora, który zmienił treść, i każde wyjście czyta tę datę.
Kiedy zmienić datę aktualizacji wpisu
- Otwórz poprzednią wersję obok obecnej. Jeśli różnica to tylko białe znaki, znaczniki albo kolejność, zatrzymaj się.
- Zapytaj, czy to zapytanie oczekuje nowości. Jeśli nie, niezmieniona data jest uczciwa i bezpieczna.
- Jeśli zmiana jest prawdziwa, napisz w tekście, co się zmieniło, blisko góry albo dołu, żeby człowiek widział powód, nie tylko datę.
- Niech
lastmodpodąża za datą treści i niczym innym. Sprawdź samą sitemapę, nie ustawienia wtyczki, i policz różne wartości.
Świeżość zdobywa się zmianą, którą widzi czytelnik albo robot. Data może ją tylko zapisać, a data, która nie zapisuje niczego, jest najtańszym sygnałem, jaki serwis może wysłać, i pierwszym, który Google uczy się ignorować.
QDF nic nie daje bez nawyku publikacji, któremu GEO i LLMO mogą zaufać: zaktualizuj fakty, zostaw URL, pokaż datę.







