Googlebot: jak rozpoznać robota Google i nie zablokować go przypadkiem

Googlebot w skrócie

Googlebot to robot, który pobiera strony do indeksu wyszukiwarki Google. Pod tą nazwą działają dwa roboty: Googlebot Smartphone i Googlebot Desktop. Większość żądań wysyła wersja na smartfony, bo Google indeksuje głównie mobilną wersję stron.

Prawdziwego Googlebota rozpoznasz po adresie IP, nie po nazwie w nagłówku. Nazwę „Googlebot” może wpisać każdy bot, a Google sam pisze, że jest ona często podrabiana. Sprawdzić to można dwoma zapytaniami DNS albo porównaniem IP z listą publikowaną przez Google. Obie metody opisujemy niżej.

Googlebot i inne roboty Google

Google ma więcej robotów niż sam Googlebot. W logach serwera i w plikach robots.txt często spotkasz te:

• Googlebot (Smartphone i Desktop): pobiera strony do wyszukiwarki, Discover, Grafiki Google, wideo i Google News. Obie wersje mają ten sam token w robots.txt, więc nie da się zablokować jednej bez drugiej.
• Googlebot-Image: pobiera obrazy, logo i favikony do wyników.
• Google-InspectionTool: robot narzędzi testowych, takich jak sprawdzanie adresu URL w Search Console i test wyników z elementami rozszerzonymi.
• GoogleOther: robot ogólny, którego zespoły Google używają na przykład do jednorazowych badań.
• AdsBot: robot reklam. Należy do robotów specjalnych i za zgodą wydawcy reklamy pomija ogólną grupę User-agent: * w robots.txt.

Osobny przypadek to Google-Extended. Nie ma własnego user agenta, jest tylko tokenem w robots.txt. Decyduje, czy treści mogą służyć do trenowania modeli Gemini, a według Google nie wpływa na obecność strony w wyszukiwarce. Różnice między robotami wyszukiwarek a botami AI omawiamy w tekście o tym, które boty AI blokować w robots.txt.

User agent Googlebota

Tak przedstawia się Googlebot Smartphone według dokumentacji Google:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

A tak Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Rzadziej pojawia się krótka wersja Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html). W miejscu W.X.Y.Z stoi numer wersji Chrome. Rośnie on razem z wersją Chromium, której używa Googlebot, dlatego przy filtrowaniu logów albo regułach na serwerze Google zaleca wpisać w tym miejscu symbol wieloznaczny. Reguła ze sztywnym numerem wersji przestanie pasować po kolejnej aktualizacji.

Sam user agent niczego nie dowodzi. Google pisze wprost, że nagłówek user agent Googlebota jest często podrabiany przez inne roboty, i radzi sprawdzić źródło żądania, zanim cokolwiek zablokujesz.

Jak sprawdzić, czy to prawdziwy Googlebot

Google podaje dwie metody. Pierwsza nadaje się do sprawdzenia kilku podejrzanych adresów ręcznie, druga do automatycznych reguł na serwerze.

Wsteczne zapytanie DNS

Weź adres IP z logów serwera i sprawdź go poleceniem host w terminalu (macOS, Linux; w Windows podobnie działa nslookup). Tak wyglądał wynik dla jednego z adresów Googlebota, sprawdzony 29 października 2026 roku:

$ host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

$ host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Nazwa hosta kończy się na googlebot.com, a zapytanie w przód zwraca ten sam IP. To prawdziwy Googlebot. Drugi krok jest konieczny, bo właściciel adresu IP może ustawić wsteczny wpis DNS na dowolną nazwę, ale nie może sprawić, żeby domena Google wskazywała jego serwer.

Według Google popularne roboty, w tym Googlebot, mają nazwy w rodzaju crawl-***-***-***-***.googlebot.com albo geo-crawl-***-***-***-***.geo.googlebot.com. Roboty specjalne, na przykład AdsBot, mają nazwy w domenie google.com, a narzędzia uruchamiane przez użytkownika także w gae.googleusercontent.com.

