Analiza crawlowania w Screaming Frog

Dlaczego analiza crawlowania jest podstawą każdego technicznego audytu SEO

Każda wyszukiwarka zaczyna od crawlowania. Zanim Google uwzględni stronę w rankingu, Googlebot musi do niej dotrzeć, pobrać ją i przetworzyć. Właśnie tu wkracza analiza crawlowania w Screaming Frog: pokazuje serwis z perspektywy crawlera, a nie odwiedzającego. Wychodzą na jaw problemy niewidoczne w przeglądarce: błąd 404 za linkiem wewnętrznym, łańcuch przekierowań z czterema przystankami, tag canonical wskazujący na niewłaściwy URL.

Dla firm B2B ma to bezpośrednie znaczenie ekonomiczne. W Austrii udział Google w rynku wynosi 81,87% (dane z maja 2026). Jeśli Google nie crawluje i nie indeksuje poprawnie Twojego serwisu, tracisz zdecydowanie najważniejszy kanał organiczny. A z każdą nową stroną rośnie liczba potencjalnych błędów technicznych, które bez systematycznego crawla pozostają niewykryte.

Analiza crawlowania nie jest więc jednorazowym audytem, lecz cyklicznym mechanizmem kontroli. Przekłada często mgliste podejrzenie („ruch organiczny stoi w miejscu”) na konkretne wyniki techniczne, którym można nadać priorytety.

Działanie i konfiguracja: podstawy pracy ze Screaming Frog

Screaming Frog działa jako aplikacja desktopowa na Twoim komputerze. To odróżnia go od chmurowych narzędzi audytowych i daje pełną kontrolę nad konfiguracją i przechowywaniem danych. Dostępne są dwa modele licencji:

Wersja darmowa a płatna: darmowa wersja crawluje do 500 adresów URL na crawl i wystarcza do małych serwisów i szybkich kontroli wyrywkowych. Płatna licencja znosi limit, odblokowuje harmonogram, niestandardową ekstrakcję, integracje przez API i renderowanie JavaScriptu. W poważnych audytach technicznych w B2B licencja to standard.

Tryb Spider a tryb List: w trybie Spider crawler zaczyna od adresu startowego i podąża za linkami wewnętrznymi jak wyszukiwarka. W trybie List crawluje tylko zadaną listę adresów URL, np. z mapy witryny XML albo eksportu z GSC. Tryb List sprawdza się przy celowanych kontrolach wybranych klastrów stron.

Tryb pamięci a tryb przechowywania w bazie danych: domyślnie Screaming Frog uruchamia się w trybie przechowywania w bazie danych i zapisuje dane crawla na dysku. Na dysku SSD ten tryb jest prawie tak szybki jak pamięć RAM, skaluje się znacznie lepiej i automatycznie zapisuje crawle. Porównania crawli są dostępne tylko w tym trybie. Według producenta tryb pamięci (RAM) sprawdza się w serwisach poniżej 500 000 adresów URL i na komputerach bez SSD. Od około 500 000 adresów URL crawl powinien więc z reguły działać w trybie bazy danych. Google kieruje swój przewodnik o crawl budget przede wszystkim do serwisów od 10 000 unikalnych stron z codziennie zmienianą treścią oraz serwisów od 1 miliona unikalnych stron z treścią zmienianą co tydzień. Według Google to tylko orientacyjne wartości. Przy serwisach tej wielkości warto osobno przyjrzeć się crawl budget.

Konfiguracja crawla zapewniająca poprawne dane

Crawl jest tyle wart, ile jego konfiguracja. Przed startem trzeba podjąć kilka decyzji, które mocno wpływają na wynik.

User-agent: Screaming Frog może przedstawiać się jako własny crawler, jako Googlebot (smartfon lub desktop) albo jako niestandardowy user-agent. Crawl jako Googlebot Smartphone ujawnia treści serwowane specjalnie na urządzenia mobilne oraz cloaking.

Respektowanie robots.txt: domyślnie narzędzie respektuje plik robots.txt. Przy pełnym audycie często warto go zignorować, aby zobaczyć także zablokowane obszary, albo przetestować własny robots.txt, zanim trafi na produkcję. Sprawdź przy tym, jakim kodem statusu odpowiada sam plik robots.txt. Według Web Almanac 2024 błąd 404 dla robots.txt zwróciło 14,1% pobrań mobilnych i 14,3% pobrań desktopowych. Google traktuje status 4xx (z wyjątkiem 429) jak brak pliku i crawluje wtedy bez ograniczeń. Krytyczne są odpowiedzi 5xx: wtedy Google najpierw wstrzymuje crawlowanie serwisu na dwanaście godzin, a potem przez maksymalnie 30 dni korzysta z ostatniej wersji pobranej bez błędów.

