Przenosisz stronę za CDN, żeby odciążyć serwer, a w logach widzisz coś odwrotnego: Googlebot zaczyna wysyłać więcej żądań, a większość z nich i tak trafia na serwer origin. Google opisał ten mechanizm 11 listopada 2026 na blogu Search Central we wpisie „Moving to a CDN without overwhelming your origin (or blocking Googlebot)”. Gary Illyes i Cherry Prommawin omówili go też w piątym odcinku serii wideo „The Non-Canonical Cabinet”, który zamyka jej pierwszy sezon.

Wpis jest krótki i pisany z przymrużeniem oka (gumowy kurczak gra w nim serwer brzegowy), ale opisuje trzy realne problemy. Szybszy serwer to dla Google sygnał, że można crawlować szybciej. Pusty cache nie chroni jeszcze origin. A ochrona przed botami włączona w panice potrafi wyciąć Googlebota z wyników. Poniżej opisuję każdy z nich i plan, który Google proponuje na dzień migracji.

Dlaczego po wdrożeniu CDN crawling przyspiesza

CDN (Content Delivery Network) trzyma kopie zasobów na serwerach brzegowych (edge), blisko użytkowników. Odciąża serwer origin, czyli ten, który przechowuje oryginalną treść, i skraca czas odpowiedzi. Google przyznaje jednak, że właściciele stron zgłaszają mu ten sam scenariusz: zaraz po przejściu na CDN ruch crawlerów na serwerze skacze, czyli dzieje się dokładnie to, przed czym migracja miała chronić.

Powód leży w tym, jak Google wylicza crawl capacity limit, nazywany też hostload, czyli limit tego, ile crawlowania wytrzyma dany host. Działają tu dwie zasady:

  • wolniejsze odpowiedzi obniżają tempo crawlowania. Google stale mierzy kondycję serwera i zwalnia, gdy czas odpowiedzi rośnie, żeby go nie przeciążyć,
  • szybkie i stabilne odpowiedzi je podnoszą. Jeśli serwer odpowiada szybko i równo, a Google ma powód, żeby crawlować więcej (tzw. crawl demand), limit stopniowo rośnie.

Gdy DNS zaczyna wskazywać na sieć brzegową CDN, czasy połączenia i odpowiedzi spadają z dnia na dzień. Dla systemów Google wygląda to tak, jakby serwer dostał potężną rozbudowę sprzętu, więc roboty zwiększają liczbę żądań.

Dokumentacja Google o crawl budget dodaje dwa szczegóły, które przy migracji mają znaczenie. Limit jest liczony dla nazwy hosta (www.example.com i sklep.example.com mają osobne budżety). Jest też wspólny dla wszystkich crawlerów Google, więc wysokie zapotrzebowanie jednego z nich zmniejsza pulę pozostałych.

Zimny cache: dlaczego CDN jeszcze Cię nie chroni

Wyższe tempo crawlowania nie byłoby problemem, gdyby CDN obsługiwał te żądania sam. Nowy CDN startuje jednak z pustym, zimnym cache.

Przy pierwszym żądaniu danego adresu w danej lokalizacji edge nie ma jeszcze kopii zasobu (HTML, CSS, JavaScript, obrazy). To cache miss: serwer brzegowy musi pobrać odpowiedź z origin, zapisać ją u siebie i dopiero wtedy odesłać klientowi. Dopiero kolejne żądania o ten sam adres są obsługiwane z cache (cache hit) bez udziału origin.

Ludzie i roboty korzystają z cache zupełnie inaczej:

UżytkownicyGooglebot
Wzorzec ruchumały zestaw popularnych adresów (strona główna, najczęściej czytane artykuły, aktywne promocje)systematyczne przejście przez całą pulę adresów URL
Rozgrzewanie cacheszybkie, bo te same strony są odwiedzane wiele razywolne, bo większość adresów robot odwiedza po raz pierwszy
Skutek dla originpo krótkim czasie niewielkikażdy nowy adres to cache miss, który trafia prosto na serwer