Porównanie z listą adresów IP

Google publikuje zakresy adresów w plikach JSON, osobno dla każdej grupy robotów. Dla Googlebota jest to common-crawlers.json, dla robotów specjalnych special-crawlers.json, a dla narzędzi uruchamianych przez użytkownika trzy kolejne pliki. Wszystkie leżą pod adresem https://developers.google.com/static/crawling/ipranges/. Pozostałe adresy Google są w pliku https://www.gstatic.com/ipranges/goog.json.

Listy się zmieniają: plik dla Googlebota, który pobraliśmy 29 października, był wygenerowany dzień wcześniej. Jeśli zapora sieciowa korzysta z tych zakresów, powinna pobierać aktualną wersję automatycznie. Kopia wklejona ręcznie po pewnym czasie przestaje się zgadzać.

Gdy zapora, CDN albo wtyczka blokuje Googlebota

Plik robots.txt to prośba, którą Googlebot respektuje. Zapora sieciowa, CDN albo wtyczka bezpieczeństwa działają inaczej: mogą odciąć robota, zanim dotrze do pliku. Takiej blokady nie zobaczysz w robots.txt, a zależnie od reguły obejmie wybrane adresy albo całą witrynę.

Przyczyny, które warto sprawdzić:

• Ustawienia botów w Cloudflare. Od 15 września 2026 roku opcje „Block” i „Block on pages with ads” obejmują także Googlebota, Bingbota i Applebota. „Block” odcina witrynę także od wyszukiwarek, a „Block on pages with ads” strony, na których Cloudflare wykryje reklamy. Cloudflare wskazuje, że do blokowania samego treningu służy opcja „Disallow AI Training”; według wpisu z 15 września 2026 roku ta opcja nie przekazuje Bingowi preferencji przez robots.txt, więc dla Binga Cloudflare wskazuje dodatkowo znacznik NOARCHIVE.
• Blokada krajów. Google pobiera strony głównie z adresów w USA. Jeśli wykryje, że strona blokuje ruch z USA, może spróbować z innych krajów, ale reguła „tylko Polska” na serwerze to ryzyko dla indeksowania.
• Limity żądań i wyzwania dla botów. Strona z CAPTCHA albo kodem 403 dla „podejrzanego” ruchu może zatrzymać też Googlebota.
• Reguły po samym user agencie. Wpuszczanie każdego, kto podaje się za Googlebota, otwiera stronę dla podróbek. Bezpieczniej oprzeć regułę na zweryfikowanych adresach IP.

Skutki blokady widać w Search Console. W statystykach indeksowania zmienia się rozkład odpowiedzi serwera, a gdy blokada obejmuje robots.txt, DNS albo połączenie z serwerem, pogarsza się też stan hosta; jak czytać ten raport, opisujemy w tekście o statystykach indeksowania w Search Console. Jeśli chcesz tylko ograniczyć, które części serwisu robot pobiera, użyj reguł opisanych w artykule o tym, jak działa plik robots.txt, a zaporę zostaw dla prawdziwych zagrożeń.

Jak Googlebot renderuje stronę

Google przetwarza strony w trzech etapach: pobieranie, renderowanie i indeksowanie. Najpierw robot pobiera kod HTML. Strony z kodem 200 trafiają do kolejki renderowania, gdzie Google uruchamia JavaScript w aktualnej wersji Chromium. Według dokumentacji strona czeka w kolejce kilka sekund, ale może dłużej.

Kilka zasad z dokumentacji Google, które mają praktyczne skutki:

• przy kodzie innym niż 200, na przykład 404, Google może pominąć renderowanie;
• jeśli w pierwotnym kodzie HTML jest noindex, Google może nie uruchomić JavaScriptu, więc usunięcie tego znacznika skryptem może nie zadziałać;
• Google nie wyrenderuje JavaScriptu z plików ani stron zablokowanych w robots.txt;
• przy indeksowaniu dla wyszukiwarki Googlebot pobiera pierwsze 2 MB pliku HTML i każdego zasobu, takiego jak CSS czy JavaScript, oraz pierwsze 64 MB pliku PDF. Limit dotyczy danych po rozpakowaniu.

Wiele poradników podaje 15 MB. To ogólny domyślny limit robotów Google, a dla Googlebota w wyszukiwarce dokumentacja podaje 2 MB. Większość stron jest od tego daleko, ale strona kategorii z setkami produktów wpisanych w kod albo z dużym blokiem danych w HTML może go przekroczyć. Po przekroczeniu limitu Googlebot przerywa pobieranie i do indeksowania przekazuje tylko pobraną część pliku.

Google zaznacza też, że renderowanie po stronie serwera albo wstępne renderowanie nadal ma sens: strona jest szybsza dla ludzi i robotów, poza tym część botów w ogóle nie uruchamia JavaScriptu.

Google-InspectionTool a Googlebot w Search Console

Test wersji opublikowanej w Search Console i test wyników z elementami rozszerzonymi nie używają Googlebota, tylko robota Google-InspectionTool. Jego user agent zawiera Google-InspectionTool/1.0. Według Google reguły dla tego robota w robots.txt dotyczą tylko narzędzi testowych i nie mają wpływu na wyszukiwarkę.

Z tego wynikają dwie sytuacje, które mylą właścicieli stron:

• test w Search Console nie przechodzi, bo zapora blokuje Google-InspectionTool, a Googlebot pobiera stronę normalnie;
• test przechodzi, a Googlebot ma problem, bo reguła na serwerze dotyczy tylko jego user agenta albo blokada działała akurat w chwili indeksowania.

Gdy wyniki testu i indeksu się nie zgadzają, porównaj logi serwera dla obu robotów. Jak czytać wynik z indeksu i test wersji opublikowanej, opisujemy w poradniku o sprawdzaniu adresu URL w Search Console.

Googlebot a przegląd od AI

Przegląd od AI i tryb AI w wyszukiwarce korzystają z tego samego indeksu co zwykłe wyniki. Według Google strona musi być zindeksowana i móc wyświetlić się w wyszukiwarce z fragmentem opisu, a witryna musi być włączona do funkcji generatywnej AI w ustawieniach Search Console. Google nie pobierze treści strony niedostępnej dla Googlebota, więc nie pokaże jej w odpowiedziach AI. Sam adres może się pojawić w zwykłych wynikach, jeśli prowadzą do niego linki z innych stron. Blokada Google-Extended tego nie zmienia, bo nie dotyczy wyszukiwarki.

Dostęp robota do strony głównej ma też drobniejsze skutki. 27 października 2026 roku Google uzupełnił dokumentację favikon: Googlebot musi móc pobrać stronę główną i przejść jej przekierowania aż do strony, na której jest wskazana favikona, a sam plik favikony musi być dostępny dla Googlebot-Image.

Co sprawdzić na swojej stronie

1. Wyszukaj w logach serwera wpisy z „Googlebot” w user agencie i zweryfikuj kilka adresów IP poleceniem host.
2. Jeśli korzystasz z Cloudflare, sprawdź, czy w ustawieniach Search i Training nie są włączone opcje „Block” albo „Block on pages with ads”.
3. Upewnij się, że zapora i wtyczka bezpieczeństwa nie blokują ruchu z USA ani robotów Google.
4. Sprawdź w statystykach indeksowania stan hosta i odpowiedzi serwera z ostatnich 90 dni.
5. Zrób test wersji opublikowanej dla kilku ważnych stron i porównaj zrzut ekranu z tym, co widzisz w przeglądarce.

Jeśli logi, raporty i testy mówią co innego albo nie masz dostępu do logów, sprawdzimy to w ramach audytu SEO i GEO.