Ile trwa skanowanie, indeksowanie i ponowna ocena stron w Google: własne czasy Google z Barcelony

2 października 2026 roku, w ostatnim dniu Search Central Live Deep Dive w Barcelonie, Gary Illyes z Google pokazał trzy slajdy zatytułowane „Ile to trwa…”: skanowanie, indeksowanie i wyświetlanie w wynikach. Każdy wymieniał procesy Google i podawał dla nich czas minimalny, zwykły i najdłuższy z wewnętrznej analizy Google. John Campbell z agencji ROAST był na sali i opublikował tabele tego samego dnia. Nazwał to zupełnie nową informacją i dla każdego, kto na pytanie „kiedy Google to podchwyci?” odpowiadał „to zależy”, rzeczywiście nią jest.

Gdy tabele zaczęły krążyć w sieci, Gary powiedział Barry’emu Schwartzowi, że slajdy były „ćwiczeniem, które miało sprawdzić, czy publiczność potrafi odnieść się do liczb wyciągniętych wewnętrznie” (Search Engine Roundtable). Przeczytaliśmy je w tym duchu: zestawiliśmy każdy wiersz z tym, co mówi dokumentacja Google, sprawdziliśmy deklaracje o czasie wdrażania aktualizacji w Search Status Dashboard i porównaliśmy tabele ROAST z dwoma innymi zapisami uczestników. Powstał przewodnik po tym, co te liczby znaczą, w czym rozmijają się z pisemnymi wskazówkami Google i jak długo czekać po zmianie na stronie małej firmy. Resztę trzeciego dnia podsumowujemy na końcu.

Co Google pokazał w Barcelonie?

Gary Illyes pokazał, ile czasu zajmują 23 procesy Google, podzielone na skanowanie, indeksowanie i wyświetlanie w wynikach. Dla każdego podał czas minimalny, zwykły i najdłuższy. Większość zwykłych czasów jest krótka: od godzin do kilku tygodni. Te najdłuższe sięgają miesięcy albo roku, a w pięciu z nich pojawia się słowo „nigdy”.

Każdy slajd rozmieszczał procesy na skali od sekund do roku. ROAST przepisał kolumny z czasem zwykłym i najdłuższym do trzech tabel, a Search Engine Roundtable, Search Engine Journal, PPC Land i inne serwisy przedrukowały je w ciągu kilku dni. Wartości minimalnych nie przepisano, ale widać je na zdjęciu slajdu o indeksowaniu, które zrobił ROAST i które pokazujemy niżej. Jest tam też przypis: czasy są „oparte na analizie wewnętrznej”.

Dwa zapisy uczestników nie zależą od ROAST. Ibrahim Anjro zebrał otwartą bazę wiedzy o wydarzeniu z nagrania i slajdów, a Liv Day z Digitaloft napisała podsumowanie. Oba źródła zgadzają się z ROAST we wszystkich zwykłych wartościach, które podają, choć Digitaloft obejmuje tylko około połowy wierszy. Baza wiedzy odnotowuje też, słowami jej autora, że czas wykrycia jest średnią „dla wszystkich znanych jej witryn” oraz że Gary nazwał średnią 1,5 godziny dla indeksowania „prawdopodobnie obniżoną przez efekt selekcji, bo tak wiele serwisów informacyjnych stale wypuszcza artykuły”. Gary podkreślił też, że procesy tworzą łańcuch. Google nie zaindeksuje strony, zanim jej nie zeskanuje, więc opóźnienia się sumują.

Google nie podał, jakich witryn ani jakiego okresu dotyczą wartości „zwykłe”; na tę lukę zwrócił uwagę Search Engine Journal. Nasza interpretacja: to średnie dla całej sieci, przesunięte w stronę szybkiego końca przez duże serwisy publikujące przez cały dzień. Strona małej firmy z kilkudziesięcioma podstronami raczej trafi bliżej wolnego końca każdego wiersza.

Ile trwa skanowanie?

Według liczb ze slajdu Google znajduje nowy URL po około 20 godzinach, a do znanego wraca mniej więcej raz w miesiącu. Zmianę w robots.txt odbiera w ciągu doby. Pisemne wskazówki Google są ostrożniejsze: nawet przy zgłoszonym skanowaniu mówią o dniach lub tygodniach, a samego skanowania w ogóle nie obiecują.

