Audyt crawlability i indeksacji – krok po kroku

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ę. Niezdiagnozowane błędy w robots.txt, sitemap.xml, canonical tagach lub architekturze URL mogą blokować indeksację mimo dobrej treści. Ten artykuł prowadzi przez kompletny przepływ audytu – od Google Search Console, przez Screaming Frog, po analizę logów serwera – z priorytetyzacją błędów 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 zdolność strony do bycia pobieraną przez Googlebota – niezbędny warunek 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 odmawia jej zaindeksowania. To dwa osobne procesy z osobnymi punktami awarii.

Crawlowanie oznacza, że Googlebot odwiedza adres URL, pobiera HTML i przetwarza zawartość. Indeksowanie to kolejny krok – Google analizuje pobraną treść i decyduje, czy warto ją dodać do bazy danych. Strona może być crawlowana, ale nieindeksowana (np. gdy ma tag noindex). Może też znajdować się w indeksie od miesięcy, mimo że Googlebot nie odwiedził jej od dawna.

Crawlowanie vs indeksowanie – kluczowa różnica

Kluczowe rozróżnienie: robots.txt blokuje crawl (i tym samym uniemożliwia indeksację). Tag noindex pozwala na crawl, ale blokuje sam zapis do indeksu. Błąd noindex nie usuwa strony już obecnej w indeksie – do tego trzeba osobnego procesu przez GSC lub nagłówka HTTP.

Jak Googlebot odkrywa i przetwarza strony

Przepływ Googlebota wygląda następująco: URL queue → fetch HTML → parsowanie linków → render queue (JavaScript) → przetworzenie → indeks. Ważną rolę odgrywa sitemap XML – to skrót, który przyspiesza odkrycie nowych URL, szczególnie przy słabej strukturze linkowania wewnętrznego.

Jeden aspekt jest często pomijany: JavaScript rendering jest opóźniony. Google stosuje tzw. second wave – treści załadowane przez JS mogą być przetwarzane z opóźnieniem od kilku godzin do kilku tygodni po pierwszym crawlu. Jeśli kluczowe treści lub linki są ładowane przez JavaScript, Googlebot może je pominąć przy pierwszej wizycie. Szczegółowe omówienie mechanizmu rankowania znajdziesz w artykule jak działa SEO.

Kiedy przeprowadzić audyt crawlability i indeksacji

Audyt crawlability powinien być przeprowadzony obligatoryjnie przed każdą migracją, po redesignie i po każdym nagłym spadku widoczności organicznej o ponad 15%. Brak audytu po migracji domeny lub CMS to jedno z najczęstszych źródeł utraty 20-40% ruchu organicznego – widzę to regularnie 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 zakładasz problem contentowy, sprawdź robots.txt i Coverage Report
2. Migracja domeny lub CMS – przekierowania, nowy robots.txt, sitemap XML – każdy element może blokować indeksację
3. Redesign z nowym szablonem – zmiana struktury URL, nowe pliki JS/CSS, nowe zasady canonical
4. Core Update od Google – aktualizacje często ujawniają istniejące problemy z indeksacją, które wcześniej nie rzutowały na pozycje
5. Dodanie dużej liczby podstron (nowa kategoria produktów, import asortymentu) – ryzyko przepełnienia crawl budgetu na niskiej jakości strony

Cykl regularnych przeglądów

Minimum dla małego serwisu (SMB): GSC Coverage miesięcznie, pełny crawl kwartalnie. Dla e-commerce z >10 000 podstron – monitoring GSC tygodniowo, pełny audyt co kwartał.

Narzędzia do audytu crawlability i indeksacji

Do 80% audytu crawlability wystarczą bezpłatne narzędzia – Google Search Console, Screaming Frog w wersji free (do 500 URL) i logi serwera – każde analizuje inną warstwę problemu i daje inne dane diagnostyczne. Wybór narzędzia zależy od skali serwisu i pytania, które chcesz postawić.

Google Search Console – bezpłatne minimum

Google Search Console to jedyne narzędzie, które pokazuje, jak Google faktycznie widzi Twój serwis – nie jak symuluje to zewnętrzny crawler. Trzy kluczowe raporty do audytu crawlability:

Raport Indeksowanie → Strony (dawny Coverage Report): pokazuje cztery stany – Zaindeksowane (cel), Z błędami (pilny priorytet), Wykluczone (do analizy – czy słusznie?), Ostrzeżenia (do monitoringu). Duża rozbieżność między liczbą zaindeksowanych URL a liczbą URL w sitemapie to sygnał alarmowy.

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 URL Inspection: sprawdzenie pojedynczego URL – czy jest zaindeksowany, kiedy ostatnio crawlowany, co Google widzi po renderowaniu. Zakładka “View tested page” pokazuje HTML po renderowaniu JavaScript – często ujawnia treści niewidoczne dla Googlebota.

