Crawl budget 2026: kiedy faktycznie limit krzywdzi serwis

Crawl budget w 2026 roku nie jest problemem teoretycznym ani mitologią, którą warto wyznawać przy każdej okazji. To realny mechanizm, który w określonych sytuacjach blokuje indeksację, opóźnia widoczność nowych treści i marnuje zasoby serwera. Pytanie nie brzmi, czy limit istnieje, bo istnieje zawsze. Pytanie brzmi: kiedy faktycznie zaczyna krzywdzić serwis i co z tym zrobić.

Ten przewodnik prowadzi przez kompletny framework decyzyjny: czym właściwie jest crawl budget limit, jak rozpoznać moment, w którym Google odpuszcza, jak zmierzyć skalę problemu w logach oraz jak naprawić serwis krok po kroku. Bez ezoteryki, bez przesady, bez powtarzania tez sprzed dekady.

Czym jest crawl budget limit i dlaczego nie każdy serwis go odczuwa

Crawl budget to suma żądań HTTP, które Googlebot (oraz boty AI: GPTBot, ClaudeBot, PerplexityBot, OAI SearchBot) wykonuje wobec danej domeny w określonym czasie. Google publicznie rozdziela ten mechanizm na dwie składowe: crawl rate limit oraz crawl demand. Pierwsza chroni serwer przed przeciążeniem. Druga decyduje o tym, jak bardzo wyszukiwarka jest zainteresowana ponownym odwiedzaniem URL-i.

Limit zaczyna boleć dopiero wtedy, gdy popyt na crawl przekracza zdolność serwisu do obsłużenia botów albo gdy struktura serwisu rozsiewa zasoby botów na strony bez wartości. W praktyce to dwa różne problemy, które mylimy notorycznie. Pierwszy wymaga inżynierii infrastruktury. Drugi wymaga radykalnego porządkowania architektury informacji.

Trzy mityczne tezy, z którymi trzeba się rozprawić

Po pierwsze, crawl budget nie jest karą za błędy SEO. To skutek matematyki: każda domena ma skończony przydział, który zależy od historii odpowiedzi serwera, jakości indeksowanych treści i poziomu zainteresowania wyszukiwarki.

Po drugie, mały serwis (do 1000 URL-i kanonicznych) praktycznie nigdy nie odczuwa limitu. Google sam to potwierdza w dokumentacji Search Central. Optymalizacja pod kątem crawl budget w takim przypadku to strzelanie z armaty do problemu, który nie istnieje.

Po trzecie, blokowanie zasobów w robots.txt nie zwalnia budżetu jeden do jeden. Bot nadal odwiedza, sprawdza, próbuje. Zaoszczędzony zostaje czas pobrania treści, ale nie czas requestu DNS, TLS i kolejnej kontroli regulaminu robots.

Kiedy crawl budget naprawdę zaczyna krzywdzić serwis

Istnieje kilka sygnałów alarmowych, które oznaczają, że jest się w czerwonej strefie. Każdy z nich wymaga osobnej diagnozy, bo każdy ma inną przyczynę.

Sygnał 1: nowe treści indeksują się dłużej niż 7 dni

W zdrowym serwisie świeży post na blogu trafia do indeksu w 1-3 dni roboczych. Jeśli czekanie rozciąga się ponad tydzień, a zgłoszenia z Search Console (URL Inspection, Request Indexing) skutkują statusem „Discovered, currently not indexed”, to znak, że Google odwiedza, ale rezygnuje z pobierania lub indeksowania. Najczęściej powód jest brutalny: serwis serwuje za dużo niskiej jakości URL-i, więc nowe trafiają do kolejki za starymi śmieciami.

Sygnał 2: liczba „discovered, not indexed” rośnie z miesiąca na miesiąc