Dla małej firmy najważniejszy jest wiersz o ponownym skanowaniu. Zmień cenę, numer telefonu albo godziny otwarcia na stronie, którą Google rzadko odwiedza, a jej zapisana kopia może być nieaktualna przez miesiąc lub dłużej. Pięć dni po wydarzeniu ROAST opublikował dane z własnej witryny: dla 178 adresów URL sprawdzanych codziennie przez 30 dni średni czas od ostatniego skanowania strony przez Google wynosił 39,2 dnia. Opóźnienie dla strony głównej wynosiło 1,6 dnia. To jedna witryna agencji, ale pokazuje, jak bardzo pojedyncza witryna może odbiegać od 30 dni typowych dla całej sieci.

Dla stron, które faktycznie się zmieniają, Narzędzie do sprawdzania adresów URL pozwala zgłosić indeksowanie jednego adresu naraz, choć przewodnik Google o ponownym skanowaniu zaznacza, że obowiązuje limit i że ponowna prośba o ten sam URL „nie sprawi, że zostanie zeskanowany szybciej”. Mapa witryny obejmuje całą witrynę, ale Google bierze pod uwagę jej datę lastmod tylko wtedy, gdy jest ona „konsekwentnie i weryfikowalnie” prawdziwa. System CMS, który codziennie wstawia dzisiejszą datę na każdej stronie, daje Google powód, by to pole ignorować.

robots.txt to jedyny wiersz, w którym slajd i dokumentacja zgadzają się co do zwykłego czasu, 24 godzin, choć dokumentacja dodaje, że Google może zachować kopię w pamięci podręcznej dłużej, gdy odświeżenie się nie powiedzie. Po odblokowaniu czegoś ważnego możesz w raporcie robots.txt poprosić Google o ponowne pobranie pliku, ale Google ostrzega, że to „nie gwarantuje natychmiastowego ponownego skanowania odblokowanych adresów URL”.

Limit wydajności skanowania to wiersz do zapamiętania przed wyprzedażą lub zmianą hostingu. ROAST podaje, że limit może spaść w ciągu sekund, gdy Google ogranicza skanowanie, a według slajdu powrót do normy zajmuje od jednego do trzech tygodni. Przewodnik Google o budżecie skanowania podaje przyczynę: gdy witryna zwalnia albo odpowiada błędami 5xx lub 429, „limit się obniża i Google skanuje mniej”. Pierwszego dnia tego samego wydarzenia prelegenci Google wskazali jako narastające problemy sieci CDN blokujące Googlebota oraz strony weryfikacyjne (challenge pages) zwracające kod 200 OK (ROAST, dzień 1). Według liczb ze slajdu reguła zapory, która przez jeden weekend traktuje Googlebota jak atak, może oznaczać tygodnie wolniejszego skanowania.

Ile trwa indeksowanie?

Gdy Google ma już stronę, według slajdu indeksowanie trwa około 1,5 godziny. Zmiany strukturalne trwają dłużej: od jednego do trzech tygodni przy zmianie strony kanonicznej, od jednego do trzech miesięcy przy przeniesieniu witryny. Strony pomocy Google są wolniejsze od slajdu przy indeksowaniu i szybsze przy przeniesieniach witryn.

1,5 godziny i „mniej więcej dzień” ze strony pomocy prawdopodobnie mierzą różne rzeczy. ROAST wyjaśnia, że „od początku do końca” oznacza „wszystkie krytyczne procesy kończą się powodzeniem”. Strona pomocy opisuje to, co widzi właściciel witryny po zgłoszeniu indeksowania, łącznie z oczekiwaniem na skanowanie. Dodaj uwagę Gary’ego o serwisach informacyjnych, a obie wartości mogą być prawdziwe jednocześnie.

