Zimny start po migracji. Jak rozgrzać cache i CDN, zanim wejdzie Googlebot

Data aktualizacji: 13 sierpnia 2026

Serwer po migracji rzadko pada dlatego, że pamięć podręczna jest pusta. Pada dlatego, że pamięć podręczna nie chce się zapełnić — a Googlebot, który właśnie zobaczył kilkadziesiąt tysięcy nowych adresów, akurat wtedy przyspiesza. W tym tekście tłumaczę, co realnie dzieje się w pierwszej godzinie po przepięciu DNS, czego z cache’u i CDN-a rozgrzać się po prostu nie da, i w jakiej kolejności ustawić stale-while-revalidate, Tiered Cache i przekierowania, żeby migracja przeszła bez awarii.

Teza: rozgrzewasz nie to, co trzeba

Powiem od razu, bez owijania w bawełnę: większość „rozgrzewania cache’u” po migracji to teatr. Ktoś odpala skrypt, który w pętli curluje pięć tysięcy adresów z sitemapy, patrzy na rosnący licznik i ma poczucie dobrze wykonanej roboty. A potem rano wchodzi Googlebot i serwer i tak siada.

Bo problemem nie było to, że pamięć podręczna jest pusta. Pusta pamięć podręczna to stan normalny każdego świeżego wdrożenia — zapełni się w kilkanaście minut, jeśli tylko nic jej w tym nie przeszkadza. Problem zaczyna się wtedy, kiedy coś przeszkadza: nagłówek Set-Cookie doklejany do każdej odpowiedzi, parametry utm_* rozbijające jeden URL na czterdzieści kluczy cache’a, przekierowania obsługiwane przez plugin odpytujący bazę przy każdym żądaniu. Wtedy cache nie jest „zimny”. On jest martwy — i żaden skrypt rozgrzewający tego nie naprawi, bo każde jego zapytanie też kończy się chybieniem.

Dlatego kolejność jest odwrotna, niż się ludziom wydaje. Najpierw usuwasz przeszkody w zapełnianiu pamięci podręcznej. Potem stawiasz warstwę, która wytrzyma chybienia. Rozgrzewanie jest ostatnie i jest najmniej ważne.

Co się naprawdę dzieje w godzinie zero

Przepięcie DNS wygląda niewinnie: zmieniasz rekord A albo CNAME, czekasz na propagację, koniec. Tyle że pod spodem odpalasz jednocześnie cztery rzeczy.

Ruch użytkowników przechodzi stopniowo, nie skokowo. Resolwery honorują TTL rekordu, więc przez jakiś czas część ludzi wciąż ląduje na starym serwerze. To akurat dobra wiadomość — masz naturalny ramp-up. Zła wiadomość jest taka, że część resolwerów (i część routerów domowych, i część firmowych proxy) TTL-a traktuje twórczo, więc na „stopniowo” nie ma co liczyć jako na gwarancję.

Googlebot przechodzi skokowo. Zwłaszcza jeśli razem z przepięciem wgrałeś nową mapę witryny albo zmieniła się struktura adresów. Nowe URL-e to dla robota nowe obiekty do pobrania, a nie „te same strony pod innym adresem”.

Aplikacja startuje z zera. Pusty cache obiektowy, pusty OPcache w PHP, zimny bufor bazy (shared_buffers w PostgreSQL, innodb_buffer_pool w MySQL — świeżo po restarcie nie ma w nich nic). Zapytania, które w starym środowisku szły z pamięci w mikrosekundach, teraz idą z dysku.

CDN startuje z zera w każdej lokalizacji z osobna. I to jest ten punkt, który najczęściej wywraca plany — wrócę do niego za moment.

Dlaczego migracja mnoży zapytania razy dwa

Jest jeszcze jeden mechanizm, o którym mało kto myśli przed wdrożeniem, a który potrafi zaskoczyć: przy zmianie adresów każdy stary URL kosztuje Cię dwa zapytania, nie jedno. Robot pobiera stary adres, dostaje 301, po czym pobiera adres docelowy. Jeśli migrujesz sklep z kilkudziesięcioma tysiącami adresów kategorii, filtrów i produktów, to w oknie kilku dni Twoja infrastruktura obsłuży ich dwukrotność.

