Crawl budget – czym jest i jak usprawnić indeksowanie dużego serwisu?

Crawl budget staje się istotny wtedy, gdy roboty wyszukiwarki muszą wybierać między tysiącami lub milionami adresów URL, a serwis stale generuje kolejne strony. Samo zwiększenie liczby odwiedzin Googlebota nie wystarczy. Trzeba sprawić, aby robot częściej trafiał na wartościowe, aktualne i możliwe do zaindeksowania treści, zamiast zużywać zasoby na duplikaty, filtry, błędy i niekończące się kombinacje parametrów.

Po lekturze zrozumiesz:

• czym jest crawl budget i od czego zależy,
• czym różnią się crawling, renderowanie i indeksowanie,
• jak analizować aktywność Googlebota w logach i Google Search Console,
• jak ograniczać marnowanie zasobów indeksowania,
• jak zarządzać filtrami, paginacją, mapami XML i JavaScriptem,
• jak ustalać priorytety optymalizacji w dużym serwisie.

Crawl budget – co to jest?

Crawl budget, czyli budżet indeksowania lub budżet crawlowania, określa skalę i częstotliwość, z jaką robot wyszukiwarki może oraz chce pobierać adresy URL danego serwisu w określonym czasie.

Nie jest to jedna, stała liczba przydzielona domenie. Crawl budget powstaje w praktyce z połączenia dwóch mechanizmów:

• crawl capacity limit – technicznej liczby równoległych połączeń, które robot może wykonać bez przeciążania serwera,
• crawl demand – zapotrzebowania na ponowne odwiedzanie adresów wynikającego między innymi z ich popularności, aktualności, jakości oraz częstotliwości zmian.

W uproszczeniu:

crawl budget = możliwości techniczne crawlowania × zapotrzebowanie na crawl

Nawet bardzo wydajny serwer nie spowoduje intensywnego crawlowania milionów bezwartościowych stron. Z drugiej strony wartościowy i często aktualizowany serwis może być odwiedzany zbyt wolno, jeśli serwer odpowiada błędami lub generuje długie czasy odpowiedzi.

Crawlowanie, renderowanie i indeksowanie to różne procesy

Pojęcia te bywają stosowane zamiennie, ale opisują inne etapy:

1. Odkrycie adresu URL – wyszukiwarka poznaje adres z linku, mapy witryny lub innego źródła.
2. Crawlowanie – robot wysyła żądanie HTTP i pobiera dokument oraz wybrane zasoby.
3. Renderowanie – wyszukiwarka przetwarza stronę, w tym JavaScript, aby poznać jej końcową zawartość.
4. Indeksowanie – zawartość zostaje przeanalizowana i może zostać dodana do indeksu.
5. Ranking – zaindeksowana strona jest oceniana pod kątem konkretnych zapytań.

Zwiększenie częstotliwości crawlowania nie gwarantuje indeksacji. Adres może zostać pobrany, ale odrzucony jako duplikat, soft 404, strona niskiej jakości albo dokument bez wystarczającej wartości dla użytkownika.

Czego crawl budget nie oznacza?

Crawl budget nie jest:

• limitem liczby stron, które mogą znaleźć się w indeksie,
• bezpośrednim czynnikiem rankingowym,
• wynikiem widocznym jako jedna metryka w Google Search Console,
• gwarancją indeksowania wszystkich adresów z mapy XML,
• problemem, który da się rozwiązać wyłącznie szybszym serwerem,
• argumentem za blokowaniem każdego niepożądanego adresu w robots.txt.

Kiedy crawl budget ma znaczenie?

Większość małych witryn nie musi aktywnie zarządzać budżetem crawlowania. Jeżeli serwis ma kilkaset lub kilka tysięcy poprawnie połączonych stron, jego problemy z indeksowaniem częściej wynikają z jakości treści, błędów technicznych albo niewłaściwych dyrektyw.

Szczególnej analizy wymagają natomiast:

• sklepy internetowe z filtrami i sortowaniem,
• marketplace’y z milionami ofert,
• portale ogłoszeniowe,
• serwisy newsowe,
• witryny z dużym archiwum,
• katalogi produktów, firm lub lokalizacji,
• serwisy wielojęzyczne,
• platformy publikujące treści generowane przez użytkowników,
• strony korzystające z rozbudowanych parametrów URL,
• aplikacje tworzące treść głównie za pomocą JavaScriptu.

Za duży serwis można operacyjnie uznać witrynę, w której wyszukiwarka musi dokonywać realnego wyboru między adresami URL. Nie istnieje jednak jedna granica dla wszystkich domen.

Google wskazuje, że świadome zarządzanie crawl budgetem jest szczególnie istotne między innymi dla serwisów mających ponad milion unikalnych stron aktualizowanych przynajmniej raz w tygodniu oraz witryn liczących ponad 10 000 stron, jeśli ich treść zmienia się codziennie.

Problem może wystąpić wcześniej, gdy niewielka liczba wartościowych stron jest otoczona dużą liczbą kombinacji filtrów, parametrów i duplikatów.

Od czego zależy crawl budget?

Kondycja i wydajność serwera

