Google ujawnia, ile trwa crawl, indeksacja i powrót po core update. Liczby z Barcelony

Gary Illyes z Google pokazał na zamknięcie konferencji Search Central Live Deep Dive Europe w Barcelonie zestaw liczb, o które branża SEO dopytywała latami: ile naprawdę trwa wykrycie nowego adresu URL, przetworzenie mapy witryny, podmiana tytułu w wynikach i powrót widoczności po core update. Według relacji z sali typowe wykrycie nowego URL zajmuje około 20 godzin, pełny przebieg indeksacji około 1,5 godziny, a odbudowa po aktualizacji rdzenia algorytmu od 3 do 6 miesięcy. Google nie opublikowało tych slajdów na oficjalnej stronie wydarzenia, więc są to liczby z relacji uczestnika, a nie deklaracja poziomu usługi.

Kontekst: skąd się wzięły te liczby

Prezentacja padła 2 października 2026 roku, w ostatnim dniu Search Central Live Deep Dive Europe w Barcelonie. To format zamknięty, bez transmisji i bez publicznego zapisu, więc wszystko, co wiemy o zawartości slajdów, pochodzi z notatek uczestników. Pierwszy szczegółowy opis opublikował John Campbell z agencji ROAST, a następnie podchwyciły go największe serwisy branżowe, w tym Search Engine Journal i PPC Land. Sam Illyes, zgodnie z relacją, przedstawił dane jako efekt wewnętrznej analizy Google, a nie jako obietnicę składaną webmasterom.

To rozróżnienie jest kluczowe i warto je powtórzyć, zanim ktokolwiek wklei te liczby do oferty dla klienta. Prezentacja operuje pojęciem „typowego” czasu, ale nigdzie nie definiuje, czy chodzi o medianę, o średnią, czy o jakiś przedział wokół mediany. Nie znamy wielkości próby, okresu pomiaru ani tego, czy dane obejmują cały indeks, czy tylko wybrany segment witryn. W tabelach, które trafiły do relacji, brakuje też kolumny z czasami najkrótszymi, więc widzimy tylko wartość środkową i ogon rozkładu.

Mimo tych zastrzeżeń jest to najbardziej konkretny zestaw danych o tempie pracy infrastruktury Google, jaki wyciekł do publicznego obiegu od lat. Do tej pory specjaliści operowali anegdotami, własnymi pomiarami na kilkunastu domenach i wymijającymi odpowiedziami w rodzaju „to zależy”. Teraz mamy punkt odniesienia, nawet jeśli jest to punkt odniesienia z gwiazdką.

Kluczowe fakty: pełna tabela czasów

Relacje zgodnie dzielą dane na trzy warstwy, które odpowiadają trzem etapom pracy wyszukiwarki: crawlowanie, indeksowanie i serwowanie wyników. Pierwsza tabela obejmuje etap, na którym Googlebot w ogóle dowiaduje się o istnieniu zasobu i go pobiera.

Druga tabela dotyczy zmian, które wprowadzamy na już istniejących stronach, oraz sytuacji kryzysowych, w których chcemy odzyskać utraconą widoczność.

Najbardziej zaskakująca liczba w całym zestawieniu to 1,5 godziny na pełną indeksację. Brzmi absurdalnie krótko wobec codziennych doświadczeń z Search Console, ale trzeba czytać ją razem z wierszem powyżej. Indeksacja liczy się od momentu, w którym dokument trafia do potoku przetwarzania, a nie od chwili publikacji. Jeśli wykrycie adresu zajmuje 20 godzin, a odświeżenie znanej strony 30 dni, to z perspektywy właściciela witryny realny czas od kliknięcia „Opublikuj” do pojawienia się w wynikach wciąż liczy się w dniach.

Illyes miał wprost ostrzec, że procesy są ze sobą powiązane i że opóźnienia się kumulują. Strona, która trafiła do kolejki z niskim priorytetem na etapie wykrywania, nie nadrobi tego na etapie indeksacji. To samo dotyczy pozycji „nigdy”, która pojawia się w kolumnie czasów najdłuższych aż czterokrotnie. Według relacji „nigdy” prawie zawsze oznacza decyzję jakościową, a nie zator w kolejce. Google nie zapomniało o takim adresie. Google go ocenił i postanowił nie wydawać na niego zasobów.

Osobną wartością tej tabeli jest wiersz o pliku robots.txt: typowo około 24 godzin, a w najdłuższym wariancie około 25 godzin. To jedyna pozycja w całym zestawieniu, w której ogon rozkładu praktycznie pokrywa się z wartością typową. Innymi słowy, odczyt robots.txt jest przewidywalny co do godziny, czego nie można powiedzieć o żadnym innym procesie na liście. Praktyczny wniosek jest prosty: jeśli przypadkiem zablokujesz katalog, masz mniej więcej dobę, zanim skutek rozejdzie się po całej witrynie, i mniej więcej dobę na odwrócenie błędu po poprawce. Przy wszystkich pozostałych operacjach taka pewność nie istnieje.

