Indeksacja i Crawl Budget — Przewodnik

Możesz mieć świetną treść i mocne linki, ale jeśli Google nie odwiedzi, nie wyrenderuje i nie zaindeksuje Twojej strony, dla wyszukiwarki ona po prostu nie istnieje. W tym przewodniku pokazuję, jak działa łańcuch crawl → render → index, czym naprawdę jest crawl budget i kiedy ma znaczenie, jak czytać raport indeksacji w Search Console i jak świadomie kierować uwagę Googlebota tam, gdzie jest wartość. To wiedza, którą wykorzystuję w każdym audycie SEO — bo porządek w indeksacji to najtańszy i najszybszy zysk widoczności, jaki znam.

Crawl, render, index — trzy etapy jednej drogi

Zanim Twoja strona pojawi się w wynikach, Google musi wykonać trzy oddzielne kroki. Crawl to odwiedzenie adresu przez Googlebota i pobranie surowego kodu HTML. Render to wykonanie tego kodu — w tym JavaScriptu — by zobaczyć treść taką, jaką widzi użytkownik. Index to świadoma decyzja, by zapisać stronę w bazie i dopuścić ją do rankingu. Każdy z tych etapów może się zatrzymać niezależnie od pozostałych, dlatego diagnozę zawsze zaczynam od ustalenia, na którym z nich coś się psuje.

Najczęstsze nieporozumienie polega na traktowaniu tych etapów jak jednej czynności. Strona może być zcrawlowana, ale nieindeksowana — bo Google uznał ją za duplikat lub treść zbyt cienką. Może być zaindeksowana, ale w wersji sprzed renderu — bo treść doładowuje się dopiero po wykonaniu skryptów. Może wreszcie w ogóle nie zostać odwiedzona — bo nie prowadzą do niej żadne linki. Bez rozróżnienia tych przypadków łatwo „naprawiać” problem, którego nie ma, a prawdziwą przyczynę zostawić nietkniętą. Pełną mapę warstw technicznych, w które wpina się indeksacja, opisuję w przewodniku po technicznym SEO.

Warto pamiętać, że render kosztuje Google realne zasoby. Googlebot crawluje natychmiast, ale render bywa odroczony do osobnej kolejki, czasem o dni. Dla treści krytycznej dla SEO oznacza to jedną praktyczną regułę: im więcej kluczowego tekstu jest w surowym HTML-u od razu, a im mniej zależy od JavaScriptu po stronie klienta, tym szybciej i pewniej trafia do indeksu. To dlatego renderowanie po stronie serwera tak mocno wpływa na tempo indeksacji nowych podstron.

Czym jest crawl budget i kiedy naprawdę ma znaczenie

Crawl budget to praktyczny limit adresów, które Googlebot odwiedzi w Twoim serwisie w danym okresie. Składa się z dwóch elementów: crawl rate limit (ile robot może odwiedzić, by nie obciążyć serwera) i crawl demand (jak bardzo Google chce odwiedzać Twoją stronę — w zależności od jej popularności i świeżości). W praktyce budżet to wypadkowa tego, jak szybko odpowiada Twój serwer i jak wartościowa jest Twoja domena w oczach wyszukiwarki.

Najważniejsza prawda o crawl budgecie jest taka: dla większości stron w ogóle nie jest problemem. Serwis do kilku tysięcy adresów Googlebot odwiedza regularnie i niemal w całości — limit nie jest tu wąskim gardłem, a czas lepiej poświęcić na treść i Core Web Vitals. Crawl budget staje się krytyczny dopiero przy skali: w dużych sklepach, portalach ogłoszeniowych, agregatorach i serwisach z setkami tysięcy adresów. To dlatego, zanim zacznę „optymalizować budżet”, zawsze pytam, czy serwis w ogóle jest w klasie, w której to ma sens.