Raport „Page indexing” w Search Console pokazuje wzrost statusu „Discovered, not indexed” oraz „Crawled, not indexed”. Jeśli w skali kwartału kategoria ta puchnie o 15 procent i więcej, to symptom tego, że Google znajduje URL-e (przez sitemap, linki wewnętrzne, parametry), ale nie uważa, że warto je odwiedzić lub zindeksować. Crawl demand drastycznie spada.

Sygnał 3: koszt serwera rośnie, a ruch organiczny nie

Analiza logów pokazuje, że Googlebot pobiera 50 000 stron dziennie, ale Search Console raportuje 800 unikalnych URL-i z ruchem organicznym. To znaczy, że 98 procent crawl budgetu jest spalane na strony bez wartości: filtry, sortowania, parametry tracking, paginacje nieskończone, duble z trailing slash i bez, wersje językowe, wersje drukowane, AMP zostawione w martwym katalogu.

Sygnał 4: spadek widoczności mimo dobrych treści

Świeże, dobrze napisane artykuły nie wbijają się do top 20, mimo że konkurencja na podobne frazy jest umiarkowana. Diagnoza: Google nie crawluje nowych URL-i wystarczająco często, żeby uchwycić sygnały rankingowe. W skrajnych przypadkach treści są indeksowane z miesięcznym opóźnieniem, kiedy momentum tematu już dawno minęło.

Framework diagnostyczny: trzy poziomy analizy

Zanim wytoczy się ciężkie działa optymalizacji, trzeba mieć dane. Bez logów, bez Search Console i bez przekroju architektury serwisu cała dyskusja o crawl budget jest spekulacją.

Poziom 1: Search Console (10 minut)

Raport „Crawl stats” w Settings: liczba requestów dziennie, średni response time, status HTTP w rozbiciu na kody.
Raport „Page indexing”: stosunek „Indexed” do „Not indexed”. Zdrowa proporcja to minimum 70 procent indexed dla treści mającej trafiać do indeksu.
Sitemap: czy wszystkie zgłoszone URL-e są kanoniczne i zwracają 200.

Poziom 2: logi serwera (1-2 dni)

Analiza logów to najuczciwszy obraz tego, co rzeczywiście robi Googlebot. Potrzebne są logi z minimum 14 dni (najlepiej 30). Narzędzia: Screaming Frog Log File Analyzer, Botify, OnCrawl, JetOctopus, własny pipeline w BigQuery.

Liczba requestów Googlebotów (z weryfikacją reverse DNS, bo fake-Googlebot jest plagą).
Top 100 najczęściej crawlowanych URL-i: czy to strony, które chcesz, żeby były crawlowane?
Procent requestów na kody 200, 301, 304, 404, 410, 5xx. Zdrowa proporcja: 90 procent 200/304, mniej niż 2 procent 4xx, zero 5xx.
Stosunek crawl-to-index: ile unikalnych URL-i odwiedzono, ile z nich jest w indeksie.

Poziom 3: pełen audyt architektury (1 tydzień)

Połączenie crawla narzędziem (Screaming Frog, Sitebulb) z mapą logów i Search Console. Cel: zidentyfikować strony zombie, czyli URL-e, które:

Są crawlowane przez Google,
Nie mają ruchu organicznego od minimum 90 dni,
Nie mają backlinków,
Nie są celowo utrzymywane (np. strony prawne, regulaminy, polityka prywatności).

Strony zombie to numer jeden wśród powodów spalania budżetu na nic. W większych e-commerce’ach potrafią stanowić 60-80 procent zindeksowanych URL-i. To problem strategiczny, nie techniczny.

Jak naprawić serwis krok po kroku

Mając już dane, można planować. Kolejność operacji ma znaczenie, bo niektóre działania uwalniają budżet natychmiast, inne dopiero po miesiącach.

Krok 1: zatrzymać krwawienie (1-2 dni roboty)

Najpilniejsze działania, które natychmiast zmniejszają liczbę bezsensownych requestów:

Dodać do robots.txt sekcję blokującą parametry filtrujące i sortujące, których nie chcesz indeksować. Przykład: Disallow: /*?sort=, Disallow: /*?color=, Disallow: /*?utm_.
Skonfigurować poprawnie 410 dla starych URL-i, które miały być usunięte na zawsze. Bot przestaje je odwiedzać szybciej niż przy 404.
Naprawić łańcuchy redirectów: każdy 301 -> 301 -> 200 to dwa requesty zamiast jednego. W większych serwisach to dziesiątki tysięcy zmarnowanych wizyt botów miesięcznie.
Sprawdzić sitemap.xml: usunąć URL-e, które są noindex, redirectują, zwracają 4xx, lub mają canonical wskazujący gdzie indziej.

Krok 2: noindex zamiast disallow tam, gdzie boli (1 tydzień)

Disallow blokuje crawl, ale nie usuwa z indeksu. Noindex wymaga, żeby bot wszedł, przeczytał meta tag i wyrzucił. To brzmi paradoksalnie (przecież chcemy oszczędzać budżet), ale to jedyna droga, żeby strona zniknęła z indeksu bez 410.

Klasyczne przypadki dla noindex follow:

Strony tagów na blogu, które nie generują ruchu.
Strony filtrujące w sklepie (kolor, rozmiar, cena), które mają wartość UX, ale nie SEO.
Strony wyników wewnętrznej wyszukiwarki.
Strony „thank you” po formularzu, koszyki, checkouty.
Paginacje głębsze niż strona 5 (kontrowersyjne, ale w 80 procent serwisów stron 6+ nikt nie odwiedza i nie linkuje).

Po zindeksowaniu noindexu (zwykle 2-4 tygodnie) można dopiero dodać disallow w robots.txt, żeby zatrzymać dalsze crawle. Nigdy odwrotnie.

Krok 3: konsolidacja treści (2-6 tygodni)

To najtrudniejsza część, bo wymaga decyzji edytorskich. Połączenie 5 artykułów po 600 słów, które kanibalizują się na to samo zapytanie, w jeden tekst 3500 słów to zysk po stronie crawl demand (jedna strona zamiast pięciu), ale też zysk w rankingu. Strategia hub-and-spoke, którą opisaliśmy w Semantic SEO 2026: entity, ontologie, schema, embeddingi, robi tu robotę: pillar zostaje, jego dawne pomocniki łączą się i wchodzą do struktury supportingów jako pełnoprawne klastry.

Krok 4: poprawić infrastrukturę (równolegle)

Crawl rate limit (czyli ile boty mogą wziąć, zanim serwer zacznie zwracać 5xx) zależy od czasu odpowiedzi. Cel: średni TTFB poniżej 200 ms dla 95 percentyla. Co najczęściej działa:

CDN z edge cache dla statyki (Cloudflare, BunnyCDN, KeyCDN).
Cache po stronie aplikacji (Redis, Memcached) dla zapytań do bazy.
Optymalizacja kwerend (indeksy, denormalizacja tam, gdzie potrzeba).
Przejście z HTTP/1.1 na HTTP/2 lub HTTP/3 dla mniejszego narzutu transportowego.
Włączenie kompresji brotli zamiast gzip.

Każde 100 ms krótszego TTFB to mierzalny wzrost liczby requestów na sekundę, które bot jest skłonny wysłać. W praktyce mamy dane od kilkunastu klientów, gdzie spadek TTFB z 800 ms do 200 ms podwoił dzienny wolumen crawla w ciągu 30 dni.

Krok 5: nakierować boty na to, co ważne

Crawl demand można pchać:

Linkowaniem wewnętrznym (im więcej kontekstowych linków do strony, tym częściej bot wraca).
Świeżymi sitemap’ami z lastmod, który mówi prawdę (kłamanie skutkuje tym, że Google przestaje wierzyć w lastmod).
Strukturą URL i kategorii, która oddaje hierarchię ważności.
IndexNow (Bing) oraz Google Indexing API (oficjalnie tylko dla JobPostings i BroadcastEvent, ale niektóre serwisy używają go szerzej, na własne ryzyko).
Backlinks z mocnych domen (klasyk, który nadal działa).

Najczęstsze błędy i pułapki, w które wpadamy

Optymalizacja crawl budgetu jest minowa, bo łatwo zrobić więcej szkody niż pożytku.

Pułapka 1: zbyt agresywny disallow

Klient zablokował w robots.txt cały katalog /wp-json/ myśląc, że zaoszczędzi budżet. Efekt: Googlebot przestał widzieć rendered HTML z REST API i serwis stracił 40 procent widoczności w 3 tygodnie. Zasada: nie blokuj nic, czego nie rozumiesz w 100 procent. W razie wątpliwości najpierw audyt, potem cięcie.

Pułapka 2: noindex z disallow jednocześnie

Jeśli strona ma noindex i jednocześnie jest disallow w robots.txt, Google nigdy nie zobaczy tagu noindex i nie wyrzuci strony z indeksu. Klasyk, który widzimy regularnie na audytach. Najpierw noindex, czekamy, potem disallow.

Pułapka 3: kanonical wskazujący na noindex

Strona A ma canonical do strony B, a strona B ma noindex. Google dostaje sprzeczny sygnał i może wyrzucić obydwie z indeksu albo zignorować canonical. Zawsze trzeba sprawdzić, czy strona docelowa canonical jest indeksowalna.

Pułapka 4: sitemap z 100 tysiącami URL-i, z których 90 procent ma noindex

To psuje zaufanie do sitemap. Sitemap to deklaracja: „te URL-e są warte indeksowania”. Jeśli kłamie, Google przestaje używać jej do priorytetyzacji. Trzymaj w sitemap wyłącznie strony 200, kanoniczne, indeksowalne.

Pułapka 5: nieskończona paginacja w sklepach

Sklep z 50 000 produktów, paginacja po 12 produktów na stronę, oznacza 4167 paginacji per kategoria. Pomnóż przez 200 kategorii i masz 833 400 URL-i paginacji. Większość bezwartościowa. Rozwiązania: zwiększyć liczbę produktów per strona, dodać noindex od strony 2, użyć rel=next/prev (deprecjonowane przez Google, ale ułatwia czytelność dla innych botów), lub zbudować strony filtrów jako pełnoprawne landing pages dla najpopularniejszych kombinacji.

Mierzenie efektów i KPI

Bez metryk nie wiadomo, czy interwencja działa. Zalecany zestaw wskaźników, mierzony co tydzień:

KPI techniczne

Requesty Googlebota dziennie: cel rosnący lub stabilny po cięciu śmieci.
Average response time: cel poniżej 200 ms.
Procent kodów 200/304: cel powyżej 90 procent.
Procent kodów 4xx: cel poniżej 2 procent.
Procent kodów 5xx: cel zero.

KPI indeksacyjne

Stosunek „Indexed” do „Discovered + Crawled, not indexed”: cel powyżej 4:1.
Średni czas indeksacji nowych URL-i: cel poniżej 72 godzin.
Procent URL-i w sitemap, które są w indeksie: cel powyżej 85 procent.

KPI biznesowe

Liczba sesji organicznych z URL-i opublikowanych w ostatnich 30 dniach: dynamika, nie wartość bezwzględna.
Liczba unikalnych URL-i z minimum 10 sesji w ostatnich 30 dniach: szerokość ruchu.
Crawl-to-traffic ratio: ile crawl trzeba na 1 sesję organiczną. Spada, kiedy optymalizacja działa.

Crawl budget w erze botów AI

Do 2024 roku jedynym istotnym botem był Googlebot. W 2026 sytuacja jest znacząco inna. GPTBot, ClaudeBot, PerplexityBot, OAI SearchBot, Amazonbot, Bytespider oraz dziesiątki mniejszych botów AI generują, w niektórych serwisach, więcej requestów niż Google. Z naszych obserwacji: średnio 30-50 procent total bot traffic to nie-Google. Co z tym robić?

Po pierwsze, mierzyć. W logach trzeba rozdzielić bota Google, bota AI z dużych dostawców (GPTBot, ClaudeBot) oraz długi ogon mniej znanych. Po drugie, zdecydować, kogo wpuszczać. Naszą rekomendacją jest wpuszczanie wszystkich legalnych botów AI na strony publiczne i blokowanie ich w robots.txt na sekcjach prywatnych (panele, koszyki, konta użytkowników). Po trzecie, optymalizować strony pod jednoczesny crawl Google i AI: dobra struktura, semantyczne nagłówki, jasna hierarchia tematyczna. To samo, co robimy dla SEO, działa też dla AIO. Więcej kontekstu na ten temat w SEO pod AI 2026: framework dla agencji.

Programmatic SEO a crawl budget

Strategia programmatic, którą rozwijamy w artykule Programmatic SEO 2026: bramka pod AIO, rate limit, wartość, ma osobną wagę w kontekście budżetu botów. Generując dziesiątki tysięcy stron z szablonu, ryzykujemy spalenie crawl demand na strony, które są poprawne technicznie, ale nudne. Bramka quality assurance, którą stosujemy (minimum 600 słów unikalnej treści per strona, 1 obraz, 3 dane strukturalne) wymusza, żeby programmatic nie zamieniał się w generator pustych URL-i.

Sklepy internetowe: osobny rozdział

E-commerce ma najbardziej dramatyczne problemy z crawl budgetem ze wszystkich typów serwisów. Powód: kombinatoryczna eksplozja URL-i z filtrów. Sklep z 3 filtrami (kolor, rozmiar, marka) na 5 wartości każdy generuje 125 kombinacji na kategorię. Trzy kategorie? 375. Dziesięć? 1250. I to przed dodaniem sortowań i paginacji.

Rozwiązanie, które działa w praktyce:

Wybrać 20-50 najwartościowszych kombinacji filtrów (na podstawie research słów kluczowych) i zrobić z nich pełnoprawne landing pages z unikalnym tekstem, schema produktu, własnym title i description.
Wszystkie pozostałe kombinacje blokować via meta robots noindex i parametry w GSC.
Atrybuty produktów feedować w schema.org pełnym opisem, żeby AI shopping (Google Shopping AI, Amazon Rufus, Perplexity Shopping) miało paszę. Więcej o tym w Sklepy pod AI 2026: feed, opisy, kategorie, schema produktu.
Konsolidować duplikaty: produkty rozsiane po wielu kategoriach powinny mieć jeden URL kanoniczny.

Studium przypadku: 4 miesiące optymalizacji

Klient: średniej wielkości e-commerce, 12 000 produktów, 380 000 zindeksowanych URL-i przed audytem.

Stan wyjściowy:

Średni czas indeksacji nowego produktu: 18 dni.
Discovered, not indexed: 287 000 URL-i.
Średni TTFB: 1100 ms.
Ruch organiczny: 95 000 sesji miesięcznie.

Działania (miesiące 1-4):

Disallow parametrów sortowania i 18 filtrów niskowartościowych.
Noindex follow na paginacjach 6+, tagach blogowych, wynikach wewnętrznej wyszukiwarki.
CDN, optymalizacja kwerend SQL, cache Redis na karty produktów.
Łączenie kanibalizujących się tekstów blogowych (47 artykułów zredukowanych do 18 nowych).
Sitemap rebuild: zostawione 38 000 URL-i kanonicznych zamiast 380 000.
50 landing pages dla najwartościowszych kombinacji filtr+kategoria.

Stan po 4 miesiącach:

Średni czas indeksacji nowego produktu: 2,8 dnia.
Discovered, not indexed: 38 000 URL-i.
Średni TTFB: 180 ms.
Ruch organiczny: 168 000 sesji miesięcznie (+77 procent).

Co warte podkreślenia: w pierwszym miesiącu widzieliśmy spadek liczby indeksowanych URL-i o 70 procent (z 380 do 113 tysięcy). Klient się stresował, my się nie. To była zaplanowana redukcja śmieci. Ruch zaczął rosnąć od miesiąca drugiego.

Crawl budget a Core Web Vitals

Mimo że to dwa różne tematy, dotykają tej samej infrastruktury. Strona, która ładuje się 4 sekundy, ma słaby LCP, słaby INP i jednocześnie mały budżet crawla (bo TTFB długi, każdy request botowy kosztuje serwer drogo, więc Google zwalnia tempo crawla).

Inwestycja w wydajność daje podwójny zwrot: lepsze user signals (CWV w GSC) i większy crawl rate. To powinno być argumentem przy każdej rozmowie o budżecie z dev teamem.

Czego nie robić, nawet jeśli ktoś radzi w internecie

Nie usuwać masowo starych treści bez analizy. Strona bez ruchu od 90 dni może mieć backlinki, które dają site-wide authority.
Nie robić 301 wszystkiego w jedno miejsce. Masowe redirecty do strony głównej Google traktuje jak soft-404.
Nie ustawiać crawl rate ręcznie w GSC na minimum. To opcja awaryjna na czas migracji, nie strategia długofalowa.
Nie używać noindex na stronach kategorii e-commerce, jeśli nie ma się alternatywnej drogi do produktów. Klasyczny strzał w stopę.
Nie ufać narzędziom, które obiecują automatyczną optymalizację crawl budget. Każdy serwis jest inny i wymaga decyzji edytorskich.

FAQ

Czy mój blog na WordPressie z 200 wpisami powinien się przejmować crawl budget?

Nie. Małe serwisy nie odczuwają limitu. Skup się na jakości treści, linkowaniu wewnętrznym i wydajności. Wracaj do tematu, kiedy przekroczysz 5000 URL-i kanonicznych albo zaobserwujesz spadek tempa indeksacji.

Co jest ważniejsze: noindex czy disallow w robots.txt?

Zależy od celu. Disallow oszczędza crawl (bot nie pobiera treści), ale nie usuwa z indeksu. Noindex usuwa z indeksu, ale wymaga, żeby bot wszedł. Standardowa sekwencja: najpierw noindex, czekamy 4-8 tygodni aż Google wyrzuci stronę z indeksu, dopiero potem dodajemy disallow w robots.txt.

Czy IndexNow zastępuje optymalizację crawl budgetu?

Nie. IndexNow przyspiesza pierwsze odwiedziny URL-i przez Bing/Yandex i częściowo Google (przez agregatory). Nie naprawia źródła problemu, którym jest struktura serwisu. Traktuj go jako uzupełnienie, nie zamiennik.

Ile czasu Googlebot poświęca dziennie na średni serwis e-commerce?

W naszych danych: dla sklepu z 10 000 produktów i czasem odpowiedzi 300 ms średnio 15-30 tysięcy requestów dziennie. Dla serwisu z 1 000 stron: 500-2000 requestów dziennie. Różnice są ogromne i zależą od historii, autorytetu domeny, częstotliwości zmian treści.

Czy boty AI marnują mój crawl budget?

Nie marnują budżetu Google. Każdy bot ma swój własny pool requestów. Natomiast obciążają twój serwer. Jeśli boty AI generują razem 60 procent obciążenia, a nie przekładają się na ruch (jeszcze), warto skonfigurować dla nich rate limit na poziomie Cloudflare lub Nginx oraz świadomie zdecydować, co im udostępniasz.

Jak często analizować logi serwera?

Dla średniego serwisu: raz na kwartał audyt głęboki, raz na miesiąc szybki przegląd top 100 najczęściej crawlowanych URL-i i kodów odpowiedzi. Dla dużego e-commerce (powyżej 50 tysięcy produktów): monitoring ciągły z alertami na anomalie (np. nagły wzrost 5xx, spadek requestów Googlebot poniżej baseline o 30 procent).

Czy migracja na nowy CMS wpływa na crawl budget?

Tak, i to mocno. W pierwszych 2-4 tygodniach po migracji Google zwykle zwiększa crawl, żeby odkryć nową strukturę. Jeśli migracja zawierała redirect mapę 1:1, wszystko wraca do baseline w 6-8 tygodni. Jeśli URL-e się pozmieniały, oczekuj 3-6 miesięcy turbulencji. Dlatego przed migracją zawsze rób kopię logów i mapy URL-i.

Narzędzia, których realnie używamy

Wbrew internetowemu szumowi, do skutecznej diagnozy crawl budgetu nie potrzeba pakietu za tysiące euro miesięcznie. Setup, który polecamy klientom:

Search Console: bezpłatny, podstawa diagnozy. Raporty Crawl stats, Page indexing, Sitemaps.
Screaming Frog SEO Spider + Log File Analyzer: dla audytu jednorazowego oraz okresowego. Licencja od 199 funtów rocznie.
Sitebulb: alternatywa dla Screaming Frog, lepsze raporty wizualne dla zarządu.
OnCrawl, Botify, JetOctopus: dla dużych serwisów (powyżej 100 tys. URL-i) z ciągłym monitoringiem logów.
Własny pipeline w BigQuery (logi z CDN przez Cloudflare Logpush albo serwerowe Nginx logi przez Fluent Bit): dla zespołów z kompetencjami danych.
Ahrefs i Semrush: nie do crawl budgetu bezpośrednio, ale do oceny, które strony zombie mają backlinki warte zachowania.

Najczęściej do pierwszego audytu wystarcza darmowy Search Console plus Screaming Frog. Dopiero kiedy jest co tygodniowo monitorować, sięga się po platformy SaaS.

Współpraca z dev teamem: jak uniknąć przepychania w kółko

Większość problemów crawl budget rozwiązuje się przez developerów, nie przez SEO. Dlatego sposób, w jaki przekazujesz wymagania, jest połową sukcesu. Co działa w praktyce:

Tikety w trackerze (Jira, Linear) z dokładnym oczekiwanym kodem HTTP i nagłówkami odpowiedzi. Nie „popraw to”, tylko „URL /kategoria/produkt-X powinien zwracać 301 do /kategoria/produkt-Y z nagłówkiem Cache-Control: public, max-age=86400”.
Demo na środowisku testowym z włączoną symulacją Googlebota (Chrome DevTools, zmiana User-Agent na Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Co kwartał wspólny review crawl stats z Search Console, na poziomie 30-minutowego spotkania devs+SEO+content.
Automatyczne alerty w Slacku, kiedy któryś z KPI wyleci poza zakres (np. spadek requestów Googlebot o 30 procent dzień do dnia).

Brzmi banalnie, ale w praktyce 80 procent klientów nie ma tych nawyków. Wprowadzenie ich obniża frustrację po obu stronach i przyspiesza realizację zmian o tygodnie.

Podsumowanie: kiedy zacząć się przejmować

Crawl budget zaczyna boleć w trzech sytuacjach: kiedy serwis przekracza kilka tysięcy URL-i kanonicznych, kiedy nowe treści indeksują się dłużej niż tydzień, lub kiedy w Search Console rośnie kategoria „Discovered, not indexed”. Każda z tych sytuacji wymaga audytu, nie panicznych decyzji. Najpierw dane (Search Console + logi serwera), potem framework (zatrzymać krwawienie, konsolidować, naprawić infra, nakierować boty), potem mierzenie KPI co tydzień.

I jeszcze jedna myśl na koniec: optymalizacja crawl budgetu w 2026 to nie jest sport dla maniaków SEO. To codzienna higiena każdego serwisu, który ma ambicje rosnąć w ruchu organicznym i widoczności w AI. Im wcześniej wbudujemy w architekturę, tym mniej będzie kosztować nas później.