Strony 404 a SEO – jak wykrywać i naprawiać niedziałające adresy?

Błędy 404 są naturalną częścią funkcjonowania internetu. Pojawiają się po usunięciu podstrony, zmianie adresu URL, wycofaniu produktu ze sprzedaży czy kliknięciu nieaktualnego odnośnika. Sama obecność takich odpowiedzi nie oznacza jednak, że witryna ma problem z pozycjonowaniem. Google potrafi rozpoznawać nieistniejące adresy i stopniowo usuwać je z indeksu. Problem zaczyna się wtedy, gdy błędy dotyczą ważnych podstron, użytkownicy regularnie trafiają na niedziałające linki, a wartościowe adresy tracą widoczność wskutek nieprawidłowych zmian w serwisie.

Błąd 404 w SEO wymaga przede wszystkim właściwej diagnozy. Nie każdy niedziałający adres powinien zostać przekierowany, a automatyczne kierowanie wszystkich usuniętych podstron na stronę główną może przynieść więcej szkody niż pożytku. Dodatkowym wyzwaniem są błędy soft 404, w których serwer zwraca pozornie poprawną odpowiedź HTTP, mimo że użytkownik nie otrzymuje oczekiwanej zawartości.

Jak rozpoznać strony 404, ustalić źródło problemu i zdecydować, kiedy przywrócić podstronę, zastosować przekierowanie 301 albo pozostawić kod 404 lub 410? Poniżej przedstawiamy procedurę diagnostyczną, którą można wykorzystać zarówno w niewielkiej witrynie firmowej, jak i w sklepie internetowym posiadającym tysiące adresów URL.

Co oznacza błąd 404 i jak interpretuje go Google?

Kod HTTP 404 Not Found informuje, że serwer nie znalazł zasobu odpowiadającego wskazanemu adresowi URL. Nie oznacza to awarii całego serwisu. Strona główna, pozostałe podstrony oraz inne zasoby mogą działać prawidłowo.

Przykładowo użytkownik otwiera adres:

https://sklep.example/produkty/model-x100/

Jeżeli produkt został usunięty, a wskazany URL nie prowadzi już do istniejącej karty, serwer może zwrócić odpowiedź:

HTTP/2 404

Googlebot odczytuje taki status jako informację, że dokument nie jest dostępny. Jeśli wcześniej znajdował się w indeksie, Google może usunąć go z wyników wyszukiwania po ponownym przetworzeniu adresu.

Warto podkreślić, że sam błąd 404 nie jest bezpośrednią karą rankingową dla całej domeny. Google nie wymaga, aby każda strona, która kiedykolwiek istniała, pozostawała dostępna bezterminowo.

Jeśli produkt został trwale usunięty i nie posiada zamiennika, odpowiedź 404 może być całkowicie prawidłowa. Natomiast jeśli ważna strona ofertowa zaczyna zwracać 404 wskutek przypadkowej zmiany adresu, firma może stracić ruch organiczny i potencjalnych klientów.

Błąd 404, 410, 301 i soft 404 – czym się różnią?

Przy analizie niedziałających adresów należy prawidłowo rozróżniać statusy HTTP oraz sytuacje, w których Google interpretuje zawartość strony inaczej, niż sugeruje odpowiedź serwera.

Kod 410 może być właściwy dla świadomie usuniętych zasobów, ale nie należy zakładać, że zawsze zapewni zauważalnie szybsze usunięcie strony z indeksu niż 404. W obu przypadkach Google rozumie, że zasób nie powinien być dalej indeksowany pod dotychczasowym adresem.

Kluczowa różnica występuje pomiędzy rzeczywistym błędem 404 a soft 404. W pierwszym przypadku serwer komunikuje brak strony. W drugim wyszukiwarka musi wywnioskować problem na podstawie zawartości lub sposobu działania witryny.

Czym jest soft 404 i dlaczego może być problemem SEO?

Soft 404 to sytuacja, w której Google rozpoznaje stronę jako nieistniejącą, pustą albo pozbawioną oczekiwanej zawartości, mimo że serwer nie zwraca prawidłowego kodu błędu 404 lub 410.

Najbardziej typowy przypadek wygląda następująco:

Żądanie: GET /nieistniejacy-produkt/
Odpowiedź serwera: HTTP 200 OK

