Audyt crawlability i indeksacji to systematyczna diagnoza techniczna strony, która odpowiada na pytanie, czy Google może poprawnie znaleźć, zrozumieć i zaindeksować każdą ważną podstronę. Niewykryte błędy w robots.txt, sitemap.xml, tagach canonical albo architekturze adresów URL mogą blokować indeksację mimo dobrej treści. Ten artykuł prowadzi przez cały audyt, od Google Search Console przez Screaming Frog po analizę logów serwera, i pokazuje, jak ustalić kolejność napraw według wpływu na widoczność organiczną. Jeśli szukasz profesjonalnego wsparcia, sprawdź audyt SEO.

Czym jest crawlability i dlaczego różni się od indeksacji

Crawlability to możliwość pobrania strony przez Googlebota; to warunek konieczny indeksacji, ale nie jej gwarancja. Większość problemów z widocznością organiczną ma źródło właśnie w tej warstwie: Google albo nie może pobrać strony, albo pobiera ją, ale jej nie indeksuje. To dwa osobne procesy i w każdym coś może się zepsuć.

Skanowanie (crawlowanie) oznacza, że Googlebot odwiedza adres URL, pobiera HTML i przetwarza zawartość. Indeksowanie to kolejny krok: Google analizuje pobraną treść i decyduje, czy dodać ją do indeksu. Strona może być skanowana, ale niezaindeksowana (np. gdy ma tag noindex). Może też od miesięcy być w indeksie, choć Googlebot dawno jej nie odwiedzał.

Crawlowanie vs indeksowanie: kluczowa różnica

Proces Co to jest Co go blokuje Przykład
Crawlowanie Googlebot pobiera HTML strony Disallow w robots.txt, timeout serwera, błąd 5xx Disallow: / blokuje cały serwis
Indeksowanie Google dodaje stronę do bazy danych Tag noindex, thin content, canonical wskazujący gdzie indziej <meta name="robots" content="noindex">

Kluczowe rozróżnienie: robots.txt blokuje crawl (i tym samym uniemożliwia indeksację). Tag noindex pozwala na crawl, ale blokuje sam zapis do indeksu. Gdy Googlebot ponownie odwiedzi stronę i odczyta noindex, usunie ją z indeksu; tymczasowo ukryć adres szybciej pozwala narzędzie Usunięcia w Search Console.

Jak Googlebot odkrywa i przetwarza strony

Googlebot działa w takiej kolejności: kolejka adresów → pobranie HTML → odczyt linków → kolejka renderowania (JavaScript) → przetworzenie → indeks. Ważną rolę odgrywa mapa witryny XML, która przyspiesza odkrywanie nowych adresów, szczególnie przy słabym linkowaniu wewnętrznym.

Jeden aspekt jest często pomijany: renderowanie JavaScriptu to osobny etap. Googlebot najpierw pobiera HTML, a stronę z JavaScriptem renderuje później. Według Google czas oczekiwania zwykle liczy się w sekundach, ale treść i linki widoczne dopiero po renderowaniu łatwiej giną, gdy skrypty są wolne, zablokowane albo zwracają błędy. Najważniejsze treści i linki powinny więc być w HTML od razu.

Ile trwa indeksowanie strony w Google

Google podaje, że indeksowanie trwa od kilku dni do kilku tygodni od zgłoszenia adresu. Tak samo jest z ponownym skanowaniem strony po zmianach. Wielokrotne zgłaszanie tego samego adresu w narzędziu Sprawdzanie adresu URL indeksowania nie przyspiesza, a liczba zgłoszeń jest ograniczona.

Czas zależy głównie od tego, jak często Googlebot odwiedza serwis i czy znajdzie link do nowej strony. Adres podlinkowany ze strony głównej albo z listy wpisów, którą robot odwiedza często, zostaje odkryty szybciej niż adres dostępny tylko w mapie witryny. Status „Strona zeskanowana, ale jeszcze niezindeksowana” w raporcie Indeksowanie stron oznacza, że Google stronę pobrał, ale nie dodał jej jeszcze do indeksu. Sam status nie mówi, dlaczego tak się stało.

Na tym blogu w pomiarze z 23.10.2026 Google ostatnio skanował 13 z 14 niezindeksowanych wpisów w czerwcu i lipcu, czyli kilka miesięcy przed pomiarem. Jeśli strona po 4 tygodniach od zgłoszenia nadal nie jest w indeksie, sprawdź po kolei przyczyny opisane niżej w sekcji o typowych błędach blokujących indeksację.

Kiedy przeprowadzić audyt crawlability i indeksacji