Problem pojawia się, gdy serwis generuje ogromne ilości bezwartościowych adresów. Filtry i parametry w sklepie potrafią z kilkuset produktów zrobić setki tysięcy unikalnych URL-i — każda kombinacja koloru, rozmiaru, sortowania i ceny to osobny adres. Googlebot odwiedza je wszystkie, marnując budżet na warianty tej samej strony, zamiast docierać do nowych produktów i ważnych aktualizacji. To klasyczny scenariusz, w którym widoczność cierpi nie przez słabą treść, lecz przez bałagan w architekturze adresów. Mechanizm pułapki filtrów rozkładam szczegółowo w artykule o nawigacji fasetowej.

Raport indeksacji w Search Console — jak go czytać

Google Search Console to pierwsze miejsce, do którego sięgam, i raport „Indeksowanie stron” (dawniej „Stan”) jest tu najważniejszy. Dzieli on wszystkie znane Google adresy na dwie grupy: „Zaindeksowane” i „Niezaindeksowane”, a każdą podzieloną na konkretne przyczyny. To nie jest abstrakcyjny wykres — to lista do działania. Każda kategoria mówi dokładnie, dlaczego dany zbiór adresów nie trafia do indeksu, i co trzeba z tym zrobić.

Czytając ten raport, szukam trzech rzeczy naraz. Po pierwsze, czy liczba zaindeksowanych stron odpowiada liczbie stron, które naprawdę chcę mieć w indeksie — duża nadwyżka to znak, że indeksują się śmieci, a duży niedobór, że coś blokuje ważne adresy. Po drugie, które przyczyny wykluczeń rosną — trend jest ważniejszy niż pojedyncza liczba. Po trzecie, czy w „wykluczonych” nie siedzą strony, które powinny być w indeksie — to najczęstsze, ciche źródło utraconej widoczności. Narzędzie „Sprawdzenie adresu URL” pozwala potem prześwietlić pojedynczy adres: czy jest zcrawlowany, jak wygląda po renderze i którą wersję Google uznaje za kanoniczną.

Przyczyny wykluczeń — od czego naprawdę zależy indeksacja

Powody, dla których strona nie trafia do indeksu, dzielę na dwie rodziny: techniczne (Google nie może lub nie powinien) i jakościowe (Google może, ale nie chce). Pierwsza to przypadkowe blokady w robots.txt, błędne tagi noindex zostawione po wdrożeniu na środowisku testowym, błędna kanonikalizacja wskazująca na inny URL, łańcuchy przekierowań i kody błędów. Druga to cienka treść, duplikacja, niski autorytet adresu i brak sygnałów, że strona jest warta pokazywania. Rozróżnienie tych dwóch rodzin decyduje o tym, czy poprawiasz konfigurację, czy treść.

Najbardziej kosztowne są błędy ciche. Tag noindex zostawiony po migracji z developmentu potrafi przez tygodnie wycinać z indeksu całe sekcje serwisu, zanim ktokolwiek zauważy spadek ruchu. Podobnie canonical wskazujący na stronę główną z każdego adresu — częsty efekt źle skonfigurowanego CMS — sprawia, że Google indeksuje tylko jedną stronę zamiast tysięcy. Dlatego po każdym wdrożeniu sprawdzam te dwa elementy jako pierwsze: czy nie ma globalnego noindex i czy canonical wskazuje na samego siebie tam, gdzie powinien. Te same zasady są kluczowe podczas migracji, którym poświęcam osobny przewodnik o przekierowaniach i migracjach.

Optymalizacja crawl budgetu — gdzie odzyskuje się najwięcej

Optymalizacja budżetu to świadome kierowanie uwagi robota tam, gdzie jest wartość, i odcinanie go od tego, co bezwartościowe. Nie chodzi o to, by Googlebot odwiedzał więcej — chodzi o to, by odwiedzał właściwe rzeczy. W praktyce pracuję na pięciu frontach, które niemal zawsze dają największy zwrot w dużych serwisach. Poniżej rozkładam je na konkretne działania.