Treść strony:
"Przepraszamy, nie znaleziono produktu."

Serwer komunikuje, że żądanie zakończyło się sukcesem, ale główna treść strony wskazuje coś przeciwnego.

Google może rozpoznać taką rozbieżność i zaklasyfikować URL jako soft 404. W rezultacie strona może zostać wykluczona z indeksu, mimo że technicznie odpowiada kodem 200.

Najczęstsze przyczyny soft 404

• Puste karty produktowe – produkt został usunięty z bazy, ale jego adres nadal zwraca 200.
• Nieprawidłowe szablony CMS – brak dokumentu powoduje wyświetlenie komunikatu błędu bez ustawienia właściwego statusu HTTP.
• Puste strony kategorii lub filtrów – adres istnieje technicznie, ale nie zawiera produktów ani innej użytecznej zawartości.
• Błędy renderowania JavaScript – istotna część strony nie zostaje poprawnie wczytana podczas przetwarzania przez Google.
• Nieprawidłowe przekierowania – nieistniejące adresy kierują użytkowników do niezwiązanej strony, np. ogólnej strony głównej.
• Problemy z bazą danych lub API – serwer zwraca 200, lecz użytkownik i Googlebot otrzymują pustą lub niekompletną zawartość.

Nie każda strona z niewielką ilością tekstu jest automatycznie soft 404. Jeśli podstrona realizuje konkretną funkcję i udostępnia wartościową zawartość, jej krótka forma nie musi stanowić problemu.

Jak naprawić soft 404?

Najpierw należy ustalić, czy zasób rzeczywiście istnieje.

Jeżeli strona została trwale usunięta i nie ma odpowiedniego zamiennika, serwer powinien zwracać 404 lub 410. Jeśli dokument został przeniesiony, należy zastosować właściwe przekierowanie.

Jeśli natomiast strona powinna działać, trzeba znaleźć przyczynę nieprawidłowego wyświetlania zawartości. Może to wymagać poprawienia zapytań do API, renderowania JavaScript, konfiguracji CMS lub dostępu do bazy danych.

Ważne jest, aby nie stosować automatycznie dyrektywy noindex do każdej strony zaklasyfikowanej jako soft 404. Jeśli przyczyną jest błąd renderowania wartościowej podstrony, noindex jedynie wykluczy ją z wyników, zamiast rozwiązać właściwy problem.

Jak wykrywać strony 404 w Google Search Console?

Google Search Console jest podstawowym źródłem danych o błędach napotykanych przez Google podczas crawlowania i indeksowania witryny. Nie powinno być jednak jedynym narzędziem wykorzystywanym w audycie.

Krok 1. Przeanalizuj raport indeksowania

W Google Search Console przejdź do sekcji „Indeksowanie”, a następnie otwórz raport „Strony”. Wśród powodów niezindeksowania można znaleźć między innymi statusy dotyczące nieznalezionych adresów oraz soft 404.

Sprawdź liczbę adresów i jej zmiany w czasie. Następnie otwórz szczegóły problemu i przeanalizuj dostępne przykłady.

Warto pamiętać, że raport nie jest pełną listą wszystkich niedziałających linków w serwisie. Pokazuje adresy znane Google oraz informacje wynikające z ich przetwarzania. Standardowe zestawienia i eksporty mogą również obejmować tylko część URL-i.

Krok 2. Sprawdź historię i znaczenie adresu

Dla każdego ważnego błędu ustal, czy:

• podstrona istniała wcześniej i generowała ruch organiczny,
• adres został zmieniony podczas aktualizacji lub migracji,
• produkt został trwale wycofany,
• URL powstał przez literówkę w odnośniku,
• Google odkryło błędny adres na zewnętrznej witrynie,
• strona powinna nadal być dostępna.

Nie warto podejmować decyzji wyłącznie na podstawie kodu 404. Dwa adresy z identycznym statusem HTTP mogą wymagać zupełnie innych działań.

Krok 3. Sprawdź adres za pomocą narzędzia inspekcji URL

W przypadku ważnych podstron wykorzystaj funkcję „Sprawdzanie adresu URL”. Pozwoli ona zweryfikować informacje Google o danym adresie i, w zależności od dostępnych danych, przeanalizować jego aktualny stan.

