Screaming Frog i Sitebulb pomagają zebrać informacje o adresach, linkach, kodach odpowiedzi, canonicalach i elementach treści. Sam crawl nie jest jednak audytem SEO. Narzędzie pokazuje stan wykryty przy określonych ustawieniach, a specjalista musi ocenić przyczynę, znaczenie problemu i właściwy sposób naprawy.
Ten sam serwis może wygenerować dwa różne raporty, jeśli jeden crawl uwzględnia JavaScript, subdomeny i mapę witryny, a drugi porusza się tylko po zwykłych linkach HTML. Dlatego pracę należy zaczynać od zakresu i konfiguracji, nie od eksportowania listy błędów.
Co właściwie pokazuje crawler SEO?
Crawler przechodzi pomiędzy adresami podobnie do robota wyszukiwarki, ale nie odtwarza dokładnie działania Google. Pokazuje przede wszystkim to, co udało mu się znaleźć i pobrać podczas konkretnego badania.
Za pomocą crawla można sprawdzić między innymi:
- kody odpowiedzi i przekierowania,
- adresy dostępne oraz zablokowane dla robota,
- canonicale i dyrektywy indeksowania,
- tytuły, meta descriptions oraz nagłówki,
- linki wewnętrzne i głębokość adresów,
- duplikaty oraz strony o bardzo podobnej treści,
- hreflangi i dane uporządkowane,
- obrazy, pliki CSS, JavaScript i inne zasoby,
- różnice między kodem źródłowym a wersją renderowaną.
Crawler nie zna natomiast wartości sprzedaży, historii migracji, jakości leadów ani przyczyny decyzji biznesowych. Nie wie również, czy strona bez ruchu jest niepotrzebna, czy dopiero czeka na publikację kampanii.
Jak przygotować crawl strony?
Przed uruchomieniem narzędzia ustal cel. Inaczej konfiguruje się kontrolę po migracji, inaczej analizę sklepu z milionem parametrów, a jeszcze inaczej odbiór nowego szablonu.
Sprawdź przede wszystkim:
- Punkt startowy: czy crawl ma rozpocząć się od strony głównej, listy URL-i, sitemap XML czy środowiska testowego?
- Zakres hostów: czy uwzględnić subdomeny, zewnętrzny system rezerwacji albo wersje językowe?
- Renderowanie: czy ważne linki i treści pojawiają się dopiero po wykonaniu JavaScriptu?
- Reguły dostępu: czy narzędzie ma respektować plik robots.txt i dyrektywy przypisane do wybranego user-agenta?
- Szybkość: ile równoległych żądań bezpiecznie obsłuży serwer?
- Logowanie: czy badanie obejmuje strony dostępne dopiero po autoryzacji?
Zbyt agresywny crawl może obciążyć słabszy serwer. Zbyt wąski pominie natomiast zasoby potrzebne do rozpoznania problemu. Ustawienia powinny zostać zapisane razem z datą badania, aby później można było odtworzyć wynik.
Screaming Frog czy Sitebulb?
Screaming Frog daje bardzo szczegółową kontrolę nad sposobem pobierania i filtrowania danych. Pozwala pracować między innymi z trybem listy, renderowaniem JavaScriptu, ekstrakcją niestandardową i integracjami z usługami Google. Pełny zakres ustawień opisuje oficjalny przewodnik SEO Spider.
Sitebulb prowadzi użytkownika przez wykryte wskazówki, wizualizacje i wyjaśnienia. Może być wygodny, gdy raport ma zostać udostępniony osobom, które nie pracują codziennie z surowymi tabelami. Dostępne są warianty działające lokalnie i w chmurze.
Wybór nie powinien zależeć od liczby komunikatów. Ważniejsze jest to, czy narzędzie obsługuje potrzebny sposób renderowania, skalę witryny, cykliczne porównania oraz format pracy zespołu.
W jakiej kolejności analizować raport?
Zamiast poprawiać zakładki od lewej do prawej, warto przechodzić od dostępności do szczegółów treści.
- Dostępność: błędy 4xx i 5xx, pętle, łańcuchy przekierowań oraz niedostępne zasoby.
- Indeksowanie: canonicale, noindex, robots.txt i adresy znajdujące się w sitemapach.
- Architektura: linki wewnętrzne, głębokość, strony osierocone i niepotrzebne warianty URL-i.
- Renderowanie: różnice między HTML-em a stroną po wykonaniu JavaScriptu.
- Treść: powtarzające się tytuły, nagłówki, opisy i zbliżone materiały.
Jeśli ważna strona zwraca błąd serwera, skracanie jej SEO title nie będzie pierwszym zadaniem. Podobnie brak meta description na stronie wyłączonej z indeksowania nie powinien otrzymać takiego samego priorytetu jak błędny canonical kategorii generującej sprzedaż.
Jak odróżnić błąd od fałszywego alarmu?
Komunikat narzędzia jest punktem do sprawdzenia. Przykładowo strona bez wewnętrznych odnośników może być osierocona, ale może też być chwilowym adresem kampanii. Odpowiedź 404 może oznaczać utracony produkt albo prawidłowo usunięty URL bez następcy.
Każdy ważny problem zweryfikuj przez:
- ręczne otwarcie reprezentatywnego adresu,
- sprawdzenie nagłówków HTTP i wersji kanonicznej,
- porównanie z sitemapą oraz linkowaniem wewnętrznym,
- kontrolę danych w Google Search Console,
- ustalenie funkcji strony i jej znaczenia biznesowego.
Sposób zamiany obserwacji w plan działań opisuję dokładniej w poradniku o analizie danych z audytu SEO.
Dlaczego warto porównywać kolejne crawle?
Pojedynczy raport pokazuje stan w danym momencie. Porównanie wykonane przed i po wdrożeniu pozwala sprawdzić, czy zmiana usunęła przyczynę i nie utworzyła nowych problemów.
Po migracji można porównać liczbę adresów 200, 301, 404 i 5xx. Po zmianie szablonu warto sprawdzić canonicale, dyrektywy, linki, nagłówki oraz renderowanie. Nie należy jednak porównywać wyników wykonanych przy zupełnie innych ustawieniach bez opisania tej różnicy.
Jak odebrać wynik audytu crawlerem?
Dobry raport powinien wskazywać nie tylko liczbę problemów, ale także przykładowe adresy, przyczynę, zakres występowania, proponowaną zmianę i kryterium odbioru. Lista tysięcy URL-i bez kontekstu przenosi analizę na osobę, która miała jedynie wdrożyć poprawkę.
Jeśli potrzebujesz crawla, który kończy się planem konkretnych zmian, napisz na czesc@seomariusz.pl lub zadzwoń: 665 015 610. Sprawdzę zarówno konfigurację badania, jak i znaczenie wykrytych problemów.