Razem daje to niewygodny efekt. Szybkie odpowiedzi z edge zachęcają Google do intensywniejszego crawlowania, a każdy jeszcze niezbuforowany adres przechodzi przez CDN prosto do origin. Google zaznacza, że roboty nie podkręcają tempa natychmiast, a wiele CDN-ów ma wbudowane wygładzanie ruchu. Mimo to, dopóki cache się nie rozgrzeje, wąskim gardłem nadal jest origin.

Im więcej adresów ma serwis, tym dłużej to trwa. W sklepie z tysiącami kart produktów, filtrów i wariantów robot długo trafia na adresy, których edge jeszcze nie widział. Jeśli origin słabo znosi nagłe obciążenie (wolne zapytania do bazy, brak cache aplikacyjnego), trzeba to uwzględnić w planie migracji. To mój wniosek z opisanego mechanizmu, bo Google nie podaje ani skali skoku, ani progów.

Ochrona przed botami, która blokuje Googlebota

Wykres żądań w logach origin tuż po migracji potrafi przestraszyć, zwłaszcza gdy nie wiadomo, skąd się wziął. Pokusa jest oczywista: wejść do panelu CDN i włączyć ogólną ochronę przed botami. Google ostrzega, że to błąd.

Reguły bez wyjątków traktują cały zautomatyzowany ruch tak samo, łącznie z robotami, na których Ci zależy. Kiedy CDN lub zapora aplikacyjna (WAF) przechwytuje żądanie i podsuwa wyzwanie w rodzaju CAPTCHA, crawler Google go nie przejdzie. Zostaje na stronie błędu lub wyzwania, która nie ma żadnej wartości ani dla wyszukiwarki, ani dla innych usług Google korzystających z pobranych danych.

Według Google witryna wygląda wtedy na celowo zablokowaną albo zepsutą. Jeśli taki stan się utrzyma, roboty się wycofają, a strony, listingi produktowe i reszta treści zaczną wypadać z wyników wyszukiwania.

Taką blokadę łatwo przeoczyć, bo właściciel jej nie widzi. W przeglądarce wszystko działa, a robot dostaje 403 albo ekran wyzwania. Dlatego po każdej zmianie reguł CDN lub WAF sprawdzam, co faktycznie dostaje Googlebot: w raporcie statystyk indeksowania w Google Search Console i w logach serwera.

Plan migracji na CDN: co zrobić przed przełączeniem

Google proponuje trzy konkretne kroki.

1. Przepuść zweryfikowane boty

Jeśli musisz blokować boty, włącz w CDN i zaporze wyjątek dla zweryfikowanych robotów. Według Google większość dużych CDN-ów i WAF-ów ma na to gotowy przełącznik lub zarządzaną regułę w rodzaju „allow known / verified bots”. Roboty Google rozpoznasz po opublikowanych przez Google zakresach adresów IP.

Samą weryfikację opisuje dokumentacja „Verify requests from Google crawlers and fetchers”. Robi się odwrotne zapytanie DNS na adres z logów i sprawdza, czy domena to googlebot.com, google.com lub googleusercontent.com. Potem zapytanie w przód musi zwrócić ten sam adres IP. Do automatycznego dopasowania służą pliki JSON z zakresami IP.

Jeszcze lepiej, według Google, kierować robots.txt albo reguły w stronę konkretnych niechcianych botów, zamiast blokować wszystkie automaty. Jak odróżnić roboty wyszukiwarek od crawlerów AI, opisałem w porównaniu crawlerów AI i wyszukiwarek, a składnię pliku w tekście o tym, co można wpisać w robots.txt.

2. Rozgrzej cache, zanim przełączysz ruch

Zanim skierujesz cały ruch przez nowy CDN, pobierz przez niego w kontrolowanym tempie:

  • strony z największym ruchem,
  • strony, na które wkrótce przyjdzie szczyt ruchu (kampanie, premiery sezonowe),
  • adresy, które Googlebot odwiedza najczęściej (znajdziesz je w logach serwera).

