Jak zrozumieć i skutecznie zarządzać crawl budget

Googlebot nie ma obowiązku odwiedzić każdej strony w serwisie, a już na pewno nie musi zrobić tego wtedy, kiedy akurat opublikujesz nową kategorię, produkt albo artykuł. To najprostszy sposób myślenia o crawl budget: nie jako o magicznym limicie, który da się „podkręcić” jednym ustawieniem, ale jako o realnym zasobie. Google ma określoną chęć i możliwość crawlowania witryny. Jeżeli serwis podsuwa mu tysiące adresów z filtrów, sortowań, pustych kategorii, błędnych przekierowań i stron bez wartości, robot traci czas tam, gdzie biznes nic z tego nie ma.

W małym serwisie usługowym crawl budget zwykle nie jest problemem. Jeżeli masz 80 podstron i Google odwiedza nowe treści tego samego dnia, większy efekt da poprawa treści, linkowania wewnętrznego i intencji strony niż nerwowe grzebanie w robots.txt. Inaczej wygląda sytuacja w e-commerce, portalu ogłoszeniowym, serwisie newsowym albo dużej stronie programmatic SEO. Tam decyzja, czy Googlebot crawluje wartościowe adresy, czy śmietnik URL-i, może wpływać na szybkość indeksacji i widoczność całych sekcji.

Kiedy crawl budget naprawdę ma znaczenie

Crawl budget to w praktyce zestaw adresów URL, które Google może i chce pobrać z danego hosta. Składają się na to dwa mechanizmy: crawl capacity limit i crawl demand.

Pierwszy mówi o tym, ile Google może pobrać bez przeciążania serwera. Jeżeli witryna działa szybko i stabilnie, Google może pozwolić sobie na więcej równoległych pobrań. Jeżeli serwer odpowiada wolno, zwraca błędy 5xx albo często wpada w przeciążenie, robot zwalnia. I nie robi tego złośliwie. Po prostu nie będzie dobijał infrastruktury, która już ma problem.

Drugi element, crawl demand, dotyczy tego, czy Google w ogóle widzi powód, żeby wracać po kolejne adresy. Wpływa na to między innymi wielkość serwisu, częstotliwość zmian, jakość treści, popularność adresów i świeżość dokumentów. Strona, która publikuje nowe oferty codziennie, ma inny rytm crawlowania niż statyczna wizytówka firmy aktualizowana raz na pół roku.

W praktyce warto zajmować się crawl budgetem, gdy występuje przynajmniej jeden z tych sygnałów:

• serwis ma dziesiątki tysięcy lub setki tysięcy adresów URL;
• w Google Search Console rośnie liczba stron typu „Discovered – currently not indexed”;
• nowe produkty, kategorie lub artykuły czekają długo na pierwsze pobranie;
• logi serwera pokazują, że Googlebot masowo odwiedza filtry, parametry, sortowania albo stare adresy;
• crawl w narzędziu technicznym wykrywa tysiące duplikatów, przekierowań, soft 404 i stron bez treści;
• serwer regularnie zwraca 5xx, timeouty albo mocno wydłuża czas odpowiedzi.

Najważniejsza decyzja: nie optymalizuj crawl budgetu tylko dlatego, że brzmi technicznie. Jeżeli serwis ma kilka tysięcy stabilnych adresów i Google szybko widzi nowe treści, problem leży gdzie indziej. Crawl budget zaczyna boleć wtedy, gdy liczba adresów znacznie przekracza liczbę stron, które realnie powinny trafić do wyników wyszukiwania.

Dobry test jest prosty: porównaj liczbę wartościowych stron z liczbą URL-i dostępnych dla robotów. Jeżeli sklep ma 12 000 produktów i kategorii, ale przez filtry, sortowania, paginację i parametry generuje 800 000 adresów, Googlebot dostaje bałagan. Nie wie od razu, które adresy są istotne. A zanim to ustali, część budżetu może pójść w ślepe uliczki.

Co zjada crawl budget i jak to wykryć

Największym wrogiem crawl budgetu nie jest jedna źle ustawiona dyrektywa. Zwykle problem tworzy suma drobnych zaniedbań, które przez lata nikomu nie przeszkadzały, aż serwis urósł.

Pierwszy winowajca to duplikacja adresów URL. Typowy przykład z e-commerce: ta sama lista produktów dostępna pod wieloma wariantami adresu, bo użytkownik może sortować po cenie, popularności, dostępności, kolorze, rozmiarze i marce. Dla klienta to wygodne. Dla Googlebota — potencjalnie tysiące kombinacji, z których większość nie powinna być crawlowana ani indeksowana.