Robot dostosowuje intensywność pobierania do reakcji infrastruktury. Jeśli serwer odpowiada szybko i stabilnie, liczba równoległych żądań może wzrosnąć. Jeżeli pojawiają się błędy, limity czasu lub przeciążenia, tempo crawlowania jest ograniczane.

Szczególnie ważne są:

• czas odpowiedzi serwera,
• udział odpowiedzi 5xx,
• liczba timeoutów,
• stabilność infrastruktury podczas wzrostu ruchu,
• prawidłowe wykorzystanie kodu 429,
• dostępność pliku robots.txt,
• wydajność API i usług niezbędnych do wygenerowania HTML.

Krótkotrwały wzrost błędów nie musi mieć długofalowych skutków. Regularne problemy mogą jednak obniżać zaufanie robota do wydajności hosta.

Zapotrzebowanie na ponowne crawlowanie

Nie wszystkie adresy są odwiedzane z taką samą częstotliwością. Większe zapotrzebowanie mogą generować strony:

• popularne i często linkowane,
• regularnie aktualizowane,
• związane z bieżącymi wydarzeniami,
• znajdujące się wysoko w strukturze serwisu,
• posiadające wiele linków wewnętrznych,
• zgłoszone w mapie XML z wiarygodnym lastmod,
• uznane za ważne na podstawie wcześniejszej aktywności.

Strona, której treść nie zmienia się przez kilka lat, zazwyczaj nie wymaga tak częstych wizyt jak karta produktu z dynamiczną ceną i dostępnością.

Jakość i unikalność treści

Duża liczba stron technicznie dostępnych nie oznacza, że wyszukiwarka będzie chciała je regularnie pobierać oraz indeksować.

Popyt na crawling może zostać ograniczony, gdy serwis zawiera dużo:

• duplikatów,
• thin contentu,
• pustych wyników wyszukiwania,
• stron wygasłych bez wartościowego zamiennika,
• automatycznie wygenerowanych kombinacji słów,
• podstron różniących się tylko drobnym elementem,
• stron uznawanych za soft 404.

Optymalizacja crawl budgetu jest więc również pracą nad wartością i strukturą serwisu, a nie tylko konfiguracją techniczną.

Struktura linkowania wewnętrznego

Linkowanie wewnętrzne pomaga robotowi:

• odkrywać nowe adresy,
• rozpoznawać hierarchię informacji,
• oceniać względną ważność stron,
• docierać do dokumentów znajdujących się poza mapą XML,
• ponownie odwiedzać kluczowe sekcje.

Adresy osierocone, czyli pozbawione linków wewnętrznych, mogą być znane wyszukiwarce z mapy XML, linków zewnętrznych lub wcześniejszych wizyt. Ich pozycja w architekturze pozostaje jednak niejasna.

Jak sprawdzić, czy serwis ma problem z crawl budgetem?

Nie należy diagnozować problemu wyłącznie na podstawie liczby niezaindeksowanych stron. Najpierw trzeba ustalić, na którym etapie procesu powstaje ograniczenie.

Sygnały ostrzegawcze

Potencjalny problem z crawlingiem może występować, gdy:

• nowe strony są odkrywane z dużym opóźnieniem,
• zaktualizowane treści długo nie pojawiają się w wynikach,
• Googlebot masowo odwiedza parametry i duplikaty,
• ważne strony są crawlowane rzadziej niż mało wartościowe,
• duża część żądań kończy się przekierowaniami lub błędami,
• w mapie XML znajdują się adresy, które przez długi czas nie są odwiedzane,
• serwer regularnie odpowiada kodami 429 lub 5xx,
• liczba wygenerowanych adresów wielokrotnie przewyższa liczbę wartościowych stron,
• sekcje położone głęboko w architekturze pozostają nieodkryte.

Samo „Odkryto – obecnie nie zindeksowano” nie dowodzi jeszcze wyczerpania crawl budgetu. Przyczyną może być również niska jakość, podobieństwo do innych dokumentów albo brak zapotrzebowania na indeksację.

Analiza crawl budgetu w Google Search Console

Raport statystyk indeksowania w Google Search Console pokazuje aktywność Googlebota na poziomie hosta lub usługi.

Warto analizować:

• łączną liczbę żądań,
• całkowity rozmiar pobieranych danych,
• średni czas odpowiedzi,
• odpowiedzi według kodów HTTP,
• typy pobieranych plików,
• cele wizyt, takie jak odkrycie lub odświeżenie,
• typy Googlebota,
• problemy z dostępnością hosta.

Dane należy interpretować w kontekście zmian wdrożeniowych i biznesowych. Spadek liczby żądań może oznaczać problem, ale może być też prawidłowym rezultatem usunięcia milionów duplikatów.

Ograniczenia Google Search Console

Raporty Search Console nie zastępują analizy logów, ponieważ:

• prezentują dane zagregowane,
• nie pokazują kompletnej listy odwiedzonych adresów,
• nie pozwalają dokładnie odtworzyć ścieżek robota,
• mogą obejmować różne rodzaje zasobów,
• nie pokazują wszystkich zależności między URL-em, szablonem i parametrami.

Do podejmowania decyzji na poziomie konkretnych wzorców adresów potrzebne są logi serwera lub dane z warstwy CDN.

Analiza logów serwera