Renderowanie JavaScriptu: wiele nowoczesnych serwisów B2B renderuje treści po stronie klienta. W standardowym crawlu Screaming Frog widzi tylko początkowy HTML. Dopiero tryb renderowania JavaScriptu (headless Chrome) wykonuje JavaScript i rejestruje to, co faktycznie widzi urządzenie użytkownika. Ten tryb jest wolniejszy i bardziej zasobożerny, ale niezbędny w aplikacjach typu Single-Page Application i frameworkach JS. Zestawienie crawla z renderowaniem i bez niego pokazuje, które treści i linki powstają dopiero po stronie klienta, a to często niedoceniane ryzyko dla indeksacji.

Dobre praktyki: od kodów statusu po linkowanie wewnętrzne

Uporządkowany proces crawlowania przechodzi od technicznej dostępności do jakości treści.

Analiza kodów statusu i niedziałających linków: w zakładce „Response Codes” narzędzie pokazuje wszystkie błędy 404, błędy serwera 5xx, łańcuchy przekierowań i pętle przekierowań. Priorytet zależy od siły linkowania: błąd 404, na który wskazuje sto linków wewnętrznych, jest pilniejszy niż osierocony błąd. Łańcuchy przekierowań z wieloma przystankami marnują crawl budget i rozmywają sygnały z linków, dlatego warto je skrócić do jednego bezpośredniego przekierowania 301.

Indeksowalność i sterowanie crawlowaniem: kolumna „Indexability” podsumowuje, czy URL jest indeksowalny, a jeśli nie, to dlaczego. Częste wyniki to dyrektywy noindex na ważnych stronach, niespójności canonical i sprzeczne dyrektywy robots. Według Web Almanac 2024 tagi canonical stosuje 69% stron desktopowych i 65% stron mobilnych, ale 0,8% ma sprzeczne wartości canonical, co Google traktuje jako niezdefiniowane zachowanie. Screaming Frog systematycznie wykrywa właśnie takie niespójności.

Audyt on-page: crawl rejestruje długość tytułów i meta description, brakujące lub zduplikowane nagłówki H1, thin content i brakujące teksty alt. Meta description to klasyczna luka: według Web Almanac 2024 tylko 66,7% stron desktopowych i 66,4% stron mobilnych miało meta description. Analiza Ahrefs obejmująca ponad milion domen wykazała nawet, że meta description brakowało w 72,9% badanych serwisów. Ważne dla kontekstu: Ahrefs podkreśla, że brak meta description nie jest bezpośrednim problemem rankingowym, bo Google generuje je automatycznie. Ustalenie priorytetów dla takich wyników to część fachowej oceny.

Linkowanie wewnętrzne i architektura serwisu: dzięki głębokości crawlowania (Crawl Depth) narzędzie pokazuje, ile kliknięć dzieli daną stronę od strony głównej. Ważne strony powinny być osiągalne w niewielu kliknięciach. Strony osierocone, czyli strony bez żadnego linku wewnętrznego, ujawnia porównanie crawla z mapą witryny lub danymi z GSC. Rozkład linków przychodzących pokazuje, które adresy URL otrzymują wewnętrzne link equity, a którym go brakuje.

Wzbogacanie danych i widoczność w AI

Sam crawl dostarcza wyników technicznych bez kontekstu ruchu. Dopiero integracja przez API pozwala ustalić ich priorytety.

Integracja przez API: Screaming Frog łączy się bezpośrednio z Google Search Console, GA4 i API PageSpeed Insights. Przez Ahrefs, Majestic lub Moz możesz dodać metryki linków, takie jak backlinki i domeny odsyłające. Powstaje w ten sposób crawl ważony ruchem: błąd techniczny na stronie z dużym ruchem organicznym dostaje wyraźnie wyższy priorytet niż ten sam błąd na stronie bez kliknięć.