Screaming Frog i Sitebulb – crawl techniczny

Screaming Frog to de facto standard crawlera SEO – wersja free (500 URL) wystarcza do większości audytów małych serwisów, wersja płatna (£259/rok) daje pełne możliwości dla e-commerce. Kluczowe zakładki w kontekście crawlability:

• Response Codes: czerwone 5xx (błędy serwera – priorytet krytyczny), pomarańczowe 4xx (404 – strata link equity), żół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 – weryfikacja, czy tylko strony, które chcesz wykluczyć, mają te dyrektywy
• Redirects: zakładka “3XX Chains” – łańcuchy przekierowań dłuższe niż 2 hopy

Sitebulb sprawdza się lepiej przy złożonej architekturze: lepsza wizualizacja crawl depth, mapy serwisu i raportowanie dla klientów. Kiedy SF, kiedy Sitebulb: do 5000 URL i szybkiej diagnozy – Screaming Frog. Gdy potrzebujesz prezentacji architektonicznej lub serwis ma > 50 000 podstron – Sitebulb.

Analiza logów serwera – zaawansowany poziom

Logi serwera to jedyne źródło prawdy o realnej aktywności Googlebota – nie symulacja, lecz zapis każdego żądania HTTP wysłanego przez Googlebot do Twojego serwera. Screaming Frog symuluje crawl, ale nie powie Ci, które URL Googlebot odwiedza najczęściej, a które ignoruje 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 output analizy logów: lista URL z >20 wizytami Googlebota w miesiącu, które nie generują wzrostu w indeksie = crawl waste – Googlebot marnuje 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 (status indeksacji), przechodzi przez weryfikację konfiguracji technicznej, crawl narzędziem i analizę duplikatów – przepływ zajmuje 2-4 godziny dla serwisów do 500 podstron. Jako konsultant zawsze zaczynam od GSC, nie od Screaming Frog – bo to Google ma zawsze rację, a zewnętrzny crawler jedynie symuluje jego zachowanie.

Krok 1 – Sprawdź status indeksacji w GSC (Coverage Report)

Otwórz GSC → Indeksowanie → Strony i skonfrontuj liczbę zaindeksowanych URL z oczekiwaniami. Jeśli serwis ma 500 podstron produktowych, a GSC raportuje 120 zaindeksowanych – masz problem. Odwrotna sytuacja (GSC pokazuje 2000 URL, a serwis ma 500 stron) sygnalizuje zduplikowane URL wchodzące do indeksu.

Stany do zbadania w pierwszej kolejności:
– “Znalezione – aktualnie nie zaindeksowane”: Google odkrył URL (z linków lub sitemaps), ale odmówił indeksacji – najczęściej thin content, duplikat lub niska jakość. Sprawdź, które URL należą do tej grupy.
– “Zablokowane przez robots.txt”: czy to celowa blokada? Szczególnie niebezpieczne po migracji z serwera testowego.
– “Wykluczone przez noindex”: weryfikacja, czy każda wykluczona strona powinna być wykluczona.

Narzędzie URL Inspection dla konkretnych stron: wpisz URL produktu lub kategorii o strategicznym znaczeniu i sprawdź datę ostatniego crawlu. Jeśli Googlebot nie odwiedzał strony od >30 dni, mimo że jest w sitemapie – 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: / – blokada całego serwisu. Najczęstszy błąd po migracji z serwera testowego. Środowisko dev miało blokadę, która nie została usunięta przed startem produkcyjnym. Naprawa: 5 minut, efekt: katastrofalny gdy niezdiagnozowane 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.

Narzędzie GSC → robots.txt Tester (w Ustawieniach): wpisz konkretne URL i sprawdź, czy są zablokowane.

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 URL z tagiem noindex (systemowy błąd: sitemap promuje strony, które sam serwis wyklucza z indeksacji). W Screaming Frog: Crawl → wgraj URL sitemaps i porównaj z wynikami crawlu – każdy URL z sitemaps, który ma błąd 4xx lub noindex, to kandydat do naprawy.

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 napotkał niedostępną stronę, może ją oznaczyć jako crawl error w GSC.
• 4xx (404) – priorytet wysoki. Strata link equity z linków zewnętrznych i wewnętrznych. Strony z zewnętrznymi linkami prowadzącymi do 404 wymagają przekierowania 301.
• 3xx łańcuchy – priorytet średni. Przekierowania dłuższe niż 2 hopy marnują crawl budget i rozmywają link equity.

