---
title: "Migracja na CDN a Googlebot: jak nie przeciążyć serwera"
description: "Po przejściu na CDN Googlebot crawluje szybciej, a zimny cache przepuszcza żądania do origin. Co radzi Google i jak nie zablokować robota przy migracji."
date: 2026-11-13
category: SEO
tags: ["CDN", "Googlebot", "crawl budget", "SEO techniczne", "indeksowanie"]
url: https://uper.pl/blog/migracja-na-cdn-a-googlebot/
---

# Migracja na CDN a Googlebot dlaczego crawling rośnie po przełączeniu DNS i jak ochronić origin

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żytkownicy | Googlebot |
|---|---|---|
| Wzorzec ruchu | mał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 cache | szybkie, bo te same strony są odwiedzane wiele razy | wolne, bo większość adresów robot odwiedza po raz pierwszy |
| Skutek dla origin | po krótkim czasie niewielki | każ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](/blog/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](/blog/ai-crawlers-vs-search-crawlers/), a składnię pliku w tekście o tym, [co można wpisać w robots.txt](/blog/google-robots-txt-co-mozna-wpisac/).

### 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](/blog/google-503-wylaczenie-strony-luka-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.

## Źródła