Przejście na CDN bez przeciążania punktu początkowego (lub blokowania Googlebota)

Środa, 11 listopada 2026 r.

Wdrożenie sieci dostarczania treści (CDN) w celu dystrybucji zasobów witryny na szybkich, rozproszonych globalnie serwerach brzegowych bliżej użytkowników może być ważnym ulepszeniem dla każdej rozwijającej się witryny: zmniejsza opóźnienia u użytkowników i chroni serwer pierwotny (źródło backendu zawierające oryginalne treści) przed dużym ruchem.

Brzmi idealnie, prawda? Cóż… faza przejściowa może być trochę dziwna.

Czasami właściciele witryn informują nas, że zaraz po umieszczeniu witryny za siecią CDN ruch robotów na ich serwerze gwałtownie wzrasta, co jest dokładnie tym, co próbowali naprawić. Zanim te serwery brzegowe wypełnią swoje pamięci podręczne, zarówno wizyty użytkowników, jak i żądania robotów muszą być pobierane bezpośrednio z serwera źródłowego.

Przechodząc na sieć CDN, warto sprawdzić, jak działa budżet indeksowania i jak w razie potrzeby zmniejszyć szybkość indeksowania przez Google. W tym poście na blogu chcemy wyjaśnić, czego można się spodziewać po takiej zmianie i jakie wyzwania się z nią wiążą. Dlatego też założyliśmy kaski i chwyciliśmy węże strażackie, aby przeprowadzić Cię przez ten proces w 5 odcinku podcastu The Non-Canonical Cabinet. Jeśli po przejściu na CDN zastanawiasz się, skąd pochodzi cały nowy ruch, lub chcesz uniknąć przypadkowego usunięcia witryny z wyszukiwarki, ten artykuł jest dla Ciebie.

Dlaczego wszystko indeksuje wszędzie jednocześnie?

Gdy przejdziesz na sieć CDN, może nastąpić wzrost ruchu związanego z robotami, ponieważ infrastruktura indeksowania Google oblicza limit indeksowania Twojej witryny (znany też jako obciążenie hosta):

• Coraz wolniejsze odpowiedzi zmniejszają szybkość indeksowania. Infrastruktura automatycznego indeksowania Google stale monitoruje stan i czas odpowiedzi serwera hosta. Gdy czas odpowiedzi się wydłuża, nasze roboty indeksujące zwalniają, aby nie przeciążać serwera i nie pogarszać wrażeń użytkowników witryny.
• Szybkie i stabilne odpowiedzi przyspieszają indeksowanie. Gdy serwer odpowiada szybko i stabilnie, nasze systemy interpretują tę szybkość jako oznakę sprawnej i wydajnej infrastruktury. Jeśli istnieje zapotrzebowanie na indeksowanie, limit wydajności indeksowania stopniowo się zwiększa.

Gdy tylko DNS zacznie wskazywać szybką sieć brzegową CDN, czasy połączenia i odpowiedzi znacznie się skrócą. Dla naszych systemów indeksujących wygląda to tak, jakby Twój serwer właśnie przeszedł gruntowną modernizację sprzętu, więc nasze roboty zaczynają zwiększać częstotliwość wniosków, aby dopasować ją do nowych możliwości.

Problem. Brak danych w pamięci podręcznej na serwerach brzegowych.

Wyższa szybkość indeksowania nie byłaby problemem, gdyby sieć CDN obsługiwała wszystkie te żądania na brzegu sieci. Haczyk polega na tym, że nowa sieć CDN zaczyna od pustej (zimnej) pamięci podręcznej.

Przy pierwszym żądaniu adresu URL w lokalizacji brzegowej sieć CDN nie ma jeszcze kopii tego zasobu (dokumentów HTML, CSS, JavaScriptu, obrazów itp.). Jest to brak w pamięci podręcznej. Aby spełnić żądanie, serwer brzegowy musi „wrócić” do serwera pierwotnego, pobrać odpowiedź, zapisać kopię w pamięci podręcznej, a następnie obsłużyć klienta. Dopiero kolejne żądania dotyczące tego samego adresu URL w pamięci podręcznej stają się trafieniami w pamięci podręcznej obsługiwanymi bezpośrednio z brzegu sieci bez obciążania serwera źródłowego. (W naszym filmie serwer brzegowy był reprezentowany przez gumowego kurczaka biegającego tam i z powrotem do stosu karteczek. Schematy sieci są subiektywne).