Audyt crawlability trzeba przeprowadzić przed każdą migracją, po przebudowie strony i po każdym nagłym spadku widoczności organicznej o ponad 15%. Brak audytu po migracji domeny albo CMS to jedna z najczęstszych przyczyn utraty 20–40% ruchu organicznego, co regularnie widzę w projektach.

Czas realizacji zależy od skali serwisu: 2-4 godziny dla serwisu do 500 podstron, 5-14 dni dla dużego e-commerce z tysiącami produktów i filtrów. To drugie wymaga głębszej analizy crawl budgetu i parametryzacji URL.

Sytuacje wymagające natychmiastowego audytu

Pięć scenariuszy, w których audyt crawlability powinien być pierwszym krokiem diagnostycznym:

  1. Nagły spadek widoczności organicznej o >15% tydzień do tygodnia: zanim założysz problem z treścią, sprawdź robots.txt i raport „Indeksowanie stron”
  2. Migracja domeny albo CMS: przekierowania, nowy robots.txt, mapa witryny XML; każdy z tych elementów może blokować indeksację
  3. Przebudowa z nowym szablonem: zmiana struktury adresów, nowe pliki JS i CSS, nowe zasady canonical
  4. Core update Google: aktualizacje często ujawniają istniejące problemy z indeksacją, które wcześniej nie wpływały na pozycje
  5. Dodanie dużej liczby podstron (nowa kategoria produktów, import asortymentu): ryzyko, że budżet indeksowania pójdzie na strony niskiej jakości

Cykl regularnych przeglądów

Typ przeglądu Częstotliwość Zakres Narzędzia
Monitoring GSC Miesięcznie Coverage Report, Crawl Stats, błędy Google Search Console
Crawl techniczny Kwartalnie Pełny crawl serwisu, redirect chains, duplikaty Screaming Frog lub Sitebulb
Pełny audyt crawl Co 6 miesięcy Wszystkie warstwy + logi serwera + AI crawlability GSC + SF + log analyzer

Minimum dla małego serwisu: raport „Indeksowanie stron” w GSC raz w miesiącu i pełne skanowanie co kwartał. W e-commerce z ponad 10 000 podstron: GSC co tydzień, pełny audyt co kwartał.

Narzędzia do audytu crawlability i indeksacji

Do 80% audytu crawlability wystarczą bezpłatne narzędzia: Google Search Console, bezpłatna wersja Screaming Frog (do 500 adresów) i logi serwera; każde analizuje inną warstwę problemu i daje inne dane. Wybór narzędzia zależy od skali serwisu i pytania, na które szukasz odpowiedzi.

Narzędzie Koszt Do czego Ograniczenia
Google Search Console Bezpłatne Perspektywa Google: co jest zaindeksowane, raport „Indeksowanie stron”, statystyki indeksowania Dane z opóźnieniem do 72h, brak widoku pełnego crawlu
Screaming Frog SEO Spider (free) Bezpłatne Symulacja crawlu, status codes, canonical, noindex Limit 500 URL
Screaming Frog SEO Spider (paid) 199 GBP rocznie (odczyt 22.10.2026) Bez limitu URL, eksport, integracja z GSC/GA4 Brak wizualizacji architektury
Sitebulb według aktualnego cennika Wizualizacja crawl depth, architektura dla dużych serwisów Płatny, wygodniejszy do prezentacji wyników
Screaming Frog Log File Analyser według aktualnego cennika Realna aktywność Googlebota z logów Wymaga dostępu do logów serwera
GoAccess Bezpłatny (open source) Analiza logów, user-agent filtering CLI, wymaga umiejętności technicznych

Google Search Console: bezpłatne minimum

Google Search Console to jedyne narzędzie, które pokazuje, jak Google faktycznie widzi Twój serwis, a nie jak symuluje to zewnętrzny robot. Trzy najważniejsze raporty w audycie crawlability:

Raport Indeksowanie stron (dawniej Stan): dzieli adresy na dwie grupy, Zaindeksowane i Niezaindeksowane, a przy niezaindeksowanych podaje przyczynę. Duża rozbieżność między liczbą zaindeksowanych adresów a liczbą adresów w mapie witryny to sygnał alarmowy: albo Google nie indeksuje części ważnych stron, albo do indeksu trafiają adresy, które nie miały się tam znaleźć.

Raport Ustawienia → Statystyki crawlowania: wykres liczby URL crawlowanych dziennie, kody odpowiedzi, czas pobierania. Nagły spadek liczby crawlowanych URL lub wzrost błędów 4xx/5xx wymaga natychmiastowej reakcji.

Narzędzie Sprawdzanie adresu URL: pokazuje dla pojedynczego adresu, czy jest zaindeksowany, kiedy był ostatnio skanowany i co Google widzi po renderowaniu. Widok przetestowanej strony pokazuje HTML po wykonaniu JavaScriptu i często ujawnia treści niewidoczne dla Googlebota.