Eksportuj do CSV: URL, Status Code, Redirect URL, Canonical. To baza do priorytetyzacji napraw. Filtrowanie 4xx w SF: zakładka Response Codes → filtr “4xx”. Wyeksportuj listę i porównaj z Ahrefs (które mają linki zewnętrzne) – te URL wymagają przekierowania 301 w pierwszej kolejności.

Krok 4 – Sprawdź canonical tagi i duplikaty URL

Screaming Frog → Canonical → filtr “canonical points to different URL” ujawnia strony, które same wskazują canonical na inny adres – potencjalny problem, gdy canonical jest błędny. Sprawdź też filtr “no canonical” – każda strona powinna mieć self-canonical jako zabezpieczenie przed duplikacją przez parametry URL.

Szybki test duplikatów: wpisz w Google site:twojadomena.pl i policz wyniki – przybliżona liczba zaindeksowanych stron. Następnie: site:twojadomena.pl inurl:?color= lub inurl:?sort= – jeśli wyników jest >10, parametry URL generują zduplikowane strony wchodzące do indeksu.

Canonical vs noindex vs 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ć

Crawl budget to liczba stron, które Googlebot może i chce odwiedzić w danym serwisie w określonym czasie – w e-commerce jest często marnowany na strony filtrów i parametry URL zamiast na nowe produkty i kategorie. Google definiuje crawl budget jako iloczyn dwóch składników.

Crawl rate limit – kondycja serwera. Im szybciej serwer odpowiada, tym więcej połączeń Googlebot może nawiązywać jednocześnie bez przeciążenia. Wolny hosting dosłownie zmniejsza dostępny crawl budget. Core Web Vitals i czas odpowiedzi serwera mają bezpośredni wpływ na tę składową.

Crawl demand – popularność stron. Strony z wieloma linkami zewnętrznymi i dużym ruchem organicznym są “głodniej” crawlowane przez Googlebota. Nowe strony bez linków i ruchu mogą czekać tygodniami na pierwsze odwiedziny.

Kiedy crawl budget jest realnym problemem: serwisy poniżej 1000 podstron – praktycznie nigdy. Staje się krytyczny przy >10 000 podstron i szczególnie w WooCommerce lub innych platformach e-commerce generujących warianty URL przez filtry (kolor, rozmiar, sortowanie). Przykład: sklep z 5000 produktami i 20 atrybutami filtrów może generować setki tysięcy unikalnych URL – wszystkie crawlowane zamiast stron docelowych.

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

Jak optymalizować crawl budget – 5 działań z priorytetem:
1. Noindex na URL śmieciowych – strony z parametrami filtrów, strony sesji, strony wyszukiwania wewnętrznego
2. robots.txt Disallow dla parametrów URL niekrytycznych dla SEO – np. ?sort=price, ?sessionid=
3. Eliminacja redirect chains – każdy łańcuch to dodatkowe żądanie HTTP marnujące budżet
4. Linkowanie wewnętrzne ważnych stron – priorytety produktów i kategorii = lepszy crawl demand
5. Poprawa szybkości serwera – bezpośredni wpływ na crawl rate limit

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 przekierowań dłuższe niż 2 hopy, 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/ lub /wp-content/themes/ – pliki CSS i JS, które Google potrzebuje do renderowania strony. Bez nich Googlebot nie może przetworzyć wyglądu strony ani JavaScript.

Diagnoza: GSC → Ustawienia → robots.txt Tester. Wpisz URL konkretnych stron i sprawdź, czy są zablokowane. Dodaj Allow: /wp-content/ dla zasobów potrzebnych do renderowania.

