Czym jest Googlebot? Crawl, render i index – wyjaśnienie

TL;DR. Googlebot to nie jeden bot, lecz cała rodzina crawlerów, a Googlebot Smartphone obsługuje dziś niemal wszystko, odkąd w 2023 r. domyślnym trybem stało się indeksowanie mobile-first. Proces przebiega w trzech fazach (crawl, render, index), oddzielonych od siebie nawet o kilka godzin czy dni, a to właśnie w fazie renderowania kryje się większość problemów typu „Googlebot nie widzi mojej strony”. Z ticketów wsparcia obsłużonych w SEOJuice od połowy 2024 do początku 2026 r. wynika, że ok. 60 % eskalacji dotyczyło renderowania; tylko ok. 20 % było prawdziwymi błędami fazy crawl (reszta to tagi noindex lub złe reguły w robots.txt). Ten poradnik omawia rodzinę botów, trzyetapowy pipeline, weryfikację prawdziwych żądań Googlebota, kwestie robotów i budżetu crawl, a także porównuje Googlebota z Bingbotem, GPTBotem, PerplexityBotem i ClaudeBotem w 2026 r.

Aktualizacja: maj 2026 r. Uzupełniono o dane z wewnętrznego miksu ticketów SEOJuice, anegdotę o awarii wynikłej z „bot-fight” w Cloudflare i odnośnik w sekcji o botach AI do wcześniejszych w artykule trybów awarii renderowania JS.

Napisałem to, bo trzy–cztery razy w tygodniu w Intercomie wysyłam ten sam wyjaśniacz. Klient mówi: „Googlebot jest zablokowany na mojej stronie”. Otwieramy Search Console. Crawl jest w porządku. Zawaliła się faza renderowania, odkąd tydzień temu deweloper przepisał tab-panel i nie zauważył, że treść artykułu montuje się dopiero po kliknięciu. Chciałem mieć jeden URL do wklejenia w tickecie zamiast pisać ten sam akapit kolejny raz. To właśnie ten URL.

Co to właściwie jest Googlebot (po ludzku)

Googlebot to program, za pomocą którego Google pobiera strony WWW, by móc dodać je do indeksu. Gdy publikujesz wpis na blogu, a on w końcu pojawia się w wynikach wyszukiwania, podróż zaczyna się od tego, że Googlebot żąda adresu, pobiera HTML, wykonuje JavaScript i przekazuje rezultat do systemu indeksowania. Bez Googlebota Twoje strony nie istnieją z perspektywy wyszukiwarki Google.

Na wstępie dwie ważne uwagi. „Googlebot” bywa używany luźno jako określenie dowolnego crawl era Google. Ściśle rzecz biorąc, Googlebot to ten crawler, który pobiera strony do głównego indeksu wyszukiwarki. Istnieją inne boty Google (AdsBot do oceny stron docelowych reklam, Storebot do ofert Shopping, Google-Extended do wyłączania treści z treningu AI) i każdy działa według innych reguł i harmonogramu. Przy debugowaniu precyzuj, o którego chodzi.

Googlebot to też nie scraper. Przed każdym crawl em czyta plik robots.txt, respektuje meta noindex, zwalnia, gdy serwer spowalnia, i identyfikuje się w nagłówkach żądania, dzięki czemu możesz zweryfikować, że to naprawdę Google. Jeśli w logach widzisz „Googlebota”, który bombarduje origin bez odpuszczania, niemal na pewno to nie jest prawdziwy Googlebot. Zweryfikuj go, zanim go ograniczysz.

Googlebot to tak naprawdę rodzina crawlerów

Botem, o którym musisz myśleć w pierwszej kolejności, jest Googlebot Smartphone, który od połowy 2023 r. domyślnie crawluje mobilną wersję Twojej witryny. Crawl desktopowy wciąż występuje, ale jest drugorzędny. Oto drzewko rodzinne z dokładnymi user-agentami podawanymi przez Google:

Symbol W.X.Y.Z w UA Smartphone i Desktop nie jest literalny. Google podstawia rzeczywistą wersję Chromium w momencie żądania i aktualizuje ją, by nadążała za stabilnym Chrome’em. Obecnie silnik renderujący Googlebota jest zaledwie kilka tygodni za publicznym Chrome’em. (Przez lata mówiłem klientom, by traktowali renderer Googlebota jak Chrome 41, bo do aktualizacji „evergreen” w 2019 r. faktycznie tak było. Jeszcze w 2021 r. powtarzałem tę przestarzałą poradę, zanim prezentacja Martina Splitta w „Search Off the Record” zmusiła mnie do przeczytania aktualnej dokumentacji). Jeśli Twoja strona używa funkcji JS wymagającej Chrome 130+, Googlebot ją obsłuży; jeśli wymaga czegoś, czego jeszcze nie ma w stabilnej wersji, nie obsłuży.