Drugi problem to parametry URL. Adresy z ?sort=, ?filter=, ?utm=, ?sessionid=, ?price_from= lub podobnymi dodatkami potrafią rozdmuchać serwis szybciej niż nowe treści. Nie każdy parametr jest zły. Parametr zmieniający realną zawartość strony może mieć sens. Parametr śledzący kampanię albo ustawiający kolejność produktów zwykle nie powinien tworzyć osobnego bytu dla Google.

Trzeci element to błędna obsługa usuniętych stron. Jeżeli produkt zniknął na stałe, a serwis nadal zwraca 200 OK z komunikatem „produkt niedostępny” albo pustą kartą, Google może potraktować to jako soft 404. Taka strona nadal może być crawlowana, mimo że nie ma wartości. Jeżeli produkt wróci za tydzień, można zostawić stronę i jasno pokazać niedostępność. Jeżeli asortyment został wycofany na zawsze, lepszą decyzją bywa 404 lub 410, ewentualnie przekierowanie do najbliższej sensownej alternatywy, ale tylko wtedy, gdy alternatywa naprawdę odpowiada intencji użytkownika.

Czwarty problem to łańcuchy przekierowań. Jedno przekierowanie 301 po migracji jest normalne. Trzy, cztery albo pięć przeskoków między starymi wersjami adresów to już marnowanie czasu robota i użytkownika. Po większej migracji warto sprawdzić, czy stare adresy prowadzą bezpośrednio do aktualnych odpowiedników, a nie przez historię wszystkich poprzednich wdrożeń.

Piąty problem to mieszanie narzędzi bez zrozumienia konsekwencji. robots.txt, noindex, canonical, sitemap i kody HTTP nie służą do tego samego.

Najprostsza praktyczna zasada:

• robots.txt blokuje crawlowanie, więc używaj go do sekcji, których Google nie powinien pobierać;
• noindex usuwa stronę z indeksu, ale Google musi ją najpierw pobrać, żeby zobaczyć tę dyrektywę;
• canonical pomaga skonsolidować duplikaty, ale nie jest rozkazem absolutnym;
• 404/410 są właściwe dla treści usuniętych na stałe;
• sitemap.xml powinna zawierać tylko adresy, które chcesz pokazać Google jako ważne i indeksowalne.

Najgorszy schemat, który często widać w praktyce: strona ma noindex, ale jednocześnie jest zablokowana w robots.txt. Google nie może wejść na adres, więc nie zawsze zobaczy noindex. Efekt bywa odwrotny od zamierzonego: adres może wisieć w wynikach jako URL bez opisu albo długo pozostawać w kolejce znanych adresów.

Jak to sprawdzić bez zgadywania? Zacznij od trzech źródeł.

Pierwsze to Google Search Console, szczególnie raport indeksowania i statystyki crawlowania. Szukaj tam wzrostów w grupach błędów, stron wykluczonych, soft 404 oraz adresów wykrytych, ale niezaindeksowanych. Nie oceniaj pojedynczego dnia. Patrz na trend: czy problem rośnie, czy jest stabilny, czy pojawił się po konkretnym wdrożeniu.

Drugie źródło to logi serwera. To najuczciwszy materiał, bo pokazuje, co Googlebot naprawdę pobierał. W logach warto rozdzielić:

• adresy z parametrami;
• kategorie, produkty, artykuły i strony statyczne;
• kody odpowiedzi 200, 3xx, 4xx, 5xx;
• częstotliwość odwiedzin nowych i starych URL-i;
• czas odpowiedzi serwera;
• ruch Googlebota na stronach zablokowanych, pustych albo mało wartościowych.

Trzecie źródło to crawl techniczny, na przykład wykonany narzędziem typu Screaming Frog, Sitebulb albo crawlerem własnym. Taki crawl nie zastąpi logów, ale pokaże architekturę: głębokość kliknięć, duplikaty title i H1, błędne canonicale, pętle przekierowań, osierocone strony, paginację i linkowanie wewnętrzne.

Priorytety są dość brutalne. Najpierw napraw błędy, które ograniczają dostęp do ważnych stron: 5xx, timeouty, błędne blokady w robots.txt, przypadkowe noindex, uszkodzone canonicale. Potem usuń marnowanie crawlu: parametry, sortowania, duplikaty, soft 404, łańcuchy przekierowań. Dopiero później dopieszczaj sitemapę i linkowanie wewnętrzne. Odwrotna kolejność wygląda ładnie w checklistach, ale w dużym serwisie potrafi nie dać żadnego efektu.

Jak uporządkować indeksowanie bez blokowania ważnych stron