Logi pokazują, o jakie zasoby robot rzeczywiście poprosił. To najważniejsze źródło danych przy optymalizacji dużego serwisu.

Analiza powinna odpowiadać na następujące pytania:

• Jakie katalogi są odwiedzane najczęściej?
• Jaki procent żądań dotyczy stron kanonicznych?
• Ile żądań trafia na filtry, sortowania i parametry?
• Jak często odwiedzane są nowe produkty lub artykuły?
• Które adresy zwracają 3xx, 4xx i 5xx?
• Jak długo robot czeka na odpowiedź?
• Czy aktywność koncentruje się na HTML, czy na zasobach?
• Czy ważne sekcje są odwiedzane regularnie?
• Jak wygląda różnica między liczbą adresów zgłoszonych, crawlowanych i indeksowanych?

Jak zweryfikować prawdziwego Googlebota?

Nie należy ufać wyłącznie nazwie user-agenta, ponieważ może zostać podszyta.

Weryfikację można przeprowadzić przez:

• porównanie adresów IP z oficjalnie publikowanymi zakresami,
• odwrotne zapytanie DNS,
• sprawdzenie, czy uzyskana domena należy do Google,
• ponowne rozwiązanie nazwy hosta do adresu IP.

Dopiero zweryfikowane wizyty powinny być wykorzystywane do oceny zachowania Googlebota.

Przydatne wskaźniki

W dużych serwisach warto zbudować własny dashboard zawierający między innymi:

Udział użytecznego crawlu

żądania do kanonicznych stron 200 / wszystkie żądania Googlebota do HTML

Udział zmarnowanego crawlu

żądania do duplikatów, błędów, parametrów i zbędnych przekierowań / wszystkie żądania do HTML

Czas pierwszego crawlu

Czas od publikacji adresu do pierwszej zweryfikowanej wizyty Googlebota.

Częstotliwość odświeżania

Mediana czasu między kolejnymi wizytami na tym samym adresie.

Pokrycie ważnych adresów

ważne adresy odwiedzone w okresie / wszystkie ważne adresy

Wskaźniki należy liczyć osobno dla typów stron, na przykład produktów, kategorii, artykułów, profili i ofert. Średnia dla całej domeny może ukrywać problem konkretnego szablonu.

Jak ustalać priorytety crawlowania?

Najważniejszym zadaniem nie jest wymuszenie większej liczby żądań, lecz skierowanie istniejącego zainteresowania robota na właściwe adresy.

Warto podzielić strony na grupy:

Priorytet wysoki

• nowe i aktualne treści,
• kategorie generujące ruch i sprzedaż,
• dostępne produkty,
• ważne strony lokalne,
• strony posiadające popyt organiczny,
• adresy z linkami zewnętrznymi,
• dokumenty często aktualizowane.

Priorytet średni

• starsze treści evergreen,
• produkty o mniejszym popycie,
• podkategorie wspierające architekturę,
• strony informacyjne o stabilnej zawartości.

Priorytet niski lub zerowy

• duplikaty,
• parametry śledzące,
• sortowania,
• puste filtry,
• wewnętrzne wyniki wyszukiwania,
• strony sesji i koszyka,
• nieograniczone kombinacje kalendarzy,
• techniczne warianty bez osobnej wartości,
• strony błędów i wygasłe oferty bez zamiennika.

Priorytety powinny wpływać na linkowanie wewnętrzne, mapy XML, sposób obsługi wygasłych adresów oraz dostępność kombinacji filtrów.

Architektura informacji i linkowanie wewnętrzne

Dobrze zaprojektowana architektura ogranicza liczbę kroków potrzebnych do dotarcia do wartościowych stron.

Spłaszczanie struktury bez utraty hierarchii

Celem nie jest umieszczenie wszystkich linków na stronie głównej. Chodzi o stworzenie czytelnej hierarchii:

• strona główna,
• główna kategoria,
• podkategoria,
• strona szczegółowa.

Ważne dokumenty powinny być osiągalne przez standardowe linki HTML i znajdować się możliwie blisko stron o dużym autorytecie wewnętrznym.

Używaj linków możliwych do crawlowania

Podstawą powinny być odnośniki w postaci <a href="...">. Element reagujący wyłącznie na zdarzenie JavaScript może nie zapewnić równie niezawodnej ścieżki odkrywania.

Dotyczy to zwłaszcza:

• paginacji,
• rozwijanych menu,
• przycisków „pokaż więcej”,
• wyników ładowanych po przewinięciu,
• list produktów i artykułów.

Eliminuj strony osierocone

Strona umieszczona tylko w mapie XML nie jest pełnoprawnym elementem architektury. Warto regularnie porównywać:

• adresy z map XML,
• adresy znalezione przez crawler,
• adresy odwiedzone przez Googlebota,
• adresy mające wyświetlenia,
• adresy znajdujące się w bazie serwisu.

Pozwala to wykryć strony osierocone oraz takie, które pozostają dostępne technicznie mimo usunięcia z nawigacji.

Parametry URL, filtry i nawigacja fasetowa

Nawigacja fasetowa jest jednym z najczęstszych powodów marnowania crawl budgetu.

Jeden katalog produktów może generować kombinacje oparte na:

• cenie,
• kolorze,
• rozmiarze,
• marce,
• dostępności,
• kolejności sortowania,
• liczbie elementów na stronie,
• parametrach kampanii,
• identyfikatorach sesji.

Nawet kilka filtrów może matematycznie utworzyć setki tysięcy adresów.

Które filtry powinny być indeksowane?

Indeksowalny filtr powinien zwykle spełniać kilka warunków:

• odpowiada na rzeczywisty popyt użytkowników,
• ma wystarczającą liczbę produktów lub ofert,
• prezentuje stabilną zawartość,
• może otrzymać unikalny tytuł, nagłówek i opis,
• ma stały, zrozumiały adres URL,
• jest wspierany linkowaniem wewnętrznym,
• nie powiela istniejącej kategorii.

Nie każda kombinacja posiadająca wolumen wyszukiwań zasługuje na osobną stronę. Trzeba również uwzględnić kanibalizację, trwałość asortymentu oraz możliwość utrzymania jakości.

Jak ograniczać niepotrzebne kombinacje?

Możliwe działania obejmują:

• usunięcie linków do bezwartościowych kombinacji,
• stosowanie jednej kolejności parametrów,
• eliminację parametrów sesyjnych,
• zamianę wartościowych filtrów na statyczne landing pages,
• użycie rel="canonical" dla rzeczywistych duplikatów,
• zastosowanie noindex tam, gdzie strona musi być dostępna dla użytkownika, ale nie powinna być indeksowana,
• blokadę crawlowania wybranych wzorców, jeśli robot nie musi odczytywać ich zawartości,
• zwracanie 404 dla niepoprawnych i nieistniejących kombinacji,
• ograniczenie liczby filtrów możliwych do jednoczesnego wybrania.

Nie należy automatycznie blokować całej nawigacji fasetowej. Niektóre kombinacje mogą stanowić wartościowe strony wejścia.

Robots.txt, noindex i canonical – różnice

Te mechanizmy rozwiązują odmienne problemy.

Mechanizm	Główne zastosowanie	Czy ogranicza crawl?	Czy usuwa z indeksu?
robots.txt	Blokowanie pobierania wzorca adresów	Tak	Nie gwarantuje usunięcia
noindex	Wykluczenie strony z indeksu	Nie od razu	Tak, po odczytaniu dyrektywy
rel="canonical"	Wskazanie preferowanej wersji duplikatu	Pośrednio	Konsoliduje sygnały, ale jest wskazówką
Przekierowanie 301/308	Trwała zmiana adresu	Pośrednio	Zastępuje stary adres docelowym
404/410	Informacja o braku zasobu	Z czasem	Tak

Dlaczego blokada w robots.txt może być błędem?

Jeśli adres zostanie zablokowany przed odczytaniem noindex, robot nie zobaczy dyrektywy. URL może nadal pojawiać się w indeksie na podstawie linków i innych sygnałów, choć bez rozpoznanej zawartości.

Typowa kolejność usuwania dużej grupy adresów wygląda następująco:

1. umożliwienie pobrania stron,
2. zastosowanie noindex lub właściwego kodu HTTP,
3. oczekiwanie na ponowny crawl i usunięcie z indeksu,
4. ewentualne ograniczenie dalszego crawlowania, jeśli adresy nadal muszą istnieć.

Canonical nie jest bezwzględną dyrektywą

Wyszukiwarka może wybrać inną stronę kanoniczną, jeśli sygnały są niespójne. Problemy pojawiają się, gdy:

• canonical wskazuje adres zwracający błąd,
• adres kanoniczny ma noindex,
• linki wewnętrzne prowadzą głównie do duplikatów,
• mapa XML zawiera wersje niekanoniczne,
• występują łańcuchy canonicali,
• treści nie są wystarczająco podobne.

Najlepszy efekt daje spójność wszystkich sygnałów: linków, map XML, przekierowań, canonicali i wersji indeksowalnej.

Kody HTTP i przekierowania

Każda niepotrzebna odpowiedź pośrednia zużywa czas oraz zasoby robota.

Odpowiedzi 200

Kod 200 powinien oznaczać, że pod adresem znajduje się prawidłowa strona. Zwracanie 200 dla pustego wyniku, usuniętego produktu lub komunikatu błędu może prowadzić do klasyfikacji jako soft 404.

Przekierowania 301 i 308

Stosuj je, gdy zasób ma trwały, znaczeniowo zbliżony odpowiednik. Unikaj:

• łańcuchów przekierowań,
• pętli,
• przekierowywania wszystkich usuniętych stron na stronę główną,
• kierowania produktów do przypadkowych kategorii,
• linkowania wewnętrznego do starych adresów.

Linki powinny prowadzić bezpośrednio do końcowego URL-a.

Błędy 404 i 410

Prawidłowy kod 404 nie jest wadą serwisu, jeśli zasób rzeczywiście nie istnieje. Kod 410 informuje, że został usunięty celowo, ale nie należy oczekiwać, że w każdej sytuacji wywoła natychmiastowe usunięcie z indeksu.

Błędy 429 i 5xx

Kod 429 informuje o zbyt dużej liczbie żądań, natomiast 5xx wskazuje problem po stronie serwera. Ich częste występowanie może ograniczać tempo crawlowania.