Wtedy edge ma kopie, zanim pojawi się fala żądań. Google żartuje, że można też poprosić znajomych, żeby każdy otworzył po dwa adresy. W praktyce wystarczy prosty skrypt, który odpytuje listę URL-i z mapy witryny lub z logów.

3. Użyj 429 lub 503 jako tymczasowego hamulca

Jeśli mimo rozgrzewania crawlowanie mocno obciąża origin, ustaw na serwerze lub w CDN limity, które na krótko zwracają 429 (Too Many Requests) albo 503 (Service Unavailable). Google mówi o kilku godzinach, najwyżej 1 do 2 dniach, i odsyła do poradnika „Reduce the Google crawl rate”.

Ten poradnik ma zastrzeżenia, które warto znać, zanim sięgniesz po hamulec:

  • zwolnienie obejmuje cały host, a nie tylko adresy zwracające błąd. Google zmniejsza tempo crawlowania dla całej nazwy hosta i sam je podnosi, gdy błędów ubywa,
  • przy 503 i 429 możesz dodać nagłówek Retry-After (liczba sekund albo data UTC), który mówi robotowi, kiedy wrócić,
  • jeśli Googlebot widzi te kody na tym samym adresie przez kilka dni, adres może wypaść z indeksu,
  • ograniczenie crawlowania ma szerokie skutki: Google odkrywa mniej nowych stron, rzadziej odświeża istniejące (zmiany cen i dostępności produktów pojawiają się w wynikach później), a usunięte strony dłużej zostają w indeksie.

O tym, jak Google traktuje kody 5xx przy wyłączonej stronie, pisałem przy okazji wyłączania strony na czas łatania PHP.

Jak sprawdzić, czy migracja przebiega zdrowo

Komunikat Google nie podaje progów ani metryk, więc ta lista to moja praktyka, oparta na opisanym mechanizmie. W czasie i po przełączeniu na CDN patrzę na cztery rzeczy:

  1. Logi origin. Ile żądań Googlebota dochodzi do serwera w porównaniu z okresem sprzed migracji i jaki odsetek z nich to cache miss. Jeśli CDN pokazuje cache hit ratio, powinien rosnąć z dnia na dzień.
  2. Statystyki indeksowania w Search Console. Czy liczba żądań rośnie, a średni czas odpowiedzi spada, i czy nie pojawiają się błędy serwera albo odpowiedzi 403.
  3. Odpowiedzi widziane przez robota. Czy żądania z zakresów IP Google nie dostają w logach WAF wyzwań CAPTCHA ani stron błędów.
  4. Sekcje serwisu. Które części witryny są najbardziej „zimne”, czyli gdzie cache miss utrzymuje się najdłużej.

Sam skok crawlingu po migracji to raczej dobra wiadomość: Google uznał infrastrukturę za zdrową i chce pobierać więcej. Kłopot zaczyna się, gdy origin nie nadąża albo zbyt ostra ochrona zamyka robotowi drogę.

Jeśli ruch rośnie nie na zwykłych stronach, tylko na adresach z filtrami i sortowaniem, przyczyną może być nawigacja fasetowa, a nie CDN. Poradnik Google o ograniczaniu crawlowania wymienia ją jako najczęstsze źródło nagłych skoków, obok kalendarzy z tysiącami dat.

Czego Google nie mówi

To wpis edukacyjny, a nie zapowiedź zmiany w algorytmie, i jego zakres jest wąski:

  • Google nie podaje, o ile i jak szybko rośnie tempo crawlowania po migracji. Pisze tylko, że roboty nie przyspieszają od razu.
  • Nie wiadomo, jak długo trwa rozgrzewanie cache ani od jakiej wielkości serwisu problem staje się odczuwalny. Najbliższą wskazówką jest dokumentacja o crawl budget, która jako orientacyjną grupę docelową podaje serwisy z ponad milionem unikalnych stron albo ponad 10 tysiącami stron zmieniających się codziennie. Google zastrzega, że to szacunki, nie progi. Dla strony z kilkuset adresami ryzyko jest moim zdaniem niewielkie.
  • Nie ma gotowych ustawień dla konkretnych dostawców CDN. Nazwy opcji różnią się między usługami, więc trzeba sprawdzić dokumentację własnego dostawcy.