Zarządzanie crawl budgetem nie polega na tym, żeby zablokować jak najwięcej adresów. To częsty błąd. Blokada jest łatwa, szybka i daje złudzenie kontroli. Problem w tym, że zła blokada może odciąć Google od stron, które powinny przekazywać sygnały, linkować dalej albo pokazywać relacje między produktami i kategoriami.

Najbezpieczniej zacząć od mapy decyzji dla typów URL-i. Nie analizuj każdego adresu ręcznie, jeżeli serwis ma 200 000 podstron. Grupuj je według wzorców.

Przykład:

• /produkt/nazwa-produktu/ — zwykle indeksowalne, jeżeli produkt istnieje i ma unikalną treść;
• /kategoria/buty-sportowe/ — indeksowalne, jeżeli ma popyt, ofertę i sensowną zawartość;
• /kategoria/buty-sportowe/?sort=price_asc — zwykle do ograniczenia;
• /kategoria/buty-sportowe/?kolor=czarny&rozmiar=42 — decyzja zależy od popytu i jakości strony;
• /search?q=... — najczęściej blokada crawlowania;
• URL-e z utm_source — nie powinny tworzyć osobnych adresów dla Google;
• stare produkty bez zamiennika — zwykle 404/410;
• stare produkty z dobrym zamiennikiem — 301 do najbliższej alternatywy, nie do strony głównej.

Największe znaczenie ma rozróżnienie filtrów indeksowalnych i nieindeksowalnych. W sklepie internetowym filtr „czarne sneakersy męskie 42” może mieć sens, jeśli ma wyszukiwania, produkty, unikalny opis, stabilny adres i miejsce w strukturze linkowania. Ale filtr „czarne sneakersy męskie 42 posortowane od najtańszych, widok 96 produktów, kampania newsletter” nie powinien udawać osobnej strony SEO.

Dobra procedura wygląda tak:

1. Zbierz typy URL-i z GSC, logów, crawla i sitemap.
2. Oceń intencję: czy użytkownik mógłby szukać tej strony w Google?
3. Sprawdź zawartość: czy strona ma unikalną wartość, produkty, tekst, linki i stabilny stan?
4. Wybierz mechanizm: indeksować, kanonikalizować, ustawić noindex, zablokować crawling, przekierować albo zwrócić 404/410.
5. Wdrożenie testuj na wzorcach, nie na pojedynczych przykładach.
6. Po wdrożeniu obserwuj logi i GSC, minimum przez kilka cykli crawlowania.

Nie ma sensu wrzucać do sitemap wszystkiego, co istnieje w bazie. Sitemap.xml powinna być listą adresów, które chcesz mieć crawlowane i potencjalnie indeksowane. Jeżeli sitemap zawiera strony z noindex, przekierowania, 404, adresy kanoniczne do innych URL-i albo warianty filtrowania bez wartości, wysyłasz Google sprzeczny sygnał: „to ważne, ale jednak nie używaj”.

Przy dużych serwisach sitemapę warto dzielić logicznie, na przykład:

• sitemap-products.xml;
• sitemap-categories.xml;
• sitemap-blog.xml;
• sitemap-images.xml, jeżeli ma to sens;
• osobne sitemapy dla wersji językowych lub rynków.

Dzięki temu łatwiej sprawdzić, czy Google ma problem z konkretnym segmentem. Jeżeli sitemap produktów ma 80 000 adresów, a indeksuje się tylko niewielka część, trzeba sprawdzić jakość kart, dostępność, duplikację, canonicale i linkowanie wewnętrzne. Jeżeli problem dotyczy tylko kategorii filtrów, nie ruszaj całego serwisu.

Ważny niuans: robots.txt nie służy do chwilowego „przesuwania” crawl budgetu. Blokowanie przypadkowych sekcji z nadzieją, że Google natychmiast przeznaczy oszczędzony czas na ważniejsze strony, jest ryzykowne. Ten mechanizm nie działa tak prosto. Blokuj to, czego Google nie powinien crawlować w ogóle albo przez długi czas: wyniki wyszukiwania wewnętrznego, nieskończone kombinacje filtrów, koszyk, panel klienta, parametry techniczne, zasoby generujące duplikację.

Równie ważna jest wydajność. Jeżeli Googlebot pobiera stronę długo, a serwer regularnie zwraca błędy, crawl budget spada z powodów infrastrukturalnych. Wtedy SEO nie naprawi wszystkiego samym plikiem robots.txt. Trzeba wejść w hosting, cache, CDN, renderowanie, bazę danych, limity aplikacji i ciężkie szablony. Szczególnie w serwisach opartych na JavaScripcie warto sprawdzić, czy Google dostaje kompletną treść bez kosztownego renderowania wszystkiego po stronie klienta.