Nie należy używać 5xx do trwałego usuwania stron. Robot może potraktować taki stan jako awarię i ponawiać próby.

Mapy witryny XML

Mapa XML pomaga wskazać adresy, które powinny zostać odkryte i rozpatrzone do indeksowania. Nie jest jednak poleceniem zaindeksowania.

Co powinno znajdować się w mapie XML?

Do map należy dodawać przede wszystkim adresy:

• kanoniczne,
• indeksowalne,
• zwracające 200,
• istotne dla wyszukiwarki,
• zgodne z aktualną strukturą serwisu.

Nie powinny się w nich znajdować:

• przekierowania,
• strony 404 i 410,
• adresy z noindex,
• duplikaty,
• parametry techniczne,
• strony zablokowane w robots.txt,
• niekanoniczne warianty.

Podział map na segmenty

W dużym serwisie mapy warto dzielić według:

• typu treści,
• sekcji,
• języka lub kraju,
• daty publikacji,
• statusu produktu,
• poziomu biznesowego priorytetu.

Taki podział ułatwia porównywanie liczby zgłoszonych i zaindeksowanych adresów. Pozwala też zauważyć, że problem dotyczy na przykład wyłącznie ofert, profili użytkowników albo konkretnej wersji językowej.

Znacznik lastmod

lastmod powinien wskazywać datę istotnej zmiany treści, a nie moment każdego technicznego wygenerowania dokumentu.

Za istotną zmianę można uznać między innymi:

• aktualizację głównej treści,
• zmianę dostępności lub kluczowych danych produktu,
• istotną korektę artykułu,
• dodanie ważnej sekcji.

Automatyczne ustawianie bieżącej daty dla wszystkich URL-i osłabia wiarygodność sygnału. Pola priority i changefreq nie służą Google do ustalania priorytetów crawlowania.

Paginacja i nieskończone przewijanie

Każda strona paginacji powinna mieć stabilny adres URL i być dostępna przez link HTML.

W praktyce należy:

• zapewnić odnośniki do kolejnych stron,
• unikać uzależniania odkrywania wyłącznie od przewijania,
• stosować samodzielne canonicale na stronach paginacji, jeśli zawierają różne elementy,
• nie kierować canonicali ze wszystkich stron paginacji do pierwszej strony,
• ograniczyć puste i bardzo głębokie zakresy,
• zadbać, aby ważne elementy nie znajdowały się wyłącznie na końcu ogromnej listy.

Atrybuty rel="next" i rel="prev" nie są obecnie wykorzystywane przez Google jako specjalny sygnał indeksacyjny. Zwykłe, poprawne linki nadal mają znaczenie dla odkrywania.

JavaScript a crawl budget

Serwisy oparte na JavaScripcie mogą wymagać dodatkowego etapu renderowania. Nie oznacza to, że każda aplikacja SPA ma problem z indeksowaniem, ale zwiększa liczbę punktów awarii.

Najczęstsze problemy to:

• brak kluczowej treści w początkowym HTML,
• linki niewidoczne bez wykonania skryptu,
• blokowanie plików JS i CSS,
• błędy API podczas renderowania,
• generowanie innych adresów po stronie klienta i serwera,
• wymaganie interakcji użytkownika do załadowania treści,
• nieskończone przestrzenie URL tworzone przez router aplikacji.

Dla krytycznych treści warto rozważyć:

• renderowanie po stronie serwera,
• generowanie statyczne,
• rozwiązania hybrydowe,
• dostarczanie najważniejszej treści i linków w HTML,
• ograniczenie liczby zasobów niezbędnych do wyrenderowania strony,
• monitorowanie błędów renderowania oraz API.

Dynamiczne renderowanie nie powinno być domyślnym, długoterminowym obejściem źle zaprojektowanej aplikacji.

Wydajność serwera i optymalizacja pobierania

Szybszy serwer nie gwarantuje indeksowania, ale zwiększa techniczną zdolność do obsługi crawlowania.

Warto wdrożyć:

• cache pełnych stron lub ich fragmentów,
• CDN,
• optymalizację zapytań do bazy danych,
• eliminację zapytań typu N+1,
• ograniczenie niepotrzebnych wywołań API,
• kompresję odpowiedzi,
• stabilne skalowanie podczas wzrostu ruchu,
• poprawną obsługę ETag i Last-Modified,
• monitoring wydajności według szablonów.

Odpowiedź 304 może ograniczyć ilość przesyłanych danych, gdy zasób nie uległ zmianie. Nadal jest jednak żądaniem robota, dlatego mechanizmy warunkowego pobierania nie zastępują kontroli przestrzeni URL.

Core Web Vitals i crawl budget są odrębnymi zagadnieniami. Mogą korzystać z częściowo wspólnych usprawnień wydajnościowych, ale dobry wynik CWV nie gwarantuje większej częstotliwości crawlowania.

Zarządzanie wygasłymi produktami i ofertami

Masowe usuwanie adresów może prowadzić do utraty linków, sygnałów historycznych i ścieżek użytkowników.

Decyzję należy uzależnić od sytuacji:

• produkt chwilowo niedostępny – pozostaw stronę 200, pokaż status i alternatywy,
• produkt wróci do sprzedaży – zachowaj adres i treść,
• produkt ma bezpośredni odpowiednik – rozważ przekierowanie,
• produkt usunięty bez zamiennika – zwróć 404 lub 410,
• strona ma ruch i linki, ale produkt nie wróci – rozważ przekształcenie jej w wartościową stronę informacyjną,
• oferta wygasła, lecz dane mają wartość archiwalną – pozostaw indeksowalną stronę tylko wtedy, gdy faktycznie odpowiada na potrzeby użytkowników.

Nie należy przekierowywać wszystkich wygasłych produktów na kategorię lub stronę główną. Takie przekierowania mogą zostać potraktowane jak soft 404.

Serwisy wielojęzyczne i hreflang

Każda wersja językowa jest osobnym adresem, który musi zostać odkryty i pobrany. Dodawanie krajów oraz języków może więc wielokrotnie zwiększyć przestrzeń crawlowania.

Należy zadbać o:

• samodzielny canonical każdej wersji,
• wzajemne i zgodne oznaczenia hreflang,
• indeksowalność wszystkich adresów w zestawie,
• brak automatycznych przekierowań wyłącznie na podstawie IP,
• dostępność wersji przez zwykłe linki,
• spójność map XML i linkowania,
• brak pustych lub maszynowo powielonych lokalizacji.

Nie warto tworzyć wersji dla każdego kraju, jeśli treść, oferta i język nie różnią się w sposób użyteczny.

Tabela decyzyjna: jak reagować na problemy z crawlingiem?

Objaw	Co sprawdzić	Prawdopodobna przyczyna	Zalecane działanie
Nowe strony długo nie są odwiedzane	Logi, linkowanie, mapa XML	Strony osierocone lub niski priorytet	Dodaj linki z ważnych sekcji i umieść URL-e w odpowiedniej mapie
Googlebot odwiedza miliony filtrów	Logi według parametrów	Nieograniczona nawigacja fasetowa	Ogranicz linki i kombinacje, ustandaryzuj parametry
Adresy są crawlowane, ale nieindeksowane	Status indeksowania, treść, canonical	Duplikacja lub niska jakość	Popraw wartość strony, skonsoliduj duplikaty
Rośnie liczba odpowiedzi 5xx	Monitoring serwera i CDN	Przeciążenie lub błąd aplikacji	Napraw infrastrukturę, wdroż cache i skalowanie
Google wybiera inny canonical	Linki, mapy, przekierowania, treść	Niespójne sygnały kanoniczne	Ujednolić wszystkie sygnały i linkować do wersji docelowej
Mapy zawierają dużo niezaindeksowanych URL-i	Segmenty map XML	Niska jakość, błędy lub duplikaty	Oczyść mapy i analizuj typy stron osobno
Wygasłe produkty nadal pochłaniają crawl	Kody HTTP, linki, mapy	Strony pozostają w architekturze	Usuń linki i mapy, zastosuj 404, 410 lub trafne przekierowanie
Strony pojawiają się dopiero po wykonaniu JS	Renderowany HTML, API, linki	Zależność od renderowania klienta	Dodaj treść i linki do HTML lub zastosuj SSR
Zablokowane URL-e pozostają w indeksie	robots.txt, dyrektywy meta	Robot nie może odczytać noindex	Tymczasowo odblokuj crawl i udostępnij noindex
Ważne strony są położone bardzo głęboko	Crawl serwisu i liczba kliknięć	Zbyt głęboka architektura	Dodaj strony hub, linki kontekstowe i lepszą paginację
Duża część crawlu trafia na przekierowania	Logi 3xx i crawler	Stare linki oraz łańcuchy	Aktualizuj linki do końcowych URL-i
Spadła liczba żądań po usunięciu duplikatów	Pokrycie ważnych stron	Prawidłowa redukcja zbędnego crawlu	Oceniaj jakość crawlu, nie samą liczbę żądań

Najczęstsze błędy w optymalizacji crawl budgetu

Blokowanie wszystkich filtrów bez analizy

Część filtrów może odpowiadać na wartościowe zapytania. Masowa blokada może usunąć z architektury strony generujące ruch i sprzedaż.

Umieszczanie noindex w robots.txt

noindex nie jest obsługiwaną dyrektywą pliku robots.txt. Powinien zostać przekazany w kodzie HTML lub nagłówku X-Robots-Tag.

Blokowanie strony przed odczytaniem noindex

Jeśli robot nie może pobrać dokumentu, nie odczyta dyrektywy wykluczającej z indeksu.

Dodawanie wszystkich adresów do mapy XML

Mapa XML nie jest magazynem wszystkich URL-i wygenerowanych przez system. Powinna zawierać wyłącznie preferowane strony przeznaczone do indeksowania.

Odświeżanie lastmod bez zmiany treści

Sztuczne zmienianie daty może sprawić, że robot przestanie traktować ten sygnał jako wiarygodny.

Usuwanie paginacji przez canonical do pierwszej strony

Kolejne strony listy zawierają inne produkty lub artykuły. Canonical do strony pierwszej może utrudnić odkrywanie głębszych elementów.

Ocenianie efektu tylko liczbą wizyt Googlebota

Po optymalizacji liczba żądań może spaść, a indeksowanie ważnych stron może się poprawić. Liczy się udział użytecznego crawlu, nie maksymalizacja aktywności robota.