A teraz dołóż do tego typową implementację przekierowań w sklepie na WordPressie albo w starszym CMS-ie: mapa 301-ek siedzi w bazie, obsługuje ją wtyczka, każde trafienie w stary adres to pełny bootstrap aplikacji, zapytanie do bazy i dopiero potem nagłówek Location. Odpowiedź, która powinna kosztować pół milisekundy na brzegu sieci, kosztuje Cię kilkaset milisekund na originie. Razy kilkadziesiąt tysięcy. To nie Googlebot kładzie serwer — kładzie go architektura przekierowań.

Cache stampede — kiedy pustka robi się groźna

Klasyk, który w dniu migracji objawia się w najczystszej postaci. Dwieście równoległych żądań trafia w ten sam nieobecny w cache’u adres — na przykład stronę główną albo najpopularniejszą kategorię. Każde z nich osobno idzie do originu. Origin generuje tę samą stronę dwieście razy naraz, zjada pulę połączeń do bazy, czas odpowiedzi rośnie, kolejne żądania czekają dłużej, kolejka rośnie dalej. Klasyczna spirala.

Po angielsku to cache stampede albo thundering herd. Po polsku: tratowanie. I to jest realny mechanizm awarii po migracji — nie „za dużo ruchu”, tylko „za dużo ruchu w ten sam jeden pusty klucz w tej samej sekundzie”.

Częsty błąd: Set-Cookie na każdej odpowiedzi

Zanim zaczniesz cokolwiek rozgrzewać, sprawdź jedną rzecz: czy nowa aplikacja nie dokleja nagłówka Set-Cookie do odpowiedzi na stronach publicznych. Sesja zakładana przy pierwszym wejściu, cookie zgody, cookie testu A/B, cookie koszyka tworzone „na zapas” — każdy z nich sprawia, że CDN uznaje odpowiedź za spersonalizowaną i przestaje ją cache’ować. Efekt: sto procent chybień na całej witrynie, przy pozornie poprawnej konfiguracji. To samo robi zbyt szeroki nagłówek Vary (szczególnie Vary: User-Agent) i niezormalizowane parametry w adresie — ?utm_source=newsletter to dla większości konfiguracji osobny klucz cache’a niż ten sam adres bez parametru. Jedna strona, kilkadziesiąt wpisów w pamięci, każdy zimny.

Czego rozgrzać się nie da (i po co to wiedzieć)

Tu jest sedno, przez które przechodzę z klientami najczęściej, bo intuicja podpowiada coś zupełnie innego niż rzeczywistość.

Nie rozgrzejesz pamięci podręcznej CDN-a globalnie. Cloudflare, Fastly, CloudFront — wszystkie trzymają cache osobno w każdym centrum danych. Kiedy odpalasz skrypt rozgrzewający z maszyny w Warszawie, zapełniasz cache w warszawskim PoP-ie. We Frankfurcie, w Amsterdamie i w Ashburn nadal jest pusto. Nawet Cloudflare w swojej dokumentacji Cache Reserve pisze o tym wprost: standardowy cache jest per lokalizacja, a obiekty są usuwane, jeśli nie są dostatecznie często pobierane. Sieci brzegowe mają setki lokalizacji. Nie rozgrzejesz ich curl-em w pętli, a jeśli spróbujesz na serio — zapłacisz za to ruchem wychodzącym z originu, czyli dokładnie tym, przed czym chciałeś się bronić.

Nie rozgrzejesz cache’u, który zaraz unieważnisz. Widziałem to w projektach, które prowadziłem: zespół uczciwie rozgrzewa cache na środowisku docelowym, po czym godzinę później wgrywa jeszcze jedną poprawkę i buduje aplikację od nowa. Nowy build, nowe klucze, wszystko od zera. Rozgrzewanie ma sens tylko wtedy, gdy jest ostatnim krokiem po ostatnim wdrożeniu — nie krokiem pośrodku.