Jeżeli strona została niedawno naprawiona, pomocny może być test opublikowanego adresu. Pozwala ocenić, czy bieżąca wersja jest dostępna i czy najważniejsza zawartość może zostać pobrana.

Nie należy jednak utożsamiać pozytywnego wyniku testu z natychmiastową zmianą statusu indeksowania. Google musi ponownie przetworzyć adres.

Jak znaleźć uszkodzone linki, których nie pokazuje Google Search Console?

Search Console pomaga identyfikować problemy zaobserwowane przez Google, ale do pełnego audytu potrzebna jest również analiza struktury serwisu.

Audyt za pomocą Screaming Frog

Jednym z praktycznych narzędzi do wykrywania uszkodzonych linków jest Screaming Frog SEO Spider. Program pozwala przeanalizować adresy dostępne przez linkowanie wewnętrzne i sprawdzić zwracane przez nie kody HTTP.

Podstawowa procedura wygląda następująco:

1. Uruchom crawl witryny.
2. Przejdź do zakładki „Response Codes”.
3. Wybierz filtr „Client Error (4xx)”.
4. Zidentyfikuj adresy zwracające 404.
5. Wybierz konkretny adres i sprawdź zakładkę „Inlinks”, aby ustalić, które podstrony do niego linkują.
6. Wyeksportuj listę błędów wraz ze źródłami odnośników.

Kluczowa jest szczególnie analiza źródeł linków. Sama informacja, że adres nie istnieje, nie wyjaśnia, dlaczego użytkownicy i Googlebot nadal do niego trafiają.

Jeżeli stary URL występuje w menu, stopce lub szablonie kategorii, pojedynczy błąd może być powielany na setkach podstron.

Analiza logów serwera

Przy większych serwisach warto wykorzystać również logi serwera. Pozwalają ustalić, jakie adresy faktycznie wywoływali użytkownicy oraz roboty, jakie kody odpowiedzi otrzymywali i jak często występowały błędy.

Przydatne informacje obejmują:

• adres żądania,
• czas jego wykonania,
• kod odpowiedzi HTTP,
• identyfikator klienta i user-agent,
• źródło odwołania, jeśli zostało zapisane,
• częstotliwość powtarzania się błędnego adresu.

Przy analizowaniu aktywności Googlebota należy pamiętać, że sam ciąg „Googlebot” w user-agent nie stanowi wystarczającego potwierdzenia tożsamości robota. W diagnostyce wymagającej pewności można zweryfikować pochodzenie żądań zgodnie z dokumentacją Google.

Logi są szczególnie przydatne, gdy błędne adresy nie występują już w aktualnym linkowaniu wewnętrznym, ale nadal otrzymują regularne żądania.

Kontrola sitemap XML i linków zewnętrznych

Warto również porównać mapę strony XML z aktualnymi kodami odpowiedzi. Sitemap powinna wskazywać poprawne, kanoniczne adresy przeznaczone do indeksowania, a nie strony zwracające 404.

Do identyfikacji niedziałających adresów posiadających linki zewnętrzne można wykorzystać narzędzia takie jak Ahrefs lub Semrush. Szczególną uwagę należy zwrócić na URL-e, które wcześniej prowadziły do wartościowych treści i mają odnośniki z wiarygodnych serwisów branżowych.

Nie każde żądanie 404 jest jednak problemem. Roboty mogą regularnie sprawdzać przypadkowe adresy, stare zasoby lub nieistniejące ścieżki. Takich przypadków nie należy automatycznie przekierowywać.

Które błędy 404 wymagają naprawy w pierwszej kolejności?

W dużej witrynie liczba niedziałających adresów może być znaczna. Dlatego zamiast naprawiać je wyłącznie według kolejności występowania w raporcie, warto stworzyć system priorytetów.

Przy nadawaniu priorytetów warto uwzględnić historyczne kliknięcia i wyświetlenia z Google Search Console, dane o konwersjach, linki zewnętrzne oraz rolę adresu w architekturze serwisu.

Nie każda strona z zerowym ruchem powinna być ignorowana. Nowy adres usługowy może nie mieć jeszcze danych historycznych, ale jego niedostępność może blokować realizację ważnych celów biznesowych.

