Google: migracja na CDN może przeciążyć serwer i zablokować Googlebota

Google ostrzega właścicieli stron, że przeniesienie witryny na CDN może w pierwszych dniach bardziej obciążyć serwer źródłowy, zamiast go odciążyć. W opublikowanym 11 listopada 2026 roku wpisie na blogu Google Search Central Gary Illyes i Cherry Prommawin tłumaczą, skąd bierze się nagły wzrost ruchu robotów po migracji i jak łatwo przy okazji odciąć Googlebota od własnej strony.

To nie jest kolejna ogólnikowa porada o szybkości strony. Google opisuje konkretny mechanizm: szybsze odpowiedzi z serwerów brzegowych podnoszą limit wydajności crawlowania, a pusty cache CDN przepuszcza te żądania prosto do serwera źródłowego. Do tego dochodzi drugie ryzyko, czyli zbyt szeroko ustawiona ochrona przed botami, która potrafi wyrzucić strony z wyników wyszukiwania.

Kontekst: dlaczego Google w ogóle o tym pisze

Wpis nosi tytuł „Moving to a CDN without overwhelming your origin (or blocking Googlebot)” i towarzyszy mu piąty odcinek serii wideo „The Non-Canonical Cabinet”, który zamyka pierwszy sezon tego formatu. Jak przyznają autorzy, Google regularnie dostaje sygnały od właścicieli stron, że zaraz po wpięciu witryny za CDN ruch robotów na serwerze rośnie niemal natychmiast. A przecież CDN wdraża się właśnie po to, żeby ten ruch zdjąć z serwera.

Temat jest bliski polskim wydawcom i sklepom internetowym. CDN przestał być rozwiązaniem tylko dla dużych graczy: wiele hostingów oferuje go w pakiecie, a darmowe plany popularnych dostawców sprawiają, że migrację przeprowadza się często w jedno popołudnie, przez zmianę rekordów DNS. Właśnie ta łatwość jest problemem. Zmiana DNS działa od razu, a cache na brzegu sieci zapełnia się stopniowo.

Wpis ukazał się dzień po starcie listopadowej aktualizacji podstawowej algorytmu Google, w okresie przed Black Friday, kiedy wiele sklepów planuje zmiany infrastruktury pod szczyt ruchu. To zbieg okoliczności, ale praktyczny: każdy, kto teraz przenosi sklep na CDN, robi to w najbardziej ryzykownym momencie roku. Serwisy Search Engine Land i Search Engine Roundtable opisały wytyczne jeszcze tego samego dnia.

Kluczowe fakty: jak Google liczy limit crawlowania

Punktem wyjścia jest pojęcie, które Google nazywa crawl capacity limit, a wewnętrznie także hostload. To górna granica tego, ile czasu serwer strony może spędzać na obsłudze połączeń z robotami Google, z uwzględnieniem liczby równoległych połączeń i ich długości. Według dokumentacji Google każda strona startuje z tym samym, zachowawczym limitem, a system podnosi go automatycznie, jeśli strona pozostaje „zdrowa” i istnieje zapotrzebowanie na crawlowanie.

W nowym wpisie Google rozpisuje tę zależność wprost:

• Coraz wolniejsze odpowiedzi obniżają tempo crawlowania. Gdy czasy odpowiedzi rosną, roboty zwalniają, żeby nie przeciążyć serwera i nie pogorszyć doświadczenia użytkowników.
• Szybkie i stabilne odpowiedzi przyspieszają crawlowanie. Jeśli serwer odpowiada szybko i równo, system odczytuje to jako sygnał wydajnej infrastruktury i, przy istniejącym zapotrzebowaniu (crawl demand), stopniowo podnosi limit.

W momencie, gdy DNS zaczyna wskazywać na sieć brzegową CDN, czasy połączenia i odpowiedzi spadają gwałtownie. Jak piszą autorzy, z perspektywy systemów crawlujących wygląda to tak, jakby serwer właśnie przeszedł potężną modernizację sprzętu. Roboty zaczynają więc stopniowo zwiększać liczbę żądań.

Zimny cache, czyli gdzie naprawdę jest wąskie gardło