Nie rozgrzejesz cache’u ISR w Next.js na wszystkich instancjach naraz, jeśli każdy kontener trzyma swoją kopię na własnym dysku. Load balancer rzuci kolejne żądanie do innego poda i znowu masz chybienie. Dokumentacja Next.js opisuje to bez ogródek: żeby cache był wspólny między instancjami, potrzebujesz własnego cacheHandler wpiętego we współdzielony magazyn — najczęściej Redis — i wyłączonego cache’u w pamięci (cacheMaxMemorySize: 0). Inaczej „rozgrzewasz” jedną trzecią klastra i nie wiesz nawet którą.

A co rozgrzejesz naprawdę? Trzy rzeczy — i akurat te trzy są warte zachodu:

origin — bufory bazy danych, OPcache, cache obiektowy, wyliczone konfiguracje;
górną warstwę CDN-a (shield / upper tier) — jeśli ją włączyłeś, bo tylko ona jest wspólna dla wielu lokalizacji;
cache aplikacyjny, jeśli jest współdzielony — ISR w Redisie, Varnish przed aplikacją, prerender wygenerowany podczas builda.

Reszta to nie rozgrzewanie, tylko generowanie sobie ruchu.

Co robić zamiast tego: pięć dźwigni

1. Stale-while-revalidate i stale-if-error

Najtańsza polisa ubezpieczeniowa, jaką znam, i pierwsza rzecz, którą ustawiam przed migracją.

stale-while-revalidate mówi warstwie pośredniczącej: „jeśli ta odpowiedź się przeterminowała, podaj użytkownikowi starą wersję od razu, a świeżą pobierz sobie w tle”. stale-if-error idzie krok dalej: „jeśli origin zwrócił błąd albo nie odpowiada, podaj starą wersję zamiast błędu”. Dla dnia migracji to różnica między „strona chwilę pokazuje nieaktualną cenę” a „strona zwraca 502″.

Cache-Control: public, s-maxage=600, stale-while-revalidate=86400, stale-if-error=86400

Rozłóżmy to na czynniki, bo każdy człon robi coś innego:

s-maxage=600 — dla CDN-a odpowiedź jest świeża przez 10 minut (max-age dotyczyłby przeglądarki, s-maxage warstw pośrednich);
stale-while-revalidate=86400 — przez kolejną dobę CDN może podawać wersję przeterminowaną, odświeżając ją w tle;
stale-if-error=86400 — a jeśli origin się wywróci, przez dobę i tak jest z czego serwować.

Fastly obsługuje oba te nagłówki natywnie. Vercel dokłada stale-while-revalidate do stron ISR automatycznie. W Cloudflare serwowanie treści przeterminowanej ustawia się po stronie Cache Rules — sprawdź, co dokładnie masz dostępne na swoim planie, zanim oprzesz na tym plan migracji, bo to się między planami różni. Ja tego nie zakładam w ciemno; wchodzę w panel i sprawdzam.

2. Origin shield: Tiered Cache, Cache Reserve, Origin Shield

Skoro cache jest osobny w każdej lokalizacji, to sensowną odpowiedzią nie jest rozgrzewanie ich wszystkich, tylko postawienie warstwy wspólnej między nimi a Twoim serwerem.

W Cloudflare to Tiered Cache: zamiast setki lokalizacji pukających niezależnie do originu, chybienia spływają do wybranej lokalizacji nadrzędnej, a ona dopiero odpytuje serwer. Jeden obiekt = jedno zapytanie do originu zamiast kilkudziesięciu. Do tego Cache Reserve — trwały magazyn oparty na R2, który trzyma obiekty domyślnie przez 30 dni i łapie to, co normalnie zostałoby wyrzucone z brzegu z braku ruchu. Cloudflare zaznacza, że Cache Reserve projektowano do pracy razem z Tiered Cache i że obiekty bez długiego czasu życia albo bez nagłówka Content-Length nie kwalifikują się do przechowania. To ważny szczegół — łatwo włączyć Cache Reserve, ucieszyć się i nie zauważyć, że połowa zasobów nie spełnia warunków wejścia.

Odpowiedniki u konkurencji: Origin Shield w CloudFront, Origin Shielding w Fastly. Mechanizm ten sam — jedna warstwa pośrednia, która absorbuje chybienia.

Jedna uczciwa uwaga: Cache Reserve kosztuje (płacisz za magazyn i operacje), więc włączanie go na całą domenę przy treści, która często się zmienia, to wyrzucanie pieniędzy. Zawężam go do zasobów o długim życiu — obrazów, plików statycznych, stron, które realnie leżą tygodniami.

