Co to jest indeksowanie (crawling) w SEO? Jak boty wyszukiwarek odczytują Twoją witrynę

TL;DR: Crawl w SEO to etap wykrywania i pobierania. Googlebot znajduje URL, pobiera jego treść i może wyrenderować JavaScript. Sama weryfikacja crawla nie gwarantuje indeksowania ani pozycji w rankingu — najpierw ustal, czy problem wydarzył się na etapie crawl, renderowania, indeksowania czy rankingu, zanim zaczniesz zmieniać stronę.

Większość problemów z crawlowaniem diagnozuje się od złej strony. Strona znika z wyników wyszukiwania, ktoś wyciąga wniosek, że Google jej nie crawluje, i edytuje robots.txt. Tymczasem Google mógł już pobrać tę stronę i zdecydować, żeby jej nie indeksować, wybrać inny kanoniczny adres (canonical) albo stwierdzić, że nie ma powodów, by ją pozycjonować na sprawdzane zapytanie.

Crawl, render, index oraz rank to osobne „bramki”. Google oficjalnie umieszcza renderowanie w etapie crawlowania, ale rozdzielenie tych elementów na potrzeby diagnozy znacznie ułatwia namierzenie awarii technicznej.

Co w praktyce oznacza crawlowanie w SEO

Google Search Central definiuje crawling wprost:

„Crawling: Google pobiera tekst, obrazy i wideo ze stron, które znalazło w internecie, przy pomocy zautomatyzowanych programów nazywanych crawlerami.”

W praktyce crawling to wykrycie plus pobranie. Google dowiaduje się, że dany URL istnieje, i prosi o jego treść, aby później mogła zostać przetworzona.

Program, który wykonuje tę pracę, to Googlebot. Google opisuje go jako „znany też jako crawler, robot, bot lub spider”. Te nazwy odnoszą się do tego samego ogólnego typu oprogramowania: zautomatyzowanego programu, który pobiera strony i podąża za linkami, aby odkrywać kolejne URL-e.

Googlebot nie sprawdza Twojej witryny, klikając po niej „oczami” jak człowiek. On prosi o HTML i zasoby wspierające. Podczas etapu crawl Google może też wyrenderować stronę przy użyciu nowszej wersji Chrome i wykonać jej JavaScript. Ma to znaczenie, jeśli Twoje istotne treści, nawigacja lub linki wewnętrzne pojawiają się dopiero po uruchomieniu skryptów.

Jeszcze jedna rzecz jest łatwa do przeoczenia: Googlebot działa głównie na urządzeniach mobilnych. Google mówi: „Dla większości witryn Google Search przede wszystkim indeksuje wersję mobilną treści. W związku z tym większość żądań crawla Googlebota będzie wykonywana z wykorzystaniem mobilnego crawlera, a mniejszość — desktopowego”. Jeśli ważna treść istnieje na wersji desktop, ale jej brakuje w wersji mobilnej, udane testy desktop mogą dać Ci fałszywe poczucie bezpieczeństwa.

Wcześniej popełniłem błąd: naprawiałem „złą bramkę”. To, że URL nie pojawia się w wynikach wyszukiwania, nie dowodzi, że samo wykrywanie nie działa, a ponowne poproszenie o crawling nie naprawi duplikatów ani treści, które nie pomagają (irytująco częsta kategoria błędu).

Crawl, render, index i rank to różne zadania

1. Crawl: wykryj i pobierz

Googlebot najpierw musi wiedzieć, że dany URL istnieje. Po wykryciu próbuje pobrać surowy HTML strony i wymagane zasoby. Ograniczenie z robots.txt, błąd DNS lub sieci, timeout albo błąd po stronie serwera mogą zatrzymać proces na tym etapie.

Udało się pobrać — URL przechodzi pierwszą bramkę. Na tym koniec.

2. Render: wykonaj stronę

Google oficjalnie zawiera renderowanie w ramach crawl, ale warto testować je osobno (nie jako czwarty, oficjalny etap, jeśli być precyzyjnym). Google podaje, że podczas crawlowania wyrenderuje strony i uruchamia JavaScript przy użyciu nowszej wersji Chrome — podobnie jak normalna przeglądarka.

W przypadku aplikacji JavaScript Google opisuje działającą sekwencję jako crawling, rendering i indexing. Strony zwracające poprawną odpowiedź mogą trafić do kolejki renderowania, gdzie headless Chromium uruchamia ich JavaScript. Google Search korzysta z stale aktualizowanej (evergreen) wersji Chromium, a nie z przeglądarki zamrożonej na stałe.