Trzyetapowy pipeline: crawl, render, index

Praca Googlebota dzieli się na trzy odrębne fazy. Nie zachodzą one jednocześnie i opóźnienie lub błąd w którejkolwiek z nich może wykluczyć stronę z wyników. Dokumentacja Google opisuje to klarownie: „Google przetwarza aplikacje JS w trzech głównych etapach: 1. Crawling 2. Rendering 3. Indexing.” Jeśli nie potrafisz nazwać fazy, w której tkwi problem, zgadujesz z naprawą. Na tym rozróżnieniu opiera się cały ten artykuł.

Faza 1: Crawling

Googlebot wybiera URL z kolejki, wysyła żądanie HTTP i odbiera surowy HTML. Tyle. JavaScript jeszcze nie działa, zawartość nie jest renderowana. Crawler czyta kod statusu, nagłówki (cache, X-Robots-Tag, przekierowania) oraz sam HTML. Źródłem URL-i są mapy XML, linki wewnętrzne z zaindeksowanych stron, linki zewnętrzne oraz zgłoszenia ręczne w narzędziu „Sprawdzenie adresu URL”.

Jeśli surowy HTML zawiera wszystko, co ma być zindeksowane (klasyczny SSR), Googlebot może przejść dalej. Jeśli jest prawie pusty, a treść wstrzykuje JS, wtedy wchodzi faza renderowania. To także w tym momencie Googlebot czyta robots.txt. Jeśli URL jest zabroniony, nawet go nie pobiera.

Faza 2: Rendering

Gdy do wyświetlenia treści potrzebny jest JS, Googlebot przekazuje URL do Web Rendering Service (WRS). WRS to bezgłowe Chromium, które ładuje stronę, uruchamia skrypty i tworzy finalny HTML. Dokumentacja mówi wprost: „Gdy zasoby na to pozwolą, headless Chromium renderuje stronę i wykonuje JavaScript.”

Fraza „gdy zasoby na to pozwolą” robi tu dużą robotę. Renderowanie jest kosztowne (pełna przeglądarka, JS, sieć), więc Google grupuje i kolejkuje te zadania. Strona może czekać w kolejce sekundy, godziny lub — w skrajnych przypadkach — dni. (Mam zrzut ekranu z 2024 r., pokazujący 96 godzin przerwy między crawl a render na audycie e-commerce Next.js; trzymam go przypiętego na Slacku, by wygrywać debatę, czy „strona została crawlowana” cokolwiek znaczy). Oficjalny komunikat jest celowo nieprecyzyjny: „Strona może pozostać w kolejce kilka sekund, ale może to zająć dłużej.” Co wciąż nie jest jasne, a docs tego nie wyjaśniają, to algorytm priorytetyzacji. Widziałem bliźniacze serwisy renderowane w 5 minut kontra 36 godzin i nigdy nie odkryłem kryterium.

To opóźnienie jest praktycznym problemem witryn renderowanych JS-owo. Post może być crawlowany w minuty, ale wyrenderowany po 24 h, więc treść trafia do wyników dopiero następnego dnia, choć Google „widzi” URL. Strony czysto SSR omijają tę kolejkę.

Faza 3: Indexing

Gdy Googlebot ma finalny HTML (z crawl lub z WRS), system indeksowania parsuje dokument, ekstraktuje tekst, klasyfikuje zawartość, ocenia sygnały rankingowe i zapisuje wszystko w indeksie. Od tego momentu strona może pojawić się w wynikach. Indeksowanie też nie jest natychmiastowe, trwa dodatkowe minuty lub godziny, ale rola Googlebota dla tego URL-a kończy się tutaj.

Co psuje renderowanie JS (i jak to wychwycić)

Problemy pojawiają się właśnie tu. Crawl prawie zawsze się udaje; strona po prostu nie renderuje się tak, jak oczekiwał deweloper. Poniższa szóstka to najczęstsze błędy, które widzę u klientów SEOJuice, w kolejności malejącej częstotliwości — punkty 1 i 2 odpowiadają łącznie za ponad połowę zgłoszeń renderowych z próby z TL;DR.