Sam wyższy limit nie byłby problemem, gdyby CDN obsługiwał wszystkie żądania na brzegu. Haczyk polega na tym, że nowy CDN startuje z pustym, „zimnym” cache. Pierwsze żądanie o dany adres w danej lokalizacji brzegowej to cache miss: serwer brzegowy musi pójść po odpowiedź do serwera źródłowego, zapisać kopię i dopiero potem ją wydać. Dopiero kolejne żądania o ten sam adres trafiają w cache.

Google zwraca uwagę na kluczową różnicę między ludźmi a robotami. Użytkownicy skupiają się na stosunkowo małym zbiorze popularnych stron: stronie głównej, najczęściej czytanych artykułach, aktualnych promocjach. Te adresy rozgrzewają się w cache bardzo szybko. Roboty robią coś odwrotnego, bo ich zadaniem jest systematyczne przechodzenie przez całą bazę adresów. W efekcie każdy adres, którego nikt wcześniej nie odwiedził przez CDN, przechodzi prosto do serwera źródłowego.

Google łagodzi obraz w dwóch punktach: roboty nie podnoszą tempa natychmiast, a wiele sieci CDN ma wbudowane mechanizmy wygładzania ruchu. Wniosek jest jednak jednoznaczny: dopóki cache się nie zapełni, CDN nie pełni roli tarczy, a cały ciężar dalej spoczywa na serwerze źródłowym.

Druga pułapka: ochrona przed botami „dla wszystkich”

Drugi wątek wpisu dotyczy reakcji administratorów. Gdy po migracji w logach serwera pojawia się fala automatycznych żądań, kusi, by wejść do panelu CDN i włączyć ogólną ochronę przed botami. Google przestrzega przed tym wprost: reguły typu „blanket”, bez wyjątków, traktują cały ruch automatyczny jednakowo, także roboty, na których właścicielowi strony zależy.

Gdy CDN albo zapora aplikacyjna (WAF) przechwytuje żądanie i podsuwa wyzwanie w rodzaju CAPTCHA, roboty Google go nie rozwiążą. Według autorów robot zostaje wtedy na stronie błędu, która nie ma wartości ani dla wyszukiwarki, ani dla innych usług Google korzystających z crawlowanych danych. Z perspektywy Google strona wygląda na celowo ograniczoną albo zepsutą. Jeśli taki stan się utrzyma, roboty się wycofają, a strony, oferty produktowe i grafiki zaczną wypadać z wyników wyszukiwania.

Trzy zalecenia Google

W części praktycznej wpis podaje trzy kroki. Warto je przytoczyć dokładnie, bo każdy z nich ma swoje ograniczenia.

1. Jeśli musisz blokować boty, wpuść zweryfikowane boty. Większość dużych dostawców CDN i WAF ma przełącznik albo gotową regułę dla znanych, zweryfikowanych botów. Roboty Google można zidentyfikować na podstawie publikowanych przez firmę zakresów IP. Google dodaje, że jeszcze lepiej jest używać robots.txt lub reguł wymierzonych w konkretne niechciane boty, niż blokować cały ruch automatyczny.
2. Rozgrzej cache, zanim otworzysz śluzy. Zanim cały ruch pójdzie przez nowy CDN, należy programowo, w kontrolowanym tempie, pobrać przez CDN strony o największym ruchu, strony pod nadchodzące szczyty (promocje, sezonowe premiery) oraz adresy najczęściej crawlowane.
3. Użyj kodu 429 lub 503 jako tymczasowego hamulca. Jeśli mimo to roboty nadmiernie obciążają serwer źródłowy, można skonfigurować reguły ograniczania ruchu tak, by zwracały 429 (Too Many Requests) albo 503 (Service Unavailable). Tylko na krótko: kilka godzin, najwyżej 1–2 dni.

Trzeci punkt odsyła do dokumentacji Google o pilnym ograniczaniu tempa crawlowania. Wynika z niej kilka szczegółów, które łatwo przeoczyć. Gdy system napotka znaczną liczbę adresów zwracających 500, 503 lub 429, obniża tempo crawlowania dla całej nazwy hosta, czyli również dla adresów, które odpowiadają poprawnie. Tempo rośnie automatycznie, gdy błędów ubywa. Przy kodach 503 i 429 można dołączyć nagłówek Retry-After, z opóźnieniem w sekundach albo z konkretną datą i godziną w UTC. Jeśli zwracanie błędów jest niewykonalne, pozostaje formularz zgłoszenia nadmiernego crawlowania w Search Console, ale jego rozpatrzenie może potrwać kilka dni, a zwiększenia tempa w ten sposób zamówić nie można.