Jak naprawić błąd 404? Cztery podstawowe scenariusze

Wybór rozwiązania zależy przede wszystkim od tego, co stało się z pierwotną zawartością i czy istnieje odpowiednia strona docelowa.

Scenariusz 1. Strona została przypadkowo usunięta

Jeśli ważna podstrona nadal powinna funkcjonować pod dotychczasowym adresem, najlepszym rozwiązaniem jest jej przywrócenie.

Przykładowo podczas aktualizacji CMS-a zmieniono slug artykułu i stary URL zaczął zwracać 404. Jeżeli zmiana nie była konieczna, można rozważyć przywrócenie oryginalnego adresu, szczególnie jeśli posiada on widoczność, linki i historię indeksowania.

Jeśli nowy adres musi pozostać, należy wykonać odpowiednie przekierowanie ze starej wersji.

Scenariusz 2. Strona została przeniesiona pod nowy adres

W przypadku trwałej zmiany adresu odpowiednim rozwiązaniem jest przekierowanie 301.

Stary adres:
https://firma.example/uslugi/audyt-strony/

Nowy adres:
https://firma.example/oferta/audyt-seo/

Oczekiwana odpowiedź:
301 → nowy adres → 200

Przekierowanie powinno prowadzić bezpośrednio do strony odpowiadającej pierwotnej zawartości.

Po wdrożeniu warto zaktualizować również linkowanie wewnętrzne, aby użytkownicy trafiali od razu do nowego adresu, bez dodatkowego przekierowania.

Scenariusz 3. Strona została trwale usunięta bez odpowiednika

Jeżeli zasób już nie istnieje, a w serwisie nie ma strony realizującej podobną funkcję, pozostawienie kodu 404 lub 410 jest prawidłowym rozwiązaniem.

Przykładowo sklep usunął produkt z limitowanej kolekcji, który nie będzie ponownie dostępny, nie posiada zamiennika i nie jest już przydatny jako źródło informacji.

Nie ma potrzeby tworzenia przypadkowego przekierowania wyłącznie po to, aby usunąć komunikat 404 z Google Search Console.

Scenariusz 4. Niedziałający link zawiera literówkę

Jeżeli problem wynika z błędnie wpisanego adresu w linkowaniu wewnętrznym, należy przede wszystkim poprawić sam odnośnik.

Przykładowo:

Błędny link:
/oferta/pozycjonowanie-lokalnee/

Prawidłowy link:
/oferta/pozycjonowanie-lokalne/

W takim przypadku często nie trzeba tworzyć nowego przekierowania. Wystarczy poprawić link w treści, menu lub szablonie, aby prowadził bezpośrednio do prawidłowej strony.

Jeżeli jednak błędny URL jest szeroko wykorzystywany poza serwisem lub regularnie odwiedzany, dodatkowe przekierowanie może być uzasadnione.

Dlaczego nie należy przekierowywać wszystkich stron 404 na stronę główną?

Masowe przekierowanie wszystkich niedziałających adresów na stronę główną jest jednym z najczęstszych błędów podczas porządkowania witryn.

Załóżmy, że użytkownik wyszukuje szczegółowy poradnik dotyczący wyboru konkretnego urządzenia. Po kliknięciu historycznego wyniku zostaje przeniesiony na stronę główną sklepu, która nie zawiera poszukiwanej informacji.

Taka sytuacja nie rozwiązuje problemu użytkownika. Google również może uznać przekierowanie na niepowiązany adres za nieodpowiednie i potraktować je podobnie do błędu soft 404.

Przekierowania powinny zachowywać zgodność tematyczną oraz możliwie dobrze realizować pierwotną intencję.

Nie oznacza to jednak, że kilka starych adresów nigdy nie może prowadzić do jednej nowej strony. Jeśli kilka poradników zostało świadomie połączonych w kompletny materiał, przekierowanie wszystkich poprzednich URL-i do nowego opracowania może być właściwe.

Przykłady technicznego wdrożenia przekierowań i błędów 404

Sposób implementacji zależy od serwera, systemu CMS i architektury witryny. Poniższe przykłady przedstawiają ogólną logikę rozwiązań i wymagają dopasowania do konkretnego środowiska.

Przekierowanie 301 na Apache