1. Treść wymagająca interakcji użytkownika

Jeśli kliknięcie „Pokaż więcej” jest jedynym sposobem na ujawnienie sekcji, Googlebot jej nie zobaczy. WRS uruchamia JS, ale nie klika i nie scrolluje. Ważne elementy muszą być w DOM przy ładowaniu, nawet jeśli schowane CSS-em. To absolutnie najczęstszy błąd, zwykle w bibliotekach komponentów, które leniwie montują zakładki, akordeony i feed „załaduj więcej”.

2. Lazy-loading bez prawidłowych sygnałów

Obrazy i bloki ładowane lazy potrzebują natywnego loading="lazy" lub Intersection Observer, który WRS potrafi obsłużyć. Niestandardowe biblioteki oparte na zdarzeniach scroll często zawodzą, bo WRS nie scrolluje. Używaj loading="lazy" dla obrazów; dla komponentów zapewnij render SSR lub framework z prawdziwym SSR/hydration.

3. Błędy JS w czasie wykonania

Gdy skrypt na górze strony rzuci nieobsłużony wyjątek, kolejne skrypty mogą się nie uruchomić, zostawiając pustą stronę. WRS zobaczy to, co zdążyło się wyrenderować przed wyjątkiem. Skorzystaj z „Wyświetl przetestowaną stronę” w URL Inspection, by zobaczyć HTML i zrzut ekranu Googlebota.

4. Reguły WAF i ochrona przed botami

CAPTCHA, zbyt agresywny Cloudflare Bot Fight Mode czy blokada geograficzna mogą zwrócić 403 lub stronę z wyzwaniem dla IP Google. (Domyślny bot-fight Cloudflare zepsuł więcej witryn w naszym logu incydentów niż jakiekolwiek inne ustawienie — pewien SaaS B2B stracił 2/3 zaindeksowanych stron w jeden weekend w 2024 r., gdy stażysta z security to włączył; odzysk zaj ął trzy tygodnie). Zawsze whitelistuj zweryfikowane zakresy IP Google (lista googlebot.json w dokumentacji) przed uruchomieniem „blokuj boty”. Po zmianach WAF sprawdzaj URL w Search Console.

5. Zasoby zablokowane w robots.txt

Jeśli w robots.txt blokujesz /static/ lub /assets/, WRS nie pobierze bundli JS/CSS, a strona wyrenderuje się bez stylów lub z popsutym JS. Pozwól Googlebotowi crawlować statyczne zasoby, nawet jeśli blokujesz inne ścieżki.

6. Treść za logowaniem lub cookies

Googlebot się nie loguje, nie obsługuje sensownie cookies i nie utrzymuje sesji. Wszystko za ścianą logowania nie będzie zindeksowane. Do treści płatnych użyj API indeksowania lub danych uporządkowanych i jawnie określ, co jest za paywallem.

Społeczność SEO w latach 2017–2020 debatowała, czy renderer Googlebota dogoni nowoczesnego Chrome’a. Debata zakończona — od przełączenia na „evergreen” w 2019 r. renderer śledzi stabilnego Chrome’a — ale wiele porad wciąż pochodzi sprzed tej zmiany, stąd wieczne punkty 1 i 2.

Jak zweryfikować, że żądanie naprawdę pochodzi od Googlebota

User-agent Googlebota można podrobić w sekundę. Każdy może wysłać żądanie udające Googlebota. Prawdziwe pochodzą z zakresów IP należących do Google. Pewna metoda to odwrotne DNS, potem zwykłe DNS. Google opisuje to w docsach, praktycznie wygląda to tak:

1. Weź IP z loga access.
2. Zrób reverse DNS. Host powinien kończyć się na .googlebot.com lub .google.com.
3. Zrób forward DNS tego hosta. Powinien wskazać to samo IP.
4. Jeśli oba kroki przejdą — to prawdziwy Googlebot. Jeśli któryś padnie — spoof.

Z konsoli: host 66.249.66.1 potem host crawl-66-249-66-1.googlebot.com. Przy dużym ruchu zautomatyzuj to w pipeline logów; zdziwisz się, ile „pików Googlebota” to w rzeczywistości scrapery z podrabianym UA. Ahrefs ma dobry walkthrough z przykładami curl, jeśli wolisz ich format.

robots.txt i budżet crawl: najczęstsze pytania

Ile Googlebot będzie crawlował moją stronę?

