W nocy

O 3 w nocy czasu pacyficznego moja produkcyjna strona obsługuje więcej żądań niż w jakimkolwiek momencie dnia roboczego. Nie od użytkowników. Od botów.

Googlebot indeksuje 21 000 stron. Bingbot indeksuje 10 000. Moje kompleksowe sprawdzenie nocne przetwarza 15 000 wpisów blogowych i stron firmowych. Rozgrzewka wypełnia pamięć podręczną Cloudflare na brzegu sieci, przygotowując ją na ruch następnego dnia. Łącznie procesy nocne dotykają więcej stron niż wszyscy ludzcy odwiedzający razem wzięci.

Strona, którą buduję w ciągu dnia, nie jest tą, która ma największe znaczenie. Największe znaczenie ma ta, którą crawlery widzą o 3 w nocy.

Spis indeksowania

Codziennie przeprowadzam spis indeksowania, który zlicza, co boty zobaczyły w ciągu ostatnich 24 godzin. Spis wykorzystuje analitykę Cloudflare API filtrowaną według user agenta. Liczby opowiadają historię o tym, co cenią wyszukiwarki:

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

Oferty pracy pochłaniają połowę budżetu indeksowania. Googlebot indeksuje 10 654 stron z ofertami dziennie. Mapa witryny z ofertami nie ma limitu. Każda kwalifikująca się oferta jest uwzględniona. Alokacja budżetu indeksowania mówi mi, co Google uznaje za najcenniejszą treść na stronie.

Wpisy blogowe otrzymują 298 wizyt crawlerów dziennie, mimo że stanowią treść najwyższej jakości. Stosunek nakładów na indeksowanie (oferty pracy 50 razy więcej niż blog) nie odpowiada nakładom na tworzenie treści (blog wymaga 100 razy więcej wysiłku na stronę niż oferty pracy). Wyszukiwarki indeksują to, co mogą przetwarzać na skalę, a nie to, co wymagało największego wysiłku.

Strony firmowe otrzymują 14 wizyt crawlerów dziennie, mimo że mapa witryny zawiera ponad 7000 stron. To problem wygłodzenia budżetu indeksowania: strony z ofertami pochłaniają tak dużo budżetu, że strony firmowe ledwo zostają odkryte. Dane nocne ujawniły ten problem. Bez spisu nie wiedziałbym, że 7000 stron firmowych jest zasadniczo niewidocznych dla crawlerów.

Co mówi status 410

Spis śledzi kody statusów HTTP. Najciekawszy status to 410: Gone (usunięto).

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

Ponad jedna trzecia wszystkich żądań crawlerów trafia na wygasłe oferty pracy zwracające 410. To oferty, które istniały, gdy crawler je po raz pierwszy odkrył, zostały zaindeksowane, a następnie usunięte. Status 410 mówi crawlerowi: „ta strona istniała, ale jest trwale usunięta — przestań jej żądać”.

Wskaźnik 410 spada. W zeszłym tygodniu wynosił 8858 dla Google. W tym tygodniu — 7614. Crawlery się uczą. Każdego dnia liczba żądań-widm maleje, w miarę jak wyszukiwarki aktualizują swoje indeksy. Niemniej nauka jest powolna. Wskaźnik 410 u Binga (42,3%) jest wyższy niż u Google (35,5%), ponieważ Bing wolniej przetwarza sygnały usunięcia.

Trend 410 to najczytelniejszy sygnał nocny. Mówi mi, w jakim tempie wyszukiwarki zbliżają się do aktualnego stanu strony. Rosnący wskaźnik 410 oznacza, że usuwam treści szybciej, niż crawlery są w stanie się dostosować. Malejący wskaźnik 410 oznacza, że indeks nadrabia. Równowaga to zero odpowiedzi 410, co oznacza, że każda strona żądana przez crawler nadal istnieje.

Problem 524

Cloudflare zwraca 524, gdy serwer źródłowy nie odpowie w oknie czasowym. W dniu intensywnego wdrażania (87 commitów) spis wykazał:

Google 524s:  68  (0.3%)
Bing 524s:    0

Sześćdziesiąt osiem przekroczeń czasu odpowiedzi serwera źródłowego w ciągu 24 godzin. Każde z nich oznacza, że Googlebot zażądał strony, Cloudflare przekazał żądanie do Railway, a Railway nie odpowiedział na czas. Najbardziej prawdopodobną przyczyną były restarty workerów Railway podczas częstych wdrożeń. Każde wdrożenie restartuje aplikację, tworząc krótkie okno, w którym żądania kończą się przekroczeniem czasu.

Dla 0,3% wizyt indeksujących Google widział uszkodzoną stronę. Błędy 524 nie pojawiły się w żadnym logu aplikacji, ponieważ aplikacja nie działała w momencie ich wystąpienia. Błąd istniał wyłącznie w przestrzeni między Cloudflare a Railway, widoczny tylko poprzez spis indeksowania.

Następnego ranka liczba błędów 524 spadła do zera. Wdrożenia ustały. Workery były stabilne. Dane nocne potwierdziły, że problem był przejściowy — wynikał z częstotliwości wdrożeń, a nie z problemów strukturalnych.

Rozgrzewka pamięci podręcznej

Zanim pojawią się crawlery, uruchamiana jest rozgrzewka. Pobiera każdy wpis blogowy, każdy wariant językowy i 50 stron firmowych przez pamięć podręczną Cloudflare na brzegu sieci. Celem jest zapewnienie, że gdy Googlebot trafi na stronę, otrzyma odpowiedź z cache zamiast czekać na renderowanie z serwera źródłowego.