3. Sklejanie zapytań (request coalescing)

Lekarstwo na tratowanie z sekcji wyżej: konfigurujesz warstwę pośrednią tak, żeby przy dwustu równoległych żądaniach w ten sam pusty klucz do originu poszło jedno, a pozostałe 199 poczekało na jego wynik.

W Nginksie robią to dwie dyrektywy, których nie zamieniłbym na nic innego:

proxy_cache_lock on;               # jedno żądanie generuje, reszta czeka
proxy_cache_lock_timeout 10s;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_background_update on;  # przeterminowaną podaj od razu, odśwież w tle

proxy_cache_use_stale updating to ten człon, który ratuje skórę: kiedy jedno żądanie odświeża wpis, pozostałe dostają wersję przeterminowaną zamiast stać w kolejce. Varnish ma to wbudowane (kolejkuje żądania w ten sam obiekt), CloudFront również scala żądania o ten sam obiekt do originu. Sprawdź, czy Twoja warstwa to robi — a jeśli stoisz na czymś własnym, dopisz to, zanim będziesz tego potrzebował.

4. Przekierowania na brzegu, nie w aplikacji

Wracam do mnożenia razy dwa. Skoro robot i tak przejdzie po wszystkich starych adresach, to zadbaj, żeby przejście po nich było tanie.

Mapa przekierowań ma leżeć jak najbliżej brzegu sieci i jak najdalej od bazy danych:

Cloudflare Bulk Redirects albo reguła w Workers — 301 odpowiada z lokalizacji brzegowej, aplikacja w ogóle się nie budzi;
map w Nginksie wczytana z pliku — bez PHP, bez zapytania do bazy, bez połączenia z bazą w puli;
wtyczka do przekierowań w CMS-ie — dopiero jako ostatnia opcja, i najlepiej tylko dla ogona długiego, nie dla wszystkich adresów.

Przy okazji: przekierowania mają być pojedyncze. Stary URL → nowy URL. Nie stary → pośredni → nowy → wersja z ukośnikiem → wersja bez ukośnika. Każdy dodatkowy skok to kolejne zapytanie i kolejne opóźnienie, a łańcuchy potrafią sumować się do sekund. Mapowanie przekierowań jeden do jednego opisałem szerzej w poniższych artykułach:

Przekierowania na krawędzi. Jak obsłużyć 100k URL-i w Next.js i Cloudflare

Tworzenie mapy przekierowań z 50 000 adresami URL. Skrypt z LLM kontra ręczna robota w Excelu?

5. Zawór bezpieczeństwa: 429 i 503 — ale ostrożnie

Załóżmy, że mimo wszystko się dzieje. Ruch przekracza możliwości, kolejka rośnie, trzeba przyhamować roboty. Wtedy — i tylko wtedy — sięgasz po kody statusu.

Zasady są dobrze udokumentowane przez Google i warto je znać przed kryzysem, nie w jego trakcie:

429 albo 503 to prawidłowy sygnał „zwolnij”. Google podaje, że jego infrastruktura obniża tempo pobierania, gdy napotka znaczącą liczbę adresów zwracających 500, 503 lub 429.
Nigdy 403 ani 404 w tym celu. Google poświęcił temu osobny wpis na blogu Search Central — wszystkie kody 4xx poza 429 skutkują usunięciem treści z wyników wyszukiwania. To nie jest hamowanie robota, to jest strzał do własnej bramki.
Maksymalnie dzień, dwa. Dokumentacja Search Console mówi jasno: nie zwracaj 503 ani 429 dłużej niż dwa–trzy dni, bo to sygnał do trwałego obniżenia tempa pobierania, a przy dłuższym utrzymaniu tego stanu adresy zaczynają wypadać z indeksu.
Obniżenie dotyczy całej nazwy hosta — nie tylko adresów, które zwróciły błąd. Jeśli przymulisz robota na jednej sekcji, spowolnisz pobieranie całej domeny.
Dokładaj nagłówek Retry-After. Googlebot go honoruje.

Googlebot a kody statusu — w pigułce