Google nazywa to budżetem crawl. Dla serwisów < 10 000 URL-i prawie nigdy nie stanowi to ograniczenia — Googlebot odwiedzi wszystko, co ważne, w rozsądnym czasie. Budżet staje się istotny dopiero przy milionach URL-i, faceted search w e-commerce czy duplikatach niskiej jakości. Google publikuje dwa czynniki: szybkość (ile Twój serwer uciągnie bez błędów) oraz popyt (popularność i częstotliwość zmian URL). Semrush ma dobre zestawienie sygnałów crawl-rate, jeśli chcesz zgłębić temat.

Czy blokować niskowartościowe URL-e?

Tak, jeśli uszczuplają budżet na dużym serwisie. Standard: zablokuj URL-e faceted search, wyniki wyszukiwania wewnętrznego, paginację powyżej 5. strony, warianty z ID sesji i endpointy admina. Użyj robots.txt do blokady crawl, a meta noindex do blokady indeksacji. To różne rzeczy: robots uniemożliwia nawet pobranie; noindex pozwala pobrać, ale nie indeksować.

Jak przyspieszyć indeksowanie nowej strony?

Zgłoś ją w narzędziu „Sprawdzenie adresu URL”. Wywoła to poza kolejką crawl (Google-InspectionTool, nie Googlebot) i jest szybsze niż czekanie na zwykły harmonogram. Dodaj też link z już zaindeksowanej, autorytatywnej strony, by kolejny crawl znalazł ją w grafie linków.

Dlaczego Googlebot crawluje mój dev/staging?

Bo gdzieś wyciekł link do publicznej sieci (przypadkowy link, wynik wyszukiwania, otwarty issue tracker), a Googlebot podąża za grafem linków. Zablokuj cały staging w robots.txt wpisem Disallow: / i dodaj podstawowe auth, jeśli treść jest wrażliwa.

Debugowanie problemów „Googlebot nie widzi strony”

Systematycznie robię cztery kroki — kolejno — aż jeden da jasną odpowiedź.

Krok 1: URL Inspection w Search Console. Wklej URL. Narzędzie pokaże, czy Google go crawluje i indeksuje, kiedy ostatnio, a „Wyświetl przetestowaną stronę” pokaże HTML i zrzut ekranu. Jeśli brakuje treści — problem w renderingu. Jeśli status ≠ 200 — problem w crawl. Z mojego doświadczenia to rozwiązuje ok. 2/3 śledztw.

Krok 2: curl z UA Googlebota. curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://twojastrona.com/ścieżka. Jeśli serwer zwraca inną treść Googlebotowi niż zwykłej przeglądarce, zobaczysz to. Cloaking (zamierzony lub nie) to częsta przyczyna zagadkowych problemów.

Krok 3: audit robots.txt i meta. Odwiedź https://twojastrona.com/robots.txt. Sprawdź, czy URL nie jest blokowany. Potem źródło strony → szukaj noindex. Zaskakująco dużo przypadków „nie chce się zindeksować” to przypadkowy noindex ze stagingu.

Krok 4: logi serwera. Przefiltruj access logi pod kątem zweryfikowanych IP Googlebota z 30 dni. Jeśli URL a brak — problem z odkryciem. Dodaj do mapy i zlinkuj. Jeśli jest, ale zwraca 4xx/5xx — napraw błąd i spróbuj ponownie. SEOJuice robi tę analizę i alarmuje, gdy kluczowy URL przestaje się pojawiać w prawdziwym ruchu Googlebota — zwykle łapiemy problemy, zanim odbiją się na rankingach.

Googlebot vs Bingbot vs boty AI

Kiedyś myślało się tylko o Googlebocie; to się zmieniło. Tak wypadają główne crawlery w 2026 r.:

Zwróć uwagę, że błędy 1, 2 i 5 z listy JS-renderu — ukryta za interakcją treść, lazy-load bez sygnałów i zablokowane zasoby statyczne — boleśniej trafiają boty AI niż Googlebota, bo ich renderery są słabsze. Ta sama checklista rozwiązuje problem cytatów Perplexity; stawka jest po prostu niższa niż w Google Search. (Zakładałem długo, że PerplexityBot zachowuje się jak Googlebot. Zweryfikowałem renderer dopiero, gdy witryna SSR klienta miała 4× więcej cytatów od konkurenta CSR).