Duplikaty i kanonikalizacja to fundament. Zanim cokolwiek innego, upewniam się, że serwis ma jedną kanoniczną wersję każdego adresu i że wszystkie warianty (z www i bez, http/https, ze slashem i bez, z parametrami) prowadzą do niej przekierowaniem 301 lub tagiem canonical. Parametry URL to drugi front i zwykle największy — w sklepie to one generują eksplozję adresów. Tu decyzja jest strategiczna: które kombinacje filtrów mają wartość wyszukiwawczą i powinny być indeksowalne, a które to czysty szum do odcięcia.

Robots.txt jest narzędziem precyzyjnym, nie tępym. Blokuję w nim ścieżki czysto funkcyjne — koszyk, panel klienta, wewnętrzne wyniki wyszukiwania — które tylko marnują budżet, ale nigdy zasobów potrzebnych do renderu strony. Mapa witryny to z kolei pozytywny sygnał kierujący: lista adresów, które chcę przekazać do indeksacji, zawierająca wyłącznie strony kanoniczne ze statusem 200. Na końcu szybkość serwera — wolne odpowiedzi obniżają crawl rate, więc poprawa wydajności to nie tylko Core Web Vitals, ale i realnie więcej odwiedzonych stron. Ten związek rozwijam w artykule o optymalizacji Core Web Vitals.

Analiza logów serwera — jedyne źródło prawdy

Wszystkie raporty i intuicje bledną wobec logów serwera. Log to zapis każdego pojedynczego żądania, jakie trafiło do Twojego serwera: kto, jaki adres, kiedy i z jakim kodem odpowiedzi. Filtrując po user-agencie Googlebota, dostaję pełną, niezmanipulowaną prawdę o tym, na co robot naprawdę wydaje czas — a nie na co według nas powinien. To w analizie logów odkrywam rzeczy niewidoczne w żadnym innym narzędziu.

Z logów odczytuję kilka kluczowych rzeczy. Które sekcje serwisu Googlebot odwiedza najczęściej, a które ignoruje — często okazuje się, że robot obsesyjnie crawluje parametry filtrów, a do nowych kategorii zagląda raz na miesiąc. Jaki procent żądań trafia w kody 200, a jaki w przekierowania i błędy — to bezpośredni pomiar marnotrawstwa budżetu. Jak szybko Google odwiedza nowo dodane strony — miara tego, czy linkowanie wewnętrzne i sitemap działają. Dla dużych serwisów analiza logów to nie luksus, lecz podstawowe narzędzie diagnostyczne, bez którego optymalizacja crawl budgetu jest zgadywaniem.

Strony osierocone i „discovered/crawled not indexed”

Strona osierocona to adres, do którego nie prowadzi żaden link wewnętrzny w serwisie. Googlebot porusza się po linkach, więc strona bez linków przychodzących jest dla niego praktycznie niewidoczna — nawet jeśli istnieje i ma świetną treść. Najczęściej są to stare produkty wycofane z kategorii, posty wypchnięte z paginacji bloga albo landing page'e, do których prowadziły tylko kampanie reklamowe. W indeksacji to ciche zjawisko: treść jest, ale dla wyszukiwarki jej nie ma.

Status „Discovered — currently not indexed” oznacza, że Google zna adres (np. z sitemap), ale jeszcze go nie odwiedził — to typowy objaw braku budżetu albo zbyt słabego linkowania wewnętrznego. Lekarstwem jest wzmocnienie ścieżek wewnętrznych do takich stron i poprawa wydajności serwera, nie zaś samo ponowne zgłaszanie URL. Z kolei „Crawled — currently not indexed” to inna historia: Google odwiedził, ocenił i świadomie odmówił indeksacji. To sygnał jakości, nie dostępu. Tu nie pomoże żaden trik techniczny — pomaga lepsza, unikalna treść, konsolidacja podobnych stron i mocniejsze linkowanie, które buduje autorytet adresu.

W praktyce traktuję te dwa statusy jak termometr zdrowia serwisu. Rosnące „discovered not indexed” mówi o problemie z budżetem i architekturą, rosnące „crawled not indexed” — o problemie z jakością i duplikacją. Diagnozę zaczynam od pytania, czy strony w tych grupach naprawdę powinny być w indeksie. Bardzo często okazuje się, że połowa z nich to warianty filtrów i duplikaty, których w ogóle nie chcemy indeksować — i wtedy „problem” jest w istocie poprawnym zachowaniem Google.