429 / 503 → „jestem przeciążony, wróć później”. Prawidłowy sygnał, dopuszczalny na krótko (dzień–dwa), obniża tempo pobierania całej domeny. 500 → „coś się u mnie zepsuło”. Też obniża tempo, ale wygląda jak awaria, a nie jak świadome hamowanie. 403 / 404 / 410 → „ta treść nie istnieje albo nie masz do niej dostępu”. Prowadzi do usunięcia strony z wyników. Nie używaj tego do hamowania robotów. Blokada w robots.txt → działa, ale wchodzi w życie nawet do doby i jest tępym narzędziem.

Źródła: Google Search Central — „Reduce Google crawl rate” i „Don’t 404 my yum”; pomoc Search Console — raport Statystyki indeksowania.

Kolejność przepięcia DNS: T-7 do T+7

Poniżej harmonogram, do którego wracam przy każdej większej migracji. Nie jest to nauka ścisła — daty przesuwaj pod swój projekt — ale kolejność ma znaczenie i tej bym nie zmieniał.

T-7 dni

Zbierz pełną listę adresów ze starej witryny: mapy witryny, logi serwera, Screaming Frog, raport skuteczności z Search Console. Logi są najważniejsze — pokażą, co robot faktycznie odwiedza, a nie co Ty myślisz, że odwiedza.
Sprawdź na środowisku docelowym trzy rzeczy: czy odpowiedzi na stronach publicznych nie niosą Set-Cookie, jak wygląda Vary i czy parametry adresu są normalizowane (utm_* powinno być ignorowane w kluczu cache’a).
Ustaw nagłówki Cache-Control z s-maxage, stale-while-revalidate i stale-if-error.
Włącz Tiered Cache (albo odpowiednik u swojego dostawcy). Rozważ Cache Reserve dla zasobów o długim życiu.

T-2 dni

Obniż TTL rekordów DNS do 300 sekund. To musi się zdążyć rozpropagować pod starym, długim TTL-em — dlatego robisz to dwa dni wcześniej, nie w dniu przepięcia. Dzięki temu, jeśli coś pójdzie źle, wycofasz się w minutach, a nie w godzinach.
Załaduj mapę przekierowań na warstwę brzegową i przetestuj ją na próbce: kilkaset adresów, sprawdzasz kod statusu i liczbę skoków.
Wykonaj ostateczny build i wdrożenie. Po tym momencie nie wgrywasz już „drobnych poprawek”.

T-1 dzień

Rozgrzej origin, kierując ruch testowy bezpośrednio na docelowy serwer (przez wpis w hosts, domenę tymczasową albo nagłówek Host) — z pominięciem CDN-a. Chodzi o bufory bazy, OPcache i cache obiektowy, nie o brzeg sieci.
Przy Next.js: upewnij się, że najważniejsze ścieżki mają wygenerowany prerender z generateStaticParams, a przy self-hoście — że cacheHandler wskazuje na wspólny Redis. Strony wygenerowane podczas builda są dostępne od pierwszego żądania, bez chybienia.
Postaw monitoring, na który będziesz patrzeć: udział trafień i chybień (cf-cache-status, X-Cache), czas odpowiedzi originu, obciążenie bazy, liczba 5xx.

T-0, przepięcie

Przepnij DNS. Nie wyłączaj starego serwera — przez najbliższe dni będzie obsługiwał resolwery, które zignorowały TTL.
Przez pierwsze 30 minut patrz na jedną metrykę: udział chybień. Jeśli po kwadransie nie spada, nie masz problemu z rozgrzewaniem — masz problem z konfiguracją. Wracasz do sekcji o Set-Cookie i Vary.
Zgłoś nową mapę witryny w Search Console. Nie wcześniej — nie ma sensu zapraszać robota do adresów, które jeszcze nie odpowiadają.

T+1 do T+7

Codziennie: raport Statystyki indeksowania w Search Console (liczba żądań, średni czas odpowiedzi, rozkład kodów statusu) i logi serwera przefiltrowane po prawdziwym Googlebocie — zweryfikowanym odwrotnym DNS-em na crawl-*.googlebot.com, nie po deklarowanym nagłówku User-Agent, bo ten podszywa się każdy.
Jeśli czas odpowiedzi rośnie, a udział trafień stoi w miejscu — zaciskasz kolejne dźwignie z sekcji wyżej, zaczynając od sklejania zapytań.
Podnieś TTL rekordów DNS z powrotem, kiedy sytuacja się ustabilizuje.

