Czym crawler jest, a czym nie jest

Screaming Frog to program instalowany lokalnie. Crawl obciąża więc Twoje łącze i procesor, ale przede wszystkim generuje ruch na serwerze klienta — na słabym hostingu agresywne przejście potrafi zauważalnie zwolnić stronę. Przy pierwszym kontakcie z nieznanym serwerem zawsze zmniejszam liczbę wątków.

Wersja darmowa ma limit 500 adresów na crawl i nie daje dostępu do konfiguracji ani do integracji z API. Do sprawdzenia małej strony wizytówkowej to wystarczy. Do audytu sklepu — nie, i nie ma sensu udawać, że jest inaczej: bez zapisanej konfiguracji i bez połączenia z Search Console robisz połowę roboty.

Audyt techniczny usuwa przeszkody, przez które wyszukiwarka nie widzi Twoich stron albo widzi je źle. Nie sprawia, że treść staje się warta czytania — to zupełnie inna robota.

Konfiguracja, którą ustawiam przed pierwszym przejściem

Nie klikam „Start” od razu po wpisaniu adresu. Kilka ustawień decyduje o tym, czy dane będą w ogóle użyteczne.

• Liczba wątków i limit szybkości — schodzę do kilku żądań na sekundę, dopóki nie wiem, jak zachowuje się serwer. Sypiące się w trakcie crawla kody 5xx to najczęściej moja wina, nie wada strony.

• Respektowanie robots.txt — domyślnie włączone i zwykle to zostawiam, bo chcę widzieć witrynę tak, jak widzi ją robot. Tryb ignorowania włączam tylko wtedy, gdy podejrzewam, że plik blokuje coś przez pomyłkę.

• Renderowanie JavaScriptu — potrzebne, gdy treść i linki pojawiają się dopiero po wykonaniu skryptów. Dobry test: przejdź stronę raz bez renderowania i raz z nim, a potem porównaj liczbę znalezionych adresów. Duża różnica to sygnał, że wyszukiwarka może mieć z tą witryną kłopot.

• Zakres crawla — subdomeny, linki zewnętrzne, parametry. W sklepach filtry z parametrami potrafią wygenerować dziesiątki tysięcy adresów, więc albo wykluczam je wzorcem, albo ograniczam głębokość.

Konfigurację zapisuję jako profil i wracam do niej przy kolejnych przejściach tej samej witryny. Bez tego porównanie „przed i po” nic nie znaczy — nie wiadomo, czy zmieniła się strona, czy ustawienia.

Kody odpowiedzi i przekierowania

Pierwsza zakładka, do której zaglądam po zakończeniu crawla, to kody odpowiedzi. Interesują mnie trzy grupy.

Błędy 404 — nie sama ich liczba, tylko to, skąd prowadzą do nich linki. Link w menu albo w treści to problem do naprawy; stary adres podlinkowany z zewnątrz wymaga innej decyzji — przekierowania na najbliższy sensowny odpowiednik albo świadomego zostawienia 404. Program pokazuje przy każdym adresie listę stron, które do niego linkują, i to jest w tym raporcie najcenniejsze.

Błędy 5xx — jeśli nie wynikają z tego, że sam zbyt mocno przycisnąłem serwer, oznaczają problem po stronie hostingu lub aplikacji. Powtarzam wtedy crawl na mniejszej prędkości, żeby to odróżnić.

Przekierowania, a właściwie ich łańcuchy. Osobny raport pokazuje całą ścieżkę: adres wejściowy, kolejne kroki i cel. Tu regularnie znajduję rzeczy, które psują mi kampanie — adres z parametrami reklamowymi przechodzący przez trzy skoki albo przekierowanie z wersji bez „www” na wersję z „www”, a potem z HTTP na HTTPS, zamiast jednego przeskoku do adresu docelowego. Każdy dodatkowy krok to opóźnienie po kliknięciu w reklamę i miejsce, w którym można stracić parametry pomiaru. Sprawdzam przy tym typ przekierowania: tymczasowe 302 tam, gdzie zmiana jest trwała, widzę na większości serwisów, które przeglądam pierwszy raz.

Indeksowalność: dyrektywy, canonicale, sitemapa

To część audytu, w której najłatwiej zrobić stronie prawdziwą krzywdę i najłatwiej ją naprawić.

W zakładce z dyrektywami filtruję adresy z noindex. Pytanie nie jest, czy takie strony są — prawie zawsze są i często słusznie — tylko czy nie ma wśród nich czegoś, co ma się indeksować. Zapomniany noindex po przeniesieniu strony z wersji testowej to jedna z najczęstszych przyczyn sytuacji „strona zniknęła z Google”.

Dalej canonicale. Sprawdzam, czy nie tworzą łańcuchów i czy nie prowadzą do adresu, który sam jest przekierowaniem albo błędem 404. Osobno oglądam, czy canonical nie wskazuje wersji z innym protokołem albo inną formą adresu — taki błąd potrafi wykluczyć z indeksu całą sekcję serwisu.