Nie obiecuj sobie, że po porządkach Google zaindeksuje każdą stronę. Crawlowanie nie oznacza indeksowania. Strona może zostać pobrana, przeanalizowana i odrzucona, jeśli jest zbyt podobna do innych, słaba jakościowo, pusta, niepopularna albo nie pasuje do tego, co Google chce pokazać w wynikach. Zarządzanie crawl budgetem zwiększa szansę, że robot szybciej trafi na właściwe adresy. Nie gwarantuje widoczności.

Najlepsza kolejność działań jest taka:

1. Usuń błędy serwera i przypadkowe blokady ważnych sekcji.
2. Ogranicz crawl śmieciowych URL-i: parametrów, sortowań, pustych filtrów i wyników wyszukiwania.
3. Napraw soft 404, łańcuchy przekierowań i stare adresy bez wartości.
4. Uporządkuj canonicale oraz reguły indeksowania.
5. Wyczyść sitemapę i zostaw w niej tylko adresy, które mają sens.
6. Wzmocnij linkowanie wewnętrzne do stron, które mają zarabiać widoczność.
7. Dopiero potem oceniaj, czy problemem nadal jest crawl budget, czy już jakość i popyt na treść.

Największy błąd? Traktowanie crawl budgetu jak osobnego projektu SEO. To nie jest osobny byt. To efekt architektury informacji, jakości URL-i, stabilności serwera, linkowania wewnętrznego i decyzji o indeksowaniu. Jeżeli te elementy są chaotyczne, Googlebot będzie chodził po chaosie. Jeżeli są uporządkowane, robot ma większą szansę robić to, czego od niego oczekujesz.

FAQ

Czy każda strona internetowa musi martwić się crawl budgetem?
Nie. Małe i średnie serwisy, w których Google szybko pobiera nowe treści, zwykle nie muszą traktować crawl budgetu jako priorytetu. Ważniejsze będą treści, linkowanie wewnętrzne, techniczna dostępność strony i dopasowanie do intencji użytkownika.

Od jakiej liczby podstron crawl budget zaczyna mieć znaczenie?
Nie ma jednej twardej granicy. Orientacyjnie problem częściej dotyczy serwisów z setkami tysięcy lub milionami URL-i, ale sklep z 20 000 produktów też może mieć kłopot, jeżeli filtry i parametry generują setki tysięcy kombinacji adresów.

Czy blokada w robots.txt poprawia indeksowanie ważnych stron?
Nie zawsze. robots.txt blokuje crawlowanie, ale nie jest narzędziem do prostego przenoszenia budżetu na inne adresy. Używaj go do sekcji, których Google nie powinien pobierać, a nie jako szybkiego sposobu na „wymuszenie” indeksacji ważnych stron.

Czy noindex oszczędza crawl budget?
Nie wprost. Google musi pobrać stronę, żeby zobaczyć noindex, więc taki adres nadal zużywa crawl. Przy dużej liczbie stron bez wartości lepiej najpierw zdecydować, czy mają być dostępne dla robota, kanonikalizowane, usunięte, przekierowane czy blokowane.

Co sprawdzić jako pierwsze przy problemach z crawl budgetem?
Najpierw logi serwera i Google Search Console. Szukaj błędów 5xx, timeoutów, soft 404, parametrów URL, przekierowań i dużych grup adresów wykrytych, ale niezaindeksowanych. Bez tego łatwo naprawiać rzeczy, które wyglądają technicznie, ale nie są źródłem problemu.

Czy sitemap.xml zwiększa crawl budget?
Nie zwiększa go automatycznie. Pomaga Google znaleźć ważne adresy, ale tylko wtedy, gdy zawiera czyste, aktualne, indeksowalne URL-e. Sitemap pełna przekierowań, błędów i stron noindex robi więcej zamieszania niż pożytku.

Czy szybszy serwer może poprawić crawlowanie?
Tak, szczególnie gdy wcześniej strona odpowiadała wolno albo zwracała błędy. Stabilny i szybki serwer ułatwia Googlebotowi pobieranie większej liczby zasobów bez ryzyka przeciążenia witryny.

Od czego zacząć porządki?
Od listy typów URL-i. Podziel adresy na produkty, kategorie, filtry, sortowania, parametry, stare strony, wyniki wyszukiwania i strony techniczne. Dla każdej grupy wybierz jedną decyzję: indeksować, zablokować, przekierować, usunąć, kanonikalizować albo zostawić z noindex. Bez takiej mapy crawl budget będzie naprawiany przypadkowo.