To rodzi ważny podział diagnostyczny. Googlebot może pobrać stronę zwracającą HTTP 200, a jednocześnie nie zobaczyć jej finalnej treści. Zablokowane zasoby, błędy skryptów, opóźniona treść po stronie klienta albo linki pojawiające się dopiero po interakcji użytkownika mogą sprawić, że efekt renderowania pozostanie niekompletny.

3. Index: analizuj i zapisuj

Google definiuje indeksowanie jako analizę tekstu, obrazów i wideo na stronie oraz zapis informacji w indeksie Google. Podczas tego procesu Google ocenia też duplikaty i wybiera, który URL uznaje za kanoniczny.

Zacrawlowana strona nie jest automatycznie indeksowana. Dyrektywa noindex może wykluczyć ją z indeksu. Google może też odmówić indeksowania cienkich lub w dużej mierze zduplikowanych materiałów albo skonsolidować stronę pod innym URL-em kanonicznym. Nasz przewodnik po tym, jak działa indeksowanie w Google, omawia ten „handoff” dokładniej.

4. Rank i serwowanie: odpowiedz na zapytanie

Zindeksowane znaczy kwalifikujące się do wyświetlenia. Nie znaczy to, że będzie widoczne dla każdego wyszukiwania ani że zagwarantowana jest określona pozycja. Google nadal musi zdecydować, czy strona pasuje do zapytania i gdzie wyląduje wśród innych kwalifikujących się wyników.

• URL może zostać wykryty, ale nie uda się go poprawnie pobrać.
• Może zostać pobrany, ale wyrenderować się niepoprawnie.
• Może zostać wyrenderowany, ale wykluczony z indeksu.
• Może zostać zindeksowany, ale nie osiągnąć rankingu dla sprawdzanego zapytania.

Google daje właścicielom witryn przydatny test rzeczywistości: „Google nie gwarantuje, że będzie crawlować, indeksować ani serwować Twojej strony — nawet jeśli Twoja strona jest zgodna z Google Search Essentials.” Techniczna dostępność jest konieczna. To jednak nie obietnica włączenia do indeksu ani widoczności.

Jak Google odkrywa strony

Google nie zaczyna od kompletnego katalogu wszystkich URL-i w sieci. W dokumentacji wskazuje trzy główne ścieżki odkrywania:

1. Powracanie do znanych URL-i. Google wraca do stron, które wcześniej pobrało.
2. Podążanie za linkami. Google wyciąga link ze znanej strony i odkrywa jego docelowy adres.
3. Odczytywanie sitemap. Google przetwarza listy URL-i przesyłane przez właścicieli witryn.

Dlatego linkowanie wewnętrzne to infrastruktura, a nie dekoracja. Strona bez linków wewnętrznych prowadzących do niej jest osierocona (orphan). Może istnieć w CMS i pojawiać się w XML sitemap, a jednocześnie pozostawać odłączona od ścieżek, którymi Googlebot zwykle podąża.

Badanie Cyrusa Sheparda dotyczące ok. 23 milionów linków wewnętrznych w około 1,800 witrynach wykazało zależność kierunkową między linkami wewnętrznymi a kliknięciami z Google: „URL-e z 0–4 linkami wewnętrznymi otrzymały średnio 2 kliknięcia z Google Search, podczas gdy URL-e z 40–44 linkami wewnętrznymi otrzymały czterokrotnie więcej.” To były korelacje, nie dowód, że dodawanie linków mechanicznie mnoży ruch.

W badaniu stwierdzono też, że efekt odwraca się po mniej więcej 45–50 linkach wewnętrznych. Więcej nie zawsze oznacza lepiej. Wniosek praktyczny jest taki, że kluczowe strony potrzebują kilku istotnych ścieżek crawlowania, a nie tego, że każda strona ma dostać dziesiątki przypadkowych linków.

Na podstawie tego, co widzimy na stronach w SEOJuice, osierocone strony i słabe wewnętrzne ścieżki występują dużo częściej niż realne problemy z „mocą” crawlowania. Zwykle naprawa polega na podpięciu strony z powiązanej, już zindeksowanej treści i utrzymaniu jej w sitemap. Spójna struktura, taka jak content silos pod SEO, daje crawlerom powtarzalne trasy między stronami powiązanymi tematycznie.

