Google publicznie odradza technikę, która od kilku miesięcy krąży po branżowych forach jako sposób na wymuszenie codziennego crawlowania witryny. Chodzi o dopisywanie zmiennego parametru z uniksowym znacznikiem czasu do adresów plików sitemap wewnątrz indeksu map witryny, tak aby robot za każdym razem widział „nowy” adres i musiał pobrać plik od nowa. John Mueller z Google odpowiedział na to krótko: to zły pomysł, bo psuje stabilność adresów URL, a stabilność jest jedną z niewielu rzeczy, na których wyszukiwarce naprawdę zależy.
Sprawa wypłynęła 2 września 2026 roku w dyskusji na Bluesky, a następnie została opisana przez serwis Search Engine Journal. Wątek jest o tyle istotny, że dotyka problemu, z którym mierzy się dziś praktycznie każdy duży serwis: jak przyspieszyć crawlowanie, kiedy Google coraz oszczędniej gospodaruje budżetem indeksacyjnym, a element lastmod bywa ignorowany.
Kontekst: dlaczego ktoś w ogóle wymyślił cache busting w sitemapie
Cache busting to stara technika frontendowa. Do adresu pliku statycznego (arkusza stylów, skryptu, obrazu) dopisuje się zmienny parametr, na przykład ?v=1756800000, żeby przeglądarka i CDN nie serwowały wersji z pamięci podręcznej, tylko pobrały plik na nowo. Mechanizm jest prosty, bezpieczny i powszechnie stosowany.
Ktoś przeniósł tę logikę na mapy witryny. Rozumowanie było następujące: skoro Google buforuje pliki sitemap i sięga po nie rzadziej niż byśmy chcieli, to wystarczy sprawić, żeby adres pliku zmieniał się codziennie. Robot zobaczy w indeksie map witryny inny zestaw adresów niż wczoraj, potraktuje je jak nowe zasoby i pobierze wszystkie od zera. Efekt uboczny, przynajmniej w teorii, to codzienne przetworzenie pełnej listy adresów serwisu.
Zgłaszający obserwację użytkownik opisał to na Bluesky tak: zauważył takie zachowanie na dużym, sztywno ustrukturyzowanym serwisie, gdzie adresy podrzędnych map witryny wewnątrz indeksu codziennie dostają świeży parametr ?v=timestamp. Nie był to więc pomysł teoretyczny, tylko wdrożenie działające na produkcji.
Co dokładnie powiedział John Mueller
Pierwsza reakcja przedstawiciela Google była raczej zdziwieniem niż oceną. Mueller zapytał, po co ktoś miałby stosować cache busting w pliku sitemap, i zastrzegł, że być może źle rozumie cel takiego zabiegu, prosząc o rozwinięcie wątku.
Kiedy intencja została wyjaśniona, stanowisko było już jednoznaczne. Mueller stwierdził, że uważa to za zły pomysł, ponieważ w ten sposób sygnalizuje się, że kanoniczny adres URL dla danej treści powinien się nieustannie zmieniać. Dodał, że nie jest to dobre ani dla wyszukiwarek, ani dla własnych statystyk, a posiadanie czystych i stabilnych adresów URL jest ważne.
To zdanie warto rozłożyć na czynniki pierwsze, bo zawiera dwa osobne argumenty. Pierwszy dotyczy sygnału wysyłanego do wyszukiwarki. Drugi, często pomijany w dyskusjach o crawl budżecie, dotyczy analityki: adresy z rotującymi parametrami rozbijają raporty, psują grupowanie w narzędziach do logów i zaśmiecają dane o pobraniach.
Kluczowe fakty w skrócie
| Element | Stan faktyczny |
|---|---|
| Data dyskusji | 2 września 2026, platforma Bluesky |
| Technika | Parametr ?v= ze znacznikiem czasu doklejany do adresów podrzędnych map witryny w indeksie sitemap |
| Cel wdrożenia | Wymuszenie codziennego pobrania pełnej listy adresów przez roboty |
| Stanowisko Google | Odradzane, argument o stabilności adresów kanonicznych i o jakości danych analitycznych |
| Rekomendowana alternatywa | Poprawnie utrzymywany element lastmod |
| Status | Wypowiedź w dyskusji publicznej, nie zmiana dokumentacji ani algorytmu |
Niuans, który w tej dyskusji łatwo przeoczyć
Jest w tej wymianie zdań szczegół techniczny, który zasługuje na uczciwe odnotowanie. Parametr ?v=timestamp w opisanym wdrożeniu trafia na adresy plików sitemap, a nie na adresy artykułów czy kart produktów. Pliki map witryny same w sobie nie są treścią, którą Google indeksuje i kanonikalizuje w klasycznym sensie, więc argument o „kanonicznym adresie URL dla danej treści” nie przekłada się na tę sytuację jeden do jednego.
To nie znaczy, że ostrzeżenie jest bezpodstawne. Znaczy tyle, że ryzyko leży gdzie indziej, niż sugeruje najkrótsze streszczenie tej wypowiedzi. Realne problemy z rotującym parametrem na plikach map witryny są następujące:
- Utrata historii przetwarzania. Google śledzi stan każdej mapy witryny pod jej adresem: kiedy została pobrana, ile adresów zawierała, czy pojawiły się błędy. Codzienna zmiana adresu resetuje tę ciągłość i każdego dnia tworzy nowy byt w systemie.
- Puchnący zbiór map witryny. Zamiast kilkudziesięciu stabilnych plików wyszukiwarka dostaje kilkadziesiąt nowych adresów dziennie. Po roku mówimy o dziesiątkach tysięcy adresów map witryny, z których zdecydowana większość zwraca już nieaktualne dane albo błąd.
- Marnowanie budżetu na pobieranie. Zasoby przeznaczone na pobranie tych samych list adresów w kółko nie zostaną przeznaczone na pobranie realnych podstron. To dokładna odwrotność zamierzonego efektu.
- Zaszumiona analityka logów. Każde narzędzie do analizy logów serwera będzie traktowało te trafienia jako osobne adresy, co rozsypuje raporty pokrycia crawlem.
Innymi słowy: technika nie tyle łamie zasady, ile obiecuje coś, czego nie dostarcza, a przy okazji generuje realne koszty. Jeżeli monitorujecie zachowanie robotów po stronie serwera, ten efekt zobaczycie w danych bardzo szybko. Praktyczny sposób na taką obserwację opisaliśmy w tekście o monitoringu botów w logach serwera.
Dlaczego w ogóle sięgamy po takie sztuczki: problem z lastmod
Sedno sprawy nie leży w cache bustingu, tylko we frustracji, która do niego doprowadziła. Oficjalną metodą komunikowania świeżości treści jest element lastmod w mapie witryny. W praktyce wielu wydawców ma poczucie, że Google go po prostu ignoruje.
Powód jest znany od lat i wielokrotnie tłumaczony przez przedstawicieli firmy. Zaufanie do lastmod działa w trybie zero jedynkowym: albo wyszukiwarka ufa datom w mapie witryny, albo nie ufa im wcale. Nie ma stanu pośredniego dla pojedynczych adresów. Jeżeli generator map witryny wstawia dzisiejszą datę przy każdym adresie za każdym razem, kiedy plik jest odświeżany, sygnał traci wartość informacyjną i cała mapa przestaje być traktowana jako wiarygodne źródło.
Gary Illyes z Google poszedł w tej sprawie jeszcze dalej. W wypowiedzi z lipca 2026 roku stwierdził, że przy niedokładnych datach lepiej wyjść na tym bez elementu lastmod w ogóle, bo przynajmniej oszczędza się kilka bajtów. To dosadne ujęcie tej samej zasady: fałszywy sygnał jest gorszy niż brak sygnału.
Jak wygląda poprawnie utrzymywany lastmod
- Data zmienia się wyłącznie wtedy, gdy zmieniła się treść merytoryczna podstrony, a nie przy każdym przebudowaniu cache czy podmianie stopki.
- Aktualizacja licznika komentarzy, bloku „powiązane wpisy” albo daty w widgecie nie jest zmianą treści.
- Data jest w formacie W3C Datetime, ze strefą czasową, i nie wyprzedza bieżącej chwili.
- Jeżeli CMS nie potrafi odróżnić edycji merytorycznej od technicznej, bezpieczniej jest usunąć
lastmodniż podawać datę nieprawdziwą.
Co to znaczy dla SEO i dla widoczności w AI
Dla klasycznego SEO wniosek jest prosty: crawlowania nie da się wymusić trikiem na warstwie transportu. Częstotliwość pobierania jest pochodną tego, jak często serwis realnie się zmienia, jak szybko odpowiada serwer i jaką wartość wyszukiwarka przypisuje domenie. Żaden parametr w adresie pliku tego nie przeskoczy.
Dla widoczności w systemach opartych na modelach językowych sprawa jest o tyle ciekawsza, że wchodzi tu w grę drugi zestaw robotów. Silniki odpowiedzi korzystają z własnych crawlerów i z indeksów budowanych niezależnie od Google, a część z nich pobiera stronę na żywo w momencie zadania pytania. Rotujące parametry w adresach to dla nich dokładnie ta sama trudność co dla klasycznej wyszukiwarki: rozmywają tożsamość zasobu i utrudniają dopasowanie cytowania do konkretnego dokumentu.
Warto też pamiętać, że stabilny adres URL jest jedynym trwałym identyfikatorem treści w ekosystemie odpowiedzi generatywnych. Kiedy asystent cytuje źródło, cytuje adres. Jeżeli ten adres jest ruchomym celem, cytowanie traci wartość, a przy okazji trudniej zmierzyć jego efekt. Tę mechanikę rozbieraliśmy szerzej przy okazji tekstu o tym, jak zmiana adresów wpływa na zgromadzony ruch.
Reakcje branży
Dyskusja pod oryginalnym wątkiem podzieliła się na trzy obozy, co dobrze pokazuje, gdzie dziś przebiegają linie sporu w technicznym SEO.
Pierwsza grupa przyjęła stanowisko Google bez zastrzeżeń: skoro istnieje przewidziany do tego mechanizm, należy go używać poprawnie, zamiast szukać obejść. Argument sprowadza się do tego, że każda technika oparta na wprowadzeniu robota w błąd co do natury zasobu prędzej czy później przestaje działać, a koszt jej utrzymania rośnie z czasem.
Druga grupa wskazywała, że odpowiedź nie adresuje realnego problemu. Wydawcy, którzy publikują dziesiątki materiałów dziennie, obserwują opóźnienia w pobieraniu liczone w dniach, a czasem w tygodniach. Dla nich zdanie o stabilnych adresach URL jest prawdziwe, ale nie rozwiązuje niczego. Pytanie brzmi: co konkretnie ma zrobić serwis, który utrzymuje lastmod wzorowo, a mimo to nie widzi przyspieszenia?
Trzecia grupa, najbardziej pragmatyczna, zwróciła uwagę na to samo co my wyżej: że parametr dotyczy plików map witryny, a nie adresów treści, więc główny argument mija się z opisanym wdrożeniem. Ta część dyskusji była też najciekawsza merytorycznie, bo dotknęła pytania, jak w ogóle Google zarządza pamięcią podręczną dla samych plików sitemap i czy zmiana ich adresu faktycznie coś przyspiesza, czy tylko wygląda na to w logach.
Nie po raz pierwszy publiczna wypowiedź pracownika Google okazuje się jednocześnie słuszna co do zasady i niewystarczająca dla osoby, która zgłasza problem. Podobny wzorzec widzieliśmy przy okazji sprawy ekranów weryfikacji botów wyrzucających strony z indeksu.
Czego ta dyskusja nie rozstrzyga
Uczciwie trzeba powiedzieć, że po tej wymianie zdań zostaje kilka pytań bez odpowiedzi, a są to akurat pytania, które najbardziej interesują osoby prowadzące duże serwisy.
Po pierwsze, nie wiemy, jak długo Google faktycznie przechowuje w pamięci podręcznej pojedynczy plik sitemap i od czego zależy ten okres. Wiadomo, że indeks map witryny bywa sprawdzany częściej niż pliki podrzędne, ale konkretne progi nigdy nie zostały opublikowane. Bez tej wiedzy trudno ocenić, czy opisane wdrożenie w ogóle cokolwiek przyspieszało, czy tylko generowało więcej wpisów w logach, które wyglądały jak przyspieszenie.
Po drugie, otwarte zostaje pytanie o serwisy, które robią wszystko poprawnie. Jeżeli daty w mapie witryny są prawdziwe, serwer odpowiada szybko, a treść realnie się zmienia, a mimo to nowe materiały czekają na pobranie kilka dni, to odpowiedź o czystych adresach URL nie wskazuje żadnego kolejnego kroku. To właśnie ta luka napędza powstawanie technik takich jak opisana.
Po trzecie, nie zostało wyjaśnione, czy rotujące adresy plików map witryny mają jakikolwiek wpływ na ocenę samej domeny, czy są neutralne i po prostu nieskuteczne. Z wypowiedzi wynika raczej to drugie, ale nie zostało to powiedziane wprost.
Co dalej
Nie zapowiedziano żadnej zmiany w dokumentacji ani w sposobie przetwarzania map witryny. To wymiana zdań w dyskusji publicznej, a nie komunikat produktowy, i tak należy ją traktować przy podejmowaniu decyzji. Nie ma podstaw, żeby zakładać karę za stosowanie takiego rozwiązania. Jest natomiast solidna podstawa, żeby uznać je za nieskuteczne.
Jeżeli sprawdzacie własną konfigurację po tej dyskusji, sensowna kolejność działań wygląda tak:
- Zdejmijcie rotujące parametry z adresów map witryny, jeśli je macie, i wróćcie do stałych adresów. Stare adresy z parametrem zostawcie działające przez kilka tygodni, żeby nie generować lawiny błędów.
- Zweryfikujcie generator lastmod. Sprawdźcie na próbce kilkunastu adresów, czy data odpowiada faktycznej ostatniej edycji merytorycznej. Jeśli wszystkie wskazują dzisiaj, macie odpowiedź, dlaczego sygnał nie działa.
- Porównajcie liczbę adresów zgłoszonych i pobranych w raportach map witryny. Rozjazd między tymi liczbami mówi więcej o wąskim gardle niż jakikolwiek trik na częstotliwość pobierania.
- Sprawdźcie czas odpowiedzi serwera dla samych robotów, nie dla użytkowników. Wolne odpowiedzi ograniczają tempo pobierania skuteczniej niż cokolwiek innego.
- Przy dużych publikacjach rozważcie osobną mapę witryny dla świeżych treści, z krótką listą najnowszych adresów. To rozwiązanie zgodne z dokumentacją i nie wymaga żadnych sztuczek.
Szerszy wniosek jest taki, że dyskusja o crawl budżecie coraz częściej sprowadza się do jednego pytania: czy serwis daje wyszukiwarce powód, żeby wracać częściej. Sztuczki na poziomie adresów plików tego powodu nie tworzą. Tworzy go tempo publikacji, jakość treści i techniczna higiena, w tym właśnie stabilne, czyste adresy URL, o które upomniał się Mueller.
FAQ
Czy stosowanie parametru ?v= w adresach map witryny grozi karą od Google?
Nic na to nie wskazuje. W wypowiedzi nie padło słowo o karze ani o filtrze. Technika została określona jako zły pomysł ze względu na sygnał wysyłany wyszukiwarce i na jakość własnych danych analitycznych, a nie jako naruszenie zasad. Ryzyko jest praktyczne, nie regulaminowe: marnujecie zasoby na pobieranie tych samych list adresów i tracicie ciągłość raportowania.
Czy da się w jakikolwiek sposób wymusić na Google codzienne crawlowanie?
Nie ma mechanizmu, który to gwarantuje. Częstotliwość pobierania jest decyzją wyszukiwarki opartą na tym, jak często treść realnie się zmienia, jak szybko odpowiada serwer i jaką wartość przypisano domenie. Można ten proces wspierać: poprawnym elementem lastmod, szybkim serwerem, regularną publikacją i osobną mapą witryny dla najnowszych materiałów. Nie da się go wymusić.
Skoro Google bywa nieufny wobec lastmod, czy w ogóle warto go podawać?
Warto, pod warunkiem że data jest prawdziwa. Zaufanie działa w trybie zero jedynkowym dla całej mapy witryny, więc jedna partia zmyślonych dat psuje sygnał dla wszystkich adresów. Jeżeli wasz system nie odróżnia edycji merytorycznej od technicznego przebudowania strony, lepszym wyjściem jest usunięcie elementu lastmod niż podawanie daty, która nic nie znaczy.
Czy ten sam problem dotyczy robotów AI?
Tak, a nawet w większym stopniu. Systemy odpowiedzi generatywnych identyfikują źródło przez adres URL i na jego podstawie budują cytowanie. Ruchomy adres rozmywa tożsamość dokumentu, utrudnia dopasowanie cytowania i praktycznie uniemożliwia zmierzenie, który materiał przyniósł widoczność. Stabilne adresy są tu warunkiem wstępnym, nie optymalizacją.
Co zrobić, jeśli mam wzorowy lastmod, a Google i tak pobiera moje strony rzadko?
Zacznijcie od danych po stronie serwera: sprawdźcie w logach, które sekcje robot faktycznie odwiedza i jak szybko dostaje odpowiedź. Potem porównajcie liczbę adresów zgłoszonych i pobranych w raportach map witryny. Najczęstsze wąskie gardła to wolne odpowiedzi serwera, duża liczba adresów o niskiej wartości pochłaniających zasoby oraz niska ocena samej domeny. Żadnego z tych problemów nie rozwiąże zmiana konstrukcji mapy witryny.