Google ostrzega właścicieli stron, że wdrożenie sieci CDN może w pierwszych dniach przynieść efekt odwrotny do zamierzonego: zamiast odciążyć serwer, ściągnie na niego falę zapytań od Googlebota. W opublikowanym 11 listopada 2026 roku wpisie na blogu Google Search Central Gary Illyes i Cherry Prommawin tłumaczą, skąd bierze się ten skok, i dodają drugie, poważniejsze ostrzeżenie: panika i włączenie blokady wszystkich botów potrafi wypchnąć stronę z wyników wyszukiwania.
Wpis towarzyszy piątemu, finałowemu odcinkowi pierwszego sezonu serii wideo „The Non-Canonical Cabinet”. Nie zmienia żadnej reguły rankingowej, ale porządkuje wiedzę, która dotąd była rozproszona po dokumentacji o budżecie indeksowania i o awaryjnym ograniczaniu crawla. Dla zespołów, które planują migrację na Cloudflare, Fastly, Akamai, Bunny czy CDN od hostingu, to w praktyce gotowa checklista na dzień przełączenia DNS.
Kontekst: dlaczego Google w ogóle o tym pisze
Jak przyznają sami autorzy, Google regularnie dostaje sygnały od właścicieli witryn, że tuż po schowaniu strony za CDN ruch robotów na serwerze rośnie niemal natychmiast. To dokładnie ten problem, który CDN miał rozwiązać. Część administratorów odczytuje to jako atak, sięga po najostrzejsze ustawienia zapory i po kilku dniach odkrywa w Search Console spadek liczby zaindeksowanych stron.
Temat wraca w szczególnym momencie. Od 10 listopada trwa listopadowa aktualizacja Core Update, a sklepy internetowe szykują infrastrukturę pod Black Friday i sezon świąteczny. To typowy okres na szybkie wdrożenia CDN „bo serwer nie wytrzyma”. Wpis Google sugeruje, żeby takie decyzje planować, a nie podejmować w ostatniej chwili.
Seria „The Non-Canonical Cabinet” to krótkie, celowo humorystyczne odcinki zespołu Search Relations. Wcześniejsze odcinki dotyczyły psucia adresów URL i pliku robots.txt, kodów 404 oraz przekierowań. Odcinek o CDN trwa niespełna 10 minut, a rolę serwera brzegowego gra w nim gumowy kurczak biegający po karteczki samoprzylepne. Za żartami stoi jednak konkretny mechanizm, który warto zrozumieć.
Kluczowe fakty: jak działa skok crawla po wdrożeniu CDN
Według wpisu Google zjawisko wynika z tego, jak infrastruktura indeksowania wyznacza limit wydajności indeksowania (ang. crawl capacity limit, wewnętrznie nazywany hostload). Działają tu dwie proste zasady:
- Wolniejsze odpowiedzi obniżają tempo crawla. Systemy Google stale mierzą kondycję i responsywność serwera. Gdy czasy odpowiedzi rosną, roboty zwalniają, żeby nie przeciążyć hosta i nie pogorszyć doświadczenia użytkowników.
- Szybkie i stabilne odpowiedzi przyspieszają crawl. Jeśli serwer odpowiada szybko i równo, Google traktuje to jako sygnał zdrowej infrastruktury. Pod warunkiem, że istnieje popyt na indeksowanie (crawl demand), limit stopniowo rośnie.
W chwili, gdy DNS zaczyna wskazywać na szybką sieć brzegową, czasy połączenia i odpowiedzi spadają gwałtownie. Z perspektywy Googlebota wygląda to tak, jakby serwer właśnie przeszedł potężną modernizację sprzętu. Roboty zaczynają więc podnosić liczbę zapytań.
Zimny cache, czyli pułapka pierwszej wizyty
Wyższe tempo crawla nie byłoby problemem, gdyby CDN przejmował wszystkie żądania. Haczyk polega na tym, że nowo uruchomiony CDN startuje z pustą, „zimną” pamięcią podręczną. Przy pierwszym żądaniu danego adresu w danej lokalizacji brzegowej serwer CDN nie ma jeszcze kopii zasobu (dokumentu HTML, CSS, JavaScriptu, obrazka). To tzw. cache miss: serwer brzegowy musi pobrać odpowiedź z serwera źródłowego (origin), zapisać ją i dopiero wtedy oddać klientowi. Dopiero kolejne żądania tego samego adresu są obsługiwane z brzegu, bez angażowania originu.
Google zwraca uwagę na różnicę w zachowaniu ludzi i robotów. Użytkownicy skupiają się na stosunkowo wąskim zestawie popularnych stron: stronie głównej, najczęściej czytanych artykułach, aktualnych promocjach. Te adresy rozgrzewają się w cache bardzo szybko. Roboty robią coś odwrotnego: ich zadaniem jest systematyczne przechodzenie przez całą bazę adresów URL, łącznie z rzadko odwiedzanymi kartami produktów, archiwami, paginacją i filtrami.
Połączenie obu zjawisk daje efekt, który autorzy opisują jako właściwe wąskie gardło migracji:
- szybkie odpowiedzi z brzegu sygnalizują robotom, że można indeksować szybciej,
- każdy jeszcze niezbuforowany adres, który robot odwiedza po raz pierwszy, przechodzi prosto do serwera źródłowego.
Google zastrzega, że roboty nie przyspieszają skokowo, a wiele sieci CDN ma wbudowane mechanizmy wygładzania połączeń. Mimo to, dopóki cache nie jest rozgrzany, CDN nie działa jeszcze jak tarcza i całą ciężką pracę wykonuje origin. W relacji serwisu Search Engine Roundtable pada obrazowy przykład: jeśli Googlebot zacznie indeksować 100 000 unikalnych adresów, których nie ma w cache, każdy z nich trzeba najpierw pobrać z serwera źródłowego.
| Etap migracji | Co widzi Googlebot | Co dzieje się na serwerze źródłowym |
|---|---|---|
| Przed CDN | Typowe czasy odpowiedzi hosta | Obsługuje cały ruch, crawl dopasowany do jego wydajności |
| Dzień przełączenia DNS | Gwałtowny spadek czasów odpowiedzi | Pusty cache, prawie każde żądanie trafia do originu |
| Pierwsze dni | Stopniowy wzrost limitu wydajności | Szczyt obciążenia: więcej żądań, wciąż dużo cache miss |
| Po rozgrzaniu cache | Szybki i stabilny host | Większość żądań obsługiwana z brzegu, origin odciążony |
Blokada wszystkich botów: błąd, który kosztuje widoczność
Druga część wpisu dotyczy reakcji administratorów. Wykres zapytań rosnący tuż po migracji łatwo pomylić z atakiem. Pokusa jest oczywista: zalogować się do panelu CDN i włączyć ochronę przed botami na najwyższym poziomie. W odcinku wideo Cherry Prommawin parodiuje to hasłem „BOTS SHALL NOT PASS”.
Problem z regułami „dla wszystkich” jest zapisany w ich nazwie. Bez wyjątków traktują każdy ruch automatyczny tak samo, łącznie z robotami, na których zależy właścicielowi strony. Gdy CDN lub zapora aplikacyjna (WAF) zatrzymuje żądanie i podsuwa wyzwanie w rodzaju CAPTCHA, roboty Google go nie rozwiążą. Według Google strona wygląda wtedy z ich perspektywy na celowo zablokowaną albo zepsutą. Jeśli taki stan się utrzyma, roboty ograniczą wizyty, a strony, oferty produktowe w zakładce Zakupy i obrazy zaczną wypadać z wyszukiwarki.
To istotne rozróżnienie: chwilowe zwiększenie crawla jest problemem wydajnościowym, który mija sam. Odcięcie Googlebota ścianą 403 albo stroną z wyzwaniem jest problemem z widocznością, którego skutki odrabia się tygodniami.
Co Google zaleca: trzy kroki na dzień migracji
Wpis kończy się konkretnym planem działania. Google wymienia trzy elementy.
1. Wpuszczaj zweryfikowane boty
Jeśli trzeba blokować boty, w ustawieniach CDN i zapory należy zezwolić na ruch zweryfikowanych robotów. Większość dużych dostawców CDN i WAF ma gotowy przełącznik lub zarządzaną regułę „verified bots”, która pozwala wybranym robotom ominąć wyzwania, a resztę ruchu dalej filtruje. Roboty Google można rozpoznać po publikowanych przez firmę zakresach adresów IP (Google udostępnia je w plikach JSON, osobno dla Googlebota, robotów specjalnych i fetcherów uruchamianych przez użytkownika) albo przez odwrotne zapytanie DNS. Jeszcze lepiej, jak piszą autorzy, celować w konkretne niechciane boty przez robots.txt lub precyzyjne reguły, zamiast blokować wszystkich klientów automatycznych.
2. Rozgrzej cache, zanim otworzysz śluzy
Przed przekierowaniem całego ruchu na nowy CDN warto programowo, w kontrolowanym tempie, pobrać przez CDN najważniejsze adresy: strony z największym ruchem, strony pod nadchodzące szczyty (kampanie sezonowe, promocje) oraz adresy najczęściej odwiedzane przez roboty. Dzięki temu serwery brzegowe będą gotowe do obsługi ruchu. Google dorzuca żart, że alternatywą jest poproszenie znajomych, by każdy otworzył po dwa różne adresy.
W praktyce listę najczęściej indeksowanych adresów najlepiej zbudować z logów serwera z ostatnich tygodni, a nie z mapy witryny. To logi pokazują, które adresy Googlebot faktycznie odwiedza, w tym te, o których zespół mógł zapomnieć: stare parametry, wersje z ukośnikiem i bez, warianty paginacji. Narzędzia do analizy logów i crawlery, które opisywaliśmy w zestawieniu narzędzi do analizy crawl budgetu, pozwalają taką listę wyeksportować w kilka minut.
3. Kody 429 lub 503 jako awaryjny hamulec
Jeśli mimo to crawl mocno obciąża origin w czasie rozgrzewania cache, Google zaleca skonfigurowanie na serwerze lub w regułach rate limiting po stronie CDN odpowiedzi 429 (Too Many Requests) albo 503 (Service Unavailable), na krótki czas: kilka godzin, najwyżej 1–2 dni.
Dokumentacja Google o awaryjnym ograniczaniu tempa indeksowania doprecyzowuje kilka szczegółów, które mają znaczenie przy takiej konfiguracji:
- gdy infrastruktura Google trafia na znaczną liczbę adresów z kodami
500,503lub429, obniża tempo crawla dla całej nazwy hosta (np.sklep.example.pl), również dla adresów, które zwracają poprawną treść, - tempo automatycznie wraca do normy, gdy liczba takich błędów spada,
- do odpowiedzi
503lub429można dodać nagłówekRetry-Afterz liczbą sekund albo dokładną datą i godziną w UTC, - jeśli zwracanie błędów nie jest możliwe, można złożyć w Search Console specjalne zgłoszenie o zbyt intensywnym crawlu, podając optymalne tempo, ale rozpatrzenie może potrwać kilka dni, a o zwiększenie tempa prosić nie można.
Ważna jest tu skala czasu. Kody 5xx i 429 utrzymywane przez wiele dni to już nie hamulec, tylko sygnał, że strona nie działa, z konsekwencjami dla indeksu. Google konsekwentnie mówi o godzinach, nie tygodniach.
Co to znaczy dla SEO i AIO
Najważniejszy wniosek dla specjalistów SEO: migracja na CDN to zmiana infrastruktury, która wpływa na crawl, a więc wymaga takiego samego planu jak przeprowadzka na nowy hosting. Zespoły, które mają już procedurę migracji WordPressa na nowy hosting bez utraty pozycji, mogą do niej dopisać kilka punktów specyficznych dla CDN.
Po pierwsze, raport „Statystyki indeksowania” w Search Console (Ustawienia) staje się głównym narzędziem kontroli w pierwszym tygodniu po przełączeniu. Warto obserwować łączną liczbę żądań, średni czas odpowiedzi oraz podział według kodów odpowiedzi. Wzrost żądań przy spadku czasu odpowiedzi to scenariusz opisany przez Google i nie powinien budzić paniki. Pojawienie się większego udziału kodów 403 lub 5xx to sygnał alarmowy.
Po drugie, ryzyko blokady dotyczy dziś nie tylko Googlebota. Strony coraz częściej zależą od robotów, które zasilają odpowiedzi AI: roboty Google obsługujące inne produkty, Bingbot (który zasila również Copilota i część odpowiedzi ChatGPT), a także roboty OpenAI, Perplexity czy Anthropic. Blanket bot protection zatrzyma je wszystkie naraz. Jeśli marka zabiega o cytowania w AI Overviews, AI Mode czy ChatGPT Search, nieprzemyślana reguła WAF może odciąć ją od tych powierzchni szybciej niż jakakolwiek zmiana treści. Dlatego decyzja „kogo wpuszczamy” powinna zapaść świadomie, z listą robotów, a nie przy jednym kliknięciu w panelu.
Po trzecie, sam wzrost crawla nie jest celem. Google mówi wprost, że wyższy limit wydajności przekłada się na częstsze wizyty tylko wtedy, gdy istnieje popyt na indeksowanie. CDN nie sprawi, że niezaindeksowane podstrony nagle trafią do indeksu, jeśli Google nie widzi w nich wartości. Szybszy serwer zdejmuje ograniczenie techniczne, ale nie zastępuje sygnałów jakości. To szczególnie ważne w trakcie trwającej aktualizacji Core Update, gdy łatwo przypisać zmiany w ruchu niewłaściwej przyczynie.
Po czwarte, CDN zmienia to, co widzą narzędzia. Po migracji adresy IP odwiedzających w logach originu to w dużej części adresy serwerów brzegowych. Bez przekazywania oryginalnego IP w nagłówkach (na przykład CF-Connecting-IP czy X-Forwarded-For) weryfikacja, czy ruch pochodzi od prawdziwego Googlebota, staje się niemożliwa. To warto skonfigurować przed przełączeniem, a nie po nim.
Reakcje branży
Wpis szybko podchwyciły serwisy branżowe. Barry Schwartz z Search Engine Roundtable streścił go jako zestaw zasad: przygotować i rozgrzać cache, wpuszczać zweryfikowane roboty wyszukiwarek, blokować złośliwe boty selektywnie, stosować rate limiting i monitorować kondycję serwera oraz aktywność crawla. Zaznaczył przy tym, że większość treści pochodzi z istniejącej dokumentacji Google, a nowością jest jej zebranie w jednym miejscu i osadzenie w scenariuszu migracji. Search Engine Land również opisał poradę jako praktyczne wskazówki na moment przejścia na CDN.
Dyskusja pod wpisem w serwisie LinkedIn krąży wokół tytułowego pytania „przenieśliśmy się na CDN, dlaczego wszystko jest crawlowane?”. To dobrze oddaje, jak często ten scenariusz zaskakuje zespoły, które robią migrację po raz pierwszy. Z perspektywy praktyków najcenniejsze jest jednoznaczne stanowisko Google w sprawie wyzwań CAPTCHA i stron weryfikacyjnych: dla robota to nie jest „ochrona”, tylko błąd, który z czasem wypycha adresy z indeksu.
W polskich realiach temat dotyczy przede wszystkim sklepów na platformach własnych i WooCommerce, które przed szczytem sprzedażowym dokładają Cloudflare do istniejącego hostingu współdzielonego lub VPS. To konfiguracje, w których origin ma najmniejszy zapas mocy, a więc najbardziej odczuje falę cache miss. Dla sklepów z dziesiątkami tysięcy kart produktów i nawigacją fasetową liczba unikalnych adresów do „rozgrzania” może być wielokrotnie wyższa niż liczba stron realnie odwiedzanych przez klientów.
Co dalej
Odcinek o CDN zamyka pierwszy sezon „The Non-Canonical Cabinet”. Autorzy zapraszają do zgłaszania w komentarzach pod wideo nietypowych przypadków na kolejny sezon, choć jego termin nie został podany (sami piszą o „budżecie w zawieszeniu”). Nie ma też sygnałów, by Google zamierzało zmieniać sposób wyznaczania limitu wydajności indeksowania. Mechanizm opisany we wpisie działa od lat, a dokumentacja o budżecie indeksowania i awaryjnym ograniczaniu crawla pozostaje punktem odniesienia.
Dla zespołów planujących migrację przed końcem roku praktyczna lista kontrolna wygląda tak:
- wyeksportować z logów listę najczęściej crawlowanych adresów i zaplanować rozgrzanie cache w kontrolowanym tempie,
- włączyć regułę dla zweryfikowanych botów i przejrzeć, które roboty AI mają mieć dostęp,
- skonfigurować przekazywanie oryginalnego IP do logów originu,
- przygotować regułę rate limiting zwracającą 429 lub 503 z nagłówkiem
Retry-After, gotową do włączenia na kilka godzin, - przez pierwszy tydzień codziennie sprawdzać raport Statystyki indeksowania i odsetek odpowiedzi 403 oraz 5xx,
- unikać przełączania DNS w trakcie kampanii sprzedażowej lub w dniach największego ruchu.
Szerszy wniosek jest prosty: CDN to jedno z najlepszych narzędzi wydajnościowych dla stron, ale pierwsze dni po jego wdrożeniu to okres przejściowy, w którym o widoczności decyduje konfiguracja, a nie sama technologia.
FAQ
Dlaczego po wdrożeniu CDN Googlebot zaczyna indeksować stronę częściej?
Google wyznacza limit wydajności indeksowania na podstawie szybkości i stabilności odpowiedzi serwera. CDN gwałtownie skraca czasy odpowiedzi, więc roboty uznają, że host wytrzyma więcej zapytań, i stopniowo zwiększają tempo crawla, o ile istnieje popyt na indeksowanie.
Czy CDN od razu chroni serwer źródłowy przed ruchem robotów?
Nie. Nowy CDN ma pusty cache, więc pierwsze żądanie każdego unikalnego adresu trafia do serwera źródłowego. Roboty przechodzą przez całą bazę adresów, a nie tylko popularne strony, dlatego to one najczęściej generują cache miss w pierwszych dniach.
Czy można włączyć ochronę przed botami w CDN bez szkody dla SEO?
Tak, pod warunkiem, że reguła wyłącza z blokady zweryfikowane roboty wyszukiwarek. Google odradza ochronę „dla wszystkich” bez wyjątków, bo roboty nie rozwiązują CAPTCHA, a utrzymana blokada prowadzi do wypadania stron z wyników wyszukiwania.
Jak awaryjnie spowolnić Googlebota w czasie migracji?
Google zaleca zwracanie kodów 429 lub 503 przez krótki czas, od kilku godzin do 1–2 dni, opcjonalnie z nagłówkiem Retry-After. Tempo crawla spada wtedy dla całej nazwy hosta i samo wraca do normy, gdy błędów ubywa.
Czy szybszy serwer po wdrożeniu CDN poprawi indeksację słabych podstron?
Niekoniecznie. CDN usuwa ograniczenie techniczne, ale Google częściej odwiedza stronę tylko wtedy, gdy widzi popyt na jej treść. Podstrony, które nie trafiają do indeksu z powodów jakościowych, nie zostaną zaindeksowane wyłącznie dzięki krótszemu czasowi odpowiedzi.