Na serwerze Apache, przy odpowiedniej konfiguracji modułów i pliku .htaccess, można zastosować:

Redirect 301 /stara-usluga/ https://firma.example/nowa-usluga/

Reguła powinna być wdrożona wyłącznie wtedy, gdy nowa podstrona stanowi właściwy odpowiednik starego adresu.

Przekierowanie 301 na Nginx

location = /stara-usluga/ {
    return 301 https://firma.example/nowa-usluga/;
}

W przypadku Nginx sposób dopasowania reguł oraz kolejność konfiguracji mają znaczenie. Zmiany należy przetestować przed wdrożeniem produkcyjnym.

Trwałe usunięcie podstrony

Jeżeli określony adres został świadomie usunięty, serwer może odpowiadać kodem 410.

Przykładowa reguła Nginx:

location = /nieaktualny-zasob/ {
    return 410;
}

Nie należy jednak stosować podobnych reguł globalnie do całych katalogów bez sprawdzenia, czy znajdują się w nich aktywne podstrony.

Jak zweryfikować kod HTTP?

Do sprawdzenia odpowiedzi serwera można użyć polecenia curl:

curl -I https://firma.example/stary-adres/

Polecenie wysyła żądanie HEAD i pozwala sprawdzić nagłówki odpowiedzi. Należy pamiętać, że niektóre serwery i aplikacje mogą obsługiwać HEAD inaczej niż GET.

Jeżeli wynik budzi wątpliwości, warto sprawdzić również odpowiedź dla standardowego żądania GET oraz zachowanie pełnego łańcucha przekierowań.

Jak naprawiać uszkodzone linki wewnętrzne?

Uszkodzone linki wewnętrzne mają znaczenie nie tylko techniczne. Mogą przerywać ścieżkę użytkownika, utrudniać przechodzenie między kategoriami i prowadzić roboty wyszukiwarki do nieistniejących zasobów.

Dlatego ich naprawa powinna obejmować źródło odnośnika, a nie wyłącznie adres docelowy.

Najważniejsze działania to:

• poprawienie błędnych adresów w menu i stopce,
• aktualizacja linków w artykułach oraz podstronach ofertowych,
• usunięcie odnośników do nieaktualnych zasobów bez zamienników,
• zastąpienie przekierowanych linków bezpośrednimi adresami docelowymi,
• kontrola breadcrumbs i automatycznych modułów powiązanych treści,
• sprawdzenie linków generowanych przez system CMS.

Jeśli stary adres jest już przekierowany, pozostawienie do niego linku wewnętrznego nie musi uniemożliwiać użytkownikowi dotarcia do treści. Mimo to warto prowadzić odnośniki bezpośrednio do aktualnych URL-i, aby ograniczać zbędne żądania i utrzymywać czytelną architekturę serwisu.

Szczegółowe zasady organizacji odnośników przedstawiamy w artykule Linkowanie wewnętrzne w SEO – jak zaplanować strukturę linków na stronie?.

Jak powinna wyglądać prawidłowa strona błędu 404?

Technicznie poprawny kod 404 nie musi oznaczać nieprzyjaznego komunikatu na pustej stronie. Użytkownik, który trafia na nieistniejący adres, powinien otrzymać jasną informację o problemie oraz możliwość dalszego korzystania z witryny.

Dobrze zaprojektowana strona błędu powinna zawierać:

• czytelny komunikat, że wskazana strona nie została znaleziona,
• spójny wygląd z pozostałą częścią serwisu,
• odnośnik do strony głównej lub ważnych sekcji,
• wyszukiwarkę wewnętrzną, jeśli ma zastosowanie,
• możliwość znalezienia powiązanych kategorii lub materiałów,
• opcjonalnie formularz zgłoszenia niedziałającego odnośnika.

W sklepie internetowym pomocne mogą być linki do najważniejszych kategorii, natomiast w serwisie eksperckim – odnośniki do działów tematycznych lub wyszukiwarki artykułów.

Najważniejsze jest jednak zachowanie właściwego statusu HTTP. Nawet rozbudowana wizualnie strona błędu powinna zwracać kod 404, jeśli dany dokument rzeczywiście nie istnieje.