Przyczyna w raporcie Co oznacza Priorytet naprawy
Zaindeksowana Strona jest w indeksie Google –
Błąd serwera (5xx), błąd przekierowania Googlebot nie mógł pobrać strony Krytyczny
Strona zeskanowana, ale jeszcze niezindeksowana Google pobrał stronę i na razie jej nie dodał; zwykle chodzi o jakość lub podobieństwo do innych stron Wysoki
Strona wykryta – obecnie niezindeksowana Google zna adres, ale odłożył skanowanie (np. przeciążony serwer, zbyt wiele adresów) Średni
Duplikat bez wskazanej strony kanonicznej Brak lub błędny canonical Wysoki
Wykluczona za pomocą tagu noindex Tag noindex: świadoma decyzja? Weryfikacja
Zablokowana przez plik robots.txt Blokada w robots.txt: celowa? Weryfikacja
Nie znaleziono (404) Strona usunięta bez przekierowania Średni

Screaming Frog i Sitebulb: crawl techniczny

Screaming Frog to standardowe narzędzie do skanowania w SEO: bezpłatna wersja (500 adresów) wystarcza do większości audytów małych serwisów, a płatna (259 GBP/rok) daje pełne możliwości przy e-commerce. Najważniejsze zakładki w audycie crawlability:

  • Response Codes: czerwone 5xx (błędy serwera, priorytet krytyczny), pomarańczowe 4xx (404, utrata sygnałów z linków), żółte 3xx (przekierowania; sprawdź łańcuchy)
  • Canonical: filtr „canonical points to different URL” (możliwy problem) i „no canonical” (każda strona powinna mieć self-canonical)
  • Directives: filtry noindex i nofollow, czyli sprawdzenie, czy te dyrektywy mają tylko strony, które chcesz wykluczyć
  • Redirects: raport „3XX Chains”, czyli łańcuchy dłuższe niż dwa przekierowania

Sitebulb sprawdza się lepiej przy złożonej architekturze: lepiej pokazuje głębokość stron i strukturę serwisu, a raporty łatwiej przekazać klientom. Do 5000 adresów i szybkiej diagnozy wybierz Screaming Frog. Gdy potrzebujesz prezentacji architektury albo serwis ma ponad 50 000 podstron, lepszy będzie Sitebulb.

Analiza logów serwera: zaawansowany poziom

Logi serwera to jedyne pewne źródło wiedzy o rzeczywistej aktywności Googlebota: nie symulacja, tylko zapis każdego żądania HTTP, które Googlebot wysłał do Twojego serwera. Screaming Frog symuluje skanowanie, ale nie powie Ci, które adresy Googlebot odwiedza najczęściej, a które pomija od miesięcy.

Jak pobrać logi: pliki access.log (Apache) lub access.log (Nginx) dostępne przez panel hostingowy lub FTP. Zawierają: IP, datę, metodę HTTP, URL, kod odpowiedzi, rozmiar, user-agent. Szukaj wpisów z user-agent „Googlebot”.

Praktyczny wynik analizy logów: lista URL z >20 wizytami Googlebota w miesiącu, które nie generują wzrostu w indeksie = zmarnowane skanowanie: Googlebot wydaje budżet na strony niskiej wartości zamiast na nowe produkty. To jeden z najczęstszych problemów w e-commerce z filtrami WooCommerce lub Magento. Omówienie technicznego SEO zawiera szerszy kontekst tej warstwy diagnostycznej.

Audyt krok po kroku: metodologia i przepływ pracy

Audyt crawlability i indeksacji zaczyna się od Google Search Console (stan indeksacji), potem obejmuje sprawdzenie konfiguracji technicznej, skanowanie narzędziem i analizę duplikatów; w serwisie do 500 podstron zajmuje 2–4 godziny. Zawsze zaczynam od GSC, a nie od Screaming Frog, bo GSC pokazuje dane samego Google, a zewnętrzny robot tylko symuluje jego zachowanie.

Krok 1. Sprawdź status indeksacji w GSC (raport Indeksowanie stron)

Otwórz GSC → Indeksowanie → Strony i porównaj liczbę zaindeksowanych adresów z oczekiwaniami. Jeśli serwis ma 500 stron produktów, a GSC pokazuje 120 zaindeksowanych, masz problem. Sytuacja odwrotna (GSC pokazuje 2000 adresów, a serwis ma 500 stron) oznacza, że do indeksu trafiają duplikaty adresów.