Duże serwisy i sklepy — gdzie crawl budget decyduje o wszystkim

W dużym e-commerce indeksacja przestaje być higieną, a staje się przewagą konkurencyjną. Sklep z kilkudziesięcioma tysiącami produktów i rozbudowaną nawigacją fasetową to środowisko, w którym crawl budget jest realnym wąskim gardłem. Jeśli Googlebot spędza 70% czasu na kombinacjach filtrów i parametrach sortowania, do nowych produktów dociera z opóźnieniem liczonym w tygodniach — a w sezonie to wprost utracony przychód. Dlatego w takich serwisach architektura adresów jest decyzją strategiczną, nie kosmetyczną.

Typowe wyzwania dużego serwisu to: eksplozja URL-i z faset, głębokie i nieskończone stronicowanie, duplikaty produktów dostępnych w wielu kategoriach, parametry trackingowe i sesyjne oraz strony wariantów (kolor, rozmiar) konkurujące o tę samą treść. Każde z nich ma sprawdzone rozwiązanie — od decyzji, które fasety indeksować, przez konsolidację wariantów canonicalem, po blokowanie ścieżek czysto funkcyjnych. Klucz to świadoma polityka: dla każdego typu adresu z góry wiadomo, czy ma być indeksowalny, kanoniczny do czegoś innego, czy całkowicie odcięty. Specyfikę faset i paginacji rozkładam na czynniki pierwsze w przewodniku o nawigacji fasetowej.

Proces — od czego zacząć i w jakiej kolejności

Porządkowanie indeksacji prowadzę zawsze w tej samej kolejności, bo każdy krok zmniejsza szum dla następnego. Nie ma sensu optymalizować crawl budgetu, dopóki nie wiesz, ile go ginie i gdzie — dlatego diagnoza wyprzedza działanie. Poniższa lista to dokładnie ta sekwencja, którą stosuję w audytach dużych serwisów.

1. Raport indeksacji. Co jest w indeksie, co wykluczone i z jakich przyczyn (Search Console). Trendy ważniejsze niż liczby.
2. Audyt blokad i tagów. Brak przypadkowych noindex i błędów w robots.txt; canonical wskazujący tam, gdzie trzeba.
3. Analiza logów. Na co Googlebot naprawdę wydaje budżet; udział kodów 200 vs przekierowania i błędy.
4. Duplikaty i parametry. Konsolidacja wersji, polityka filtrów i parametrów (zwłaszcza w sklepach).
5. Linkowanie wewnętrzne. Eliminacja stron osieroconych, spłaszczenie struktury, wzmocnienie ważnych adresów.
6. Sitemap i wydajność. Mapa tylko z kanonicznych 200; szybszy serwer = wyższy crawl rate.
7. Monitoring. Cykliczna kontrola raportu indeksacji i logów — indeksacja to higiena ciągła, nie projekt jednorazowy.

Podsumowanie

Indeksacja to pierwszy i najtańszy obszar, w którym odzyskuje się widoczność. Zanim zaczniesz walczyć o pozycje, upewnij się, że Google w ogóle widzi, rozumie i chce indeksować Twoje strony — bo treść niewidoczna dla wyszukiwarki nie istnieje. Łańcuch crawl → render → index, świadome zarządzanie crawl budgetem w dużych serwisach, uważna lektura raportu indeksacji i analiza logów to narzędzia, którymi domyka się tę warstwę raz, a potem utrzymuje w higienie.

Jeśli chcesz zacząć od konkretu, najwięcej zyskuje się zwykle na uporządkowaniu parametrów w sklepie i odzyskaniu zmarnowanego budżetu, a tuż obok na Core Web Vitals i wydajności serwera. Potrzebujesz pełnej diagnozy indeksacji i crawl budgetu? Napisz do mnie przez formularz kontaktowy, a o moim doświadczeniu przeczytasz na stronie o autorze.