Różnica ma znaczenie. Wpis blogowy z cache zwraca się w 80 ms. Wpis bez cache potrzebuje 1,5 sekundy od serwera źródłowego. Googlebot ma budżet częstotliwości indeksowania mierzony w żądaniach na sekundę. Szybsze odpowiedzi oznaczają więcej zaindeksowanych stron w tym samym oknie czasowym. Rozgrzana pamięć podręczna podwaja efektywne pokrycie indeksowania.

Rozgrzewka jest niewidoczna dla użytkowników. Żaden odwiedzający nie korzysta z wpisu blogowego zbuforowanego o 2 w nocy. Mimo to rozgrzewka decyduje o tym, czy Googlebot odkryje 300 czy 600 wpisów blogowych w swoim nocnym oknie. Wpływ na SEO jest realny, mimo że żaden człowiek nie widzi tego mechanizmu.

Co ujawnia noc

Każdego ranka czytam nocne logi. Schemat jest ten sam: głównie zielone, kilka anomalii, jedna lub dwie rzeczy warte zbadania. Rytm jest nudny. Wartość tkwi właśnie w tym nudnym rytmie.

Nudna noc oznacza, że wdrożenia niczego nie zepsuły, crawlery znalazły to, czego się spodziewały, cache działa, a strona jest gotowa na ruch następnego dnia. Ciekawa noc oznacza, że coś się zmieniło: nowy wzorzec błędów, reguła cache, która przestała działać, przesunięcie budżetu indeksowania wskazujące na zmianę sygnału rankingowego.

Spis indeksowania pokazał mi, że 7000 stron firmowych jest niewidocznych dla Google. Żadna dzienna metryka by tego nie ujawniła. Analityka użytkowników pokazuje zerowy ruch na stronach firmowych, co przypisywałem niskiemu zapotrzebowaniu. Spis wykazał zero wizyt crawlerów na stronach firmowych, co oznacza, że Google nie ocenił nawet tych stron. Problem nie leży w zapotrzebowaniu. Problem leży w odkrywalności.

Analiza 524 pokazała mi, że wdrożenia na Railway tworzą okna przekroczenia czasu, w które trafia Googlebot. Żaden monitoring aplikacji by tego nie ujawnił, ponieważ aplikacja nie działa podczas przekroczenia czasu. Problem istnieje w luce infrastrukturalnej między wdrożeniem a dostępnością.

Trend 410 pokazał mi, że Bing przetwarza sygnały usunięcia o 20% wolniej niż Google. Ma to znaczenie dla SEO: wygasłe oferty pracy pozostają w indeksie Binga dłużej, potencjalnie serwując nieaktualne wyniki użytkownikom szukającym na platformach zasilanych przez Bing (DuckDuckGo, Yahoo).

Każdy z tych wniosków pochodził z danych nocnych. Dzień mówi, co robią użytkownicy. Noc mówi, co robi infrastruktura, gdy nikt nie patrzy. Jedno i drugie ma znaczenie. Z perspektywy SEO noc ma większe.

FAQ

Jak przeprowadzasz spis indeksowania?

Spis wykorzystuje analitykę GraphQL Cloudflare API (httpRequestsAdaptiveGroups) filtrowaną według wzorców user agenta (%Googlebot% i %bingbot%). Kategoryzuje strony według prefiksu ścieżki URL i agreguje kody statusów. Skrypt wykonuje się w 30 sekund i generuje porównanie zachowań indeksujących Google i Binga obok siebie.

Dlaczego nie korzystasz z Google Search Console do danych o indeksowaniu?

Google Search Console raportuje statystyki indeksowania z opóźnieniem 2–3 dni i ograniczoną szczegółowością. Spis z Cloudflare działa w czasie rzeczywistym (ostatnie 24 godziny) i obejmuje kody statusów, kategorie treści oraz status cache, których GSC nie raportuje. GSC jest przydatne do śledzenia trendów. Spis jest przydatny do decyzji operacyjnych.

Czy rozgrzewka zwiększa koszty Cloudflare?

Nie. Pamięć podręczna Cloudflare jest wypełniana przez każde żądanie, niezależnie od źródła. Rozgrzewka wykorzystuje standardowe żądania HTTP, które wliczają się do normalnego limitu żądań. Na darmowym planie nie ma limitu żądań dla odpowiedzi z cache. Żądania do serwera źródłowego podczas rozgrzewki wliczają się do przepustowości Railway, ale przy 15 000 stronach o średniej wielkości 50 KB suma wynosi około 750 MB na jedną rozgrzewkę.

Co jeśli crawlery zmienią swoje zachowanie?

Spis rejestruje wszystko, co robią crawlery, niezależnie od zmian. Przesunięcie wzorca indeksowania (więcej stron z ofertami, mniej wpisów blogowych) pojawia się natychmiast w następnym spisie. Dane trendowe z kolejnych dni ujawniają, czy przesunięcie to jednorazowa anomalia, czy trwała zmiana.

Źródła

Artykuł opiera się na codziennych danych ze spisu indeksowania zbieranych za pomocą Cloudflare GraphQL API od marca 2026. Narzędzie do spisu: ~/Projects/Utility/crawl_census.py. Narzędzie do sprawdzania nocnego: ~/.claude/skills/nightcheck/.