Temat CDN-ów i crawlowania Google poruszał już w cyklu „Crawling December” w 2024 roku. Nowy wpis skupia się na samym okresie przejściowym: zimnym cache i skutkach ogólnej ochrony przed botami. Relację z odcinka opublikował też Barry Schwartz w Search Engine Roundtable.

Podsumowanie

CDN przyspiesza odpowiedzi, a Googlebot odbiera to jako zgodę na szybsze crawlowanie. Dopóki cache jest zimny, robot trafia na wiele adresów po raz pierwszy i każde takie żądanie ląduje na origin. Do tego dochodzi drugie ryzyko: ogólna ochrona przed botami, która podsuwa crawlerowi CAPTCHA i prowadzi do wypadania stron z wyników.

Rady Google mieszczą się w trzech punktach: przepuść zweryfikowane boty, rozgrzej cache przed zmianą DNS, a jeśli origin potrzebuje chwili oddechu, zwracaj 429 lub 503 najwyżej przez 1 do 2 dni. Przed migracją ustalam też, kto i kiedy czyta logi, żeby reagować w pierwszych godzinach, a nie po tygodniu.

Często zadawane pytania

Dlaczego po wdrożeniu CDN Googlebot crawluje częściej?

CDN skraca czas odpowiedzi, a Google traktuje szybkie i stabilne odpowiedzi jako sygnał, że serwer wytrzyma więcej. Jeśli jest zapotrzebowanie na crawlowanie (crawl demand), limit stopniowo rośnie i robot wysyła więcej żądań.

Czy CDN odciąży serwer od razu po uruchomieniu?

Nie. Nowy CDN ma pusty cache, więc pierwsze żądanie o każdy adres w danej lokalizacji trafia na origin (cache miss). Googlebot odwiedza dużo różnych adresów, więc wiele takich żądań przechodzi do serwera, zanim cache się rozgrzeje.

Czy mogę włączyć w CDN ochronę przed botami?

Tak, ale z wyjątkiem dla zweryfikowanych robotów. Ogólne reguły z wyzwaniem CAPTCHA zatrzymują też Googlebota, który go nie rozwiąże. Google widzi wtedy stronę jako zablokowaną lub zepsutą, a jej adresy mogą wypaść z wyników.

Jak rozgrzać cache CDN przed migracją?

Pobierz przez nowy CDN w kontrolowanym tempie strony z największym ruchem, strony przed spodziewanym szczytem (kampanie, akcje sezonowe) i adresy najczęściej odwiedzane przez Googlebota. Te ostatnie znajdziesz w logach serwera.

Jak szybko zmniejszyć crawling, gdy origin jest przeciążony?

Zwracaj kod 429 lub 503 przez krótki czas, od kilku godzin do najwyżej 1 do 2 dni, opcjonalnie z nagłówkiem Retry-After. Google zwolni crawlowanie całego hosta, a dłuższe utrzymywanie tych kodów może skończyć się usunięciem adresów z indeksu.

Źródła

  1. Moving to a CDN without overwhelming your origin (or blocking Googlebot) Google Search Central Blog · developers.google.com ·
  2. Optimize your crawl budget Google Crawling Infrastructure · developers.google.com
  3. Reduce the Google crawl rate Google Crawling Infrastructure · developers.google.com
  4. Verify requests from Google crawlers and fetchers Google Crawling Infrastructure · developers.google.com
  5. Crawling December: CDNs and crawling Google Search Central Blog · developers.google.com ·
  6. Google: How Moving to a CDN Can Accidentally Overwhelm Your Website Search Engine Roundtable · seroundtable.com ·