Próba wymuszania indeksacji pojedynczo

Ręczne zgłaszanie tysięcy adresów nie zastąpi poprawnej architektury. Interfejsy przeznaczone do zgłaszania wybranych typów treści również nie powinny być używane jako ogólny mechanizm indeksowania zwykłych stron.

Mity dotyczące crawl budgetu

Mit: każda witryna ma dzienny limit stron

Wyszukiwarka dynamicznie dostosowuje aktywność. Nie istnieje jedna publiczna, stała liczba przypisana domenie.

Mit: robots.txt usuwa stronę z wyników

Plik blokuje pobieranie, ale nie gwarantuje usunięcia adresu z indeksu.

Mit: sitemap wymusza indeksację

Mapa pomaga w odkrywaniu i monitorowaniu, lecz nie zastępuje jakości, unikalności i poprawnej architektury.

Mit: noindex natychmiast oszczędza crawl budget

Robot musi najpierw odwiedzić stronę i odczytać dyrektywę. Dopiero z czasem częstotliwość wizyt może się zmniejszyć.

Mit: szybszy serwer rozwiąże każdy problem

Wydajność poprawia zdolność do crawlowania, ale nie tworzy zapotrzebowania na pobieranie duplikatów i stron niskiej jakości.

Mit: duża liczba stron oznacza problem

Miliony wartościowych, dobrze zorganizowanych stron mogą być obsługiwane poprawnie. Problemem jest niekontrolowana i mało wartościowa przestrzeń URL.

Crawl budget w liczbach

Poniższe wartości pomagają projektować rozwiązania techniczne, ale nie stanowią gwarancji indeksowania:

• serwisy mające ponad 1 000 000 unikalnych stron, które zmieniają się przynajmniej raz w tygodniu, powinny szczególnie analizować crawl budget,
• podobna potrzeba może dotyczyć serwisów mających ponad 10 000 stron, jeśli treści zmieniają się codziennie,
• jedna mapa witryny może zawierać maksymalnie 50 000 adresów URL,
• nieskompresowana mapa XML może mieć maksymalnie 50 MB,
• plik robots.txt obsługiwany przez Google ma limit 500 KiB,
• Googlebot przetwarza pierwsze 15 MB pliku HTML lub obsługiwanego pliku tekstowego; zasoby takie jak obrazy i skrypty są pobierane osobno,
• Googlebot może podążyć za maksymalnie około 10 kolejnymi przekierowaniami, ale w praktyce należy dążyć do jednego kroku,
• raport statystyk indeksowania w Search Console prezentuje dane z okresu około 90 dni.

Nie istnieją uniwersalne wartości prawidłowego udziału crawlu, czasu odpowiedzi ani częstotliwości odwiedzin. Wewnętrzne cele należy wyznaczać osobno dla każdego typu strony.

Przykładowe operacyjne cele mogą obejmować:

• ograniczenie błędów 5xx dla wizyt robotów do poziomu bliskiego zeru,
• skrócenie mediany pierwszego crawlu nowych, priorytetowych stron,
• wzrost udziału żądań do kanonicznych dokumentów 200,
• spadek liczby żądań do parametrów technicznych,
• ograniczenie łańcuchów przekierowań do pojedynczego kroku,
• zwiększenie odsetka ważnych stron odwiedzonych w ustalonym okresie.

Plan optymalizacji crawl budgetu krok po kroku

Etap 1: zinwentaryzuj przestrzeń URL

Zbierz adresy z:

• bazy danych,
• map XML,
• crawl serwisu,
• logów,
• Search Console,
• systemów analitycznych,
• raportów linków zewnętrznych.

Następnie pogrupuj je według szablonu, parametrów, statusu HTTP, indeksowalności i wersji kanonicznej.

Etap 2: określ strony wartościowe

Ustal, które typy URL-i:

• odpowiadają na popyt,
• generują konwersje,
• mają unikalną treść,
• są aktualne,
• posiadają linki,
• powinny znaleźć się w wynikach wyszukiwania.

Bez tej klasyfikacji nie da się stwierdzić, czy crawl jest użyteczny.

Etap 3: znajdź największe źródła marnowania zasobów

Najpierw eliminuj problemy o największej skali:

• nieskończone kombinacje filtrów,
• parametry śledzące,
• duplikaty protokołów i hostów,
• błędne paginacje,
• masowe soft 404,
• łańcuchy przekierowań,
• stare środowiska testowe,
• kalendarze bez końcowej daty,
• strony wyszukiwania wewnętrznego.

Etap 4: ujednolić sygnały

Dla każdej strony przeznaczonej do indeksowania zadbaj o zgodność:

• kodu 200,
• braku noindex,
• dostępności dla robota,
• samodzielnego lub właściwego canonicala,
• obecności w mapie XML,
• linków prowadzących do wersji kanonicznej,
• spójnego adresu w danych strukturalnych i hreflang.

Etap 5: popraw odkrywanie stron priorytetowych

Wykorzystaj:

• strony-huby,
• kategorie i podkategorie,
• linkowanie kontekstowe,
• sekcje „powiązane”,
• poprawną paginację,
• segmentowane mapy XML,
• linki z często odwiedzanych stron.