Co to znaczy dla codziennej pracy nad SEO

Pierwszy praktyczny wniosek dotyczy map witryny. Przez lata w polskiej branży pokutowało przekonanie, że sitemapa jest czymś w rodzaju przycisku przyspieszającego indeksację. Liczba 24 godzin przy czasie najdłuższym sięgającym 14 dni albo nigdy mówi coś innego: mapa witryny to kanał zgłoszeniowy, nie kanał priorytetowy. Jeśli strony z sitemapy nie wchodzą do indeksu, problemem nie jest format pliku ani częstotliwość jego odpytywania, tylko ocena jakości. Rozpisaliśmy ten mechanizm szerzej w materiale Strona nie jest indeksowana: 9 przyczyn i naprawa.

Drugi wniosek dotyczy cyklu odświeżania treści. Trzydzieści dni jako typowy czas ponownego pobrania znanego adresu to dane, które realnie zmieniają kalendarz redakcyjny. Jeśli aktualizujesz stary poradnik w poniedziałek i w piątek sprawdzasz, czy coś drgnęło w rankingu, mierzysz szum, a nie efekt. Pierwszy sensowny pomiar wypada po miesiącu, a dla witryn o słabszym profilu linkowym jeszcze później. Z drugiej strony liczba 30 dni jest wartością typową, więc serwisy z wysokim tempem publikacji i mocnym linkowaniem wewnętrznym mogą ją skracać. Mechanikę podziału zasobu crawlowego opisaliśmy w tekście Crawl budget w praktyce 2026.

Trzeci wniosek jest najtrudniejszy do sprzedania klientowi: core update recovery w przedziale od 3 do 6 miesięcy, z ogonem sięgającym roku. To potwierdza, co praktycy powtarzają po każdej większej aktualizacji, czyli że odbudowa widoczności zwykle nie następuje w ramach tej samej aktualizacji, która spadek wywołała. Trzeba doczekać kolejnego przeliczenia. Dla agencji oznacza to, że uczciwy harmonogram naprawczy po core update zaczyna się od kwartału, a nie od „sprawdzimy za dwa tygodnie”.

Czwarty wniosek to pochwała dla tych, którzy robią audyty tytułów i opisów. Zmiana title i snippetu propaguje się w 1–2 dni. To jeden z nielicznych elementów SEO z natychmiastowym sprzężeniem zwrotnym, więc jeśli szukasz działań o szybkim zwrocie, warstwa metadanych wciąż jest najtańszym testem, jaki masz pod ręką.

Osobno warto odnotować wiersz o zmianie kanonicznego URL. Przedział od 1 do 3 tygodni pokrywa się z tym, co Google potwierdzało już wcześniej w tym roku, o czym pisaliśmy w tekście Google potwierdza: naprawa kanonicznych URL może zająć nawet dwa tygodnie. Nowy slajd dokłada do tego kolumnę z czasem najdłuższym, czyli miesiące przy sprzecznych sygnałach. Sprzeczne sygnały to w praktyce rozjazd między tagiem canonical, mapą witryny, linkowaniem wewnętrznym i przekierowaniami.

Co to znaczy dla widoczności w AI

Liczby dotyczą klasycznego potoku wyszukiwarki, ale konsekwencje dla AIO są bezpośrednie. Modele generatywne Google, zarówno AI Overviews, jak i AI Mode, sięgają po dokumenty z tego samego indeksu. Jeśli strona jest „crawled, currently not indexed”, nie istnieje też jako potencjalne źródło cytowania w odpowiedzi generowanej. Nie ma osobnego, szybszego kanału dla warstwy AI.

Praktyczny skutek jest taki, że treść przygotowana pod cytowanie w odpowiedziach AI dziedziczy wszystkie opóźnienia z tabeli. Publikujesz dziś, Googlebot przyjdzie za dobę, a jeśli dokument przejdzie ocenę jakości, zacznie pracować w warstwie generatywnej dopiero po pełnym cyklu. Odświeżenie istniejącego materiału, na przykład dopisanie świeżych danych, które mają zwiększyć szansę na cytowanie, wpada w okno 30 dni. To tłumaczy, dlaczego tak wiele testów AIO prowadzonych w cyklu dwutygodniowym nie pokazuje żadnego sygnału. Nie dlatego, że zmiana nie działa, tylko dlatego, że wyszukiwarka jeszcze jej nie zobaczyła.

Dla danych strukturalnych tabela podaje przedział od kilku godzin do 1–2 tygodni, z ogonem „tygodnie lub nigdy”. Schema jest więc szybsza niż przebudowa treści, ale wolniejsza niż zmiana tytułu. Jeśli wdrażasz rozbudowany Product, FAQPage albo Organization pod widoczność w asystentach, zaplanuj okno obserwacji na co najmniej dwa tygodnie.

Jak sprawdzić te liczby na własnej witrynie