Przyczyny do zbadania w pierwszej kolejności:

  • „Strona zeskanowana, ale jeszcze niezindeksowana”: Google pobrał stronę, ale uznał, że nie warto jej teraz dodawać do indeksu. Najczęściej to cienka treść, duplikat albo strona podobna do wielu innych w serwisie.
  • „Strona wykryta – obecnie niezindeksowana”: Google zna adres, ale jeszcze go nie odwiedził. Zwykle oznacza to zbyt wiele adresów do skanowania albo wolny serwer.
  • „Zablokowana przez plik robots.txt”: czy to celowa blokada? Szczególnie niebezpieczne po migracji z serwera testowego.
  • „Wykluczona za pomocą tagu noindex”: sprawdź, czy każda taka strona rzeczywiście ma być poza indeksem.

Sprawdzanie adresu URL dla konkretnych stron: wpisz adres ważnego produktu albo kategorii i sprawdź datę ostatniego skanowania. Jeśli Googlebot nie odwiedzał strony od ponad 30 dni, choć jest w mapie witryny, to sygnał do głębszej analizy.

Krok 2. Zweryfikuj robots.txt i sitemap.xml

Otwórz twojadomena.pl/robots.txt i przeskanuj zawartość pod kątem błędów blokujących indeksację. Trzy krytyczne przypadki:

  1. Disallow: / blokuje cały serwis. To najczęstszy błąd po przeniesieniu strony z serwera testowego. Środowisko testowe miało blokadę, której nikt nie usunął przed startem. Naprawa zajmuje 5 minut, a skutki są katastrofalne, jeśli błąd zostaje niewykryty przez tygodnie.
  2. Blokada /wp-content/ lub katalogów z CSS/JS: uniemożliwia Google renderowanie strony. Googlebot nie może przetworzyć JavaScript i CSS, które są niezbędne do wyrenderowania treści.
  3. Brak Allow dla zasobów krytycznych do renderowania.

W GSC otwórz Ustawienia → raport robots.txt: pokazuje, kiedy Google pobrał plik i czy nie było błędów. Czy konkretny adres jest zablokowany, sprawdzisz narzędziem Sprawdzanie adresu URL. Dawny tester robots.txt Google wycofał w grudniu 2023 r.

sitemap.xml: sprawdź trzy rzeczy: czy plik istnieje (twojadomena.pl/sitemap.xml), czy jest zgłoszony w GSC (Indeksowanie → Mapy witryny) i czy nie zawiera adresów z tagiem noindex, bo wtedy mapa promuje strony, które serwis sam wyklucza z indeksu. W Screaming Frog wczytaj adresy z mapy witryny i porównaj z wynikami skanowania; każdy adres z mapy z błędem 4xx albo noindex trzeba poprawić.

Krok 3. Uruchom crawl i przeanalizuj błędy

Screaming Frog: uruchom crawl całego serwisu i przejdź przez zakładki Response Codes, Directives i Redirects w podanej kolejności. Priorytet błędów:

  • 5xx (błędy serwera): priorytet krytyczny. Googlebot trafił na niedostępną stronę i GSC może pokazać ją jako błąd serwera.
  • 4xx (404): priorytet wysoki. Sygnały z linków zewnętrznych i wewnętrznych przepadają. Strony 404, do których prowadzą linki zewnętrzne, wymagają przekierowania 301.
  • Łańcuchy 3xx: priorytet średni. Łańcuchy dłuższe niż dwa przekierowania marnują budżet indeksowania i opóźniają przekazanie sygnałów.

Wyeksportuj do CSV: URL, Status Code, Redirect URL, Canonical. To podstawa do ustalenia kolejności napraw. Błędy 4xx w Screaming Frog znajdziesz w zakładce Response Codes → filtr „4xx”. Porównaj tę listę z Ahrefs: adresy, do których prowadzą linki zewnętrzne, przekieruj 301 w pierwszej kolejności.

Krok 4. Sprawdź canonical tagi i duplikaty URL

W Screaming Frog filtr Canonical → „canonical points to different URL” pokazuje strony, których canonical wskazuje inny adres; to problem, jeśli canonical jest błędny. Sprawdź też filtr „no canonical”: każda strona powinna mieć canonical wskazujący na siebie, co chroni przed duplikatami z parametrów w adresach.

Szybki test duplikatów: wpisz w Google site:twojadomena.pl i sprawdź przybliżoną liczbę zaindeksowanych stron. Następnie wpisz site:twojadomena.pl inurl:?color= albo inurl:?sort=. Jeśli wyników jest więcej niż 10, parametry w adresach tworzą duplikaty, które trafiają do indeksu.