Na wolny koniec tego wiersza trafiają przede wszystkim małe witryny. W raporcie „Indeksowanie stron” status „Crawled - currently not indexed” oznacza, że Google pobrał stronę i pominął ją w indeksie; Google zaznacza, że „może zostać lub nie zostać zindeksowana w przyszłości” i że nie trzeba jej zgłaszać ponownie. Gdy właściciel witryny poskarżył się w 2025 roku, że z kilkumiesięcznej witryny zindeksowano tylko cztery strony, John Mueller odpowiedział, że „często to znak, że nasze systemy nie są przekonane co do całej witryny”. Długi ogon widać też w narzędziach śledzących indeksowanie: IndexCheckr, który sprzedaje takie narzędzie, podaje średnią 27,4 dnia dla stron monitorowanych przez jego użytkowników, liczoną od początku śledzenia.

Przy przeniesieniach witryn jest odwrotnie. Przewodnik Google mówi, że „przeniesienie większości stron małej lub średniej witryny może zająć kilka tygodni, a większe witryny potrzebują więcej czasu”. Slajd zgadza się co do wartości minimalnej, która na zdjęciu brzmi „a few weeks (small)” (kilka tygodni, mała witryna), ale typowe przeniesienie trwa na nim od jednego do trzech miesięcy, a najdłuższe od sześciu miesięcy do ponad roku. Ten sam przewodnik każe zachować przekierowania „zazwyczaj co najmniej 1 rok”. Ruch ma własny zegar. W badaniu 892 migracji domen przeprowadzonym przez Dana Taylora z agencji 10 Spurs nowa domena potrzebowała średnio 523 dni, by osiągnąć ruch organiczny starej domeny. Badanie opierało się na zewnętrznych szacunkach ruchu i próbie zebranej przez społeczność, więc jego średnia więcej mówi o ryzyku niż o jakiejkolwiek pojedynczej witrynie.

Przy zmianach strony kanonicznej najdłuższy przypadek ze slajdu sam podaje przyczynę: sprzeczne sygnały. Gdy tag canonical wskazuje jeden URL, linki wewnętrzne i mapa witryny drugi, a przekierowanie trzeci, Google potrzebuje miesięcy, by się zdecydować. Rada Johna Muellera z drugiego dnia brzmiała: stosuj przekierowania przy przeniesieniach witryn i dbaj o jednoznaczne sygnały kanoniczne (ROAST, dzień 2). Dane strukturalne mają to samo „albo nigdy” co indeksowanie: znaczniki na stronie, którą Google ocenia nisko, mogą nigdy nie zamienić się w wynik rozszerzony, choćby były w pełni poprawne.

Po jakim czasie zmiany pojawiają się w wynikach wyszukiwania?

Według slajdu nowy tytuł lub fragment widać zwykle po jednym lub dwóch dniach, a Google cofa działanie ręczne od jednego do dwóch tygodni po prośbie o ponowne rozpatrzenie. Najwolniejsza jest odbudowa po aktualizacji podstawowej (core update): zwykle od trzech do sześciu miesięcy, a w najgorszym razie witryna czeka na kolejną aktualizację podstawową.

Narzędzie do usuwania to najszybszy sposób z całej listy i tu strona pomocy Google zgadza się ze slajdem. Ukrywa adres URL w wynikach na około sześć miesięcy, a Google zaznacza, że zablokowanie adresu URL nie powstrzymuje Google przed skanowaniem strony. Trwałe usunięcie nadal wymaga zmiany na samej stronie, a wtedy obowiązuje wolniejszy zegar indeksowania.

Przy odbudowie po core update najważniejsza jest realistyczna liczba. Strona Google o aktualizacjach podstawowych mówi, że część zmian „może zacząć działać po kilku dniach, ale może to potrwać kilka miesięcy”, a jeśli po kilku miesiącach nie widać efektu, „może to oznaczać czekanie na kolejną aktualizację podstawową”. Baza wiedzy zapisuje zastrzeżenie, które tabela ROAST zgubiła: odbudowa trwa od trzech do sześciu miesięcy „po tym, jak witryna wykonała pracę, by odzyskać ruch”, więc zegar rusza, gdy poprawki są gotowe. Dotychczasowe przypadki sugerują, że nawet to bywa zbyt optymistyczne: po wrześniowej aktualizacji pomocnych treści (helpful content update) z 2023 roku Search Engine Roundtable opisał pierwsze odbudowy dopiero przy core update z sierpnia 2024 roku, jedenaście miesięcy później, a Glenn Gabe naliczył 47 witryn ze wzrostami wśród ponad 380 śledzonych.