Sitemapę porównuję z tym, co znalazł crawler: program pozwala wczytać plik XML i skonfrontować go z wynikami przejścia. Szukam adresów z sitemapy, które zwracają kod inny niż 200, oraz stron osieroconych — takich, do których nie prowadzi żaden link wewnętrzny. Te drugie wykryjesz tylko wtedy, gdy dorzucisz do crawla dane zewnętrzne: sitemapę albo dane z Search Console.

Przy okazji notuję głębokość klikania. Jeśli ważny produkt leży sześć kliknięć od strony głównej, to problem strukturalny, nie techniczny — ale też trafia do raportu.

Tytuły, opisy i nagłówki

Najnudniejsza część audytu, a dla mnie przy okazji materiał źródłowy: z tytułów i nagłówków czytam, jak właściciel strony nazywa swoje produkty.

W zakładce tytułów szukam duplikatów, adresów bez tytułu i tytułów, w których ktoś upchnął nazwę firmy trzy razy. Program pokazuje długość w znakach i w pikselach — ta druga liczba jest bliższa temu, co zobaczy użytkownik w wynikach. Obcięty tytuł nie jest błędem technicznym, tylko zmarnowaną szansą. Meta opisy sprawdzam pobieżnie, bo wyszukiwarka i tak często przepisuje je po swojemu, ale te brakujące na stronach ofertowych warto uzupełnić.

Nagłówki H1: interesuje mnie ich obecność i sens, nie liczba. Strona z H1 „Strona główna” to sygnał, że szablon powstał bez myślenia o tym, o czym ta strona właściwie jest.

Zaglądam też do raportu bliskich duplikatów treści. W sklepach z wieloma wariantami produktu i w serwisach ze stronami pod kolejne miasta potrafi on pokazać, że wiele podstron różni się jednym słowem.

Podłączenie API: Search Console, Analytics, PageSpeed

Sam crawl mówi o strukturze. Żeby powiedzieć, co z tego ma znaczenie, potrzebuję danych o ruchu i wynikach.

W konfiguracji dostępu do API podłączam Search Console — raport skuteczności oraz integrację z API inspekcji adresów URL, dzięki której przy każdym adresie widzę stan indeksowania wprost od Google. Trzeba pamiętać o limicie: około dwóch tysięcy zapytań na dobę na jedną zweryfikowaną usługę. Przy większym serwisie sprawdzam więc próbkę adresów albo rozkładam to na kilka dni.

Podłączam też PageSpeed Insights, który dokłada do każdego adresu dane o szybkości, w tym trzy podstawowe wskaźniki internetowe: LCP, FID i CLS. Od razu widzę wtedy, czy problem dotyczy jednej podstrony, czy całego szablonu.

Integracja z Analytics wymaga dziś ostrożności. Program łączy się z Universal Analytics i dokłada do wierszy crawla dane o sesjach oraz konwersjach. Kłopot w tym, że po marcowej zapowiedzi wygaszenia Universal Analytics nowe wdrożenia pomiarowe robimy już w GA4 — a do GA4 crawler na razie nie ma w oknie API swojego wejścia. Dopóki się to nie zmieni, dane o ruchu do porównania z crawlem eksportuję ręcznie i łączę je po adresie w arkuszu. Niewygodne, ale działa.

Jak z listy błędów zrobić raport, z którego ktoś skorzysta

Największym błędem przy audycie technicznym nie jest przeoczenie problemu. Jest nim wysłanie klientowi eksportu z tysiącami wierszy, opisanego jako „lista błędów do naprawy”. Taki plik nie zostaje otwarty po raz drugi.

Robię to inaczej. Z crawla wybieram kilkanaście pozycji i układam je w trzy grupy: rzeczy, które wykluczają strony z indeksu albo psują ścieżkę użytkownika i trzeba je naprawić natychmiast; rzeczy, które da się poprawić w szablonie jednym ruchem dla wielu adresów; oraz rzeczy do zrobienia, gdy będzie czas. Do każdej pozycji dopisuję jedno zdanie: co jest nie tak, gdzie to zobaczyć i kto ma to zmienić — programista, redaktor czy administrator serwera.

Nowa zakładka z problemami ułatwia ten etap, bo grupuje znaleziska i szacuje ich wagę. Nie zwalnia jednak z myślenia: narzędzie nie wie, że akurat ta jedna strona z canonicalem w złym miejscu jest stroną docelową kampanii z połową budżetu konta.

Na koniec crawl zapisuję i powtarzam po wdrożeniu poprawek, na tej samej konfiguracji — program potrafi porównać dwa przejścia i pokazać różnice. Tylko tak, zamiast dyskusji o tym, czy „chyba coś naprawiliśmy”, mam listę tego, co faktycznie zniknęło z raportu. Drugi przebieg zwykle ujawnia też problemy powstałe przy naprawianiu poprzednich — lepiej dowiedzieć się o tym samemu niż od klienta.