Dwa wnioski praktyczne. Boty AI renderują JS słabiej. Jeśli Twoja treść zależy od CSR, możesz rankować w Google, a dla ChatGPT, Perplexity i Claude być niewidoczny — widzą pustą stronę. Lekarstwo to samo: SSR lub prerender. Nasz darmowy AI Visibility Checker w minutę pokazuje, które crawlery widzą Twoją treść. Po drugie, każdy bot AI ma własne dyrektywy robots.txt. User-agent: GPTBot blokuje trening OpenAI. User-agent: Google-Extended — Gemini. User-agent: Googlebot wciąż kontroluje zwykłą wyszukiwarkę. Chcesz być w Google, a nie w AI? Ustaw reguły osobno.

„Najczęściej pomijany fakt o Googlebocie: crawl i render to nie to samo. URL może być crawlowany, a pełnej wersji treści nadal nie będzie przez godziny.” — Martin Splitt, Google Search Relations, parafraza z Search Off the Record.

FAQ

Czym jest Googlebot?

To crawler Google do odkrywania i pobierania stron, by mogły trafić do indeksu. To rodzina botów (Smartphone, Desktop, Image, Video, News) z różnymi UA i celami, ale w praktyce „Googlebot” oznacza głównie Googlebot Smartphone, główny od czasu mobile-first 2023.

Czy Googlebot uruchamia JavaScript?

Tak. Web Rendering Service (headless Chromium) wykonuje JS na stronach, które go potrzebują. Wersja Chromium nadąża za stabilnym Chrome’em, więc nowoczesny JS zwykle działa. Haczyk: kolejka renderów — może to być sekunda, godziny, a czasem dni. Strony SSR omijają kolejkę.

Jak sprawdzić, czy żądanie jest naprawdę od Googlebota?

Reverse DNS IP → powinno kończyć się na .googlebot.com lub .google.com. Potem forward DNS tego hosta → powinien wrócić to samo IP. Jeśli coś nie pasuje, to spoof. Sam UA nie wystarcza.

Czy mogę zablokować Googlebota?

Tak. W robots.txt wpisz User-agent: Googlebot i Disallow: /. Blokuje to crawl, więc strona nie będzie indeksowana ani widoczna. Do precyzyjniejszej kontroli użyj meta noindex (pozwala crawlować, ale blokuje indeks). Nie blokuj CSS i JS potrzebnych do renderu.

Czy Googlebot to to samo co GPTBot lub PerplexityBot?

Nie. To osobne crawlery innych firm i celów. Googlebot indeksuje web dla Google Search. GPTBot zbiera dane treningowe ChatGPT. PerplexityBot pobiera treści do swojego engine’u. Każdy ma inny UA i własne zasady robots.txt. Możesz zezwolić Googlebotowi i zablokować GPTBota — ustaw reguły osobno.

Dlaczego Googlebot nie zindeksował mojej nowej strony?

Najczęstsze przyczyny: brak linku z indeksowanej strony (Googlebot nie zna URL-a), kod ≠ 200, meta noindex, blokada w robots.txt lub treść zależna od JS czekającego w kolejce render. Użyj URL Inspection — „Wyświetl przetestowaną stronę” pokaże, co widzi bot. Nowe strony trafiają do indeksu zwykle w kilka godzin–dni, dłużej na słabo crawlowanych witrynach.

Co to oznacza dla Twojej strony

Wniosek praktyczny: jeśli Twoja treść zależy od JS, a jedynym testem zdrowia jest „czy rankuje w Google”, optymalizujesz pod najsilniejszy renderer w ekosystemie, ignorując resztę. Boty AI są słabsze, a ich udział w ruchu rośnie co kwartał. SSR to już nie „optymalizacja pod Google” — to warunek widoczności w AI, i właśnie to warto zapamiętać.

Chcesz szybki test, które crawlery widzą Twoją stronę? Nasz darmowy AI Visibility Checker renderuje URL pod tymi samymi ograniczeniami, co Googlebot, GPTBot, PerplexityBot i ClaudeBot, i pokazuje, który widzi pustą stronę. W większości audytów co najmniej jeden kluczowy szablon (zwykle produkt lub blog) renderuje się w Google poprawnie, a w Perplexity — na biało.

Nad czym wciąż pracuję: logika priorytetyzacji kolejki renderów. Docs twierdzą, że zależy od zasobów, ale zmienność między bliźniaczymi serwisami sugeruje coś więcej. Jeśli masz czysty dataset „przed/po”, daj znać.

Powiązane materiały:

• SEO dla Single Page Applications
• Answer Engine Optimization (AEO)
• Darmowe narzędzie SEO Audit
• Darmowy AI Visibility Checker