Jedno zbyt szerokie ustawienie w panelu Cloudflare potrafi odciąć Googlebota od witryny i w ciągu kilkunastu dni wypchnąć ją z wyników wyszukiwania. Problem jest podstępny, bo strona działa dla użytkowników, podczas gdy ruch organiczny topnieje. Poniżej znajduje się metoda szybkiej diagnozy oraz zasady bezpiecznej konfiguracji reguł.
Ten scenariusz stał się bardziej prawdopodobny wraz z falą blokad wymierzonych w boty AI. Presja, by chronić treści przed trenowaniem modeli, popycha zespoły do zaostrzania reguł, a to właśnie tam najczęściej rodzi się przypadkowe odcięcie robota indeksującego. Warto więc podejść do tematu z chłodną głową, oddzielając realny mechanizm od modnej narracji o wojnie z botami AI.
Na czym polega blokowanie Googlebota przez Cloudflare
Problem sprowadza się do nieumyślnego odcięcia ruchu Googlebota na poziomie infrastruktury Cloudflare, zanim żądanie w ogóle dotrze do serwera witryny. Strona pozostaje w pełni dostępna dla zwykłych użytkowników, dlatego problem długo bywa niezauważony, mimo że jego skutki dla widoczności są poważne.
- Blokada powstaje najczęściej na skutek zbyt szerokich reguł WAF lub próby blokowania botów AI, które przy okazji obejmują standardowego Googlebota.
- Częstą przyczyną jest zablokowanie całej puli adresów IP Google w ramach ASN 15169, co odcina również robota indeksującego. ASN 15169 to numer systemu autonomicznego Google, obejmujący adresy jego usług.
- Googlebot odpowiada zarówno za klasyczne indeksowanie, jak i za AI Overviews, więc jego blokada uderza w oba kanały widoczności jednocześnie.
W projektach, które mieliśmy okazję audytować blokada Googlebota niemal zawsze była skutkiem ubocznym reguły wymierzonej w scrapery, a nie świadomą decyzją. To istotne rozróżnienie, bo pokazuje, gdzie realnie szukać źródła problemu: nie w intencji, lecz w zbyt szerokim zasięgu reguły, która miała chronić serwer, a przy okazji odcięła najważniejszego gościa.
Różnica między Googlebotem a Google-Extended
Rozróżnienie tych dwóch robotów jest kluczowe, ponieważ wiele blokad wynika z pomylenia celu ochrony treści przed trenowaniem AI z blokadą standardowego indeksowania. To dwa odrębne User-Agenty o zupełnie różnych konsekwencjach.
- Googlebot skanuje i indeksuje strony na potrzeby wyników wyszukiwania, a jego zablokowanie prowadzi wprost do deindeksacji.
- Google-Extended to osobny User-Agent służący wyłącznie do pobierania danych na potrzeby trenowania modeli AI.
- Precyzyjne zablokowanie Google-Extended chroni treści przed trenowaniem AI i nie wpływa na standardowe indeksowanie przez Googlebota.
W praktyce oznacza to, że cel, który stawia sobie wiele zespołów, czyli ochrona treści przed trenowaniem modeli, da się osiągnąć bez najmniejszego ryzyka dla widoczności. Problem pojawia się dopiero wtedy, gdy zamiast celować w Google-Extended, reguła obejmuje cały ruch Google.
Jak deindeksacja wpływa na ruch organiczny i przychody
Skutki błędnej blokady nie są natychmiastowe, co czyni je jeszcze bardziej niebezpiecznymi. Witryna przez pewien czas utrzymuje pozycje, a potem gwałtownie traci widoczność, gdy Google przetworzy powtarzające się odmowy dostępu.
- Gdy witryna zwraca Googlebotowi błędy z serii HTTP 403 (Forbidden), czyli odmowę dostępu, podstrony stopniowo znikają z indeksu.
- Pierwsze skutki deindeksacji mogą pojawić się w ciągu kilkunastu dni od wystąpienia blokady.
- Odbudowa utraconych pozycji trwa zwykle od kilku tygodni do kilku miesięcy, znacznie dłużej niż samo powstanie problemu.
- Drastyczny spadek ruchu organicznego przekłada się na bezpośrednie straty finansowe, co nadaje sprawie charakter YMYL.
Ta asymetria między tempem powstania problemu a tempem jego naprawy jest tu najważniejsza. Blokadę można wprowadzić w kilka sekund jednym kliknięciem, jej skutki ujawnią się po kilkunastu dniach, a powrót do stanu wyjściowego zajmie tygodnie lub miesiące. To dysproporcja, która powinna skłaniać do ostrożności przy każdej zmianie w warstwie WAF.
Dlaczego agresywne reguły nie poprawiają budżetu indeksowania
Wśród webmasterów krąży przekonanie, że ostre reguły bezpieczeństwa oszczędzają zasoby serwera i poprawiają budżet indeksowania. W praktyce efekt bywa odwrotny i pogarsza ocenę techniczną witryny.
- Wbrew popularnemu mitowi zbyt agresywne reguły, takie jak JS Challenge dla każdego nierozpoznanego ruchu, nie poprawiają budżetu indeksowania.
- Takie reguły mogą blokować renderowanie stron przez Googlebota i obniżać ocenę techniczną witryny.
Po złagodzeniu nadmiarowych wyzwań dla nierozpoznanego ruchu można zaobserwować poprawę renderowania kluczowych podstron w narzędziach Google. To spostrzeżenie z konkretnych wdrożeń, a nie ogólna reguła, dlatego warto potwierdzić je na własnym projekcie. Mechanizm jest jednak logiczny: robot, który zamiast treści dostaje wyzwanie do rozwiązania, nie renderuje strony tak, jak powinien, a to przekłada się na sposób, w jaki Google ją ocenia.
Jak zdiagnozować blokadę Googlebota w panelu Cloudflare
Zamiast czekać na spadki widoczne w Google Search Console, blokadę można wykryć bezpośrednio w panelu Cloudflare. To najszybsza metoda potwierdzenia, że problem leży w warstwie infrastruktury, a nie w samej treści witryny.
- Diagnostykę zaczyna się od zakładki Security, a następnie Events w panelu Cloudflare.
- Filtr ustawiony na ASN równe 15169 w połączeniu z akcją Block lub Managed Challenge ujawnia blokowany ruch Google.
- Należy sprawdzić hierarchię reguł WAF i upewnić się, że reguła Skip lub Allow dla Known Bots znajduje się wyżej niż reguły blokujące scrapery.
W audytach, które przeprowadzaliśmy najszybszym potwierdzeniem problemu było odnalezienie zdarzeń Block przypisanych do ASN 15169 jeszcze przed pojawieniem się alertów w Search Console. To przewaga tej metody: działa wyprzedzająco, zanim spadek ruchu odbije się na raportach. Warto pamiętać, że nazwy funkcji i ścieżki w panelu Cloudflare bywają aktualizowane, więc każdą konfigurację należy zweryfikować z bieżącą dokumentacją producenta.
Weryfikacja tożsamości Googlebota przez rewersyjny DNS
Zanim dany ruch zostanie uznany za prawdziwego Googlebota, warto potwierdzić jego tożsamość, ponieważ część scraperów podszywa się pod robota Google. Google udostępnia do tego oficjalną metodę.
- Google Search Central opisuje weryfikację Googlebota za pomocą rewersyjnego DNS oraz oficjalnych list adresów IP.
- Potwierdzenie tożsamości pozwala odróżnić prawdziwego Googlebota od scraperów podszywających się pod jego User-Agenta.
Ten krok bywa pomijany, a jest istotny, bo część reguł blokujących powstaje właśnie w reakcji na fałszywego Googlebota. Odróżnienie jednego od drugiego pozwala zablokować scraper, nie ruszając prawdziwego robota indeksującego.
Jak bezpiecznie skonfigurować reguły WAF i Bot Management
Celem konfiguracji jest zachowanie równowagi między ochroną serwera przed obciążającymi scraperami AI a pełną dostępnością dla robotów wyszukiwarek. Właściwa kolejność reguł jest tu ważniejsza niż ich liczba.
- Kluczową najlepszą praktyką jest umieszczenie reguły Skip lub Allow dla Known Bots wyżej w hierarchii Custom Rules niż jakiejkolwiek reguły blokującej scrapery.
- Funkcja Verified Bots utrzymuje automatycznie aktualizowaną listę zaufanych botów, w tym Googlebota, i powinna pozostać aktywna oraz nienaruszona.
- Wbudowane blokowanie botów AI jest uznawane za bezpieczniejsze niż statyczne, autorskie reguły WAF, ponieważ dynamicznie reaguje na rotację User-Agentów przez firmy AI.
Sedno leży w kolejności przetwarzania reguł. Reguła zezwalająca dla znanych botów musi zadziałać wcześniej niż reguła blokująca, w przeciwnym razie Googlebot zostanie odcięty, zanim system rozpozna go jako zaufanego. To najczęstszy błąd konfiguracyjny i zarazem najłatwiejszy do naprawienia.
W praktyce rezygnacja z ręcznych, statycznych blokad na rzecz mechanizmów Verified Bots i wbudowanego blokowania botów AI ograniczała ryzyko przypadkowego odcięcia Googlebota. Statyczna reguła oparta na nazwie User-Agenta starzeje się z każdą zmianą po stronie dostawców AI, podczas gdy mechanizm aktualizowany automatycznie nadąża za tą rotacją. Przed każdą zmianą warto jednak wykonać kopię konfiguracji i przetestować ją w kontrolowanych warunkach.
Blokowanie botów AI bez odcinania Googlebota
Ochrona treści przed trenowaniem modeli AI dla niektórych może być uzasadniona, ale musi być realizowana precyzyjnie. Błąd na tym etapie to najczęstsza droga do przypadkowej deindeksacji.
- Wbudowane, automatycznie aktualizowane blokowanie botów AI w Cloudflare jest bezpieczniejsze od statycznych reguł opartych na nazwach User-Agentów.
- Aktywne Verified Bots stanowią warunek bezpiecznego blokowania botów AI bez ryzyka odcięcia zaufanych robotów wyszukiwarek.
- Precyzyjna blokada Google-Extended pozwala ograniczyć trenowanie AI na treściach, nie wpływając na indeksowanie przez Googlebota.
Klucz to precyzja zamiast szerokiego zasięgu. Blokada wymierzona dokładnie w Google-Extended i oparta na aktualizowanych mechanizmach realizuje cel ochrony treści, nie dotykając kanału, od którego zależy widoczność. To rozwiązanie mniej efektowne niż jednym ruchem odciąć cały ruch botów, ale znacznie bezpieczniejsze.
Co zrobić po wykryciu i odblokowaniu Googlebota
Samo usunięcie blokady to dopiero początek procesu odzyskiwania widoczności. Kolejne kroki mają skrócić czas powrotu podstron do indeksu i potwierdzić, że problem nie powróci.
- Po korekcie reguł należy potwierdzić w Google Search Console, że Googlebot ponownie uzyskuje dostęp i nie otrzymuje błędów HTTP 403.
- Odbudowa pozycji zajmuje od kilku tygodni do kilku miesięcy, dlatego działania warto rozpocząć niezwłocznie po diagnozie.
Po przywróceniu dostępu monitorowaliśmy zdarzenia bezpieczeństwa dla ASN 15169, aby upewnić się, że blokada nie pojawia się ponownie. Ten ostatni krok bywa pomijany, a jest istotny, bo reguły WAF potrafią zostać przywrócone przy kolejnej aktualizacji konfiguracji lub wdrożeniu nowej polityki bezpieczeństwa. Warto pamiętać, że powyższe wskazówki mają charakter edukacyjny i nie zastępują audytu technicznego przeprowadzonego na konkretnej witrynie.
Warto zweryfikować konfigurację Cloudflare i reguły WAF pod kątem dostępności Googlebota, zanim spadek ruchu stanie się widoczny w statystykach. Przy podejrzeniu problemu z indeksowaniem sensownym krokiem jest zlecenie audytu technicznego widoczności organicznej, a każdą planowaną zmianę w warstwie WAF warto skonsultować z zespołem SEO i DevOps przed jej wdrożeniem na produkcji.