Wcześniej traktowałem umieszczenie w sitemap jako mocniejszy dowód, niż jest w rzeczywistości. To potwierdza, że URL został przekazany do Google, a nie że Google go pobrało albo zindeksowało (przeceniałem sygnał). Sitemap pomaga w wykrywaniu, ale nie zastępuje linków wewnętrznych ani nie wymusza konkretnego rezultatu.

Dla pojedynczego nowego lub zaktualizowanego URL-a w Google Search Console w URL Inspection dostępna jest też akcja Request Indexing. Dodaje to prośbę do kolejki przetwarzania Google. To impuls, nie rozkaz.

robots.txt, noindex i nofollow robią różne rzeczy

robots.txt steruje pobieraniem

Plik robots.txt mówi crawlerom zgodnym z normami, do których ścieżek URL mogą uzyskać dostęp. Google podaje, że służy to głównie do zapobiegania przeciążaniu witryny przez żądania crawlera.

To nie jest niezawodne narzędzie do „usuwania”. Google w swojej dokumentacji robots.txt stwierdza, że „Strona zablokowana w robots.txt może nadal zostać zindeksowana, jeśli ma do niej link z innych witryn” i wprost nazywa ten plik „nie mechanizmem służącym do wykluczania stron internetowych z Google”. Google może wiedzieć, że zablokowany URL istnieje, nawet jeśli nie ma zgody na pobranie jego treści.

Sprawdzaj każdą ogólną regułę przed publikacją. Produkcyjny Disallow: / to bardzo mało tekstu i potrafi odebrać Googlebotowi dostęp do całej witryny. Generator robots.txt może pomóc w przygotowaniu pliku, ale jego wynik nadal trzeba przetestować względem Twoich kluczowych ścieżek.

noindex steruje kwalifikowalnością do indeksu

Użyj noindex, gdy Google może crawlowć stronę, ale nie powinno jej utrzymywać w wynikach wyszukiwania. Nie blokuj jednocześnie tego URL-a w robots.txt. Google musi pobrać stronę, aby przeczytać dyrektywę noindex.

Zastosowanie obu rozwiązań może dać efekt odwrotny do zamierzonej pewności. Ograniczenie crawla uniemożliwia Google zobaczenie instrukcji indeksowania, więc zablokowany URL może pozostać znany dzięki linkom zewnętrznym lub wewnętrznym.

nofollow to wskazówka na poziomie linku

Attribution nofollow nie jest zakazem crawlowania strony jako całości. Google traktuje je jako wskazówkę, a nie gwarantowaną blokadę. Nie powinno się go używać do ukrywania URL-a, ochrony prywatnych treści ani do zapewnienia wykluczenia z indeksu.

Żeby było ciekawiej, te czyste definicje robią się mniej komfortowe w nawigacji fasetowej (faceted navigation). Nie ma uniwersalnie bezpiecznego wzorca robots.txt dla każdej kategorii sklepów. Część przefiltrowanych URL-i spełnia różne, realne potrzeby wyszukiwania; inne tworzą w praktyce nieskończoną liczbę kombinacji. Blokowanie najpierw, a mapowanie wartości później jest ryzykowne (i tak, to jeden z obszarów, w których nie ufam naprawom „jedną linijką”).

Możliwe, że nie masz problemu z crawl-budgetem

Crawl budget to zestaw URL-i, które Google może i chce crawlowć. Google opisuje dwa elementy: limit możliwości crawlowania (uwzględnia równoległe połączenia, czas odpowiedzi i kondycję serwera) oraz crawl demand (zależny m.in. od rozmiaru witryny, częstotliwości aktualizacji, jakości, popularności i „świeżości” treści).

Brzmi to na tyle istotnie, że pewnie martwi każdego właściciela witryny. Ale progi Google mówią co innego.

„Jeśli Twoja witryna nie ma dużej liczby stron, które zmieniają się szybko, albo jeśli wydaje się, że Twoje strony są crawlowane tego samego dnia, w którym są publikowane, nie musisz czytać tego przewodnika.”

Google kieruje wskazówki dotyczące crawl-budgetu przede wszystkim do witryn z ponad milionem unikalnych stron zmieniających się mniej więcej co tydzień albo do witryn z ponad 10 000 unikalnych stron zmieniających się codziennie. Dla większości mniejszych witryn wystarczy utrzymanie sitemap i kontrola pokrycia indeksowania.