Co to znaczy dla SEO i AIO

Najważniejsza lekcja z wpisu Google jest taka, że migracja na CDN to zmiana infrastrukturalna, która ma bezpośrednie skutki dla widoczności w wyszukiwarce. W polskich projektach migracje często prowadzi administrator lub firma hostingowa, a specjalista SEO dowiaduje się o nich po fakcie, gdy w Search Console rosną błędy. Opisane przez Google ryzyka dobrze uzasadniają, dlaczego SEO powinno mieć miejsce przy planowaniu takiej zmiany.

Kto jest najbardziej narażony

Problem zimnego cache rośnie razem z liczbą adresów. Dokumentacja Google o budżecie crawlowania wskazuje grupy, którym szczególnie opłaca się nim zarządzać: bardzo duże serwisy (powyżej miliona unikalnych stron) z treściami zmieniającymi się mniej więcej co tydzień, średnie i większe serwisy (powyżej 10 tys. stron) z treściami zmieniającymi się codziennie oraz strony, w których duża część adresów ma w Search Console status „Strona wykryta, obecnie nie zindeksowana”. W polskich realiach to przede wszystkim sklepy z rozbudowaną nawigacją fasetową, portale ogłoszeniowe i serwisy informacyjne z wieloletnim archiwum.

Sklepy mają tu podwójny kłopot. Filtry, sortowania i parametry generują ogromną liczbę adresów, które ludzie odwiedzają rzadko, a roboty chętnie. Każdy z nich to po migracji osobny cache miss. Jeśli serwer źródłowy sklepu i tak pracował blisko granicy, faza rozgrzewania może skończyć się spowolnieniem także dla klientów. Szerzej o tym, jak ruch robotów przekłada się na obciążenie i koszty serwera, pisaliśmy w tekście o tym, jak boty AI wpływają na obciążenie serwera i koszty crawla.

Ochrona przed botami a widoczność w AI

Wątek bot protection ma w 2026 roku dodatkowy wymiar. Wiele firm włącza agresywne reguły antybotowe nie z powodu migracji, ale z powodu rosnącego ruchu crawlerów AI. Google przypomina, że reguła bez wyjątków odcina także jego własne roboty, a te zasilają nie tylko klasyczne wyniki, ale również inne produkty oparte na crawlowanych danych. Dla strategii AIO oznacza to prostą zasadę: decyzję o tym, które boty wpuszczać, trzeba podejmować na poziomie konkretnych agentów, a nie jednym przełącznikiem.

Warto też pamiętać, że Google rekomenduje do tego robots.txt i reguły celowane. Kontrola przez robots.txt jest jawna, przewidywalna i łatwa do audytu, natomiast reguły w panelu CDN bywają niewidoczne dla zespołu SEO. Wyzwanie CAPTCHA nie zostawia śladu w robots.txt, więc przy rutynowym przeglądzie pliku nikt go nie zauważy.

Kody 429 i 503 to hamulec, nie strategia

Zalecenie dotyczące kodów 429 i 503 jest bardzo precyzyjne czasowo i warto je tak traktować. Google mówi o kilku godzinach, najwyżej 1–2 dniach. Dłuższe zwracanie błędów to już inne ryzyko, bo obniżone tempo crawlowania dotyczy całego hosta. W praktyce oznacza to, że nowe treści i zmiany na stronie dłużej czekają na odwiedziny robota. O tym, ile Google potrzebuje na crawlowanie i indeksowanie nowych adresów, pisaliśmy przy okazji danych o czasach crawlowania i indeksowania w Google.

Ważna różnica: kod 403 to nie to samo co 429 czy 503. W podsumowaniu wpisu Google wprost wymienia „ściany 403” i strony z wyzwaniami jako coś, czego należy unikać wobec swoich robotów. Kody 429 i 503 komunikują „spróbuj później”, a blokada lub wyzwanie komunikuje „nie masz tu wstępu”.

Reakcje branży i szerszy obraz

Branżowe serwisy anglojęzyczne opisały wpis w ciągu kilku godzin od publikacji, akcentując przede wszystkim paradoks wzrostu ruchu po wdrożeniu rozwiązania, które miało go zmniejszyć. To dobry sygnał, że temat trafia w realny problem: Google rzadko tak szczegółowo łączy zachowanie swoich robotów z konkretną zmianą infrastruktury po stronie właściciela witryny.