Pełną listę kontrolną migracji — od inwentaryzacji adresów po weryfikację po wdrożeniu — rozpisałem osobno: [LINK WEWNĘTRZNY → checklista migracji strony bez spadków ruchu].

Kontrargumenty, które słyszę najczęściej

„Mam mały serwis, to mnie nie dotyczy.” Częściowo słusznie. Przy witrynie wizytówkowej z trzydziestoma podstronami zimny start trwa minutę i nikt go nie zauważy. Ale skala nie jest jedynym czynnikiem — decyduje też koszt wygenerowania pojedynczej strony. Widziałem serwisy o niewielkiej liczbie adresów, które kładły się przy dwudziestu równoległych żądaniach, bo każda strona odpalała serię ciężkich zapytań do bazy. Jeśli Twoja strona bez cache’u generuje się dwie sekundy, masz problem niezależnie od rozmiaru.

„Googlebot sam się wycofa, kiedy zobaczy, że serwer się dusi.” Prawda — i właśnie w tym rzecz. Wycofa się, tylko odzyskiwanie tempa pobierania zajmuje potem tygodnie, a obniżka dotyczy całej nazwy hosta. Migracja to najgorszy możliwy moment na to, żeby robot zwolnił, bo akurat wtedy potrzebujesz, żeby jak najszybciej przeszedł po wszystkich przekierowaniach i przeliczył nowe adresy.

„Skoro rozgrzewanie brzegu nie działa, to po co narzędzia do cache warming?” Bo mają sens tam, gdzie warstwa jest wspólna: przy Varnishu na jednym serwerze, przy cache’u stron w CMS-ie, przy ISR ze wspólnym magazynem, przy górnej warstwie CDN-a. Nie mają sensu jako sposób na zapełnienie setek niezależnych lokalizacji brzegowych. To rozróżnienie, nie potępienie — narzędzie jest dobre, tylko bywa używane do nie swojego zadania.

„Przecież Cache Reserve rozwiązuje wszystko.” Nie rozwiązuje. Rozwiązuje wypadanie rzadko odwiedzanych zasobów z brzegu, i robi to dobrze. Nie rozwiązuje cache’owania treści dynamicznej, nie obejdzie Set-Cookie i kosztuje. To jeden element układanki.

Co bym zrobił na Twoim miejscu

Gdybym miał zostawić Ci z tego tekstu trzy zdania, byłyby to te:

Po pierwsze: zanim cokolwiek zaczniesz rozgrzewać, sprawdź, czy cache w ogóle się zapełnia. Set-Cookie na stronach publicznych, zbyt szeroki Vary i nienormalizowane parametry adresu robią więcej szkody niż jakikolwiek pusty start.

Po drugie: ustaw stale-while-revalidate i stale-if-error, włącz warstwę pośrednią (Tiered Cache lub odpowiednik) i sklejanie równoległych zapytań. Te trzy rzeczy razem kosztują popołudnie pracy i zmieniają migrację z ryzykownej w nudną. Nudna migracja to dobra migracja.

Po trzecie: przekierowania trzymaj na brzegu i pojedyncze. Robot i tak przejdzie po wszystkich starych adresach — Twoim zadaniem jest sprawić, żeby go to nic nie kosztowało.

A rozgrzewanie? Zrób je na końcu, na origin, po ostatnim wdrożeniu, na dwustu najważniejszych adresach z logów. Nie na pięciu tysiącach z mapy witryny, bo połowy z nich i tak nikt nigdy nie odwiedza.

I jeszcze jedno, z gatunku „ciut prywaty”: w dniu przepięcia nie odświeżaj Search Console co dziesięć minut. Statystyki indeksowania i tak aktualizują się z opóźnieniem, a Google potrzebuje kilku dni, żeby przeliczyć nowe adresy. Zrób sobie porządną kawę i patrz w logi serwera — one mówią prawdę w czasie rzeczywistym, panel dopiero za dzień.