Jeśli publikujesz umiarkowaną liczbę URL-i i Google pobiera nowe strony szybko, przestań próbować optymalizować crawl budget. Napraw uszkodzone ścieżki wykrywania, przypadkowe dyrektywy, awarie renderowania, błędy serwera albo jakość treści. Dla naprawdę dużych lub wysoce dynamicznych witryn nasz przewodnik po optymalizacji crawl budget omawia trudniejsze przypadki.

Jak sprawdzić, co Google crawluje

Zacznij od URL Inspection

Dla pojedynczej brakującej strony URL Inspection w Google Search Console to najszybszy punkt startu. Może pokazać datę ostatniego crawlowania, czy crawl był dozwolony, status indeksowania oraz wybrany przez Google URL kanoniczny.

Traktuj te pola jak sekwencję. Jeśli crawl został zablokowany, napraw dostęp. Jeśli Google crawluje URL, ale wyklucza go z indeksu, kolejne żądanie crawla raczej nie rozwiąże problemu u źródła.

Użyj Crawl Stats do wzorców w skali całej witryny

Raport Crawl Stats pokazuje historię crawlowania Google, w tym liczby żądań, łączny rozmiar pobrań, średni czas odpowiedzi, odpowiedzi serwera, problemy z dostępnością, typy plików, cel crawlowania oraz typ Googlebota.

Google nazywa to raportem zaawansowanym i mówi, że witryny z mniej niż 1000 stron zazwyczaj nie potrzebują go. To ma sens. Po migracjach lub nagłych zmianach na poziomie całej witryny nadal go sprawdzam, ale nie jest to przydatny codzienny „wynikowy scoreboard” (więcej crawlowania nie oznacza automatycznie lepiej).

Użyj logów serwera do precyzyjnych żądań

Logi dostępu serwera rejestrują żądania, które faktycznie trafiły do Twojej infrastruktury. Mogą ujawnić, które URL-e pobiera Googlebot, jak często odwiedza poszczególne sekcje oraz czy parametry lub „śmieciowe” URL-e otrzymują uwagę, gdy cenne strony są rzadko odwiedzane.

Stringi user-agent dla Googlebota zawierają Googlebot/2.1, ale tekst w user-agent da się naśladować. Dla niezawodnej identyfikacji zweryfikuj podejrzane żądania jako Googlebot przez reverse i forward DNS, zamiast polegać wyłącznie na samym stringu.

Dla większości witryn prawdziwa aktywność Googlebota powinna być dość łagodna. Google mówi: „Dla większości witryn Googlebot nie powinien uzyskiwać dostępu do Twojej witryny częściej niż raz na kilka sekund średnio”.

Pięć typów awarii crawlowania SEO, które warto naprawić

1. Osierocone i prawie-osierocone strony

Osierocona strona nie ma żadnej ścieżki z linkowania wewnętrznego z reszty witryny. Prawie-osierocona może mieć jeden mało znany link z archiwum albo strony paginacji, którą Google rzadko ponownie odwiedza. Dodaj linki kontekstowe z odpowiednich, już zindeksowanych stron — zamiast polegać wyłącznie na sitemap.

Zwykle to pierwsza kwestia strukturalna, którą sprawdzam. URL istnieje, więc zespół zakłada, że witryna udostępnia go prawidłowo. To nie jest to samo.

2. Zablokowany JavaScript lub CSS

Google renderuje strony w Chromium. Jeśli robots.txt blokuje zasoby potrzebne do odsłonięcia treści lub nawigacji, żądanie HTML może się udać, ale wyrenderowana strona pozostanie niekompletna.

Porównaj wyrenderowane wyjście Google z tym, co widzą użytkownicy — szczególnie w aplikacjach renderowanych po stronie klienta, gdzie początkowy HTML zawiera niewiele treści „z krwi i kości”.

3. Nieskończone pułapki crawlowania

Filtry, parametry sortowania, kalendarze, strony wyszukiwania i identyfikatory sesji mogą generować ogromne liczby kombinacji URL-i o niskiej wartości. To staje się realnym problemem crawlowania na dużych witrynach.

Typowe sposoby naprawy to konsolidacja duplikatów przez kanoniczne adresy, ograniczanie kombinacji parametrów możliwych do crawl-u oraz blokowanie odpowiednich wzorców. Najpierw zmapuj, które kombinacje zasługują na indeksowanie, dopiero potem je ograniczaj — blanketowa reguła może usunąć wartościowe strony kategorii razem z tym „śmieciem”.