Wpis wpisuje się w szerszą serię materiałów Google Search Central. Dokumentacja crawlowania ma dziś osobną sekcję poświęconą infrastrukturze crawlującej Google, która wyjaśnia pojęcia takie jak hostload i podkreśla, że te same roboty obsługują wiele produktów. Ton wpisu jest lekki (gumowy kurczak w roli serwera brzegowego, Gary Illyes, który „sam nie zawsze rozwiązuje CAPTCHA”), ale treść jest bardzo konkretna.

Dla polskiego rynku ma to praktyczne znaczenie. Coraz więcej firm korzysta z CDN wbudowanych w hosting lub w platformy sklepowe, często z domyślnie włączonymi profilami bezpieczeństwa. Właściciel strony może nawet nie wiedzieć, że jego dostawca stosuje regułę antybotową, dopóki w raporcie Statystyki indeksowania nie zobaczy skoku błędów lub spadku liczby żądań.

Lista kontrolna przed migracją na CDN

Na podstawie wpisu i dokumentacji Google można zbudować prostą listę kroków dla zespołu SEO i administratora. Nie zastępuje ona dokumentacji dostawcy CDN, ale porządkuje kolejność.

• Przed przełączeniem: zrób zrzut raportu Statystyki indeksowania w Search Console (liczba żądań, średni czas odpowiedzi, rozkład kodów) jako punkt odniesienia.
• Przed przełączeniem: sprawdź, czy profil bezpieczeństwa CDN ma włączony wyjątek dla zweryfikowanych botów i czy nie ma reguł z wyzwaniami dla całego ruchu automatycznego.
• Przed przełączeniem: przygotuj listę adresów do rozgrzania: strony o największym ruchu, strony kampanii sezonowych, adresy najczęściej odwiedzane przez Googlebota według logów serwera.
• W dniu przełączenia: monitoruj obciążenie serwera źródłowego i udział cache miss w ruchu robotów.
• Awaryjnie: miej gotową regułę zwracającą 429 lub 503 z nagłówkiem Retry-After, uruchamianą na kilka godzin, nie na tygodnie.
• Po przełączeniu: przez kolejne dni porównuj Statystyki indeksowania z punktem odniesienia i weryfikuj w narzędziu do sprawdzania adresów URL, czy Googlebot dostaje treść, a nie stronę wyzwania.

Szczególnie ostrożnie warto podejść do migracji połączonych z innymi zmianami, na przykład z przeniesieniem sklepu na nową platformę. Wtedy nakładają się na siebie dwa źródła ryzyka: nowe adresy i przekierowania oraz zimny cache. O tym, jak zaplanować taki projekt krok po kroku, piszemy w poradniku o migracji sklepu na nowy silnik bez utraty widoczności.

Co dalej

Wpis kończy pierwszy sezon serii „The Non-Canonical Cabinet”. Wcześniejsze odcinki dotyczyły psucia adresów URL i pliku robots.txt oraz błędów 404 i przekierowań. Autorzy zapowiadają kolejny sezon, choć z zastrzeżeniem, że zależy on od budżetu, i zachęcają do zgłaszania nietypowych przypadków w komentarzach pod filmem.

Google nie zapowiada przy tym żadnej zmiany w działaniu robotów. To wyjaśnienie istniejącego mechanizmu, a nie nowa reguła. Mechanizm limitu crawlowania działa tak samo jak dotąd: Google reaguje na szybkość i stabilność odpowiedzi, a odpowiedzialność za to, by szybkość brzegu nie przerodziła się w przeciążenie źródła, spoczywa po stronie właściciela strony.

W najbliższych tygodniach temat będzie szczególnie aktualny. Trwa listopadowa aktualizacja podstawowa, która sama w sobie utrudnia odczytywanie danych w Search Console, a sklepy szykują się do Black Friday i świątecznego szczytu. Jeśli ktoś planuje teraz migrację na CDN, wpis Google daje mocny argument, by albo przeprowadzić ją z rozgrzaniem cache i sprawdzoną konfiguracją botów, albo przesunąć ją na spokojniejszy okres po szczycie sprzedażowym.

FAQ