Lancuchy przekierowan (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 hop w łańcuchu to dodatkowe żądanie HTTP. Przy crawl budgecie ograniczonym dla dużego serwisu – marnowanie budżetu. Dodatkowo link equity z linków zewnętrznych rozmywa się przy każdym przekierowaniu – Google przekazuje nieco mniej “siły” przez każdy kolejny redirect.

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 parametrow filtrow

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 parametryczna jest crawlowana ale nie indeksowana jako osobna strona
2. robots.txt Disallow dla parametrów niekrytycznych dla SEO – oszczędza crawl budget, ale strona nie będzie crawlowana wcale
3. Noindex na stronach parametrycznych – Google crawluje, ale nie indeksuje. W WooCommerce: ustaw noindex dla stron generowanych przez plugin filtrów (np. FiboFilters, WOOF).

JavaScript rendering a widocznosc tresci dla 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 – lazy loading obrazów i tekstu, Single Page Applications (React, Vue, Next.js), dynamiczne listy produktów renderowane client-side. Googlebot przy pierwszym crawlu pobiera surowy HTML i odkłada rendering JS na drugi etap (second wave) – może to potrwać dni lub tygodnie.

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: Server-Side Rendering (SSR) lub Static Site Generation (SSG) dla krytycznych treści. Minimum wymagane: H1, meta description, linki wewnętrzne i kluczowe treści muszą być obecne w surowym HTML – nie dopiero po załadowaniu JS.

Orphan pages i strony niedostepne w 3 kliknieciach

Objaw: strony zaindeksowane w GSC Coverage, ale bez ruchu organicznego i bez żadnych linków wewnętrznych wskazujących na nie. Orphan pages to strony “osierocone” – Google je odkrył (np. z zewnętrznego linku lub starej sitemaps), ale serwis nie linkuje do nich wewnętrznie.

Jak wykryć: (1) eksportuj listę URL z GSC Coverage Report (Zaindeksowane), (2) eksportuj listę URL z crawlu Screaming Frog, (3) porównaj – URL w GSC, ale nieznaleziony przez SF crawl = orphan page (SF nie dostał się tam linkami wewnętrznymi). Narzędzie do porównania: VLOOKUP w Excelu lub 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 bledow po audycie – matryca wplyw/wysilek

Po audycie crawlability lista błędów liczy zazwyczaj 20-50 pozycji – priorytetyzacja matrycą wpływ/wysiłek zapewnia naprawę tego, co blokuje indeksację, przed optymalizacjami detali. Rola konsultanta to właśnie interpretacja kontekstu biznesowego i wskazanie kolejności napraw – nie generowanie listy problemów do samodzielnego rozwiązania.

Matryca 2×2:

Ćwiartka 1 – Rób natychmiast (wysoki wpływ, niski wysiłek):
– Disallow: / w robots.txt – naprawa: 5 minut, wpływ: katastrofalny dla indeksacji
– noindex na stronie głównej lub kluczowych kategoriach – naprawa: 2 minuty
– Brakująca lub niezgłoszona sitemap.xml – naprawa: 30 minut
– Łańcuchy przekierowań na URL z linkami zewnętrznymi – naprawa: 1-2 godziny

Ćwiartka 2 – Zaplanuj jako projekt (wysoki wpływ, wysoki wysiłek):
– Przebudowa parametryzacji URL w e-commerce (setki tysięcy zduplikowanych URL) – tygodnie deweloperskie
– Migracja z CSR na SSR dla serwisu opartego o React/Vue – projekt deweloperski
– Wdrożenie prawidłowej architektury canonical dla dużego katalogu produktów – wymagają planu i testów

Ćwiartka 3 – Rób przy okazji (niski wpływ, niski wysiłek):
– 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łóż (niski wpływ, wysoki wysiłek):
– Zmiana architektury CMS bez strategicznego powodu
– Refactoring struktury URL stron z minimalnym ruchem organicznym

Jeśli chcesz oddelegować priorytetyzację i wdrożenie profesjonalnym oczom – sprawdź audyt SEO.

AI crawlability – dodatkowa warstwa nowoczesnego audytu

Nowoczesny audyt crawlability obejmuje nie tylko Googlebota, ale też crawlery AI – GPTBot (ChatGPT), ClaudeBot (Anthropic) i PerplexityBot – które nie renderują JavaScript i wymagają osobnej konfiguracji w robots.txt. To gap, którego 8 z 10 analizowanych konkurentów w tej niszy nie pokrywa.

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

1. Brak obsługi JavaScript – boty AI widzą wyłącznie surowy HTML, bez żadnego renderowania. Jeśli Twoje treści są ładowane przez JS, dla GPTBota lub ClaudeBota nie istnieją.
2. Wyższa częstotliwość crawlowania – wg danych Conductor (2024) GPTBot crawluje niektóre serwisy nawet 8× częściej niż Googlebot. To zwiększone obciążenie serwera.
3. Brak narzędzia do ręcznego zgłaszania stron – nie ma odpowiednika GSC URL Inspection dla ChatGPT ani Perplexity.

Dwa typy botów AI – różna strategia robots.txt:

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

# Pozwalaj botom cytujacym AI na dostep
User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: ClaudeBot
Allow: /

# Ogranicz boty wylacznie treningowe (opcjonalnie)
User-agent: GPTBot
Disallow: /

Jak sprawdzić wizyty AI botów: analiza logów serwera (access.log) – szukaj user-agent zawierającego “GPTBot”, “ClaudeBot”, “PerplexityBot”, “CCBot”. Częstotliwość wizyt pokaże, które serwisy są aktywnie indeksowane przez AI crawlery.

Warunek konieczny cytowania przez AI: treści kluczowe muszą być dostępne w statycznym HTML. Boty AI nie renderują JavaScript – jeśli Twoje artykuły eksperckie są ładowane przez React lub Vue bez SSR, dla ChatGPT i Perplexity nie istnieją jako treść do cytowania. Jeśli chcesz optymalizować serwis pod kątem AI Search – sprawdź usługę AIO/GEO.

FAQ – czesto zadawane pytania o crawlability i indeksacje

Po jakim czasie Google indeksuje strone?

Nowe strony mogą być zaindeksowane od kilku godzin do kilku tygodni – zależy od crawl budgetu serwisu, obecności linków wewnętrznych i zewnętrznych oraz zgłoszenia w GSC. Zgłoszenie URL przez GSC URL Inspection (przycisk “Przetestuj URL”, następnie “Poproś o indeksowanie”) może przyspieszyć indeksację do 1-3 dni. Duże serwisy z niskim crawl budgetem lub strony bez linków wewnętrznych mogą czekać tygodniami. Niezgłoszona sitemap.xml to jeden z najczęstszych powodów opóźnionej indeksacji.

Jak sprawdzic, czy moja strona jest zaindeksowana?

Wpisz site:twojadomena.pl w Google – wyniki pokażą przybliżoną liczbę zaindeksowanych stron. Dokładniejsze dane: GSC → Indeksowanie → Strony → liczba URL ze stanem “Zaindeksowane”. Narzędzie URL Inspection w GSC pozwala sprawdzić status konkretnej podstrony i datę ostatniego crawlu przez Googlebota.

Co zrobic, gdy Google nie indeksuje strony?

Sprawdź cztery przyczyny w tej kolejności: (1) blokada w robots.txt – otwórz twojadomena.pl/robots.txt i sprawdź reguły Disallow, (2) tag noindex w kodzie strony – sprawdź w źródle strony <meta name="robots">, (3) błędny canonical wskazujący na inny URL – sprawdź Screaming Frog, zakładka Canonical, (4) thin content lub duplikat – Google może odmawiać indeksacji stron o niskiej unikalnej wartości. Zgłoś URL przez GSC URL Inspection i obserwuj stan przez 1-2 tygodnie.

Czym rozni sie crawlability od indeksacji?

Crawlability to dostepnosc 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 indeksacje czy tylko crawlowanie?

Robots.txt blokuje wyłącznie crawlowanie – nie indeksację bezpośrednio. Jeśli strona nie jest crawlowana, nie może być nowo zaindeksowana. Ale robots.txt nie usuwa strony już obecnej w indeksie – Google może ją wyświetlać w wynikach bez odwiedzania. Do usunięcia z indeksu służy tag noindex (crawl wymagany) lub narzędzie usuwania URL w GSC.

Jak przyspieszyc indeksacje nowych stron?

Cztery działania w kolejności skuteczności: (1) zgłoś URL przez GSC URL Inspection → “Poproś o indeksowanie” – najszybsza metoda, (2) dodaj stronę do sitemap.xml i upewnij się, że sitemap jest zgłoszona w GSC, (3) dodaj linki wewnętrzne z popularnych, często crawlowanych stron serwisu, (4) zdobądź linki zewnętrzne z innych serwisów – Googlebot śledzi zewnętrzne linki i odkrywa przez nie nowe URL szybciej niż przez same sitemaps.

Kiedy crawl budget ma znaczenie?

Dla serwisów ponizej 1000 podstron crawl budget rzadko jest problemem – staje sie krytyczny przy >10 000 podstron, szczegolnie w e-commerce. WooCommerce z pluginami filtrów może generować setki tysięcy wariantów URL (każda kombinacja filtrów = osobna strona), zjadając cały dostępny budżet na strony bez wartości SEO zamiast na nowe produkty. Kluczowy sygnał: GSC Crawl Stats pokazuje dużą liczbę crawlowanych URL dziennie, ale liczba zaindeksowanych stron nie rośnie proporcjonalnie.

Jak sprawdzic, czy Googlebot odwiedza moja strone?

Dwa sposoby: (1) GSC → Ustawienia → Statystyki crawlowania – wykres URL crawlowanych dziennie z podziałem na kody odpowiedzi, szybkość pobierania i typy zasobów, (2) analiza logów serwera (access.log) – szukaj wpisów z user-agent “Googlebot/2.1”. Logi dają dokładniejszy obraz: które konkretne URL Googlebot odwiedza, jak często i z jakimi kodami odpowiedzi – informacji niedostępnych w GSC na poziomie per-URL.