Canonical, noindex czy robots.txt? Kiedy co stosować:

  • Canonical: gdy duplikat musi być dostępny dla użytkowników (np. strona filtrowana), ale nie powinien wchodzić do indeksu jako osobna strona
  • Noindex: gdy strona nie powinna być w indeksie, ale Googlebot może ją crawlować (np. strony koszyka, konta użytkownika)
  • robots.txt Disallow: gdy strona nie powinna być nawet crawlowana (oszczędza crawl budget, ale nie usuwa z indeksu jeśli już jest)

Crawl budget: co to jest i jak go optymalizować

Budżet indeksowania (crawl budget) to liczba stron, które Googlebot może i chce odwiedzić w danym serwisie w określonym czasie; w e-commerce często idzie na strony filtrów i adresy z parametrami zamiast na nowe produkty i kategorie. Google opisuje go jako połączenie dwóch składników.

Limit wydajności skanowania (crawl rate limit) zależy od kondycji serwera. Im szybciej serwer odpowiada, tym więcej połączeń Googlebot może otwierać jednocześnie bez przeciążenia. Wolny hosting dosłownie zmniejsza dostępny budżet. Core Web Vitals i czas odpowiedzi serwera bezpośrednio wpływają na ten składnik.

Zapotrzebowanie na skanowanie (crawl demand) zależy od popularności stron. Strony z wieloma linkami zewnętrznymi i dużym ruchem organicznym Googlebot odwiedza częściej. Nowe strony bez linków i ruchu mogą tygodniami czekać na pierwszą wizytę.

Kiedy budżet indeksowania jest realnym problemem: w serwisach poniżej 1000 podstron praktycznie nigdy. Staje się krytyczny powyżej 10 000 podstron, szczególnie w WooCommerce i innych platformach e-commerce, które tworzą warianty adresów przez filtry (kolor, rozmiar, sortowanie). Przykład: sklep z 5000 produktów i 20 atrybutami filtrów może mieć setki tysięcy unikalnych adresów, które robot skanuje zamiast stron docelowych.

Jak sprawdzić: GSC → Ustawienia → Statystyki crawlowania → wykres URL crawlowanych dziennie i kody odpowiedzi.

Jak oszczędzać budżet indeksowania: 5 działań według priorytetu:
1. Usuń linki do adresów bez wartości: strony z parametrami filtrów, sesji i wyszukiwarki wewnętrznej; noindex nie oszczędza budżetu, bo Google i tak je skanuje
2. robots.txt Disallow dla parametrów nieistotnych dla SEO, np. ?sort=price, ?sessionid=
3. Usunięcie łańcuchów przekierowań: każdy łańcuch to dodatkowe żądania HTTP, które marnują budżet
4. Linkowanie wewnętrzne do ważnych stron: więcej linków do najważniejszych produktów i kategorii zwiększa zapotrzebowanie na ich skanowanie
5. Szybszy serwer: bezpośrednio podnosi limit wydajności skanowania

Typowe błędy blokujące indeksację i jak je naprawić

Najczęstsze błędy blokujące indeksację to przypadkowy Disallow: / w robots.txt po migracji, łańcuchy dłuższe niż dwa przekierowania, duplikaty URL z parametrów filtrów i treści ładowane przez JavaScript niedostępne dla Googlebota. Każdy z tych błędów ma konkretny objaw diagnostyczny, narzędzie do weryfikacji i ścieżkę naprawy.

Błędny robots.txt: najczęstszy przypadek

Objaw w GSC: raport „Zablokowane przez robots.txt” dla ważnych stron produktowych lub kategorii.

Przyczyna 1 (krytyczna): Disallow: / w pliku robots.txt. Najczęściej dzieje się to po migracji z serwera testowego lub stagingowego, który miał tę regułę ustawioną. Deweloper zapomina o jej usunięciu przed startem produkcyjnym. Czas diagnozy: 30 sekund (sprawdzenie twojadomena.pl/robots.txt). Czas naprawy: 5 minut. Czas ujawnienia w GSC: 1-3 dni.

Przyczyna 2 (wysoki priorytet): blokada /wp-content/plugins/ albo /wp-content/themes/, czyli plików CSS i JS, których Google potrzebuje do renderowania strony. Bez nich Googlebot nie odtworzy wyglądu strony ani działania JavaScriptu.

Diagnoza: raport robots.txt w Ustawieniach GSC i narzędzie Sprawdzanie adresu URL dla konkretnych stron. Dodaj Allow: /wp-content/ dla zasobów potrzebnych do renderowania.

Łańcuchy przekierowań (redirect chains)

Objaw w Screaming Frog: zakładka Redirects → filtr „3XX Chains” wyświetla URL z łańcuchami A → B → C (lub dłuższymi).

