Błędy 404 i nieprawidłowo skonfigurowane przekierowania to jedne z najczęstszych problemów technicznych, które obniżają widoczność serwisu w Google. Audyt 404 i redirectów pozwala wykryć miejsca, gdzie traci się link equity, gdzie użytkownicy natrafiają na ślepe uliczki i gdzie roboty indeksujące marnują crawl budget. Przeprowadzony metodycznie, dostarcza listy priorytetowych poprawek z bezpośrednim przełożeniem na pozycje i wskaźniki zaangażowania.
Z naszego artykułu dowiesz się:
Jak przeprowadzić audyt broken links i stron 404
Punktem startowym jest zawsze pełne przeczytanie serwisu przez crawlera. Screaming Frog SEO Spider to narzędzie, które w praktyce sprawdza się najlepiej — przechodzi przez wszystkie wewnętrzne i zewnętrzne adresy URL, rejestruje kody odpowiedzi HTTP i zapisuje pełny obraz struktury linków. W trybie domyślnym crawler startuje z adresu głównego i podąża za każdym linkiem na stronie, co daje kompleksowy wgląd w to, co faktycznie indeksuje się w serwisie.
Przed uruchomieniem skanowania warto skonfigurować kilka parametrów. Screaming Frog umożliwia podłączenie konta Google Search Console, dzięki czemu do listy URL-i crawlera dokładane są adresy pobrane bezpośrednio z danych o ruchu organicznym — to eliminuje ryzyko pominięcia stron, do których nie prowadzi żaden wewnętrzny link. Drugi istotny krok to załadowanie sitemapy XML: narzędzie porówna wtedy listę URL-i zadeklarowanych jako aktywne z faktycznym stanem serwera.
Po zakończeniu skanowania filtrujemy wyniki według kodu odpowiedzi. Zakładka „Response Codes” z filtrem „4xx” pokazuje wszystkie adresy zwracające błędy klienta — wśród nich dominują 404 (nie znaleziono) i 410 (trwale usunięto). Przy dużych serwisach lista potrafi liczyć setki pozycji, dlatego kolejnym krokiem jest nadanie im priorytetów.
Ocena priorytetu naprawy błędów 404
Nie każdy błąd 404 wymaga natychmiastowej interwencji. O priorytecie decydują trzy kryteria: liczba linków przychodzących wskazujących na adres, historyczny ruch organiczny oraz głębokość linkowania wewnętrznego.
URL z linkami zewnętrznymi (backlinkami) z innych domen jest absolutnie najwyższym priorytetem — każda taka strona „przepala” link equity zamiast przekazywać je dalej. Dane o backlinkach pobieramy z Google Search Console (zakładka „Linki” > „Zewnętrzne linki”) lub z narzędzia do analizy profilu linków. Konfrontujemy tę listę z adresami 404 ze Screaming Frog i oznaczamy pokrywające się pozycje jako krytyczne.
Drugi poziom priorytetu stanowią strony, które generowały ruch organiczny przed zniknięciem. W Google Search Console eksportujemy raport z zakładki „Skuteczność” z widokiem na konkretne strony, a następnie sprawdzamy, które z pozycji z błędem 404 pojawiają się w historycznych danych o kliknięciach. Strona z 200+ kliknięciami miesięcznie, która nagle zwraca 404, to wymierne straty ruchu.
Źródła błędów 404, których często się nie sprawdza
Standardowy crawl wykrywa błędy w linkach widocznych w kodzie HTML. Istnieje jednak kilka źródeł, które łatwo pominąć:
- Linki w nagłówkach i stopkach wczytywanych dynamicznie przez JavaScript — Screaming Frog w trybie renderowania JavaScript (wymaga konfiguracji) potrafi je złapać, ale bez tej opcji zostaną zignorowane
- Adresy URL obecne wyłącznie w sitemapie XML, do których nie prowadzi żaden link wewnętrzny
- Linki w plikach PDF hostowanych na serwerze — Screaming Frog potrafi je parsować po włączeniu odpowiedniej opcji
- Adresy URL z dużych eksportów produktowych (feed XML dla Google Merchant), które mogą zawierać strony produktów już wycofanych ze sprzedaży
Każde z tych źródeł warto osobno przejrzeć — razem mogą ujawnić kilkanaście do kilkudziesięciu dodatkowych błędów niewidocznych przy standardowym skanowaniu.
Analiza redirect chains i ich wpływ na SEO
Przekierowania same w sobie nie są problemem — standardowe przekierowanie 301 przenosi zdecydowaną większość wartości linkowania na docelowy adres. Problem pojawia się, gdy przekierowania tworzą łańcuchy lub pętle.
Redirect chain to sytuacja, gdy adres A przekierowuje na B, B na C, a C dopiero zwraca kod 200. Google i inne roboty indeksujące podążają za takimi łańcuchami, ale każde dodatkowe ogniwo wydłuża czas crawlowania i powoduje utratę części sygnałów rankingowych. Przyjmuje się, że po dwóch przeskokach przekazanie mocy linkowania zaczyna maleć w zauważalny sposób. Przy pięciu lub więcej przekierowaniach robot może w ogóle zrezygnować z podążania za łańcuchem.
Screaming Frog wizualizuje redirect chains w zakładce „Redirects” > „Redirect Chains”. Widoczna jest tam pełna sekwencja przeskoków dla każdego adresu URL — liczba hopów, kody pośrednie i adres docelowy. Łańcuchy dłuższe niż dwa przeskoki trafiają na listę do naprawy.
Redirect loops — pętle przekierowań
Pętla przekierowań (redirect loop) to szczególny przypadek, w którym adres A kieruje na B, a B z powrotem na A — lub w wersji wieloelementowej: A → B → C → A. Przeglądarka wyświetla wtedy komunikat o zbyt wielu przekierowaniach, a robot indeksujący po prostu rezygnuje z dalszego podążania za adresem.
Screaming Frog oznacza takie adresy kodem błędu lub wyświetla komunikat w kolumnie „Redirect To”. Pętle najczęściej pojawiają się po migracji serwisu, gdy reguły w pliku .htaccess lub konfiguracji serwera Nginx nakładają się na siebie albo są wzajemnie sprzeczne. Warto je traktować jako błędy krytyczne — nie tylko nie przekazują żadnej wartości, ale aktywnie blokują indeksację.
Metodologia naprawy i walidacja po wdrożeniu
Zebrane dane z crawla i Search Console trafiają do arkusza kalkulacyjnego, który staje się centrum zarządzania całą naprawą. Minimalna struktura takiego arkusza obejmuje kolumny: adres źródłowy (błąd 404 lub łańcuch), typ błędu, priorytet (1-3), proponowany adres docelowy przekierowania, status wdrożenia, data weryfikacji.
Adres docelowy dla przekierowania powinien być stroną tematycznie najbliższą usuniętej. Jeśli usunięto stronę kategorii „Laptopy do 3000 zł”, docelem powinien być ogólny listing laptopów lub nowa kategoria cenowa — nie strona główna serwisu. Przekierowanie wszystkiego na stronę główną (tzw. soft 404) to powszechny błąd: Google potrafi wykryć taką praktykę i traktować takie przekierowania jako 404.
Sposób wdrożenia zależy od infrastruktury. W serwisach opartych na Apache przekierowania trafiają do pliku .htaccess, w Nginx do bloku server w konfiguracji, a w systemach CMS takich jak WordPress do wtyczek lub bezpośrednio do reguł serwera z pominięciem PHP dla lepszej wydajności.
Po wdrożeniu przekierowań obowiązuje walidacja w dwóch etapach. Pierwszy to natychmiastowe sprawdzenie ręczne dla krytycznych adresów — curl z opcją -I lub narzędzia do sprawdzania nagłówków HTTP pokazują faktyczny kod odpowiedzi i ścieżkę przekierowania. Drugi to ponowne uruchomienie crawla Screaming Frog nie wcześniej niż 48-72 godziny po wdrożeniu, co pozwala wychwycić nieoczekiwane efekty uboczne, np. nowe pętle.
Monitorowanie redirectów i błędów 404 po audycie
Jednorazowy audyt to tylko punkt wyjścia. Błędy 404 pojawiają się stale — usuwa się produkty ze sklepu, reorganizuje kategorie, zmienia strukturę URL po redesignie. Bez regularnego monitorowania lista błędów narastałaby ponownie przez kolejne miesiące.
Google Search Console oferuje raport „Pokrycie indeksu”, który w czasie zbliżonym do rzeczywistego informuje o URL-ach zwracających błędy 404. Raport jest szczególnie wartościowy, bo pokazuje wyłącznie adresy, które Google próbuje zaindeksować — a więc te, które realnie wpływają na crawl budget i indeksację.
Screaming Frog można uruchamiać w trybie harmonogramowanym (funkcja dostępna w licencji płatnej) i wysyłać raporty różnicowe — tylko nowe błędy wykryte od ostatniego skanu. Alternatywnie, krótki skrypt monitorujący kody HTTP dla listy kluczowych adresów URL można ustawić jako zadanie cron i uruchamiać codziennie lub kilka razy w tygodniu.
Dla serwisów e-commerce z dużą rotacją produktów sprawdza się dodatkowe zabezpieczenie na poziomie CMS: automatyczne przekierowanie ze strony usuniętego produktu na nadrzędną kategorię, wyzwalane w momencie archiwizacji lub usunięcia produktu. Takie rozwiązanie eliminuje błędy, zanim zdąży je zarejestrować jakikolwiek robot.
Regularność przeglądów powinna odpowiadać dynamice zmian w serwisie. Duże sklepy internetowe wymagają monitorowania co tydzień, serwisy contentowe z rzadkimi zmianami strukturalnymi — raz na miesiąc wystarczy. Istotne, by harmonogram był przestrzegany konsekwentnie, a nie uruchamiany tylko reaktywnie po spadkach w rankingach.