4. Wolne lub niewiarygodne serwery

Google dostosowuje możliwości crawlowania w odpowiedzi na stan serwera. Uporczywe timeouty, wolne odpowiedzi i błędy 5xx mogą sprawić, że Google ograniczy crawl. Crawl Stats mogą pokazać sumaryczne zmiany w czasie odpowiedzi, a logi wskażą szablony i URL-e, które je powodują.

5. Przypadkowe blokady produkcyjne

Sprawdź, czy reguły robots.txt z wersji staging nie trafiły na produkcję, czy nie ma globalnych dyrektyw noindex, zablokowanych assetów oraz ustawień CMS zaprojektowanych tak, by zniechęcić wyszukiwarki. To przyziemne awarie, ale z konsekwencjami na poziomie całej witryny.

Podczas migracji z seojuice.io do seojuice.com w styczniu 2026 r. traktowaliśmy discovery, fetching, wybór canonical i indeksowanie jako osobne checki. Przecrawlony URL na starym hoście nie dowodził, że jego zamiennik na nowym hoście został zindeksowany, a poprawny redirect nie dowodził, że Google jeszcze przełączyło canonical. Ta separacja uchroniła nas przed sprowadzeniem migracji do mylącego checkboxu „Google to widzi”.

Jesteśmy dwuosobowym zespołem — Lida i ja — więc kolejność diagnostyki ma znaczenie. Nie możemy spędzać dni na dopieszczaniu teorii o crawl-budget, gdy osierocona strona albo noindex na produkcji robią faktyczne szkody.

Jeśli te powtarzalne problemy są trudne do ręcznego monitorowania, SEOJuice ma darmowy plan — bez potrzeby podawania karty. Automatyzacja może dodać istotne linki wewnętrzne, a audyt strony oznaczy blokady robots.txt, tagi noindex i zablokowane zasoby. Potrafi naprawić albo wypunktować konkretne problemy na stronie; nie wymusi jednak na Google szybszego crawlowania, indeksowania strony ani przyznawania pozycji w rankingu.

Najczęściej zadawane pytania

Co to jest crawling w SEO?

Crawling w SEO to proces, w którym boty wyszukiwarek odkrywają i pobierają strony. Googlebot znajduje URL-e, wracając do wcześniej znanych stron, podążając za linkami oraz czytając sitemap. Udały crawl nie gwarantuje indeksowania ani pozycji w rankingu.

Jaka jest różnica między crawlingiem a indeksowaniem?

Crawling oznacza, że Google pobiera stronę. Indeksowanie oznacza, że Google analizuje stronę, ocenia jej canonical i może zapisać informacje w indeksie Google. Strona może zostać zcrawlowana, ale nie zindeksowana — np. przez noindex, duplikację, słabą jakość treści albo wybór canonical.

Co to jest web crawler, spider albo bot?

Web crawler to zautomatyzowany program, który odwiedza URL-e, pobiera treści i podąża za linkami, by znaleźć inne strony. Krawler Google to Googlebot. Crawler, spider, robot i bot to różne nazwy dla tego samego ogólnego typu oprogramowania.

Jak Google znajduje i crawluje moją stronę?

Google wraca do URL-i, które już zna, podąża za linkami z wcześniej znanych stron do nowych lokalizacji oraz czyta przesłane XML sitemap. Linki wewnętrzne dostarczają bezpośrednich ścieżek odkrywania, a sitemap dostarcza przydatną listę URL-i, które Google może uznać za kandydatów do crawlowania.

Czy robots.txt blokuje Google przed crawlingiem albo indeksowaniem?

robots.txt ogranicza crawling, a nie indeksowanie. Zablokowany URL może nadal pojawić się w Google, jeśli został wykryty dzięki linkom. Aby utrzymać crawlowalną stronę poza indeksem, użyj noindex i nie próbuj jednocześnie uniemożliwiać Google pobrania dyrektywy.

Jak mogę sprawdzić, co Google crawluje?

Użyj URL Inspection do statusu jednego URL-a, Crawl Stats do wzorców żądań i serwera w skali całej witryny oraz logów dostępu serwera do dokładnych URL-i, o które poprosił Googlebot. Razem te źródła pozwalają odróżnić realną awarię crawlowania od późniejszego problemu z renderowaniem albo indeksowaniem.