Przy działaniach ręcznych slajd dodaje coś, o czym dokumentacja nie wspomina: nieaktywne witryny czekają znacznie dłużej. Sama strona pomocy mówi, że rozpatrywanie spraw związanych z linkami może trwać dłużej niż zwykle, i prosi, by nie wysyłać nowej prośby przed decyzją w sprawie poprzedniej.

Jak długo trwa wdrażanie aktualizacji podstawowych i antyspamowych?

W tabelach ROAST wdrożenie aktualizacji podstawowej trwa od dwóch do czterech tygodni, a antyspamowej od jednego do dwóch dni. Search Status Dashboard Google pokazuje szerszy rozrzut: dziewięć aktualizacji podstawowych od marca 2024 roku trwało od 6 do 45 dni, a osiem antyspamowych od 19,5 godziny do prawie czterech tygodni.

Cztery z dziewięciu aktualizacji podstawowych zmieściły się w przedziale od dwóch do czterech tygodni. Z czterech aktualizacji antyspamowych z 2026 roku dwie zbliżyły się do wartości ROAST, czyli od jednego do dwóch dni: marcowa trwała 19,5 godziny, a czerwcowa dwa dni. Sierpniowa trwała 2 dni i 16 godzin, a wrześniowa 13 dni i 16 godzin; Gary przemawiał osiem dni po jej starcie, jak zauważył PPC Land. Własne komunikaty Google o starcie aktualizacji w panelu są ostrożne: „może potrwać do 2 tygodni”, „do 3 tygodni”, „do miesiąca”.

Baza wiedzy odczytuje tę samą linię na slajdzie inaczej: aktualizacja podstawowa wpływa na witrynę w ciągu od dwóch do czterech tygodni od początku wdrażania, a antyspamowa w ciągu od jednego do dwóch dni. Tak rozumiany slajd opisuje moment, w którym witryna odczuwa zmianę, a podane wyżej czasy trwania z panelu mu nie przeczą. Przetestowaliśmy sformułowanie ROAST, ponieważ to ta wersja się rozpowszechniła.

Do własnej analizy najprzydatniejszą liczbą, jaką Google opublikował, nadal jest ta ze strony o aktualizacjach podstawowych: odczekaj „co najmniej pełny tydzień po zakończeniu aktualizacji podstawowej”, zanim zaczniesz czytać dane w Search Console.

Dlaczego wciąż wraca słowo „nigdy”?

Na slajdach „nigdy” pojawia się przy wykrywaniu, ponownym skanowaniu, mapach witryn, indeksowaniu i danych strukturalnych, a ROAST zauważa, że zwykle wiąże się z jakością. Szybszy serwer nie uratuje strony, której Google nie uważa za wartą zachowania. Przewodnik Google o tym, jak działa Wyszukiwarka, mówi to wprost: Google „nie gwarantuje, że przeskanuje, zindeksuje lub wyświetli twoją stronę”.

Duy Nguyen, analityk jakości wyszukiwania w Google, wygłosił wykład o jakości wcześniej tego samego dnia. Opisał jakość jako setki sygnałów, które różnią się zależnie od rodzaju wyniku, przy czym Google stale testuje zmiany. Poradził, by przeczytać publiczne wytyczne dla raterów, które oceniają treść według nakładu pracy, oryginalności, talentu lub umiejętności i dokładności. Te cztery pojęcia trafiły do przewodnika Google o pomocnych treściach 1 października, dzień wcześniej; opisaliśmy tę zmianę w artykule o treści głównej. Powiedział też, że Google ocenia jakość strony niezależnie od tego, kto ją napisał. Niska jakość może być dziełem człowieka lub AI, a zasady dotyczące spamu Google nazywają masowo produkowane strony nadużywaniem treści masowych (scaled content abuse) „niezależnie od tego, jak je stworzono”.