Nie należy zmieniać odpowiedzi na 200 tylko po to, aby użytkownik mógł korzystać z menu lub wyszukiwarki. Zawartość nawigacyjna nie zmienia faktu, że żądany zasób jest niedostępny.

Strony 404 w sklepach internetowych – na co szczególnie uważać?

W e-commerce błędy 404 bardzo często wynikają ze zmian asortymentu. Produkty są wycofywane, kategorie reorganizowane, a systemy magazynowe automatycznie aktualizują dostępność.

Największym problemem jest automatyczne usuwanie stron produktów po osiągnięciu zerowego stanu magazynowego.

Jeżeli towar jest jedynie chwilowo niedostępny, karta produktowa zazwyczaj powinna pozostać aktywna i zwracać kod 200. Można na niej wyświetlić informację o braku dostępności, zachować parametry techniczne i wskazać inne produkty.

Inaczej należy postąpić z modelem trwale wycofanym. Jeśli posiada bezpośredniego następcę, uzasadnione może być przekierowanie 301. Jeśli nie ma zamiennika, a strona nie zapewnia wartości informacyjnej, kod 404 lub 410 może być prawidłowym rozwiązaniem.

Szczególnej uwagi wymagają także filtry produktowe. Jeżeli sklep generuje adresy dla kombinacji parametrów, które nie zwracają żadnych produktów, należy zaplanować ich obsługę zgodnie z polityką indeksowania i zaleceniami Google. W wielu przypadkach trwałe puste kombinacje nie powinny funkcjonować jako indeksowalne strony zwracające 200.

Strony 404 po migracji serwisu – jak uniknąć utraty ruchu?

Zmiana domeny, struktury URL lub systemu CMS często powoduje pojawienie się dużej liczby błędów 404. Jeśli stare adresy były wcześniej indeksowane i posiadały linki, nieprawidłowo przeprowadzona migracja może prowadzić do spadku ruchu organicznego.

Podstawą jest przygotowanie mapy przekierowań ze starych adresów na właściwe nowe URL-e.

Nie należy jednak traktować każdego starego adresu jako strony wymagającej przekierowania. Jeżeli określony zasób został celowo usunięty i nie posiada odpowiednika, może prawidłowo zwracać 404 lub 410.

W procesie migracji warto kontrolować:

• zgodność przekierowań z mapą adresów,
• brak pętli i wielostopniowych łańcuchów,
• aktualizację linków wewnętrznych,
• poprawność mapy XML,
• kody HTTP kluczowych podstron,
• ruch organiczny i indeksowanie po wdrożeniu.

Dokładne planowanie przenoszenia serwisu omawiamy w poradniku Migracja strony a SEO – jak nie stracić pozycji i ruchu z Google?.

Praktyczny przykład audytu 404 w dużym sklepie internetowym

Załóżmy, że sklep posiada około 30 tysięcy produktów. Google Search Console wykazuje kilka tysięcy niedziałających adresów, a dodatkowy crawl wskazuje liczne uszkodzone linki wewnętrzne.

Zamiast automatycznie przekierowywać wszystkie adresy na kategorie, warto przeprowadzić uporządkowany proces.

Etap 1. Zebranie danych

Łączymy dane z Google Search Console, eksportu produktów, sitemap XML, crawlera i narzędzia analizującego linki zewnętrzne.

Następnie przypisujemy każdemu URL-owi informacje dotyczące statusu produktu, historycznego ruchu, linkowania i istnienia ewentualnego zamiennika.

Etap 2. Segmentacja adresów

Okazuje się, że niedziałające adresy należą do czterech głównych grup:

• produkty chwilowo niedostępne, które system błędnie usunął,
• produkty trwale wycofane z bezpośrednimi następcami,
• stare produkty bez zamienników,
• nieprawidłowo wygenerowane adresy filtrów i sortowania.

Każda grupa wymaga innego rozwiązania. Nie ma uzasadnienia dla stosowania jednej reguły przekierowania do wszystkich URL-i.

Etap 3. Wdrożenie poprawek

Przywracamy karty produktów, które powinny nadal istnieć. Dla modeli zastąpionych bezpośrednimi odpowiednikami przygotowujemy odpowiednie przekierowania.

Produkty bez zamienników mogą pozostać pod kodem 404 lub 410, jeśli nie mają wartościowej funkcji informacyjnej.

