Crawl budget to limit zasobów, które Googlebot przeznacza na skanowanie Twojej witryny w określonym czasie. Prowadzisz sklep z tysiącami podstron produktowych, a Google ignoruje większość z nich? Problem niemal zawsze leży w budżecie crawlowania. Ten artykuł pokazuje, jak go zdiagnozować, zmierzyć i naprawić — żeby każda ważna podstrona trafiała do indeksu. Bazuję na danych z SEO dla e-commerce, które prowadzimy w Westom od lat.
Najważniejsze wnioski — crawl budget w pigułce
Zanim wejdziesz w szczegóły, oto osiem faktów podsumowujących całe zagadnienie budżetu crawlowania. Pozwolą Ci szybko ocenić, czy Twoja strona ma z nim problem.
- Crawl budget to połączenie dwóch czynników: crawl rate limit (ile żądań na sekundę serwer obsłuży bez degradacji) i crawl demand (jak bardzo Google chce skanować Twoje URL-e).
- Dla witryn poniżej 10 000 podstron crawl budget rzadko stanowi wąskie gardło — Google zazwyczaj skanuje je w całości.
- Sklepy internetowe z 50 000+ URL-i (warianty produktów, filtry, paginacja) tracą nawet 60% budżetu crawlowania na podstrony, które nie powinny być indeksowane.
- Jedyne wiarygodne źródło danych o crawl budgecie to raport „Statystyki indeksowania” w Google Search Console (GSC) oraz analiza logów serwera (server logs).
- Plik robots.txt to najszybszy sposób na odebranie Googlebotowi dostępu do bezwartościowych ścieżek — działa natychmiast.
- Strony z czasem odpowiedzi serwera powyżej 800 ms mają obniżony crawl rate limit, bo Google nie chce przeciążać wolnego serwera.
- Sitemap XML nie zwiększa crawl budgetu, ale zmienia priorytety — Google szybciej odkrywa nowe i zaktualizowane URL-e.
- Optymalizacja crawl budgetu daje najlepsze efekty w połączeniu z technicznym audytem SEO — sama blokada ścieżek bez naprawy struktury linków wewnętrznych to połowiczne rozwiązanie.
Czym dokładnie jest crawl budget i jak go rozumie Google
Crawl budget to ilość zasobów (liczba żądań HTTP i czas), które Googlebot przeznacza na skanowanie danej witryny w określonym oknie czasowym. Składa się z dwóch niezależnych czynników: crawl rate limit i crawl demand — dopiero ich połączenie daje faktyczny budżet crawlowania Twojego serwisu.
Google oficjalnie opisał ten mechanizm w na blogu Search Central, a od tamtej pory kilkukrotnie go doprecyzował. Sam termin „budżet” bywa mylący. Nie chodzi o żadną kwotę — to raczej pojemność uwagi, jaką Googlebot poświęca Twojej domenie. I ta uwaga jest skończona.
Dwa sklepy z identyczną liczbą URL-i mogą mieć zupełnie inny crawl budget. Dlaczego? Bo różnią się szybkością serwera, strukturą linków i jakością treści. Martin Splitt z Google ujął to najprościej:
„If Googlebot can’t see it, it doesn’t exist.”
(pol. Jeśli Googlebot tego nie widzi, to nie istnieje.)
I dokładnie o to chodzi w crawl budgecie — nie o to, czy treść jest dobra, ale czy bot w ogóle do niej dotarł. Przejdźmy do dwóch składowych.
Crawl rate limit — ile wytrzyma Twój serwer
Crawl rate limit to maksymalna częstotliwość zapytań, przy której Googlebot nie powoduje problemów z wydajnością serwera. Google dynamicznie dostosowuje ten limit na podstawie czasu odpowiedzi — jeśli serwer zwalnia, bot odpuszcza.
Na hostingu współdzielonym z czasem odpowiedzi 1200 ms Google będzie crawlował znacznie wolniej niż na dedykowanym serwerze z odpowiedzią poniżej 200 ms. Mówimy o różnicy rzędu kilkuset żądań dziennie kontra kilkudziesięciu tysięcy. Przepaść.
Widzimy to regularnie u klientów e-commerce. Sklep na Shoperze z planem podstawowym potrafi mieć crawl rate limit na poziomie 500 zapytań dziennie, podczas gdy ten sam katalog na zoptymalizowanym VPS-ie jest skanowany 5000 razy dziennie. A strona ładująca się ponad 3 sekundy traci 53% użytkowników mobilnych (Google / Think with Google). Bot Google reaguje podobnie — tylko po cichu.
Crawl demand — jak bardzo Google chce skanować Twoje URL-e
Crawl demand to poziom zainteresowania Google Twoimi stronami. Zależy od popularności URL-i, częstotliwości zmian treści i tego, czy URL jest obecny w indeksie. Strona, która generuje ruch i jest często aktualizowana, będzie skanowana częściej.
Google przyznaje wyższy crawl demand stronom, na które prowadzą linki zewnętrzne, które mają historię zmian treści i które użytkownicy odwiedzają z wyników wyszukiwania. Stare, statyczne podstrony z zerowym ruchem? Koniec kolejki — albo pominięcie. Bo 94% stron nie ma żadnego ruchu z Google (SE Ranking, 2025). Większość z nich Google po prostu przestał odwiedzać.
Samo dodanie 10 000 podstron produktowych do sitemap nie gwarantuje, że Google je zeskanuje. Jeśli te podstrony nie mają linków wewnętrznych i unikalnej treści — Googlebot uzna je za bezwartościowe i poświęci czas na coś innego. Gary Illyes z Google mówi o tym wprost:
„Narrow it down as much as you can. Don’t create low quality and no value add pages. It’s just not worth it because one thing is that we don’t necessarily want to index those pages. We think that it’s a waste of resources.”
(pol. Zawężaj tematykę jak tylko możesz. Nie twórz stron niskiej jakości. Nie chcemy ich indeksować — to marnowanie zasobów.)
Marnowanie zasobów — ich słowa, nie nasze. A crawl budget to właśnie ten zasób, który Google oszczędza, gdy widzi na Twojej domenie zbyt dużo balastu.
Dlaczego Google ignoruje Twoje podstrony — crawl budget jako przyczyna
Google nie indeksuje podstron z kilku powodów, ale w sklepach internetowych z dużym katalogiem głównym winowajcą jest wyczerpany crawl budget. Bot dociera do strony głównej i kategorii, ale nie penetruje głębszych poziomów — wariantów, filtrów, paginacji.
Raport „Strony” (dawniej „Pokrycie”) w Google Search Console u jednego z naszych klientów — sklepu z modą na WooCommerce — pokazywał 38 000 adresów URL ze statusem „Wykryto — obecnie nie zaindeksowano”. Większość to warianty kolorów i rozmiarów generujące oddzielne URL-e bez tagu canonical. Trzydzieści osiem tysięcy stron, o których Google wiedział, ale nie chciał ich skanować.
Problem nie leżał w jakości treści. Treści były poprawne. Serwer odpowiadał szybko. Winowajca? Marnowany budżet crawlowania — Googlebot dziennie odwiedzał ok. 4200 URL-i, z czego 2800 to były warianty kolorystyczne, filtrowane listy i zduplikowane paginacje. Dwie trzecie budżetu w błoto.
Po optymalizacji (canonical, robots.txt, czyszczenie parametrów URL w GSC) w ciągu liczba zaindeksowanych stron produktowych wzrosła o 34%. Bez dodania ani jednej nowej treści. Zero contentu. Czysta technika.
Jak sprawdzić crawl budget swojej strony
Crawl budget mierzysz w dwóch miejscach: w raporcie „Statystyki indeksowania” (Crawl Stats) w Google Search Console oraz przez analizę logów serwera. GSC daje ogólny obraz. Logi — pełny szczegół z dokładnością co do URL-a i sekundy.
Google Search Console — raport statystyk indeksowania
Raport „Statystyki indeksowania” w GSC pokazuje liczbę żądań Googlebota dziennie, średni czas odpowiedzi serwera i rozmiar pobieranych danych. To punkt startowy — mówi Ci, ile uwagi Google poświęca Twojej domenie.
Ścieżka: GSC → Ustawienia → Statystyki indeksowania. Zobaczysz trzy wykresy: łączną liczbę żądań indeksowania, całkowity rozmiar pobranych danych i średni czas odpowiedzi. Każdy rozbity na .
Na co zwrócić uwagę? Nagłe spadki liczby żądań przy stałym czasie odpowiedzi — Google mógł obniżyć crawl demand (np. po fali treści niskiej jakości). Czas odpowiedzi rośnie, a żądania spadają? Serwer jest wąskim gardłem. Oba scenariusze widzimy co miesiąc u nowych klientów.
Analiza logów serwera — pełen obraz crawlowania
Analiza logów (access logs) to jedyna metoda, która pokazuje dokładnie, które URL-e Googlebot odwiedza, kiedy i z jakim kodem odpowiedzi. Pozwala zidentyfikować marnowany crawl budget co do konkretnej ścieżki.
Potrzebujesz dostępu do access logów serwera (Apache, Nginx, LiteSpeed) i narzędzia do ich parsowania. Screaming Frog SEO Spider (wersja płatna) ma wbudowany moduł do analizy logów. Alternatywy: JetOctopus, Oncrawl albo skrypt w Pythonie z biblioteką Pandas — jeśli lubisz grzebać w danych ręcznie.
Z logów wyciągniesz: procent crawl budgetu marnowany na ścieżki z parametrami, stosunek crawlowania stron 200 vs. 301/404/410, częstotliwość powrotów bota na tę samą stronę i listę URL-i, które Google kompletnie pomija. To ostatnia grupa jest najcenniejsza — bo tam leżą Twoje pieniądze.
Crawl budget w e-commerce — największe pożeracze budżetu
Organik odpowiada za 44,56% ruchu w polskim e-commerce — to największy kanał (Harbingers + Openfield, 2025). A sklepy internetowe mają specyficzny problem z crawl budgetem: generują ogromną liczbę URL-i, które nie niosą unikalnej wartości. Filtry facetowe, warianty produktów, parametry sortowania i wielopoziomowa paginacja potrafią zwielokrotnić liczbę adresów nawet kilkudziesięciokrotnie.
Sklep z 5000 produktów, z których każdy ma 4 warianty kolorystyczne i 5 rozmiarów, generuje potencjalnie 100 000 URL-i wariantów. Dodaj filtry — cena, marka, materiał — i dostajesz miliony kombinacji. Ile z nich ma unikalną treść? Żadna. Ile z nich zjada crawl budget? Wszystkie.
| Źródło problemu | Estymowany % marnowanego budżetu | Rozwiązanie |
|---|---|---|
| Filtry facetowe (cena, kolor, marka) | 20–30% | robots.txt + noindex/canonical na kombinacjach filtrów |
| Warianty produktów jako oddzielne URL-e | 15–25% | Tag canonical wskazujący na produkt główny |
| Paginacja (/?page=2, /?page=3…) | 10–20% | Implementacja rel=”next”/”prev” lub load more + prawidłowy canonical |
| Parametry sortowania (?sort=price_asc) | 5–15% | Blokada w robots.txt lub parametry URL w GSC |
| Wewnętrzne wyszukiwarki (/search?q=…) | 5–10% | Disallow w robots.txt |
| Stare/wycofane produkty (soft 404) | 5–10% | Zwracanie kodu 410 (Gone) zamiast soft 404 |
Suma tych problemów w niezoptymalizowanym sklepie? Googlebot marnuje 60–80% swojego czasu na URL-e bez wartości. Pozostałe 20–40% budżetu idzie na właściwe strony — kategorie, produkty, artykuły blogowe. Efekt: nowe produkty czekają tygodniami na zaindeksowanie, a zmiany cen w istniejących kartach pojawiają się w Google z kilkudniowym opóźnieniem. I tu zaczyna się realna strata pieniędzy — bo 38% polskich e-commerce nie pojawia się nawet w odpowiedziach AI (Harbingers, 2025). Jeśli Google nie crawluje Twoich stron, nie będziesz widoczny nigdzie.
Jak poprawić crawl budget — plan działania krok po kroku
Optymalizacja crawl budgetu to cztery kroki: blokada śmieciowych ścieżek w robots.txt, poprawa struktury linków wewnętrznych, przyspieszenie serwera i uporządkowanie sitemap XML. Kolejność ma znaczenie — zacznij od tego, co daje natychmiastowy efekt.
robots.txt — pierwsza linia obrony crawl budgetu
Plik robots.txt to najszybszy sposób na odcięcie Googlebota od bezwartościowych URL-i. Zmiany w robots.txt Googlebot wykrywa przy każdej wizycie — efekt widoczny jest w ciągu .
Zablokuj: ścieżki wewnętrznej wyszukiwarki (/search, /szukaj), parametry sortowania (?sort=, ?order=), strony koszyka i checkoutu, panele administracyjne, tagi i archiwa dat (jeśli duplikują treść kategorii). Na platformach typu Shoper i WooCommerce te ścieżki są przewidywalne — poniżej gotowy fragment.
Przykład dla WooCommerce:
User-agent: Googlebot
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*?s=
Disallow: /*?orderby=
Disallow: /*?filter_
Disallow: /tag/
Struktura linków wewnętrznych a crawl budget
Linki wewnętrzne to mapa, po której porusza się Googlebot. Strony głęboko zagnieżdżone (więcej niż 3 kliknięcia od strony głównej) mają niższy priorytet crawlowania. Płaska struktura linkowania sprawia, że bot efektywniej wykorzystuje swój budżet.
Sklepy z hierarchią: strona główna → kategoria → podkategoria → produkt → wariant mają już 4 poziomy zagnieżdżenia. Dodaj do tego brak breadcrumbs i słabe linkowanie kontekstowe — i produkty na 4. poziomie trafiają do „szarej strefy”. Google je widzi w sitemapie, ale nie dociera do nich przez linki. A jak mówi John Mueller: spójność to najważniejszy czynnik technicznego SEO (Bluesky, lis 2025). Bez spójnej struktury linkowania nie ma spójnego crawlowania.
Co działa: breadcrumbs z poprawnym Schema.org, linki do powiązanych produktów (cross-sell i up-sell), linki z artykułów blogowych do kart produktowych, mapy kategorii w stopce. Każdy z tych elementów daje Googlebotowi dodatkową ścieżkę do głębszych podstron — i sygnał, że te podstrony mają wartość.
W pozycjonowaniu stron i sklepów linkowanie wewnętrzne to jeden z najbardziej niedocenianych elementów. Widzimy sklepy, które inwestują tysiące w link building zewnętrzny, a ich własna struktura linków jest chaotyczna. To jak budowanie autostrady do miasta, w którym nie ma ulic.
Szybkość serwera i renderowanie JavaScript
Czas odpowiedzi serwera (TTFB — Time to First Byte) bezpośrednio wpływa na crawl rate limit. Google zmniejsza częstotliwość zapytań, gdy serwer odpowiada wolno — chroni go przed przeciążeniem, ale kosztem Twojego budżetu crawlowania.
Cel: TTFB poniżej 400 ms dla stron HTML. Sklepy z ciężkimi wtyczkami WooCommerce lub PrestaShop bez cache potrafią mieć TTFB powyżej 2000 ms. Pięć razy powyżej normy. Rozwiązanie: cache na poziomie serwera (Varnish, Redis, LiteSpeed Cache), optymalizacja bazy danych i CDN. Skrócenie ładowania o zaledwie 0,1 sekundy potrafi zwiększyć konwersje o 8% (Deloitte / Google) — ale w kontekście crawl budgetu liczy się jeszcze bardziej, bo każda milisekunda opóźnienia to mniej żądań bota dziennie.
Osobny problem to renderowanie JavaScript. Google musi najpierw pobrać HTML, potem załadować i wykonać JS, a dopiero wtedy „zobaczyć” treść. To kosztuje podwójnie — dwa przejścia crawlera na jedną stronę. Sklep generujący treść dynamicznie przez JS (React, Vue bez SSR) zużywa podwójną porcję crawl budgetu na każdą podstronę. Podwójną. Przy 50 000 URL-i to różnica, która decyduje o indeksacji.
Sitemap XML — porządek w priorytetach crawlowania
Sitemap XML nie zwiększa crawl budgetu, ale pomaga Google mądrzej go rozdzielić. Prawidłowa sitemap zawiera WYŁĄCZNIE strony do indeksowania — czyste URL-e z kodem 200, bez duplikatów, bez zablokowanych w robots.txt.
Częsty błąd: sitemap generowana automatycznie przez Rank Math, Yoast czy moduł Shoper zawiera wszystko — warianty, tagi, archiwa dat, strony z noindex. Googlebot dostaje listę 80 000 URL-i, z których 30 000 nie powinno być indeksowanych. To szum, który obniża efektywność crawlowania. A Google tego szumu nie lubi.
Rozwiązanie: ręczna konfiguracja sitemap. W Rank Math wyłącz: tagi, archiwa autorów, archiwa dat, formaty mediów. W WooCommerce upewnij się, że warianty produktów nie mają własnych URL-i w sitemapie. Użyj lastmod z faktyczną datą modyfikacji treści — Google traktuje ten parametr jako sygnał do ponownego crawlowania.
Google w dokumentacji Search Central (aktualizacja z marca 2026) potwierdza, że lastmod jest brany pod uwagę, gdy odpowiada rzeczywistej zmianie treści. Sztucznie aktualizowane daty lastmod mogą obniżyć zaufanie do całej sitemap.Czy crawl budget wpływa na pozycjonowanie
Crawl budget sam w sobie nie jest czynnikiem rankingowym — Google to wielokrotnie potwierdził. Ale wpływa pośrednio: strona, która nie jest zaindeksowana, nie ma szans na żadną pozycję. Kropka. Optymalizacja crawl budgetu nie poprawi pozycji istniejących stron, ale zapewni, że nowe i zaktualizowane treści trafią do indeksu szybciej.
W e-commerce ten pośredni wpływ jest ogromny. Sklep dodający 200 nowych produktów miesięcznie, który czeka na indeksację, traci potencjalnego ruchu na każdy produkt. Przy marży 15% i średniej wartości zamówienia 180 zł — to policzalny koszt utraconych przychodów. I nikt tego nie raportuje, bo tych sesji po prostu nie widać w analytics.
Drugi aspekt: szybkość aktualizacji indeksu. Zmieniasz ceny, opisy lub dostępność produktów, a Google potrzebuje tygodnia, żeby to „zobaczyć”? W wynikach wyszukiwania wyświetlają się nieaktualne dane. Użytkownik klika, widzi inną cenę, wychodzi. CTR spada.
„Crawl budget to nie ranking factor, ale indeksacja factor. W e-commerce różnica między indeksacją po 2 dniach a po 3 tygodniach to różnica między sprzedażą a pustym ruchem. Optymalizuję crawl budget u klientów nie po to, żeby podnieść pozycje — ale żeby w ogóle dać Google szansę te strony ocenić.”
— Tomasz Węsierski, założyciel Westom, specjalista SEO z kilkunastoletnim doświadczeniem
Typowe błędy, które zabijają budżet crawlowania
8 na 10 sklepów, które trafiają do nas na audyt SEO, ma te same problemy. Powtarzalne, przewidywalne i — co najgorsze — łatwe do uniknięcia od samego początku.
- Łańcuchy przekierowań (redirect chains) — przekierowanie 301 prowadzące do kolejnego 301, które prowadzi do jeszcze jednego. Każde ogniwo zużywa osobne żądanie crawl budgetu. Googlebot śledzi maksymalnie 5 przekierowań w łańcuchu — potem odpuszcza. Widzieliśmy łańcuchy o 8 ogniwach. Osiem.
- Soft 404 — strona zwraca kod 200, ale wyświetla komunikat „Produkt niedostępny” bez żadnej treści. Google musi ją pobrać, zrenderować i przeanalizować, zanim uzna za bezwartościową. Zwracaj kod 410 (Gone) dla trwale usuniętych produktów — to jasny sygnał, że bot nie musi tu wracać.
- Duplicate content bez canonical — ten sam produkt dostępny pod kilkoma URL-ami (z parametrem sesji, ze śledzeniem UTM, z różną ścieżką kategorii). Każdy wariant to osobne żądanie bota. A treść identyczna.
- Strony z nieskończonymi pętlami — kalendarz, generator filtrów, faceted navigation bez limitu — tworzą technicznie nieskończoną liczbę URL-i. Googlebot wchodzi w pętlę i marnuje setki żądań dziennie na strony, których nikt nigdy nie odwiedzi.
- Niewłaściwe hreflang — błędy w implementacji hreflang (brak return tagów, wskazywanie na strony noindex) powodują, że Googlebot wielokrotnie weryfikuje te same relacje językowe. Kiedyś naprawialiśmy hreflang dla expondo na 4 rynkach — samo uporządkowanie return tagów odczuwalnie poprawiło crawlowanie wersji DE i IT.
- Orphan pages — strony bez żadnych linków wewnętrznych. Googlebot je pomija, bo nie ma do nich ścieżki. Jednocześnie zajmują miejsce w sitemapie i zaciemniają obraz. Duchy w Twoim serwisie.
Narzędzia do monitorowania crawl budgetu
Żadne pojedyncze narzędzie nie daje pełnego obrazu crawl budgetu. Potrzebujesz połączenia danych z GSC, logów serwera i crawlera zewnętrznego. Poniżej zestawienie sprawdzonych rozwiązań — i tego, co z każdego wyciągniesz.
| Narzędzie | Co daje w kontekście crawl budgetu | Cena (orientacyjna) |
|---|---|---|
| Google Search Console | Raport Crawl Stats, raport Stron (pokrycie indeksu), raport sitemap | Bezpłatne |
| Screaming Frog SEO Spider | Pełny crawl witryny, analiza logów, identyfikacja duplikatów, łańcuchów 301, orphan pages | 259 GBP/rok |
| JetOctopus | Zaawansowana analiza logów serwera, porównanie crawl vs. indeks, segmentacja URL-i | od 50 USD/mies. |
| Oncrawl | Automatyczna analiza logów, korelacja crawlowania z pozycjami, alerty spadków | od 69 EUR/mies. |
| Ahrefs / Semrush (moduł Site Audit) | Wykrywanie problemów technicznych wpływających na crawl budget (przekierowania, canonical, duplikaty) | od 129 USD/mies. (Ahrefs Lite) |
Dla sklepów do 10 000 podstron wystarczy GSC + Screaming Frog. Powyżej tej granicy inwestycja w narzędzie do analizy logów (JetOctopus lub Oncrawl) się zwraca — pozwala wychwycić problemy niewidoczne w standardowym crawlu. Bo standardowy crawl nie powie Ci, jak często bot wraca na tę samą stronę ani ile czasu spędza na 301-kach.
Kiedy crawl budget NIE jest Twoim problemem
Optymalizacja crawl budgetu ma sens tylko dla serwisów z dużą liczbą URL-i. Twoja strona ma poniżej 5 000 podstron, a serwer odpowiada szybko? Crawl budget niemal na pewno nie jest przyczyną problemów z indeksacją.
Mały sklep z 500 produktami i dobrą strukturą linków Google przeskanuje w całości w ciągu jednego dnia. Jeśli mimo to podstrony nie są indeksowane — szukaj przyczyny gdzie indziej: w dyrektywie noindex, w tagu canonical wskazującym na inny URL, w niskiej jakości treści albo w ręcznych sankcjach. Nie wszystko da się zrzucić na crawl budget.
Sam Google w dokumentacji Search Central pisze wprost: „Jeśli Twoja witryna nie ma setek tysięcy stron, prawdopodobnie nie musisz się martwić o crawl budget”. To ważne zastrzeżenie. Zbyt wielu SEO-wców diagnozuje „problem z crawl budgetem” w serwisach, gdzie problemem jest po prostu brak jakości. Bo jak powiedział John Mueller — niektóre treści SEO to cyfrowy kompost: zajmują miejsce, ale nie wnoszą unikalnej wartości (Mueller Report of SEO Memes, gru 2025). I żadna optymalizacja crawl budgetu tego nie naprawi.
Typowe sytuacje, w których crawl budget nie jest winny: strona nie jest indeksowana, bo ma noindex w meta robots; strona jest w indeksie, ale na dalekiej pozycji (to kwestia jakości i autorytetu, nie crawlowania); strona zniknęła z indeksu po aktualizacji algorytmu — quality issue, nie crawl issue.
Strategia optymalizacji crawl budgetu — od czego zacząć
Zacznij od danych, nie od zmian. Pobierz raport z GSC, przeanalizuj logi serwera za ostatnie i zestawij wyniki crawla Screaming Frog z mapą sitemap. Dopiero z tą wiedzą podejmuj decyzje — inaczej działasz w ciemno.
Priorytet pierwszy: blokada ścieżek marnujących crawl budget w robots.txt. Działa od razu, nie wymaga ingerencji w kod sklepu. Priorytet drugi: prawidłowe tagi canonical na wariantach produktów i stronach filtrów. Priorytet trzeci: porządek w sitemapie — usunięcie URL-i, które nie powinny być indeksowane.
Priorytet czwarty (długoterminowy): poprawa struktury linków wewnętrznych, przyspieszenie serwera i eliminacja problemów z renderowaniem JS. To wymaga więcej czasu i zasobów, ale daje trwały efekt. A trwały efekt to w SEO jedyny efekt, na który warto pracować.
Crawl budget to jedno z tych zagadnień SEO, które nie daje natychmiastowego skoku pozycji, ale bez jego optymalizacji reszta działań — treści, linki, UX — nie ma szans zadziałać. Jeśli Google nie widzi Twoich stron, nie może ich ocenić. A jeśli ich nie oceni — nie wyświetli ich nikomu.
Regularny monitoring crawl budgetu — raz w miesiącu sprawdzenie raportu GSC i zestawienie z danymi z logów — pozwala wychwycić problemy, zanim wpłyną na indeksację. W e-commerce, gdzie katalog zmienia się dynamicznie, to nie opcja. To element podstawowej higieny pozycjonowania strony.