Gary zamknął poranek jedną liczbą: Google odfiltrowuje 40 miliardów stron spamerskich dziennie. Liczba pojawiła się po raz pierwszy w raporcie Google o walce ze spamem za 2020 rok, opublikowanym w kwietniu 2021 roku („każdego dnia wykrywamy 40 miliardów spamerskich stron”), w porównaniu z 25 miliardami w raporcie za 2019 rok. Strona How Search Works o spamie nadal jej używa, a nowszego wyniku nie znaleźliśmy. Swojego ostrzeżenia, że treści masowe są teraz większym problemem niż spam linkowy, nie poparł żadnymi opublikowanymi danymi, więc pozostaje ono oceną z wnętrza zespołu.

Powiedział też, że aktualizacje podstawowe działają na poziomie strony, a nie domeny, dlatego niektóre strony w witrynie zyskują, a inne tracą. Przewodnik Google o systemach rankingowych mówi, że jego systemy „są zaprojektowane do pracy na poziomie strony”, po czym dodaje: „Wykorzystywane są też sygnały i klasyfikatory dotyczące całej witryny”. Google ocenia więc każdą stronę osobno, na tle tego, co sądzi o witrynie wokół niej.

Gdzie slajd i dokumentacja Google się rozchodzą

W większości wierszy slajd jest po prostu dokładniejszy niż dokumentacja, która nie podaje żadnej liczby. W kilku miejscach oba źródła wskazują różne kierunki, dlatego warto wiedzieć, skąd pochodzi dana liczba, zanim zacytujesz ją klientowi lub przełożonemu:

• Indeksowanie: około 1,5 godziny na slajdzie, od „mniej więcej dnia” do „tygodnia lub dwóch” na stronach pomocy.
• Przeniesienia witryn: zwykle od jednego do trzech miesięcy na slajdzie, „kilka tygodni” dla małych i średnich witryn w przewodniku.
• noindex i inne adnotacje meta: co najwyżej cztery dni na slajdzie; dokumentacja ostrzega, że ponowna wizyta „może potrwać miesiące”. Oba stwierdzenia mogą być prawdziwe, jeśli slajd liczy od ponownego skanowania.
• Wdrażanie aktualizacji, w odczytaniu slajdu przez ROAST: od dwóch do czterech tygodni dla aktualizacji podstawowych i od jednego do dwóch dni dla antyspamowych; w panelu od 6 do 45 dni oraz od 19,5 godziny do prawie czterech tygodni.
• Poziom strony: „nie na poziomie domeny” na scenie; sygnały dotyczące całej witryny „są też wykorzystywane” w przewodniku.

Zapisy uczestników rozchodzą się też w jednym miejscu: przy adnotacjach linków ROAST podaje „miesiące” jako czas najdłuższy, a baza wiedzy odczytuje punkt końcowy na slajdzie jako około roku.

Tak rozumiemy tę różnicę: dokumentację pisze się tak, by była bezpieczna dla każdej witryny, i rzadko się ją poprawia, a slajd pokazuje zmierzone średnie dla całej sieci. Żadne z nich nie jest obietnicą dla twojej witryny.

Co jeszcze Google powiedział trzeciego dnia

Oprócz czasów trzeci dzień obejmował rozumienie zapytań, ocenę jakości i spamu, drogę treści do Discover, nowe dane o produktach dla zakupów z AI oraz Search Console. Większość pokrywa się z tym, co Google już opublikował. Kilka punktów, głównie o przepisywaniu zapytań, istnieje na razie tylko jako słowa wypowiedziane ze sceny.

John Mueller zaczął od rozumienia zapytań. Google wykrywa język, pomija słowa funkcyjne (stop words), chyba że należą do nazwy, rozpoznaje encje i rozszerza synonimy, więc zapytanie „fried chicken place in barcelona” jest wyszukiwane tak, jakby brzmiało place OR area OR location OR restaurant. Niektóre synonimy zależą od kontekstu: GM oznacza General Motors obok słowa „car” i genetycznie zmodyfikowany obok słowa „barley”. „Rodzeństwo” (siblings), takie jak Canon i Nikon, jest uczone z wyszukiwań „X vs Y” i traktowane osobno. Strona Google How Search Works wspomina o „zaawansowanym systemie synonimów”, ale ani rodzeństwa, ani przepisywania w stylu OR nie opisuje żaden dokument, który znaleźliśmy. W AI Overviews i AI Mode model dodaje query fan-out (rozbijanie jednego zapytania na wiele pokrewnych wyszukiwań), co strona Google o funkcjach AI opisuje jako „wysyłanie wielu powiązanych wyszukiwań w podtematach i źródłach danych”. Mueller powiedział, że zapytania fan-out nie pojawiają się w Search Console, ponieważ nie pochodzą od użytkowników. Gary wyjaśnił następnie pobieranie kandydatów (retrieval): przed rankingiem Google zawęża indeks do stron kandydujących, język i kraj są na tym etapie ważnymi sygnałami, a o wyniku końcowym rozstrzyga jakość.