Jednocześnie poprawiamy linkowanie wewnętrzne, aktualizujemy mapy XML i ograniczamy generowanie niepotrzebnych kombinacji adresów.

Etap 4. Kontrola techniczna

Po wdrożeniu wykonujemy ponowny crawl i sprawdzamy najważniejsze schematy odpowiedzi:

Aktywna karta produktu → 200

Stary produkt z odpowiednim następcą → 301 → 200

Produkt usunięty bez zamiennika → 404 lub 410

Nieprawidłowy link wewnętrzny → poprawiony adres

Strona zawierająca komunikat błędu → właściwy status HTTP

W kolejnym kroku monitorujemy indeksowanie, liczbę błędnych odnośników oraz ruch organiczny na stronach docelowych.

Sukcesem nie jest jednak doprowadzenie do zera liczby adresów 404 w GSC. Ważniejsze jest przywrócenie dostępności strategicznych stron i usunięcie niepotrzebnych problemów w nawigacji.

Jak monitorować błędy 404 po wdrożeniu napraw?

Kontrola błędów powinna być częścią regularnego monitoringu technicznego, szczególnie w dużych sklepach i serwisach często zmieniających strukturę.

Warto połączyć kilka źródeł informacji:

W przypadku GA4 trzeba pamiętać, że standardowa analityka nie rejestruje automatycznie kodu HTTP każdej odpowiedzi serwera. Wykrywanie błędów za pomocą tytułu strony „404” lub dedykowanego zdarzenia wymaga poprawnej konfiguracji i nie zastępuje analizy kodów serwera.

Warto również ustawić alerty dla sytuacji, w których ważne podstrony nagle zaczynają zwracać 404 lub liczba błędów znacząco wzrasta po wdrożeniu zmian.

Najczęstsze błędy podczas naprawiania stron 404

Źle przeprowadzona optymalizacja może ukryć rzeczywisty problem, zamiast go rozwiązać. Szczególnie należy unikać następujących praktyk:

• Przekierowywanie wszystkich błędów 404 na stronę główną – bez sprawdzenia zgodności tematycznej.
• Stosowanie kodu 200 na szablonie błędu – prowadzące do problemów soft 404.
• Usuwanie produktów chwilowo niedostępnych – mimo że powinny wrócić do sprzedaży.
• Ignorowanie linków wewnętrznych prowadzących do 404 – nawet jeśli istnieją już przekierowania.
• Tworzenie łańcuchów przekierowań – zamiast kierowania bezpośrednio do aktualnego URL-a.
• Blokowanie adresów 404 w robots.txt – co może uniemożliwić Googlebotowi odczytanie prawidłowego statusu usuniętej strony.
• Automatyczne przekierowywanie przypadkowych błędnych adresów – bez ustalenia ich pochodzenia.
• Ocena problemu wyłącznie na podstawie liczby adresów w Search Console – bez analizy ich wartości biznesowej.

Najważniejsze jest ustalenie, czy strona powinna istnieć, została przeniesiona, czy rzeczywiście zakończyła swój cykl życia.

Strony 404 a SEO – najważniejsza jest świadoma obsługa adresów URL

Błędy 404 nie są zjawiskiem, które należy bezwzględnie wyeliminować z każdej witryny. Prawidłowy kod 404 jest naturalnym sposobem informowania wyszukiwarek, że określony zasób nie istnieje. Problem pojawia się dopiero wtedy, gdy niedziałające adresy utrudniają użytkownikom korzystanie z serwisu, prowadzą do utraty ważnych podstron lub wynikają z nieprawidłowej konfiguracji technicznej.

Skuteczne zarządzanie błędami powinno łączyć analizę danych z Google Search Console, crawlowanie witryny, kontrolę linkowania i ocenę historycznej wartości poszczególnych URL-i. Dopiero na tej podstawie można zdecydować, czy stronę przywrócić, przekierować, czy pozostawić prawidłowy status usunięcia.

Celem audytu nie jest usunięcie wszystkich komunikatów 404 z raportu GSC, ale zapewnienie, aby użytkownicy i roboty wyszukiwarek trafiali do właściwych zasobów, a strategiczne podstrony pozostawały dostępne i indeksowalne.