Dlaczego to problem: każdy dodatkowy krok w łańcuchu to dodatkowe żądanie HTTP, a w dużym serwisie z ograniczonym budżetem indeksowania to marnowanie budżetu. Do tego sygnały z linków zewnętrznych docierają do celu z opóźnieniem.

Naprawa: zaktualizuj linki wewnętrzne i przekierowania bezpośrednio do końcowego URL, eliminując pośrednie etapy. Narzędzie: w Screaming Frog wyeksportuj listę „Chains”, zidentyfikuj URL źródłowe i zaktualizuj przekierowania w .htaccess lub konfiguracji serwera.

Duplikaty URL z parametrów filtrów

Objaw w GSC: „Zduplikowana, bez zaznaczonego kanonicznego” jako stan Coverage Report. Potwierdzenie: site:twojadomena.pl inurl:?sort= zwraca setki wyników.

Przyczyny: parametry sortu (?sort=price), filtrów (?color=red&size=M), sesji (?sessionid=abc123), paginacji (?page=2). Każda unikalna kombinacja parametrów tworzy osobny URL, który Googlebot traktuje jako osobną stronę.

Trzy rozwiązania (wybór zależy od kontekstu):
1. Canonical na wersję bez parametrów: szybkie wdrożenie; strona z parametrem jest skanowana, ale nie indeksowana jako osobna strona
2. robots.txt Disallow dla parametrów nieistotnych dla SEO: oszczędza budżet indeksowania, ale robot w ogóle nie odwiedzi tych stron
3. Noindex na stronach z parametrami: Google je skanuje, ale nie indeksuje. W WooCommerce ustaw noindex dla stron tworzonych przez wtyczkę filtrów (np. FiboFilters, WOOF).

Renderowanie JavaScriptu a widoczność treści w Google

Objaw: GSC URL Inspection → „View tested page” → zakładka HTML pokazuje inną (uboższą) treść niż ta, którą widzisz w przeglądarce po pełnym załadowaniu.

Przyczyna: treści ładowane przez JavaScript, np. leniwie ładowane obrazy i tekst, aplikacje jednostronicowe (React, Vue, Next.js) albo listy produktów renderowane w przeglądarce. Googlebot najpierw pobiera surowy HTML, a JavaScript renderuje w osobnym etapie, więc treść widoczna dopiero po renderowaniu trafia do indeksu później i łatwiej o błędy.

Test diagnostyczny: Ctrl+U w przeglądarce → surowy HTML. Następnie GSC URL Inspection → „View tested page” → HTML. Porównaj: czy kluczowe treści (H1, opisy, linki wewnętrzne) są w surowym HTML, czy pojawiają się dopiero po renderowaniu?

Rozwiązanie: renderowanie po stronie serwera (SSR) albo generowanie statycznych stron (SSG) dla najważniejszych treści. Minimum: H1, meta description, linki wewnętrzne i główna treść muszą być w surowym HTML, a nie pojawiać się dopiero po załadowaniu JS.

Strony osierocone i strony dalej niż 3 kliknięcia od głównej

Objaw: strony zaindeksowane w GSC, ale bez ruchu organicznego i bez żadnych linków wewnętrznych. Strony osierocone (orphan pages) Google odkrył np. z linku zewnętrznego albo ze starej mapy witryny, ale serwis do nich nie linkuje.

Jak je wykryć: (1) wyeksportuj z GSC listę zaindeksowanych adresów, (2) wyeksportuj listę adresów ze skanowania Screaming Frog, (3) porównaj obie listy. Adres obecny w GSC, którego Screaming Frog nie znalazł, to strona osierocona, bo robot nie dotarł do niej przez linki wewnętrzne. Do porównania wystarczy WYSZUKAJ.PIONOWO w Excelu albo Screaming Frog → Bulk Export → All Inlinks.

Crawl depth: użyj SF lub Sitebulb do wizualizacji głębokości struktury. Strony ważne (produkty bestsellery, kluczowe kategorie) nie powinny być głębiej niż 3 kliknięcia od strony głównej. Każdy dodatkowy poziom = mniejsza częstotliwość crawlowania przez Googlebota.

Priorytetyzacja błędów po audycie: matryca wpływ/wysiłek

Po audycie crawlability lista błędów ma zwykle 20–50 pozycji, a macierz wpływu i nakładu pracy pozwala najpierw naprawić to, co blokuje indeksację, a dopiero potem detale. Rolą konsultanta jest właśnie ocena kontekstu biznesowego i wskazanie kolejności napraw, a nie przekazanie listy problemów do samodzielnego rozwiązania.

Matryca 2×2:

Ćwiartka 1: rób od razu (duży wpływ, mały nakład):

  • Disallow: / w robots.txt: naprawa zajmuje 5 minut, a skutki dla indeksacji są katastrofalne
  • noindex na stronie głównej albo w najważniejszych kategoriach: naprawa w 2 minuty
  • Brakująca albo niezgłoszona sitemap.xml: naprawa w 30 minut
  • Łańcuchy przekierowań na adresach z linkami zewnętrznymi: naprawa w 1–2 godziny

Ćwiartka 2: zaplanuj jako projekt (duży wpływ, duży nakład):

  • Przebudowa parametrów w adresach w e-commerce (setki tysięcy zduplikowanych adresów): tygodnie pracy programistów
  • Przejście z renderowania w przeglądarce na renderowanie po stronie serwera w serwisie opartym na React lub Vue: projekt programistyczny
  • Wdrożenie poprawnej architektury canonical dla dużego katalogu produktów: wymaga planu i testów

Ćwiartka 3: rób przy okazji (mały wpływ, mały nakład):

  • Broken link z footera prowadzący do 404 (brak linków zewnętrznych do niego)
  • Brakujący self-canonical na pojedynczej, mało ważnej podstronie

Ćwiartka 4: odłóż (mały wpływ, duży nakład):

  • Zmiana architektury CMS bez strategicznego powodu
  • Refactoring struktury URL stron z minimalnym ruchem organicznym

Jeśli wolisz zlecić ustalenie kolejności napraw i nadzór nad wdrożeniem, zobacz audyt SEO.

Roboty AI: dodatkowa część audytu

Nowoczesny audyt crawlability obejmuje nie tylko Googlebota, ale też roboty AI: GPTBot (OpenAI), ClaudeBot (Anthropic) i PerplexityBot, które w większości nie renderują JavaScriptu i wymagają osobnej konfiguracji w robots.txt.

Trzy kluczowe różnice botów AI względem Googlebota:

  1. Brak obsługi JavaScriptu: większość robotów AI czyta surowy HTML bez renderowania. Jeśli Twoje treści ładuje JS, dla GPTBota czy ClaudeBota one nie istnieją.
  2. Inna częstotliwość odwiedzin: roboty AI odwiedzają serwisy według własnych zasad; Conductor opisał przykład serwisu, który ChatGPT odwiedzał częściej niż Googlebot. Rzeczywiste wizyty sprawdzisz w logach serwera.
  3. Brak narzędzia do ręcznego zgłaszania stron: nie ma odpowiednika Sprawdzania adresu URL z GSC dla ChatGPT ani Perplexity.

Dwa typy botów AI i różne zasady w robots.txt:

Bot Typ Funkcja Strategia
GPTBot Treningowy Dane treningowe modeli OpenAI Zablokowanie nie ogranicza widoczności w wyszukiwaniu ChatGPT
OAI-SearchBot Wyszukiwanie Indeks wyszukiwania w ChatGPT Zablokowanie ogranicza pojawianie się w wynikach wyszukiwania ChatGPT
ChatGPT-User Na żądanie Pobieranie strony, gdy użytkownik o nią poprosi Zablokowanie uniemożliwia ChatGPT otwarcie strony na prośbę użytkownika
ClaudeBot Treningowy Dane treningowe Anthropic Podobna strategia jak GPTBot
Claude-SearchBot Wyszukiwanie Wyniki wyszukiwania w Claude Zablokowanie ogranicza widoczność w wyszukiwaniu Claude
Claude-User Na żądanie Pobieranie strony, gdy użytkownik o nią poprosi Zablokowanie uniemożliwia Claude otwarcie strony na prośbę użytkownika
PerplexityBot Wyszukiwanie Indeks Perplexity Zablokowanie ogranicza pojawianie się w Perplexity

Przykładowa konfiguracja robots.txt dla strategii „chcę być cytowany w AI Search”:

# Wpuść roboty wyszukiwania i pobierania na żądanie
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
Allow: /

# Zablokuj roboty zbierające dane do trenowania (opcjonalnie)
User-agent: GPTBot
User-agent: ClaudeBot
Disallow: /

Jak sprawdzić wizyty botów AI: przeanalizuj logi serwera (access.log) i szukaj user-agentów zawierających „GPTBot”, „ClaudeBot”, „PerplexityBot”, „CCBot”. Częstotliwość wizyt pokaże, jak często roboty AI pobierają Twój serwis.

Warunek konieczny cytowania przez AI: najważniejsze treści muszą być w statycznym HTML. Boty AI nie renderują JavaScriptu, więc jeśli Twoje artykuły eksperckie ładuje React albo Vue bez SSR, dla ChatGPT i Perplexity nie istnieją jako treść do cytowania. Jeśli chcesz przygotować serwis pod AI Search, sprawdź usługę AIO/GEO.

FAQ: pytania o crawlability i indeksację