Dane strukturalne: podczas crawla narzędzie waliduje znaczniki Schema.org i zgłasza brakujące lub błędne dane strukturalne. Poprawne oznaczenie jest warunkiem wyników rozszerzonych, a coraz częściej także przetwarzania treści przez systemy AI.

Sterowanie crawlerami AI: dziś plik robots.txt reguluje dostęp klasycznych wyszukiwarek i crawlerów AI, takich jak GPTBot. Screaming Frog może sprawdzić, jakie dyrektywy dotyczą tych user-agentów. Jeśli chcesz, aby AI cytowała Cię w odpowiedziach (AI Answer Inclusion), musisz świadomie zdecydować, które crawlery AI otrzymają dostęp. W 2024 roku robiło to niewielu: według Web Almanac 2024 tylko 2,6% (mobile) lub 2,9% (desktop) plików robots.txt wymieniało GPTBot wprost. Żaden inny crawler AI nie był wymieniany częściej.

Najczęstsze błędy w analizie crawlowania

Crawl serwisów JS bez renderowania JavaScriptu: jeśli crawlujesz serwis renderowany po stronie klienta bez trybu renderowania, przeoczysz brakujące treści i linki i wyciągniesz błędne wnioski.

Wyniki bez priorytetów: eksport z crawla z tysiącami wierszy to nie plan działań. Bez ważenia według ruchu z GSC lub Analytics zasoby idą na nieistotne wyniki.

Ignorowanie konfiguracji robots.txt: crawl, który ślepo respektuje robots.txt, pomija zablokowane obszary. Crawl, który go ignoruje bez udokumentowania tego, generuje wyniki dla stron, których w rzeczywistości nie da się crawlować.

Źle wybrany tryb przechowywania: crawlowanie dużych serwisów w trybie RAM kończy się przerwaniem crawla. W trybie bazy danych na klasycznym dysku twardym (HDD) wąskim gardłem staje się nośnik danych.

Jednorazowy crawl zamiast monitoringu: pojedynczy crawl to migawka. Problemy techniczne powstają na bieżąco przez wdrożenia, zmiany treści i migracje.

Metryki, pomiar i raportowanie

Wartość analizy crawlowania pojawia się dopiero wtedy, gdy wyniki zostaną przełożone na mierzalne KPI.

Porównania crawli w czasie: płatna wersja pozwala w trybie przechowywania w bazie danych porównywać crawle. Widać wtedy, czy liczba błędów 404 spada, czy łańcuchy przekierowań zostały usunięte i czy pojawiły się nowe problemy z indeksacją.

Harmonogram i automatyzacja: zaplanowane crawle (np. co tydzień) zapewniają ciągły monitoring techniczny, którego wyniki eksportuje się i przenosi do raportów.

Przełożenie na KPI SEO: wyniki techniczne łączą się z metrykami biznesowymi. Spadek liczby indeksowalnych stron koreluje ze spadkiem wyświetleń w GSC. Naprawione niedziałające linki i skrócone łańcuchy przekierowań poprawiają efektywność crawlowania. Efekt da się śledzić w ruchu organicznym, wskaźniku indeksacji i indeksie widoczności (np. w Sistrix). Tak audyt techniczny staje się udokumentowanym wkładem w ROI z SEO.

Krok dalej: od crawla do priorytetowego planu działań w B2B

Przemyślany proces włącza Screaming Frog w cały zestaw narzędzi SEO. Crawl dostarcza techniczną bazę danych. GSC i GA4 dostarczają kontekst ruchu. Sistrix lub Ahrefs dają perspektywę widoczności i konkurencji.

Praktyczny przebieg audytu B2B obejmuje zwykle pięć kroków. Po pierwsze, poprawnie skonfigurować crawl (user-agent, renderowanie, tryb przechowywania). Po drugie, podłączyć GSC, GA4 i narzędzie do analizy backlinków, aby nadać wynikom wagi. Po trzecie, uszeregować wyniki według istotności problemu i znaczenia dla ruchu. Po czwarte, opracować konkretny, wykonalny plan działań, który przypisuje wynikom technicznym osoby odpowiedzialne. Po piąte, monitorować efekt za pomocą zaplanowanych crawli kontrolnych i zestawiać go z rozwojem widoczności na tle konkurencji.

W ten sposób analiza crawlowania przestaje być zwykłym skanem błędów i staje się strategicznym narzędziem sterowania, które łączy techniczną doskonałość z mierzalnymi wynikami biznesowymi.