W 4PEOPLE analizujemy niedziałające adresy jako element technicznego SEO, uwzględniając ich wpływ na architekturę strony, linkowanie wewnętrzne, indeksowanie i ruch organiczny. Dzięki temu działania naprawcze można dostosować do rzeczywistych problemów serwisu, zamiast wdrażać automatyczne przekierowania bez analizy konsekwencji.

FAQ – błędy 404, uszkodzone linki i soft 404

Czy błędy 404 obniżają pozycje całej strony w Google?

Nie. Samo występowanie kodów 404 nie oznacza kary ani automatycznego obniżenia pozycji całej domeny. Problem pojawia się wtedy, gdy błędy dotyczą ważnych podstron, powodują utratę dostępu do wartościowych treści lub utrudniają korzystanie z witryny.

Czy wszystkie strony 404 trzeba przekierować?

Nie. Przekierowanie 301 warto stosować przede wszystkim wtedy, gdy strona została przeniesiona lub istnieje odpowiedni zamiennik. Jeśli zasób został trwale usunięty i nie ma odpowiadającej mu strony, kod 404 albo 410 jest prawidłowym rozwiązaniem.

Co to jest soft 404?

Soft 404 oznacza sytuację, w której Google interpretuje stronę jako nieistniejącą lub pozbawioną właściwej zawartości, mimo że odpowiedź serwera nie wskazuje prawidłowego błędu 404 lub 410. Typowym przykładem jest strona z komunikatem „Nie znaleziono produktu”, która zwraca kod HTTP 200.

Jak znaleźć uszkodzone linki na stronie?

Można wykorzystać Google Search Console, narzędzia crawlujące takie jak Screaming Frog lub Sitebulb, a także analizę logów serwera. W przypadku linków wewnętrznych szczególnie istotne jest sprawdzenie źródła odnośnika, aby poprawić nie tylko niedziałający adres, ale również strony, które do niego prowadzą.

Czy błąd 404 należy usunąć z Google Search Console?

Nie trzeba usuwać każdego zgłoszonego adresu 404. Jeśli strona została trwale usunięta i poprawnie zwraca odpowiedni kod, jej obecność w raporcie może być naturalna. Jeśli jednak strona powinna istnieć, należy usunąć przyczynę błędu, a następnie poczekać na ponowne przetworzenie adresu przez Google.

Czy lepiej stosować 404 czy 410?

Kod 404 informuje, że zasób nie został znaleziony, natomiast 410 jednoznacznie wskazuje jego trwałe usunięcie. Oba kody są poprawne w odpowiednich sytuacjach. Nie ma gwarancji, że 410 zawsze spowoduje zauważalnie szybsze usunięcie adresu z indeksu Google.

Czy przekierowanie 301 przenosi wartość SEO starej strony?

Poprawne przekierowanie do odpowiadającej strony docelowej pozwala Google przetwarzać sygnały związane ze starym adresem w kontekście nowego URL-a. Nie gwarantuje jednak zachowania identycznych pozycji. Ważne jest, aby przekierowanie prowadziło do rzeczywiście powiązanej zawartości.

Czy można zablokować adresy 404 w robots.txt?

Nie jest to zalecany sposób obsługi usuniętych stron. Jeśli Googlebot nie może pobrać adresu, nie zobaczy zwracanego przez niego kodu 404 lub 410. W przypadku stron trwale usuniętych lepiej umożliwić robotowi odczytanie prawidłowego statusu HTTP.

Jak często wykonywać audyt błędów 404?

Częstotliwość zależy od wielkości serwisu i dynamiki zmian. W dużych sklepach warto prowadzić regularny monitoring oraz wykonywać dodatkowe kontrole po aktualizacjach asortymentu, przebudowie kategorii i migracjach. W mniejszych witrynach okresowy audyt może być wystarczający, jeśli nie pojawiają się istotne zmiany techniczne.

Czy strona błędu 404 może mieć menu i wyszukiwarkę?

Tak. Warto zaprojektować użyteczną stronę błędu, która pomoże użytkownikowi znaleźć inne zasoby serwisu. Obecność menu, linków czy wyszukiwarki nie powinna jednak zmieniać statusu HTTP. Jeśli żądany zasób nie istnieje, serwer nadal powinien zwracać kod 404.