Eric Murillo, który w Google zajmuje się zaufaniem i bezpieczeństwem w Discover, powiedział, że nie ma specjalnego bota Discover: treści pochodzą ze zwykłego indeksu i przechodzą przez bramkę kwalifikacyjną. Jego rady dotyczące obrazów zgadzają się z dokumentacją Google o Discover co do joty: szerokość co najmniej 1200 px, ponad 300 000 pikseli, proporcje 16:9 i max-image-preview:large. Resztę o Discover opisaliśmy w naszym przewodniku po Discover.

Alex Jansen, inżynier oprogramowania w Google, przedstawił atrybuty konwersacyjne (conversational attributes) dla zakupów. Są udokumentowane: to sześć opcjonalnych atrybutów Merchant Center, ogłoszonych 20 maja 2026 roku, które „pomagają systemom AI i agentom konwersacyjnym lepiej rozumieć szczególne niuanse twoich produktów” (Merchant Center Help). Jego przykład z czajnikiem pochodzi od samego Google: strona pomocy o atrybucie pytań i odpowiedzi używa czajnika do herbaty z pięcioma często zadawanymi pytaniami. Wskazał też najważniejsze cechy produktu (product highlights), gdzie każdy produkt może mieć od 2 do 100 takich cech, a Google zaleca cztery do sześciu.

Ariel Kroszynski, który zarządza inżynierią front-endu w Search Console, omówił ostatni rok: grupy zapytań w raporcie Insights (październik 2025 roku, tylko dla usług z dużą liczbą zapytań), konfigurację opartą na AI raportu Skuteczność (Performance) (grudzień 2025 roku, najpierw dla ograniczonej grupy witryn) oraz raportowanie web multimodal (24 września 2026 roku). ROAST pisze, że nie było aktualizacji dotyczącej raportowania generatywnej AI. To znaczy, że nie ogłoszono niczego nowego: raport skuteczności generatywnej AI istnieje od 3 czerwca 2026 roku, a 31 sierpnia trafił do wszystkich witryn. Pokazuje, jak często twoje strony pojawiały się w AI Overviews i AI Mode, według strony, kraju, urządzenia i daty, bez danych o zapytaniach, co pasuje do tego, co Mueller powiedział o fan-out.

Pablo Pérez, starszy menedżer ds. badań marketingowych i insightów w Google, wrócił do modelu Messy Middle z 2020 roku, w którym kupujący krążą między eksploracją a oceną. Jego nowa teza brzmiała, że AI pozwala ludziom dłużej badać temat przed zakupem, a zainteresowanie wyszukiwaniem frazy „is [brand] legit” w Wielkiej Brytanii rosło od 2020 roku i osiągnęło szczyt w 2026. Nie mogliśmy sprawdzić tej serii samodzielnie; pochodzi z wystąpienia.

Gary zamknął trzy dni stwierdzeniem, że funkcje AI w Wyszukiwarce Google korzystają z tych samych procesów co tradycyjne wyniki. Przewodnik Google o funkcjach generatywnej AI mówi to samo na piśmie: optymalizacja pod wyszukiwanie z generatywną AI „to optymalizacja pod doświadczenie wyszukiwania, a więc nadal SEO”. Tę tezę omówiliśmy w artykule Dobre SEO to dobre GEO.

Co praktycy przynieśli na scenę

Prelegenci ze społeczności przynieśli liczby z własnych przypadków. Żadna nie miała opublikowanej metody, więc traktuj je jako przykłady: to liczby pokazane przez prelegentów, w relacji ROAST. Większość mierzyła, co strona robiła dla biznesu: od konwersji po zapytania od klientów i pytania kierowane do zespołu sprzedaży.