Tabela z Barcelony ma sens dopiero wtedy, gdy zestawisz ją z własnymi danymi. Trzy źródła wystarczą do zrobienia tego w godzinę. Pierwsze to raport statystyk indeksowania w Search Console, w którym widać liczbę żądań Googlebota na dzień, średni czas odpowiedzi i podział na typ pobrania (odkrycie kontra odświeżenie). Jeśli udział odkryć jest bliski zera przy regularnych publikacjach, masz problem z wykrywaniem nowych adresów, a nie z jakością treści.

Drugie źródło to narzędzie do sprawdzania adresów URL. Pole z datą ostatniego pobrania pokazuje realny interwał odświeżania dla konkretnej strony. Zbierz dziesięć do piętnastu adresów z różnych sekcji serwisu, zanotuj daty i policz medianę. Jeśli wychodzi istotnie powyżej 30 dni, wiesz, że Twoja witryna leży w wolniejszej części rozkładu, a wtedy każdy plan optymalizacyjny trzeba rozpisać na dłuższy horyzont. Przy okazji zwróć uwagę na status: „Crawled, currently not indexed” na świeżo pobranej stronie to sygnał oceny jakości, a nie opóźnienia.

Trzecie źródło to logi serwera, jeśli masz do nich dostęp. Logi są jedynym miejscem, w którym zobaczysz pełny obraz, łącznie z pobraniami, które nigdy nie skończyły się indeksacją, oraz z żądaniami od botów AI. W odróżnieniu od Search Console, która pokazuje dane zagregowane i z opóźnieniem, log daje znacznik czasu co do sekundy. Dla witryn powyżej kilku tysięcy adresów to najtańszy sposób, by sprawdzić, czy Googlebot w ogóle dociera do sekcji, na której Ci zależy.

Przy każdej z tych weryfikacji pamiętaj o jednej pułapce. Raporty Search Console same bywają opóźnione, czasem o tygodnie, co w tym roku było już przedmiotem osobnej awarii. Jeśli liczby z raportu nie zgadzają się z tym, co widzisz w wynikach wyszukiwania, najpierw sprawdź, czy nie patrzysz na nieaktualne dane, a dopiero potem wyciągaj wnioski o crawlowaniu.

Reakcje branży

Odbiór w anglojęzycznej części branży był ostrożnie pozytywny. Komentatorzy chwalili sam fakt, że Google w ogóle pokazuje rozkłady, zamiast odsyłać do ogólników, ale szybko zaczęli punktować brak metodologii. Najczęściej powtarzane zastrzeżenie dotyczy słowa „typowy”. Bez informacji o tym, czy to mediana, czy średnia, ta sama liczba może opisywać dwa zupełnie różne światy, bo rozkłady czasów crawlowania są silnie skośne.

Druga fala komentarzy dotyczyła ryzyka nadużyć. Już w dniu publikacji relacji pojawiły się głosy, że liczby trafią do ofert agencyjnych jako obietnice terminów, mimo że Google nigdzie ich nie potwierdziło oficjalnie i nie wiąże się nimi. Z perspektywy polskiego rynku to realne ryzyko, bo zapis w rodzaju „indeksacja w 20 godzin” brzmi jak parametr usługi, a jest tylko wartością środkową z nieznanej próby.

Trzeci wątek to pytanie, dlaczego slajdy nie trafiły na oficjalną stronę wydarzenia. Search Central Live Deep Dive to cykl płatny i zamknięty, a Google nie ma obowiązku publikować materiałów. Część obserwatorów czyta to jednak jako świadomą decyzję: dane mają krążyć w branży, ale bez statusu dokumentacji, do której można się odwołać w sporze.

Co dalej

Najważniejsze pytanie brzmi, czy Google potwierdzi te liczby w oficjalnej dokumentacji. Precedensy są mieszane. Część informacji z konferencji zamkniętych trafiała później do Search Central Blog, część pozostawała na zawsze w statusie „ktoś to słyszał na sali”. Jeśli potwierdzenia nie będzie, tabela pozostanie użyteczną heurystyką, ale nie argumentem.

Dla zespołów SEO sensowny plan na najbliższe tygodnie wygląda następująco. Po pierwsze, zestaw te liczby z własnymi danymi z Search Console, zwłaszcza z raportem statystyk indeksowania i datami ostatniego pobrania w narzędziu do sprawdzania adresów URL. Jeśli Twoja witryna odstaje w górę, masz konkretny problem do zdiagnozowania, a nie ogólne poczucie, że „Google wolno chodzi”. Po drugie, przejrzyj zobowiązania terminowe w umowach i ofertach pod kątem wierszy o migracji i powrocie po core update. Po trzecie, wydłuż okna pomiarowe w testach treściowych do co najmniej 30 dni, bo krótsze okno mierzy przede wszystkim opóźnienie infrastruktury.

Warto też pamiętać, że tabela opisuje stan na październik 2026 roku. Google przebudowuje potok przetwarzania pod obciążenie generatywne, a wraz z nim zmienia się ekonomia crawlowania. Liczby, które dziś wyglądają na stabilne, za rok mogą opisywać inny system.

FAQ