TL;DR: Jeśli Twoja strona ma mniej niż 10 000 podstron, crawl budget prawie na pewno nie jest Twoim problemem. Przestań go optymalizować. Ale jeśli prowadzisz sklep internetowy z 500 tysiącami stron produktowych, serwis ogłoszeniowy z nieskończonymi parametrami URL albo cokolwiek z nawigacją fasetową — crawl budget po cichu zabija Twoje indeksowanie. Ten przewodnik pokazuje, jak zdiagnozować, czy faktycznie masz problem z crawl budgetem, i jak go naprawić. Odpowiedź jest zazwyczaj nudna: szybsze serwery, czystsze adresy URL, lepszy robots.txt.
Twój faktyczny crawl budget to mniejsza z tych dwóch wartości. Jeśli Google naprawdę chce dziś przeskanować 50 000 Twoich stron (wysoki popyt), ale Twój serwer obsłuży tylko 5 000 zapytań bez degradacji wydajności (niski limit częstotliwości), dostajesz 5 000. Jeśli Twój serwer poradzi sobie ze 100 000 zapytań, ale Google interesuje się tylko 2 000 Twoich stron (niski popyt), dostajesz 2 000.
To jest element, który większość poradników źle interpretuje. Traktują crawl budget jak stały zasób, który trzeba "oszczędzać" blokując nieistotne strony. W rzeczywistości jest dynamiczny, zmienia się codziennie, i dla większości witryn w ogóle nie stanowi wąskiego gardła.
Muszę to powiedzieć jasno, bo widziałem agencje sprzedające optymalizację crawl budgetu stronom z 200 podstronami.
Jeśli Twoja witryna ma mniej niż około 10 000 unikalnych adresów URL, optymalizacja crawl budgetu jest prawie na pewno stratą czasu.
Gary Illyes mówił to wielokrotnie, m.in. na Google I/O i na Twitterze. Jego dokładne sformułowanie: "Jeśli Twoja strona ma kilka tysięcy adresów URL, w większości przypadków będzie crawlowana efektywnie". Martin Splitt, Developer Advocate w Google, potwierdził to w odcinku JavaScript SEO office hours, mówiąc że crawl budget staje się realnym problemem "dopiero gdy masz dziesiątki tysięcy stron lub więcej".
Google crawluje miliardy stron dziennie. Twój 500-stronicowy blog na WordPressie to błąd zaokrąglenia. Google przeskanuje go w całości w ciągu kilku dni od jakiejkolwiek zmiany, bez żadnych specjalnych działań z Twojej strony.
Gdzie crawl budget ma faktyczne znaczenie:
Jeśli żaden z tych scenariuszy Cię nie dotyczy, przeskocz do sekcji FAQ na dole i zajmij się czymś innym. Mówię poważnie. Poświęć czas na jakość treści i linkowanie wewnętrzne. Nadal uważam, że 90% osób robiących "optymalizację crawl budgetu" powinno to usłyszeć: Twój problem prawdopodobnie leży zupełnie gdzie indziej.
2. Sprawdź lukę w indeksowaniu. Porównaj liczbę stron w mapie witryny z liczbą zaindeksowanych stron w raporcie "Strony" w GSC. Jeśli masz 100 000 adresów URL w sitemap, ale tylko 40 000 zaindeksowanych, coś pochłania Twój crawl budget zanim dotrze do stron, które mają znaczenie.
3. Sprawdź logi serwera. To jest właściwa diagnostyka. GSC daje Ci zagregowane dane. Logi serwera dają prawdę — każde pojedyncze żądanie Googlebota, kiedy, do jakiego adresu URL i jaką odpowiedź dostał. Jeśli widzisz, że Googlebot spędza 60% crawlu na stronach paginacji archiwum lub filtrowanych adresach URL, to jest Twój problem, czarno na białym.
Powiem szczerze o pewnym ograniczeniu: nie jestem pewien, czy raport statystyk crawlowania w GSC jest zawsze dokładny. Widzieliśmy rozbieżności między tym, co raportuje GSC, a tym, co pokazują logi serwerów naszych klientów. Czasem znaczące rozbieżności — 30-40% różnicy. Nie wiem, czy to kwestia próbkowania po stronie Google, artefakt cache'owania, czy coś innego. Dlatego zawsze rekomenduję weryfikację w logach serwera, jeśli stawka jest wysoka.
| Sygnał diagnostyczny | Zdrowy | Ostrzeżenie | Krytyczny |
|---|---|---|---|
| Nowa strona zaindeksowana w ciągu | 1-3 dni | 1-2 tygodni | 4+ tygodnie lub nigdy |
| Żądania crawlowania/dzień vs łączna liczba stron w GSC | > 50% stron crawlowanych tygodniowo | 10-50% tygodniowo | < 10% tygodniowo |
| Średni czas odpowiedzi serwera | < 200ms | 200-500ms | > 500ms |
| % crawlu na nieindeksowalnych URL | < 10% | 10-30% | > 30% |
| Łańcuchy przekierowań w crawlu | Brak | < 5% żądań | > 5% trafia w łańcuchy |
| Wskaźnik błędów 5xx podczas crawlowania | 0% | < 1% | > 1% |
Uwaga: te progi to wytyczne oparte na doświadczeniu, wynikające z wzorców obserwowanych w danych klientów SEOJuice, a nie oficjalne wartości opublikowane przez Google. Twoje wyniki mogą się różnić w zależności od wielkości witryny, niszy i architektury serwera.
Jeśli większość Twoich sygnałów mieści się w kolumnie "Zdrowy", nie masz problemu z crawl budgetem. Idź optymalizować coś innego.
To jest czynnik crawl budgetu, który ma największy wpływ i poświęca mu się najmniej uwagi. Wszyscy chcą rozmawiać o robots.txt i mapach witryn. Nikt nie chce rozmawiać o tym, dlaczego ich serwer potrzebuje 1,2 sekundy na odpowiedź na proste żądanie HTML.
Googlebot jest grzeczny. Monitoruje czas odpowiedzi Twojego serwera w czasie rzeczywistym. Jeśli serwer zaczyna zwalniać, Googlebot zmniejsza częstotliwość crawlowania, żeby go nie przeciążyć. Tak działa limit częstotliwości crawlowania. Serwer odpowiadający w 100ms będzie crawlowany dramatycznie częściej niż ten odpowiadający w 800ms.
"Jeśli strona jest naprawdę szybka, Googlebot będzie mógł używać więcej połączeń i crawlować ją szybciej. Jeśli strona zwalnia lub odpowiada błędami serwera, zwolni i będzie crawlować mniej."
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
To bezpośredni cytat z oficjalnego wpisu o crawl budgecie. "Naprawdę szybka" dla Google oznacza czas do pierwszego bajtu (TTFB) poniżej 200ms. Nie czas ładowania strony — TTFB. Czas, jaki serwer potrzebuje na rozpoczęcie wysyłania odpowiedzi HTML.
Szybkie wygrane w kwestii czasu odpowiedzi serwera:
Na stronie jednego klienta SEOJuice (sklep meblowy, mniej więcej 80 000 stron produktowych) obserwowaliśmy, jak częstotliwość crawlowania w GSC spadła z 15 000 żądań dziennie do 3 000 w ciągu dwóch tygodni. Żadnych zmian w treści ani strukturze. Przyczyna? Dostawca hostingu przeniósł ich na nowy klaster serwerów i TTFB wzrosło z 180ms do 900ms. Gdy naprawili hosting, częstotliwość crawlowania wróciła do normy w ciągu czterech dni. Żadnych zmian w robots.txt. Żadnych aktualizacji mapy witryny. Same szybsze serwery.
Parametry URL to najczęstsze źródło marnowania crawlu. Problem jest podstępny, bo często nie wiesz, że to się dzieje.
Weź pod uwagę sklep internetowy z filtrowaniem. Użytkownik przegląda buty i wybiera: rozmiar 42, kolor czarny, marka Nike, sortowanie po cenie, strona 2. To daje URL taki jak:
/buty?rozmiar=42&kolor=czarny&marka=nike&sortuj=cena&strona=2Teraz pomnóż to przez każdą możliwą kombinację. 8 rozmiarów, 12 kolorów, 40 marek, 4 opcje sortowania, 50 stron wyników. To 8 × 12 × 40 × 4 × 50 = 768 000 adresów URL. Z jednej strony kategorii. A treść na większości tych stron znacząco się pokrywa — czarne buty Nike w rozmiarze 42 posortowane po cenie to w większości te same produkty co czarne buty Nike w rozmiarze 42 posortowane po najnowszych.
Googlebot tego nie wie. Widzi 768 000 unikalnych adresów URL i zaczyna je crawlować. Twoje właściwe strony produktowe — te, które powinny się pozycjonować — czekają w kolejce za setkami tysięcy przefiltrowanych wariantów, których nikt nigdy nie wyszuka.
To właśnie ludzie mają na myśli mówiąc, że "nawigacja fasetowa tworzy pułapki crawlowania". Nie chodzi o to, że Google wpada w nieskończoną pętlę (choć to może się zdarzyć przy pewnych ustawieniach paginacji). Chodzi o to, że Google przeznacza swój ograniczony crawl budget na adresy URL, które nie wnoszą żadnej unikalnej wartości.
Chcę tutaj być precyzyjny: narzędzie do parametrów URL w Google Search Console zostało wycofane i usunięte w 2022 roku. Kiedyś Google pozwalał Ci określać, które parametry ignorować. Ta opcja zniknęła. Teraz masz trzy narzędzia do obsługi tego:
Każde rozwiązanie ma swoje kompromisy. Robots.txt i tagi canonical omawiam w osobnych sekcjach poniżej.
Twój robots.txt to pierwszy plik, który Googlebot sprawdza przed crawlowaniem Twojej witryny. To też najbardziej źle rozumiany plik w SEO. Ludzie albo zostawiają go pustym (tracąc okazję), albo przesadzają (blokując rzeczy, których nie powinni).
Oto kluczowa zasada: blokuj rzeczy, które marnują crawl budget, a nie rzeczy, które są "nieistotne". Jest różnica. "Nieistotna" strona może nadal wymagać indeksowania. Strona marnująca crawl budget to taka, która nie wnosi unikalnej wartości do wyszukiwania i istnieje w tysiącach wariantów parametrycznych.
# Blokowanie parametrów nawigacji fasetowej
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Blokowanie wewnętrznych wyników wyszukiwania
Disallow: /search?
Disallow: /search/
# Blokowanie URL-i opartych na sesji
Disallow: /*?sessionid=
Disallow: /*?ref=
# Blokowanie panelu administracyjnego, koszyka i konta
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Blokowanie wersji do druku i PDF
Disallow: /*?print=
Disallow: /*?format=pdf
# NIE blokuj CSS, JS ani obrazów
# Googlebot potrzebuje ich do renderowania Twoich stron
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlKrytyczne błędy, które widziałem:
/products/ bo chce zablokować /products?filter= i przypadkowo deindeksuje cały katalog produktów.Ten ostatni punkt warto powtórzyć, bo wprawia w błąd nawet doświadczonych specjalistów SEO. Robots.txt blokuje crawlowanie. Nie blokuje indeksowania. Jeśli chcesz zapobiec indeksowaniu, użyj <meta name="robots" content="noindex"> lub nagłówka HTTP X-Robots-Tag. Ale pamiętaj: żeby Google zobaczył tag noindex, musi najpierw przeskanować stronę. Więc jeśli blokujesz crawlowanie w robots.txt I dodajesz noindex, Google nigdy nie zobaczy tagu noindex. To tworzy paradoks, który dezorientuje ludzi od lat.
Mapa witryny nie gwarantuje indeksowania. Nie gwarantuje nawet crawlowania. To, co robi, to daje Google wskazówkę, które adresy URL istnieją, kiedy były ostatnio modyfikowane i (dyskusyjnie) jak ważne są względem siebie.
Błędy, które ludzie popełniają z mapami witryn, prawie zawsze dotyczą uwzględniania zbyt wielu rzeczy, nie zbyt mało.
Co uwzględniać w mapie witryny:
<lastmod> — nie bieżącą datę, nie tę samą datę na każdej stronie, ale faktyczną datę ostatniej modyfikacjiCo wykluczać z mapy witryny:
Widziałem mapy witryn z 500 000 adresów URL, z których tylko 80 000 było faktycznie indeksowalnych. Pozostałe 420 000 to przekierowania, strony z noindex, warianty parametryczne i uszkodzone adresy URL. Taka mapa witryny nie pomaga Google — wysyła go na poszukiwanie skarbów, gdzie 84% mapy jest błędne.
Martin Splitt nazwał <lastmod> "jednym z najbardziej nadużywanych tagów w mapach witryn", bo tyle platform CMS ustawia go na bieżącą datę na każdej stronie. Kiedy każda strona mówi "właśnie mnie zmodyfikowano", Google uczy się ignorować ten sygnał. Jeśli Twój CMS nie śledzi rzeczywistych dat modyfikacji, napraw to zanim zaczniesz martwić się o cokolwiek innego związanego z mapą witryny.
Nawigacji fasetowej poświęcam osobną sekcję, bo jest to punkt styku crawl budgetu, duplikatów treści i architektury technicznej — a błędne podejście może po cichu pogrążyć SEO witryny przez miesiące.
Problem: nawigacja fasetowa (filtry w e-commerce, serwisach ogłoszeniowych, portalach pracy) generuje wykładniczą liczbę kombinacji URL. Matematykę omawialiśmy wyżej. Ale rozwiązanie nie jest tak proste jak "zablokuj wszystko w robots.txt", bo niektóre strony fasetowe mają realną wartość wyszukiwania.
Pomyśl o tym: "buty do biegania Nike rozmiar 42" to realne zapytanie wyszukiwania, które prawdziwa osoba wpisuje w Google. Strona fasetowa pasująca do tego zapytania mogłaby się na nie pozycjonować. Blokowanie wszystkich fasetowych adresów URL oznacza utratę tej szansy.
Framework, który rekomenduję (i który wdrażamy dla klientów SEOJuice z tym problemem):
| Typ fasety | Przykład | Wartość wyszukiwania | Zalecane podejście |
|---|---|---|---|
| Kategoria + Marka | /buty/nike/ | Wysoka — ludzie szukają marka+kategoria | Indeksuj, uwzględnij w mapie witryny, użyj czystego URL |
| Kategoria + 1 filtr | /buty?kolor=czarny | Średnia — zależy od wolumenu wyszukiwań | Sprawdź wolumen wyszukiwań. Indeksuj jeśli >100 miesięcznych wyszukiwań, w przeciwnym razie canonical do strony nadrzędnej |
| Kategoria + 2+ filtry | /buty?kolor=czarny&rozmiar=42 | Niska — zbyt szczegółowe dla większości wyszukiwań | Canonical do najbardziej trafnego pojedynczego filtra lub kategorii nadrzędnej |
| Warianty sortowania | /buty?sortuj=cena-rosnaco | Żadna — nikt nie szuka "buty posortowane po cenie" | Blokuj w robots.txt lub noindex |
| Głębokie strony paginacji | /buty?strona=47 | Żadna poza stroną 2-3 | Noindex po stronie 3-5, zachowaj crawlowalność |
| Parametry sesji/śledzenia | /buty?utm_source=email | Żadna | Blokuj w robots.txt, usuwaj na poziomie serwera |
Implementacja tagu canonical dla stron z wieloma filtrami wygląda tak:
<!-- Na /buty?kolor=czarny&rozmiar=42&sortuj=cena -->
<link rel="canonical" href="https://example.com/buty?kolor=czarny" />
<!-- Na /buty?sortuj=cena -->
<link rel="canonical" href="https://example.com/buty" />
<!-- Na /buty (czysta strona kategorii) -->
<link rel="canonical" href="https://example.com/buty" />Jeden błąd, który popełniłem i którego do końca nie rozwiązałem: co robić ze stronami fasetowymi, które zgromadziły backlinki. Jeden klient miał tysiące zewnętrznych linków wskazujących na przefiltrowane adresy URL. Wskazanie ich przez canonical na stronę nadrzędną powinno przenieść equity w górę — brzmi dobrze w teorii.
W praktyce zaobserwowaliśmy 15% spadek pozycji strony nadrzędnej po wdrożeniu tagów canonical. Nadal nie wiem dlaczego. Moje najlepsze przypuszczenie to to, że nagła konsolidacja tysięcy sygnałów zmyliła ocenę Google, ale to spekulacja. Cofnęliśmy tagi canonical na najczęściej linkowanych stronach fasetowych i zostawiliśmy je jako indeksowalne. To kompromis, z którym nie czuję się komfortowo.
Krótka wersja: rel="next" i rel="prev" są wycofane. Google potwierdził w 2019 roku, że nie używał tego sygnału od lat. Więc co robić zamiast tego?
Trzy opcje, uszeregowane według moich preferencji:
Opcja 1: Load-more lub infinite scroll z pushState. To najczystsze podejście dla nowych witryn. Użytkownicy widzą jeden URL. Google crawluje pełną treść. Żadnych adresów URL paginacji do marnowania crawl budgetu. Ale wymaga JavaScriptu, co wprowadza własne koszty crawl budgetu (więcej o tym poniżej).
Opcja 2: Tradycyjna paginacja z noindex na stronie 2+. Zachowaj paginowane adresy URL jako crawlowalne (żeby Google mógł odkryć produkty/artykuły z nich linkowane), ale dodaj noindex, żeby Google nie próbował indeksować identycznych stron szablonowych. Tag canonical na każdej stronie paginacji powinien być samoodwołujący się — nie wskazuj canonical ze wszystkich stron na stronę 1, bo treść jest inna.
Opcja 3: Strona "pokaż wszystko". Jeśli Twoja paginowana treść liczy mniej niż ~200 elementów, rozważ jedną stronę "pokaż wszystko", która konsoliduje serię paginacji przez canonical. Google historycznie preferował strony "pokaż wszystko". Wada: czas ładowania. Jeśli Twoja strona "pokaż wszystko" ładuje się 8 sekund, szkodzi bardziej niż pomaga.
<!-- Strona 2 archiwum bloga -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Ważne: użyj "noindex, follow" — nie "noindex, nofollow"
Chcesz, żeby Google podążał za linkami na stronach paginacji,
żeby odkrył właściwe strony z treścią -->Zwróć uwagę na dyrektywę follow. To kluczowe. Nie chcesz, żeby strona paginacji trafiła do indeksu, ale absolutnie chcesz, żeby Google podążał za linkami na niej, żeby znaleźć Twoją właściwą treść. Użycie nofollow tutaj osierociłoby każdy artykuł lub produkt linkowany tylko ze strony 2+ Twojego archiwum.
Ta sekcja dotyczy każdego, kto prowadzi witrynę intensywnie wykorzystującą JavaScript (React, Vue, Angular, Next.js bez prawidłowego SSR). Jeśli Twoja strona to tradycyjny HTML renderowany po stronie serwera, przeskocz dalej.
Google crawluje w dwóch falach. Pierwsza fala: pobiera i przetwarza surowy HTML. Druga fala: renderuje stronę za pomocą przeglądarki Chromium w trybie headless, żeby wykonać JavaScript i zobaczyć finalną treść. Druga fala następuje później — czasem godziny później, czasem dni.
Martin Splitt wyjaśniał to szczegółowo w swoich JavaScript SEO office hours. Kluczowy wniosek: renderowanie jest kosztowne dla Google. Wymaga więcej zasobów niż proste pobranie HTML. Google musi uruchomić instancję Chromium, wykonać Twój JavaScript, poczekać na odpowiedzi z API i dopiero potem przetworzyć wyrenderowany DOM. To oznacza, że strony zależne od JavaScriptu są crawlowane mniej efektywnie niż strony renderowane po stronie serwera.
Wpływ na crawl budget:
Rozwiązanie: renderowanie po stronie serwera (SSR) lub generowanie statyczne (SSG). Next.js, Nuxt, SvelteKit — wszystkie to wspierają. Jeśli nie możesz wdrożyć pełnego SSR, użyj renderowania dynamicznego: serwuj wyrenderowany HTML Googlebotowi, a pełne doświadczenie JS użytkownikom. Google technicznie to odradza, ale na początku 2026 roku działa to w praktyce. Wyzwania specyficzne dla SPA omawiamy w naszym przewodniku po najlepszych praktykach SEO dla SPA.
Na co zwracać uwagę w logach:
Narzędzia: Screaming Frog Log Analyzer to najpopularniejsze dedykowane narzędzie. Możesz też parsować logi narzędziami wiersza poleceń (grep na user agenta Googlebota, przekierowanie przez awk). Do bieżącego monitoringu funkcja analizy crawlowania w SEOJuice automatycznie przetwarza logi serwera i sygnalizuje problemy z crawl budgetem.
Realny przykład z naszych danych: jeden klient miał witrynę na WordPressie z ~25 000 opublikowanymi wpisami. Dobra treść, przyzwoity ruch. Ale logi serwera pokazywały, że Googlebot spędzał 40% crawl budgetu na endpointach API /wp-json/ i adresach URL /feed/. To nie są strony, których ktokolwiek szuka. Dodanie dwóch linii do robots.txt uwolniło te 40% dla właściwych stron z treścią. W ciągu trzech tygodni częstotliwość crawlowania stron z artykułami wzrosła o 60%, a 12 nowych stron zostało zaindeksowanych po miesiącach spędzonych w czyśćcu "Odkryto — aktualnie nie zaindeksowano".
# Oszczędności crawl budgetu specyficzne dla WordPressa
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/Linki wewnętrzne to najsilniejszy sygnał, nad którym masz kontrolę, żeby powiedzieć Google, które strony mają znaczenie. Nie tagi meta. Nie wartości priorytetu w mapie witryny (które Google i tak ignoruje). Linki wewnętrzne.
Każdy link to głos. Strona linkowana ze strony głównej, nawigacji i 50 innych stron będzie crawlowana częściej niż strona linkowana z jednej strony archiwum ukrytej trzy kliknięcia w głąb. To podstawowa dystrybucja PageRank i tak Googlebot decyduje, na co przeznaczyć crawl budget.
Praktyczne konsekwencje: jeśli strony nie są indeksowane i dzieli je 3+ kliknięcia od strony głównej, dodanie linków wewnętrznych z dobrze połączonych stron zwiększa ich częstotliwość crawlowania. Widzieliśmy to konsekwentnie — strony, które przechodzą z 0-1 linków wewnętrznych do 5+, otrzymują pierwszą wizytę Googlebota w ciągu 48 godzin, nawet na dużych witrynach, gdzie nowe strony zazwyczaj czekają tygodniami.
Dlatego wbudowaliśmy automatyczne linkowanie wewnętrzne w SEOJuice. Ręczne zarządzanie linkami wewnętrznymi na ponad 10 000 stronach jest niemożliwe. Ale korzyści z priorytetu crawlowania czynią z tego jedną z najbardziej opłacalnych aktywności technicznego SEO.
Płaska architektura (każda strona osiągalna w 3 kliknięciach lub mniej) jest lepsza dla crawl budgetu niż głębokie hierarchie. Ale "płaska" nie znaczy "linkuj wszystko do wszystkiego". Oznacza strategiczne linkowanie — klastry tematyczne, strony hubowe, linki kontekstowe — tworzące jasne ścieżki crawlowania do Twoich najważniejszych stron.
Chcę być konkretny o tym, co faktycznie robimy, zamiast rzucać ogólnikami marketingowymi.
SEOJuice śledzi zachowanie crawlerów przez trzy źródła: statystyki crawlowania z GSC (przez Search Console API), nasze własne dane z crawlowania (crawlujemy witryny klientów, żeby zbudować graf linków wewnętrznych) i opcjonalnie, integrację z logami serwera.
Co pokazujemy:
Nie robimy jeszcze pełnej analizy logów w produkcie (parsowanie dowolnych formatów logów serwera na dużą skalę to wyzwanie inżynieryjne, które nie rozwiązałem w sposób, który mnie satysfakcjonuje). Ale dane z GSC plus nasz własny crawler dają większości witryn wystarczająco dużo, żeby zidentyfikować i naprawić problemy z crawl budgetem bez dotykania pliku logów.
Jeśli dotarłeś tak daleko i ustaliłeś, że faktycznie masz problem z crawl budgetem, oto co naprawić, w kolejności wpływu:
Kroki 1-3 rozwiązują problem dla większości witryn, które faktycznie potrzebują optymalizacji crawl budgetu. Kroki 4-9 to reszta — witryny ze złożoną architekturą, gdzie podstawy nie wystarczają.
Nie. Crawl budget wpływa na to, czy Twoje strony zostaną przeskanowane i zaindeksowane, a nie na to, jak się pozycjonują po zaindeksowaniu. Ale strona, która nigdy nie zostanie przeskanowana, nigdy nie zostanie zaindeksowana, a strona, która nigdy nie zostanie zaindeksowana, nie może się pozycjonować. Więc crawl budget to warunek wstępny, nie czynnik rankingowy. Jego optymalizacja nie poprawi pozycji już zaindeksowanych stron — pomaga stronom, które w ogóle nie są indeksowane.
Prawie nigdy. Ustawienia częstotliwości crawlowania w GSC pozwalają Ci zmniejszyć częstotliwość crawlowania przez Googlebota, nie zwiększyć. Jedyny powód to sytuacja, gdy Googlebot dosłownie przeciąża Twój serwer. Jeśli Twój serwer obsłuży ten ruch, zostaw to w spokoju. Widziałem ludzi zmniejszających częstotliwość myśląc, że "skupi" to Google na ważnych stronach. Tak to nie działa — Google po prostu crawluje mniej wszystkiego.
Popularne, często aktualizowane strony: kilka razy dziennie. Statyczne strony niezmieniane od miesięcy: co kilka tygodni. Średnia to mniej więcej co 1-2 tygodnie na stronę, ale różni się ogromnie. Serwisy informacyjne są crawlowane w ciągu minut. Rzadko aktualizowana strona "O nas" może czekać miesiąc między wizytami. Tag <lastmod> może sugerować, że strona się zmieniła, ale tylko jeśli używasz go dokładnie — Google ignoruje go, jeśli jest zawsze ustawiony na dzisiejszą datę.
Możesz zwiększyć limit częstotliwości crawlowania (szybszy serwer) i zmniejszyć marnowanie crawlu (żeby więcej budżetu szło na ważne strony). Ale nie możesz bezpośrednio powiedzieć Google, żeby crawlował Cię więcej. Popyt na crawlowanie to decyzja Google oparta na postrzeganej wartości treści. Najlepsze pośrednie podejście: publikuj regularnie, buduj backlinki, twórz treść, która jest naprawdę użyteczna. Wartościowe witryny są crawlowane agresywniej, automatycznie.
Tak. Google nadal crawluje stronę, żeby zobaczyć tag noindex. 100 000 stron z noindex to 100 000 trafień w crawl budget (choć rzadszych niż w przypadku zaindeksowanych stron). Jeśli te strony naprawdę nigdy nie potrzebują indeksowania, robots.txt jest bardziej efektywny pod kątem crawlowania — ale blokowanie w robots.txt uniemożliwia Google zobaczenie czegokolwiek na stronie, w tym linków. Używaj noindex+follow, gdy chcesz odkrywania linków, ale nie indeksowania. Używaj robots.txt, gdy nie chcesz, żeby strona była crawlowana w ogóle.
Ten artykuł jest częścią naszej serii o technicznym SEO. Jeśli pracujesz nad problemami z crawl budgetem, te powiązane przewodniki Ci pomogą:
Jeśli prowadzisz dużą witrynę i chcesz automatycznego monitorowania crawl budgetu, SEOJuice śledzi marnowanie crawlu, prędkość indeksowania i czas odpowiedzi serwera na wszystkich Twoich stronach. Nie zastąpi analizy logów w przypadku złożonych architektur, ale wykrywa większość problemów z crawl budgetem, które mają znaczenie — ciągle, a nie tylko gdy ktoś sobie przypomni o audycie. Rozpocznij darmowy okres próbny i sprawdź, na co idzie Twój crawl budget w kilka minut.
no credit card required
No related articles found.