• Robert Wojno z Hostinger porównał ogólny poradnik „Co to jest hosting VPS?” (1,6 mln wyświetleń) z niszowym poradnikiem o uruchomieniu serwera Palworld (46 000 wyświetleń). Niszowa strona miała współczynnik klikalności 23 razy wyższy i lepiej konwertowała.
• Juan Seguí z acceseo dodał szczegółowe FAQ odpowiadające na pytania, które zadają prawdziwi rodzice, na przykład czy podwójny wózek mieści się w windzie razem z rodzicem. Kliknięcia organiczne wzrosły o 14%, a liczba pytań przedsprzedażowych kierowanych do zespołu spadła.
• Noe Rivas z seosve połączył stronę z wideo dla osób początkujących w danym temacie, a wynik pojawił się w AI Overviews, Gemini, YouTube i wyszukiwaniu grafiki.
• Nik Vujic z Get Stuff Digital uruchamia agentów LLM na danych z Search Console i GA4, by śledzić w czasie, na ile zapytań rankuje każdy artykuł.
• Alex Wright z iDHL pokazał markę, której sesje organiczne spadły o 47%, podczas gdy sesje bezpośrednie się utrzymały (spadek o 2%). Liczba zapytań od klientów na 100 kliknięć z wyszukiwarki wzrosła 2,7 raza, udział marki we wszystkich kliknięciach z wyszukiwania urósł z 17% do 38%, współczynnik klikalności w Google Ads zwiększył się o 36% przy niezmienionej pozycji reklam, a 83% jej cytowań w AI pochodziło ze stron, których marka nie posiada.

Dla małej firmy przypadek Wrighta jest najprzydatniejszy: kliknięcia spadły, a liczba zapytań od klientów na kliknięcie wzrosła. Najważniejsza jest liczba leadów miesięcznie, a same kliknięcia z Search Console mogą dawać mylny obraz.

Co to znaczy dla strony małej firmy

Slajd najbardziej przydaje się przy ustalaniu, kiedy sprawdzić wprowadzoną zmianę. Jeśli zmiana wyraźnie przekroczyła zwykły czas, zbadaj przyczynę; jeśli nadal mieści się w zakresie, poczekaj. Dla większości małych witryn uczciwe oczekiwanie leży między zwykłą wartością ze slajdu a ostrożniejszą liczbą w dokumentacji Google.

Dziś otwórz raport „Indeksowanie stron”. Strony w statusie „Crawled - currently not indexed” na razie leżą w kolumnie „nigdy” ze slajdu, a ponowne zgłoszenie indeksowania ich nie ruszy; może ruszyć je lepsza strona. „Discovered - currently not indexed” to co innego: Google mówi, że zwykle oznacza to odroczenie skanowania, by nie przeciążyć witryny, więc długa lista w tym statusie jest powodem, by sprawdzić szybkość serwera.

W tym tygodniu sprawdź, czy twoja sieć CDN lub ochrona przed botami przepuszcza Googlebota i czy strony weryfikacyjne (challenge pages) nie zwracają kodu 200 OK. Upewnij się też, że daty lastmod w mapie witryny zmieniają się tylko wtedy, gdy zmienia się strona. Jeśli planujesz migrację, zachowaj przekierowania co najmniej przez rok i zaplanuj pierwsze trzy miesiące wokół przeniesienia.

Od tego momentu zapisuj oczekiwaną datę przy każdej zmianie, według tabeli powyżej. Wolny tydzień nie wygląda wtedy na problem, a prawdziwy problem nie czeka miesiącami na reakcję.

To są średnie Google. Nikt spoza Google, nas też to dotyczy, nie może obiecać, kiedy Google przeskanuje, zindeksuje lub ponownie oceni stronę. Audyt może za to pokazać, w której kolumnie tabeli są twoje strony i dlaczego. Jeśli strony tkwią w „nigdy”, nasz audyt SEO strony zaczyna się właśnie tam.

Źródła

Wydarzenie:

• John Campbell, „Google Search Central Live Deep Dive, Barcelona, Day 3 Recap”, ROAST, 2 października 2026: weareroast.com; dzień 1, 30 września 2026: weareroast.com; dzień 2, 1 października 2026: weareroast.com
• John Campbell, „How Often Does Google Recrawl Pages? Real Data from the ROAST Website”, ROAST, 7 października 2026: weareroast.com
• Ibrahim Anjro, „Search Central Live Deep Dive Europe 2026: The Knowledge Base”, sesja D3-S17 „How long does it take to..?”, GitHub: github.com
• Liv Day, „Google Search Central Live Deep Dive Europe 2026: A Summary”, Digitaloft, 4 października 2026: digitaloft.co.uk
• Google Search Central Blog, „Search Central Deep Dive Europe 2026”, 6 lipca 2026: developers.google.com
• Barry Schwartz, „Google Search Data On Crawling, Indexing & Serving Timelines”, Search Engine Roundtable, 5 października 2026: seroundtable.com
• Matt G. Southern, „Google Shows How Long Crawling, Indexing & Recovery Can Take”, Search Engine Journal, 4 października 2026: searchenginejournal.com
• „Google says new pages take about 20 hours to be found, some never are”, PPC Land, 3 października 2026: ppc.land

Dokumentacja Google o skanowaniu, indeksowaniu i wyświetlaniu:

• Ask Google to recrawl your URLs: developers.google.com
• URL Inspection tool, Search Console Help: support.google.com
• Page indexing report, Search Console Help: support.google.com
• Build and submit a sitemap: developers.google.com; Sitemaps report, Search Console Help: support.google.com
• How Google interprets the robots.txt specification: developers.google.com; robots.txt report, Search Console Help: support.google.com
• Crawl budget management: developers.google.com; How HTTP status codes affect Google’s crawlers: developers.google.com
• Understand JavaScript SEO basics: developers.google.com
• Block search indexing with noindex: developers.google.com
• How to specify a canonical: developers.google.com
• Site moves and migrations: developers.google.com
• Video indexing report, Search Console Help: support.google.com
• Removals tool, Search Console Help: support.google.com
• Influencing title links: developers.google.com
• Manual actions report, Search Console Help: support.google.com
• Google Search’s core updates: developers.google.com; Google Search spam updates: developers.google.com
• Google Search Status Dashboard, Ranking history, odczytano 27 października 2026: status.search.google.com
• In-depth guide to how Google Search works: developers.google.com

Google o jakości, spamie i funkcjach AI:

• Creating helpful, reliable, people-first content: developers.google.com
• Spam policies for Google web search: developers.google.com
• How we fought Search spam on Google in 2020, 29 kwietnia 2021: developers.google.com; Webspam report 2019, 9 czerwca 2020: developers.google.com
• How Search Works, Detecting spam: google.com; Ranking results: google.com
• A guide to Google Search ranking systems: developers.google.com
• AI features and your website: developers.google.com; Optimizing your website for generative AI features on Google Search: developers.google.com
• Discover and your website: developers.google.com
• Merchant Center Help: conversational attributes support.google.com, question and answer support.google.com, product highlight support.google.com; Google Marketing Live shopping updates, 20 maja 2026: blog.google
• Search Central Blog: query groups, październik 2025 developers.google.com; AI-powered configuration, grudzień 2025 developers.google.com; Generative AI performance reports, 3 czerwca 2026 developers.google.com; web multimodal reporting, 24 września 2026 developers.google.com
• Think with Google, „Navigating purchase behavior and decision-making”, lipiec 2020: thinkwithgoogle.com

Dane niezależne i praktycy:

• „Google says poor indexing on strong hosting indicates quality issues”, PPC Land, 16 lipca 2025: ppc.land
• Joel Cariño, „Google Indexing Study: Insights from 16 Million Pages”, IndexCheckr, 28 lutego 2025: indexcheckr.com
• Dan Taylor, „How Long Should An SEO Migration Take? [Study]”, Search Engine Journal, 8 stycznia 2025: searchenginejournal.com
• Barry Schwartz, „Reports Of Google Helpful Content Update Resurrections With August 2024 Core Update”, Search Engine Roundtable, sierpień 2024: seroundtable.com