Po jakim czasie Google indeksuje stronę?

Według Google indeksowanie trwa od kilku dni do kilku tygodni, zależnie od tego, jak często robot odwiedza serwis, od linków wewnętrznych i zewnętrznych oraz od zgłoszenia w GSC. Zgłoszenie adresu w narzędziu Sprawdzanie adresu URL („Poproś o zindeksowanie”) przekazuje stronę do kolejki, ale ponowne zgłoszenia tego samego adresu niczego nie przyspieszają. Duże serwisy z ograniczonym budżetem albo strony bez linków wewnętrznych mogą czekać tygodniami. Niezgłoszona sitemap.xml to jedna z najczęstszych przyczyn opóźnionej indeksacji.

Jak sprawdzić, czy moja strona jest zaindeksowana?

Wpisz w Google site:twojadomena.pl, a wyniki pokażą przybliżoną liczbę zaindeksowanych stron. Dokładniejsze dane: GSC → Indeksowanie → Strony → liczba adresów zaindeksowanych. Narzędzie Sprawdzanie adresu URL pokazuje stan konkretnej podstrony i datę ostatniej wizyty Googlebota.

Co zrobić, gdy Google nie indeksuje strony?

Sprawdź cztery przyczyny w tej kolejności: (1) blokadę w robots.txt: otwórz twojadomena.pl/robots.txt i sprawdź reguły Disallow; (2) tag noindex: sprawdź w źródle strony <meta name="robots">; (3) błędny canonical wskazujący inny adres: sprawdź w Screaming Frog w zakładce Canonical; (4) treść o niskiej wartości albo duplikat: Google może nie indeksować stron, które wnoszą mało nowego. Zgłoś adres w narzędziu Sprawdzanie adresu URL i obserwuj jego stan przez 1–2 tygodnie.

Czym różni się crawlability od indeksacji?

Crawlability to dostępność strony dla Googlebota (pobieranie HTML), indeksacja to dodanie strony do bazy danych Google po jej przetworzeniu. Blokada w robots.txt zatrzymuje crawl i przez to uniemożliwia indeksację. Tag noindex pozwala na crawl, ale blokuje indeksację. Strona może być crawlowana przez miesiące bez wejścia do indeksu (np. thin content), a może być w indeksie od lat bez świeżego crawlu.

Czy robots.txt blokuje indeksację czy tylko crawlowanie?

Robots.txt blokuje tylko skanowanie, a nie bezpośrednio indeksację. Strona, której robot nie odwiedza, nie zostanie zaindeksowana na nowo. Robots.txt nie usuwa jednak strony, która już jest w indeksie, i Google może ją pokazywać w wynikach bez odwiedzania. Do usunięcia z indeksu służy tag noindex (robot musi go odczytać) albo narzędzie Usunięcia w GSC.

Jak przyspieszyć indeksację nowych stron?

Cztery działania od najskuteczniejszego: (1) zgłoś adres w narzędziu Sprawdzanie adresu URL → „Poproś o zindeksowanie”, raz, bo kolejne zgłoszenia nie pomagają; (2) dodaj stronę do sitemap.xml i sprawdź, czy mapa jest zgłoszona w GSC; (3) dodaj linki wewnętrzne z popularnych, często odwiedzanych przez robota stron serwisu; (4) zdobądź linki z innych serwisów, bo Googlebot podąża za linkami zewnętrznymi i przez nie szybciej odkrywa nowe adresy niż przez same mapy witryny.

Kiedy crawl budget ma znaczenie?

W serwisach poniżej 1000 podstron budżet indeksowania rzadko jest problemem, a staje się krytyczny powyżej 10 000 podstron, szczególnie w e-commerce. WooCommerce z wtyczkami filtrów może tworzyć setki tysięcy wariantów adresów (każda kombinacja filtrów to osobna strona) i zużywać cały dostępny budżet na strony bez wartości dla SEO zamiast na nowe produkty. Ważny sygnał: w statystykach indeksowania w GSC robot skanuje dziennie dużo adresów, a liczba zaindeksowanych stron nie rośnie proporcjonalnie.

Jak sprawdzić, czy Googlebot odwiedza moją stronę?

Dwa sposoby: (1) GSC → Ustawienia → Statystyki indeksowania, czyli wykres liczby skanowanych adresów dziennie z podziałem na kody odpowiedzi, czas pobierania i typy zasobów; (2) analiza logów serwera (access.log): szukaj wpisów z user-agentem „Googlebot/2.1”. Logi dają dokładniejszy obraz, bo pokazują, które konkretne adresy Googlebot odwiedza, jak często i z jakimi kodami odpowiedzi, a takich danych dla pojedynczych adresów GSC nie podaje.