Zasadniczo głównym wąskim gardłem podczas uruchamiania CDN jest nadal serwer pierwotny.

Użytkownicy zwykle skupiają się wokół stosunkowo niewielkiego zestawu popularnych stron (strony głównej, najpopularniejszych artykułów lub aktywnych promocji), które szybko się rozgrzewają w pamięci podręcznej CDN. Roboty działają dokładnie odwrotnie. Ich zadaniem jest systematyczne sprawdzanie wszystkich adresów URL w Twoich zasobach reklamowych.

Teraz połącz te 2 zachowania:

1. Szybkie odpowiedzi z brzegu sieci sygnalizują robotom Google, że mogą bezpiecznie indeksować szybciej.
2. Gdy roboty po raz pierwszy przetwarzają te duże liczby adresów URL, każdy niebuforowany adres URL powoduje brak w pamięci podręcznej, który jest przekazywany bezpośrednio do serwera pierwotnego.

Roboty nie zwiększają od razu szybkości indeksowania, a wiele sieci CDN ma wbudowane funkcje zarządzania tempem połączeń, które pomagają wygładzać skoki ruchu. Mimo to, dopóki tymczasowe przechowywanie danych na serwerach brzegowych nie zostanie zapełnione (rozgrzane), sieć CDN nie będzie jeszcze działać jako tarcza, a serwer pierwotny nadal będzie wykonywać najcięższą pracę.

Nie indeksuj! Gdy ogólna ochrona przed botami idzie za daleko

Niespodziewany wzrost liczby automatycznych żądań w dziennikach źródłowych tuż po migracji może wywołać niepokój administratorów, jeśli nie wiedzą, dlaczego tak się dzieje. Gdy pamięć podręczna się zapełnia, wykresy żądań mogą gwałtownie rosnąć. Można ulec pokusie, aby zalogować się w panelu CDN i włączyć ogólną ochronę przed botami. Cytując Cherry: „BOTY NIE PRZEJDĄ!”

Problem z ogólnymi regułami bezpieczeństwa polega na tym, że bez wyjątków traktują one cały ruch automatyczny tak samo, w tym ruch z robotów, na których Ci zależy. Gdy sieć CDN lub zapora sieciowa aplikacji internetowej (WAF) oznaczy automatyczne żądania i przechwyci je za pomocą testu, takiego jak CAPTCHA, roboty Google nie przejdą testu. (Googlebot ma wiele talentów, ale rozpoznawanie sygnalizacji świetlnej i kurczaków nie jest jednym z nich. Nawet Gary nie zawsze potrafi to zrobić).

Pozostawienie włączonej ogólnej ochrony przed botami bez wykluczenia zweryfikowanych robotów indeksujących powoduje, że roboty indeksujące utkną na stronie błędu, która nie jest przydatna dla wyszukiwarki ani innych usług korzystających z zeskanowanych danych. Z naszej perspektywy wygląda na to, że Twoja witryna jest celowo ograniczona lub uszkodzona. Jeśli pozostawisz je na miejscu, nasze roboty będą się wycofywać, a Twoje strony, informacje o produktach i zdjęcia kurczaków zaczną znikać z wyszukiwarki.

Jak wytresować sieć CDN (bez spalania punktu początkowego)

Nie musisz zatrudniać strażaka, aby wdrożyć CDN. Musisz mieć odpowiednie oczekiwania i plan działania, taki jak:

1. Jeśli musisz blokować boty, zezwól na zweryfikowane boty w ustawieniach CDN i zapory sieciowej. Większość głównych sieci CDN i systemów WAF oferuje wbudowany przełącznik lub regułę zarządzaną, która umożliwia zezwalanie na znane lub zweryfikowane boty. Dzięki temu preferowane roboty mogą omijać testy CAPTCHA, a niechciany ruch jest nadal filtrowany (nasze roboty możesz zidentyfikować na podstawie opublikowanych zakresów adresów IP Google). Możesz też skonfigurować plik robots.txt lub użyć reguł, aby kierować reklamy na konkretne niechciane boty, zamiast blokować wszystkich automatycznych klientów.
2. Zanim otworzysz bramy, rozgrzej pamięć podręczną. Zanim przekierujesz cały ruch przez nową sieć CDN, pobierz automatycznie strony o największym natężeniu ruchu, strony, na których spodziewasz się szczytowego natężenia ruchu (np. strony promocyjne lub sezonowe), oraz najczęściej indeksowane adresy URL przez sieć CDN w kontrolowanym tempie, aby pamięci podręczne na serwerach brzegowych były gotowe do obsługi ruchu. Jeśli jednak, w przeciwieństwie do Gary'ego, masz znajomych, możesz poprosić ich o wejście na 2 różne adresy URL. To też zadziała.
3. Jeśli potrzebujesz tymczasowej przerwy, użyj 429 lub 503. Jeśli podczas zapełniania pamięci podręcznej liczba indeksowanych stron nadal powoduje krytyczne obciążenie serwera pierwotnego, skonfiguruj reguły ograniczania liczby żądań na serwerze lub w sieci CDN, aby zwracały kod stanu HTTP 429 (Too Many Requests) lub 503 (Service Unavailable) przez krótki czas (kilka godzin lub maksymalnie 1–2 dni), zgodnie z opisem w naszym przewodniku na temat pilnego zmniejszania szybkości indeksowania przez Google.

Podsumowanie TL;DR (kto umieszcza TL;DR na końcu?!)

Zanim owiniesz kabel Ethernet wokół szafy serwerowej i uznasz, że to koniec, pamiętaj o 3 rzeczach, gdy przechodzisz na sieć CDN:

• Szybsze odpowiedzi oznaczają szybsze indeksowanie: małe opóźnienie na brzegu sieci CDN sygnalizuje robotom Google, że witryna działa prawidłowo i może obsłużyć większą szybkość indeksowania.
• Pamięć podręczna chroni Cię tylko podczas drugiej wizyty: w przypadku pustej pamięci podręcznej pierwsze żądanie dotyczące każdego unikalnego adresu URL jest brakiem w pamięci podręcznej, które trafia bezpośrednio do serwera pierwotnego. W miarę możliwości wstępnie rozgrzewaj pamięci podręczne.
• W razie potrzeby zwolnij zweryfikowane roboty z testów botów: nie pozwól, aby ogólne reguły WAF lub CAPTCHA blokowały roboty Google za pomocą ścian 403 lub stron testowych. Korzystaj ze zwolnień dla zweryfikowanych botów i polegaj na tymczasowych odpowiedziach 429 lub 503, jeśli Twój serwer źródłowy naprawdę potrzebuje przerwy.

Czy nie jesteście rozbawieni? Obejrzyj odcinek

thought Obejrzyj finałowy odcinek pierwszego sezonu (odcinek 5) podcastu The Non-Canonical Cabinet. Architekturę sieci wyjaśniamy za pomocą plastikowego kasku budowlanego, dymiącej szafki na dokumenty i gumowego kurczaka, który pełni rolę serwera brzegowego. Jesteśmy prawie pewni, że żadnego z tych przedmiotów nie było w naszych pierwotnych opisach stanowisk.

Interesuje Cię cały sezon 1? Próbowaliśmy uszkodzić adresy URL i plik robots.txt. Rozmawialiśmy o 404 i przekierowaniach. Obejrzyj wszystkie 5 odcinków Gwarantujemy, że nie zabraknie drobiu.

Masz jakiś dziwny przypadek, który chcesz, żebyśmy wyciągnęli z (nieco przypalonej) szafki w następnym sezonie (w zależności od budżetu)? Dodaj komentarz do filmu.

Dbaj o pamięć podręczną, porządek w zaporach sieciowych i bezpieczeństwo gumowych kurczaków.

Autorzy: Cherry, Gary, kurczak z pustą pamięcią podręczną, kurczak owinięty folią bąbelkową i alarm wyjący w tle.