Google po raz pierwszy pokazał branży własne widełki czasowe dla crawlowania, indeksowania i serwowania wyników. Gary Illyes zaprezentował je 2 października 2026 roku na zamknięciu Search Central Live Deep Dive Europe w Barcelonie, a slajd z tabelami szybko obiegł zachodnie serwisy SEO. Najmocniejsza liczba: wyjście z core update trwa typowo od 3 do 6 miesięcy, a w najgorszym wariancie od pół roku do roku.
Kontekst: skąd się wzięły te liczby
Search Central Live Deep Dive Europe to format zamknięty, kameralny i mocno techniczny. Tegoroczna edycja odbyła się w Barcelonie między 30 września a 2 października 2026 roku. Ostatniego dnia Gary Illyes, analityk Google, pokazał zestaw tabel opisujących, ile czasu zajmują poszczególne etapy pracy wyszukiwarki: od odkrycia nowego adresu URL, przez renderowanie i anotacje, aż po zmianę pozycji w wynikach po aktualizacji algorytmu.
Trzeba od razu postawić granicę. Google nie opublikowało tych danych oficjalnie, nie ma komunikatu prasowego, nie ma wpisu na blogu Search Central. To, co krąży po branży, pochodzi z relacji uczestników, w tym z obszernego podsumowania przygotowanego przez Johna Campbella z agencji ROAST, które później opisały serwisy SEO. Jak podaje Search Engine Journal, w materiale nie ma ani metodologii, ani wielkości próby, ani definicji tego, co Google nazywa wartością typową. To są punkty odniesienia, nie zobowiązania.
Dla polskiego rynku ma to konkretne znaczenie. Przez lata dyskusja o tym, czy strona indeksuje się wolno, opierała się na anegdotach i porównaniach między agencjami. Teraz mamy liczby, które wprawdzie nie są gwarancją, ale pozwalają ustawić realistyczne oczekiwania w rozmowie z klientem i w planie wdrożeniowym.
Kluczowe fakty: trzy tabele, które warto zapisać
Illyes rozbił proces na trzy warstwy: crawling, indexing i serving. W każdej podał wartość typową oraz najwolniejszy obserwowany wariant. Słowo „nigdy” pojawia się w tych tabelach zaskakująco często i, co istotne, zwykle nie odnosi się do kolejki, lecz do oceny jakości.
Crawling
| Proces | Typowo | Najwolniej |
|---|---|---|
| Odkrycie nowego adresu URL | ok. 20 godzin | tygodnie lub nigdy |
| Ponowne pobranie znanego adresu | ok. 30 dni | tygodnie lub nigdy |
| Przetworzenie sitemapy | ok. 24 godziny | do 14 dni lub nigdy |
| Odczyt zmienionego robots.txt | ok. 24 godziny | ok. 25 godzin |
| Zmiana crawl capacity | 4 godziny do 2 tygodni | 1–3 tygodnie na odbudowę |
| Zmiana crawl demand | ok. 20 godzin | tygodnie lub miesiące |
Indexing
| Proces | Typowo | Najwolniej |
|---|---|---|
| Renderowanie | sekundy do godzin w kolejce | dni lub tygodnie |
| Anotacje meta | 45–90 minut | 1–4 dni |
| Anotacje linków | minuty do 3 tygodni | miesiące |
| Indeksacja end to end | ok. 1,5 godziny | miesiące lub nigdy |
| Zmiana kanonikalizacji | 1–3 tygodnie | miesiące |
| Aktualizacja danych strukturalnych | godziny do 2 tygodni | tygodnie lub nigdy |
| Migracja domeny | 1–3 miesiące | pół roku do ponad roku |
Serving
| Proces | Typowo | Najwolniej |
|---|---|---|
| Zmiana tytułu w SERP | 1–2 dni | tygodnie lub miesiące |
| Zmiana snippetu | 1–2 dni | tygodnie lub miesiące |
| Usunięcie URL przez Search Console | ok. 2 godziny | ok. 24 godziny |
| Zdjęcie ręcznego działania | 1–2 tygodnie | 4–6 tygodni lub dłużej |
| Zmiana po spam update | 1–2 tygodnie | miesiące |
| Odbudowa po core update | 3–6 miesięcy | pół roku do roku |
Illyes zwrócił uwagę na jeden mechanizm, który łatwo przeoczyć przy czytaniu tabel osobno: procesy są ze sobą powiązane, a opóźnienia się kumulują. Strona nie zostanie zaindeksowana, zanim nie zostanie pobrana, a nie zostanie pobrana, zanim nie zostanie odkryta. Jeżeli każdy etap wpadnie w swój najwolniejszy wariant, suma przestaje przypominać wartość typową.
Co to znaczy dla SEO
Pierwszy wniosek jest nieprzyjemny, ale porządkujący: 30 dni to typowy czas ponownego pobrania znanego adresu. Oznacza to, że przeciętna aktualizacja treści na podstronie, która nie jest ani stroną główną, ani świeżym newsem, nie zostanie zauważona przez Google tego samego dnia ani nawet w tym samym tygodniu. Audyt treści, w którym poprawiacie 200 artykułów, realnie rozlicza się dopiero po miesiącu, a w ogonie rozkładu po kwartale.
Drugi wniosek dotyczy indeksacji end to end. Półtorej godziny brzmi jak dobra wiadomość, ale ta liczba opisuje czas przetworzenia, a nie czas oczekiwania. Illyes doprecyzował, że „end to end oznacza, iż wszystkie krytyczne procesy zakończyły się powodzeniem”. Jeżeli strona nigdy nie trafia do kolejki, bo nie została odkryta albo odrzucono ją na etapie oceny jakości, półtorej godziny nie ma żadnego zastosowania. Dlatego warto czytać kolumnę „najwolniej” dosłownie: słowo „nigdy” przy indeksacji nie opisuje przeciążenia infrastruktury, tylko decyzję selekcyjną.
Trzeci wniosek jest operacyjny i dotyczy budżetu crawlowania. Google ponownie przypomniało, że crawl budget składa się z dwóch niezależnych składników. Crawl rate limit zależy od infrastruktury: czasu nawiązania połączenia, time to first byte oraz odsetka odpowiedzi 429 i 5xx. Crawl demand zależy od jakości serwisu, częstotliwości zmian i popularności adresów w sieci. To rozróżnienie decyduje o tym, czy problem rozwiązuje administrator serwera, czy redakcja. Jeżeli nie macie go rozpisanego dla swojego serwisu, dobrym punktem wyjścia jest nasz materiał o tym, jak diagnozować i optymalizować crawl budget.
Czwarty wniosek dotyczy migracji. Przedział 1–3 miesiąca dla przeniesienia witryny, z ogonem sięgającym roku, jest znacząco dłuższy niż to, co zwykle obiecuje się w briefie projektowym. Illyes złagodził go uwagą, że „mała migracja może zostać zamknięta w kilka tygodni”, ale skala pozostaje czynnikiem decydującym. Planując przeniesienie serwisu, warto zarezerwować okno obserwacyjne liczone w kwartałach, nie w tygodniach.
Piąty wniosek dotyczy sitemapy i pliku robots.txt, czyli dwóch narzędzi, którym branża przypisuje magiczne właściwości. Tabele mówią coś innego. Przetworzenie sitemapy trwa typowo dobę, ale w ogonie rozkładu rozciąga się do czternastu dni albo kończy się słowem „nigdy”. Zmieniony robots.txt Google odczytuje w okolicach doby, z bardzo wąskim rozrzutem do mniej więcej dwudziestu pięciu godzin. Praktyczny wniosek: odblokowanie sekcji serwisu w robots.txt zadziała szybko i przewidywalnie, natomiast wrzucenie dwóch tysięcy adresów do sitemapy nie jest przyciskiem przyspieszającym indeksację. Sitemapa pomaga w odkrywaniu, nie w selekcji.
Szósty wniosek dotyczy anotacji linków. Przedział od kilku minut do trzech tygodni, z ogonem liczonym w miesiącach, tłumaczy zjawisko, które wiele osób zna z praktyki: nowy link wewnętrzny albo zewnętrzny bywa widoczny w raportach długo przed tym, zanim przełoży się na jakikolwiek ruch pozycji. Jeżeli przebudowujecie linkowanie wewnętrzne, pierwsza sensowna ocena efektu wypada po miesiącu, a nie po tygodniu.
Co to znaczy dla AIO i widoczności w modelach
Warstwa generatywna dziedziczy opóźnienia warstwy klasycznej. AI Overviews, tryb AI w wyszukiwarce i asystenci korzystający z indeksu Google nie mają osobnego, szybszego kanału pobierania dla waszych treści. Jeżeli ponowne pobranie trwa typowo 30 dni, to nowa sekcja FAQ dodana na podstronie produktowej ma szansę zasilić odpowiedź generatywną dopiero po tym czasie, a nie od razu po publikacji.
Ma to praktyczną konsekwencję dla strategii cytowalności. Jeżeli chcecie, żeby model zacytował konkretną definicję albo liczbę, lepiej opublikować ją jako nowy adres URL niż doklejać do starego artykułu. Nowy URL mieści się w oknie dwudziestu godzin na odkrycie, podczas gdy aktualizacja istniejącego adresu wpada w okno trzydziestodniowe. To nie jest trik, tylko konsekwencja tego, jak działa harmonogram pobierania.
Osobny sygnał dotyczy danych strukturalnych. Przedział od kilku godzin do dwóch tygodni, z ogonem „tygodnie lub nigdy”, oznacza, że wdrożenie schematu nie jest zmianą natychmiastową. Jeżeli testujecie wpływ danych strukturalnych na widoczność w odpowiedziach generatywnych, okno pomiarowe krótsze niż trzy tygodnie prawie na pewno da wam fałszywy wynik negatywny.
Reakcje branży
Reakcje rozłożyły się na dwie strony. Część praktyków przyjęła tabele z ulgą, bo dają wreszcie wspólny słownik w rozmowie z klientem i z zarządem. Zamiast tłumaczyć, że „to zależy”, można pokazać przedział i wskazać, gdzie dany serwis w nim siedzi.
Druga część branży ostrzega przed traktowaniem tych liczb jak gwarancji. Argument jest mocny: bez wielkości próby i bez definicji wartości typowej nie wiadomo, czy mediana dotyczy wszystkich adresów w sieci, czy tylko tych, które przeszły selekcję. Jeżeli Google liczy medianę indeksacji wyłącznie na adresach faktycznie zaindeksowanych, to półtorej godziny opisuje populację po filtrze, a nie przed nim. Dla serwisu, który walczy o samo wejście do indeksu, taka mediana jest nieinformatywna.
W polskim kontekście najgłośniej odbił się przedział odbudowy po core update. Trzy do sześciu miesięcy to okres dłuższy niż typowy kwartalny cykl rozliczeniowy w agencjach, co stawia pytanie o to, jak w ogóle raportować skuteczność działań naprawczych. Nasz case sklepu, który odzyskał ruch po core update, pokazuje ten sam rytm od strony danych: pierwsze realne ruchy pojawiły się dopiero po kilku miesiącach systematycznej pracy.
Pojawił się też głos pośredni, który wydaje się najbliższy prawdy operacyjnej. Te liczby są użyteczne nie jako prognoza, lecz jako test diagnostyczny. Jeżeli wasz serwis mieści się w widełkach, problem leży gdzie indziej niż w infrastrukturze pobierania i nie ma sensu wydawać budżetu na przyspieszanie serwera. Jeżeli odstajecie o rząd wielkości, macie twardą przesłankę, żeby szukać przyczyny technicznej albo jakościowej. Tabela nie mówi wam, co się stanie. Mówi, czy wasza sytuacja jest zwyczajna.
Warto też zwrócić uwagę na to, czego w tabelach nie ma. Nie ma ani słowa o czasie, w jakim treść trafia do odpowiedzi generatywnych, ani o tym, jak szybko zmienia się skład źródeł cytowanych w AI Overviews. To luka znacząca, bo właśnie tam przenosi się dziś najwięcej uwagi i budżetu. Dopóki Google nie poda własnych widełek dla warstwy generatywnej, jedyną sensowną hipotezą pozostaje ta, że dziedziczy ona opóźnienia warstwy klasycznej.
Co dalej
Na razie nie zanosi się na oficjalną publikację tych danych. Google rzadko zamienia materiał konferencyjny w dokumentację, a konferencje typu Deep Dive mają z założenia luźniejszą formułę niż blog Search Central. Warto więc traktować tabele jako roboczy punkt odniesienia i weryfikować je na własnych danych.
Najprostszy sposób weryfikacji jest też najtańszy. Weźcie dwadzieścia adresów opublikowanych w ostatnim kwartale, sprawdźcie w narzędziu do sprawdzania adresu URL datę ostatniego pobrania i policzcie, ile dni dzieli publikację od pierwszego fetcha. Jeżeli mediana istotnie przekracza dwadzieścia godzin, problemem jest odkrywanie, czyli linkowanie wewnętrzne i sitemapa. Jeżeli pierwszy fetch następuje szybko, ale kolejny nie przychodzi przez kwartał, problemem jest crawl demand, czyli jakość i częstotliwość zmian. Dwie różne diagnozy, dwa różne plany naprawcze.
Drugi krok to ustawienie okien pomiarowych pod te widełki. Zmiana tytułu i opisu: ocena po tygodniu. Wdrożenie danych strukturalnych: ocena po trzech tygodniach. Przebudowa kanonikalizacji: ocena po miesiącu. Działania po core update: ocena po kwartale, z kontrolnym odczytem po pół roku. Jeżeli nie wiecie, które raporty czytać na którym etapie, pomocny będzie nasz przewodnik po raportach Search Console.
Trzeci krok dotyczy komunikacji. Jeżeli pracujecie po stronie agencji albo in house, te widełki są argumentem w rozmowie o harmonogramie. Obietnica „zaindeksujemy to w tydzień” jest obietnicą, nad którą nie macie kontroli, bo decyzja o pobraniu i o selekcji leży po stronie wyszukiwarki. Obietnica „usuniemy przyczyny techniczne i zmierzymy efekt po kwartale” jest obietnicą wykonalną. Różnica wydaje się kosmetyczna, ale to ona decyduje o tym, czy projekt kończy się rozliczeniem efektu, czy kłótnią o termin.
Najważniejsza zmiana nie dotyczy jednak żadnej pojedynczej liczby. Dotyczy tego, że kolumna „najwolniej” w tabelach Google tak często kończy się słowem „nigdy”. To najmocniejsze potwierdzenie tezy, która od kilku lat przebija się w danych praktyków: indeksacja nie jest kwestią przepustowości, tylko selekcji. Wyszukiwarka nie ma problemu z pobraniem waszych stron. Ma problem z uznaniem, że warto.
FAQ
Czy Google oficjalnie opublikowało te widełki czasowe?
Nie. Dane pochodzą z prezentacji Gary’ego Illyesa na Search Central Live Deep Dive Europe w Barcelonie 2 października 2026 roku i krążą w branży za pośrednictwem relacji uczestników konferencji. Nie ma komunikatu prasowego ani wpisu na blogu Search Central, nie podano też metodologii ani wielkości próby. Traktujcie je jako punkty odniesienia, nie jako zobowiązanie Google.
Ile realnie trwa wyjście z core update?
Według zaprezentowanych tabel typowo od 3 do 6 miesięcy, a w najwolniejszym wariancie od pół roku do roku. To znacznie dłużej niż kwartalny cykl raportowania w większości agencji, więc plan naprawczy po aktualizacji warto rozpisywać na dwa kwartały z kontrolnym odczytem po sześciu miesiącach.
Dlaczego moja zaktualizowana podstrona nie zmienia się w wynikach?
Ponieważ typowy czas ponownego pobrania znanego adresu to około 30 dni, a nie kilka godzin. Zanim uznacie aktualizację za nieskuteczną, sprawdźcie w narzędziu do sprawdzania adresu URL, czy Googlebot w ogóle pobrał nową wersję strony. Jeżeli data ostatniego pobrania jest wcześniejsza niż wasza edycja, mierzycie starą treść.
Czy szybkie serwery przyspieszą indeksację?
Tylko częściowo. Szybkie odpowiedzi i brak błędów 429 oraz 5xx podnoszą crawl rate limit, czyli to, ile Googlebot może pobrać. Nie wpływają jednak na crawl demand, czyli na to, ile Googlebot chce pobrać, bo ten składnik zależy od jakości serwisu, częstotliwości zmian i popularności adresów. Serwer naprawia połowę problemu, redakcja drugą.
Co oznacza „nigdy” w kolumnie najwolniejszych przypadków?
W relacjach z prezentacji słowo „nigdy” powtarza się przy odkrywaniu, indeksacji i danych strukturalnych, i zwykle wiąże się z oceną jakości, a nie z zatorem w kolejce. Innymi słowy, część adresów nie czeka na swoją turę, tylko nie zostanie przetworzona wcale, bo wyszukiwarka nie uznała ich za wartościowe.