Etap 6: monitoruj wdrożenie w logach

Porównaj okres przed i po zmianie. Analizuj nie tylko liczbę żądań, lecz także ich rozkład.

Dobra zmiana powinna prowadzić do:

• mniejszej liczby wizyt na duplikatach,
• szybszego odkrywania nowych stron,
• większego udziału crawlu stron kanonicznych,
• spadku błędów i przekierowań,
• stabilniejszego czasu odpowiedzi,
• lepszego pokrycia priorytetowych sekcji.

Etap 7: oceń efekt indeksacyjny i biznesowy

Celem nie jest poprawa wykresu aktywności robota sama w sobie. Ostatecznie należy sprawdzić:

• liczbę zaindeksowanych wartościowych stron,
• czas od publikacji do indeksacji,
• wyświetlenia i kliknięcia,
• widoczność nowych sekcji,
• konwersje organiczne,
• zmiany liczby duplikatów i stron niskiej jakości.

FAQ

Czy crawl budget wpływa bezpośrednio na pozycje?

Nie jest bezpośrednim czynnikiem rankingowym. Może wpływać pośrednio, jeśli ważne strony nie są odkrywane, odświeżane lub przekazywane do procesu indeksowania na czas.

Czy mały serwis powinien optymalizować crawl budget?

Zwykle wystarczy poprawna architektura, mapa XML, stabilny serwer i brak duplikatów. Zaawansowana analiza logów staje się potrzebna, gdy występują realne opóźnienia lub niekontrolowana liczba URL-i.

Jak zwiększyć crawl budget?

Nie ma jednego przełącznika. Należy poprawić stabilność serwera, ograniczyć zbędne URL-e, zwiększyć jakość treści, uporządkować linkowanie oraz konsekwentnie wskazywać wersje kanoniczne.

Czy usunięcie stron niskiej jakości pomaga?

Może pomóc, jeśli strony nie odpowiadają na potrzeby użytkowników i generują dużą liczbę zbędnych adresów. Nie należy jednak usuwać treści wyłącznie na podstawie braku ruchu bez oceny jej funkcji, sezonowości i znaczenia w architekturze.

Czy canonical oszczędza crawl budget?

Może z czasem ograniczyć crawlowanie duplikatów, ale robot musi okresowo odwiedzać różne wersje, aby zweryfikować relację. Skuteczniejsze jest również usunięcie zbędnych linków do duplikatów.

Czy nofollow ogranicza crawling filtrów?

Nie jest niezawodnym narzędziem do zarządzania crawl budgetem. Adres może zostać odkryty z innych linków, map, historii crawlowania lub źródeł zewnętrznych.

Czy można całkowicie zatrzymać crawlowanie parametrów?

Można blokować określone wzorce w robots.txt, ale decyzja wymaga analizy. Blokada uniemożliwia robotowi odczytanie zawartości, canonicala i noindex.

Czy wszystkie strony kanoniczne powinny znaleźć się w mapie XML?

Nie jest to bezwzględnie konieczne, ale w dużym serwisie warto umieszczać w mapach wszystkie ważne, kanoniczne i indeksowalne adresy. Ułatwia to odkrywanie oraz monitoring.

Jak często analizować logi?

W serwisach szybko zmieniających się monitoring powinien działać stale, a alerty mogą być generowane codziennie. Pogłębioną analizę warto wykonywać po migracjach, zmianach filtrów, wdrożeniach JavaScriptu i przebudowie architektury.

Po jakim czasie widać efekty optymalizacji?

Efekt techniczny może pojawić się w logach po kilku dniach, ale pełna zmiana wzorców crawlowania i indeksowania może wymagać kilku tygodni lub dłużej. Zależy to od skali witryny i częstotliwości wizyt robota.

Czy niski crawl oznacza karę?

Nie. Spadek aktywności może wynikać ze stabilnej treści, usunięcia duplikatów, niższego zapotrzebowania lub problemów serwera. Dopiero zestawienie logów, statusów indeksowania i jakości stron pozwala ustalić przyczynę.

Jaki jest najważniejszy wskaźnik crawl budgetu?

Nie ma jednej uniwersalnej metryki. Najbardziej użyteczne jest połączenie udziału crawlu kanonicznych stron 200, czasu pierwszej wizyty, pokrycia priorytetowych URL-i oraz liczby żądań marnowanych na duplikaty i błędy.

Podsumowanie

Optymalizacja crawl budgetu polega na zarządzaniu przestrzenią URL, jakością stron oraz techniczną dostępnością serwisu. Największe efekty daje zwykle nie zwiększanie liczby wizyt robota, lecz eliminowanie adresów, których nie powinien regularnie pobierać.

W dużym serwisie należy połączyć dane z logów, Google Search Console, map XML, crawlera i bazy aplikacji. Następnie trzeba wskazać strony priorytetowe, ograniczyć duplikaty, uporządkować filtry, skrócić przekierowania, poprawić linkowanie i zapewnić stabilną infrastrukturę.

Dobrze wykorzystany crawl budget oznacza, że wyszukiwarka szybciej odkrywa i odświeża najważniejsze treści, a mniej zasobów przeznacza na techniczne warianty, błędy oraz strony bez wartości indeksacyjnej.