Błąd 404: co oznacza i jak go naprawić na stronie?

Błąd 404 Not Found oznacza, że serwer nie znalazł zasobu odpowiadającego żądanemu URL. To kod HTTP, a nie sam wygląd strony z komunikatem "Nie znaleziono strony". Własna strona 404 może wyglądać jak reszta serwisu, ale nadal powinna zwracać status 404 dla nieistniejącego adresu.

Nie myl 404 z błędem 403 ani 500. Przy 403 serwer odmawia dostępu do zasobu, a przy 500 wystąpił błąd po stronie serwera podczas obsługi żądania. Przy 404 zasób pod tym adresem nie został znaleziony, choć sama witryna może działać poprawnie.

Warto sprawdzić rzeczywisty status, a nie oceniać go wyłącznie po nagłówku strony. Użyj narzędzi developerskich przeglądarki, zakładki Network, albo wtyczki do crawlowania, która pokazuje kod odpowiedzi. Jeśli strona prezentuje komunikat o braku treści, lecz zwraca 200, może to być soft 404. Google opisuje soft 404 jako stronę wyglądającą na nieistniejącą, która zwraca status sukcesu, przez co sygnał dla wyszukiwarki jest niejednoznaczny: diagnostyka błędów crawlowania Google.

Odróżnienie prawdziwego 404 od problemu całego routingu oszczędza niepotrzebnych przekierowań. Jeśli podobne błędy obejmują wiele podstron WordPressa, zobacz też poradnik o typowych błędach WordPressa.

Sprawdź adres, który zwraca 404, oraz kilka znanych działających podstron. To proste porównanie rozdziela literówkę lub usuniętą treść od awarii reguł routingu.

Testuj URL z końcowym ukośnikiem i bez niego, ale nie zakładaj, że każdy serwer musi obsługiwać oba warianty tak samo. Sprawdź też wersję domeny z `www` oraz bez `www` i upewnij się, że wszystkie warianty prowadzą do oczekiwanego adresu kanonicznego. Jeśli 404 pojawia się po kliknięciu linku wewnętrznego, skopiuj URL z linku i porównaj go z faktycznym adresem strony.

Przed edycją reguł serwera zapisz przykładowe adresy, które działają, i te, które nie działają. Ta lista pozwala po zmianie powtórzyć identyczne testy i wykryć, czy naprawa pojedynczego URL nie zepsuła innych typów podstron.

Diagnozuj od najprostszej różnicy w adresie do konfiguracji serwera. Nie zaczynaj od masowego przekierowywania wszystkich błędów na stronę główną, bo maskuje ono problem i utrudnia użytkownikowi znalezienie właściwej treści.

1. Porównaj żądany URL z adresem w menu, linku, kampanii lub zewnętrznym odnośniku. Zwróć uwagę na literówki, wielkość liter, polskie znaki, końcowy ukośnik i zmieniony slug.
2. W panelu CMS sprawdź, czy strona istnieje, jest opublikowana i ma oczekiwany adres. W WordPressie znajdziesz ją w `Strony > Wszystkie strony` lub `Wpisy > Wszystkie wpisy`.
3. Sprawdź historię zmian URL oraz reguły przekierowań. Zwróć uwagę na łańcuchy, pętle i przekierowanie do adresu, który sam zwraca 404.
4. Porównaj access logi dla żądanego URL. Zapisz status, datę, metodę i adres źródłowy. Jeśli serwer rejestruje ścieżkę, sprawdź, czy użytkownik i roboty wyszukiwarek żądają tego samego adresu.
5. Jeśli problem obejmuje wiele tras, sprawdź ustawienia bezpośrednich odnośników, reguły rewrite, konfigurację serwera WWW i ewentualny cache.

Logi access pokazują żądanie i status, natomiast log błędów może wskazać problemy z rewrite, brak pliku albo błędną konfigurację. Lokalizacja logów zależy od hostingu. Gdy nie masz dostępu, podaj administratorowi przykładowe adresy oraz godzinę wystąpienia i poproś o wpisy dla tego zakresu.

Jeżeli po sprawdzeniu adresu okazuje się, że problem dotyczy struktury URL w WordPressie, zapoznaj się z materiałem o permalinkach WordPress i błędach 404. W przypadku awarii wielu typów podstron warto porównać objawy z opisem problemów z WordPressem.

Sposób naprawy zależy od tego, czy strona istnieje, czy zmieniła adres, czy też WordPress nie potrafi dopasować trasy do treści. Zrób kopię konfiguracji przed zmianą reguł serwera lub permalinków.

Jeśli strona istnieje, sprawdź jej status publikacji, slug i przypisany typ treści. Potem w panelu WordPress przejdź do `Ustawienia > Bezpośrednie odnośniki` i sprawdź wybraną strukturę URL. Zapisanie ustawień odświeża reguły przepisywania adresów, ale nie zmieniaj przypadkowo struktury, jeśli nie planujesz migracji URL.

Jeżeli używasz Apache, sprawdź `.htaccess` w katalogu instalacji. WordPress może wyświetlić komunikat "Powinieneś zaktualizować plik .htaccess teraz", kiedy nie może sam zapisać reguł dla permalinków. Przed jakąkolwiek edycją skopiuj plik i zachowaj jego obecną zawartość. Dokumentacja WordPressa opisuje zapisanie ekranu permalinków i ręczne umieszczenie reguł, jeśli `.htaccess` nie jest zapisywalny: Ustawienia bezpośrednich odnośników.

Jeśli wszystkie podstrony po migracji zwracają 404, sprawdź także, czy serwer obsługuje wymagane reguły rewrite. Dokumentacja WordPressa wskazuje, że przy 404 dla Pretty Permalinks na Apache przyczyną może być nieaktywne `mod_rewrite`: FAQ rozwiązywania problemów WordPress. Na Nginx reguły są konfigurowane inaczej, więc nie wklejaj tam składni `.htaccess`.

Gdy pojedyncza wtyczka zmienia routing, testuj ją na stagingu i dezaktywuj tylko ją. Zmiana całego zestawu wtyczek może wpłynąć na formularze, sklep lub integracje. Jeśli problem zaczął się po aktualizacji, sprawdź log zmian i kopię sprzed aktualizacji, a nie odtwarzaj całej witryny bez ustalenia przyczyny.

Przekierowanie 301 stosuj wtedy, gdy stary adres został trwale przeniesiony i istnieje sensowny odpowiednik treści. Jeżeli nie ma właściwego zamiennika, pozostaw status 404 albo zwróć 410, gdy zasób został trwale usunięty.

Nie kieruj wszystkich nieistniejących adresów na stronę główną. Taki przekaz nie wyjaśnia użytkownikowi, gdzie trafiła konkretna treść, a Google może zaklasyfikować podobną stronę jako soft 404. Google zaleca 301, gdy strona została przeniesiona, oraz prawdziwe 404 lub 410, gdy nie ma zastępczej treści: wskazówki Google dotyczące błędów crawlowania.

Przed zmianą adresu przygotuj mapę stary URL -> nowy URL. Sprawdź, czy adres docelowy zwraca 200, czy nie ma pętli i czy przekierowanie prowadzi bezpośrednio do końcowej strony. Zaktualizuj linki wewnętrzne, mapę witryny i odnośniki w kampaniach, zamiast polegać na przekierowaniu jako jedynym rozwiązaniu.

W sklepie internetowym odróżnij sezonowy brak produktu od jego trwałego wycofania. Jeśli produkt wróci, zachowanie strony z informacją o dostępności jest zwykle bardziej użyteczne niż kasowanie URL. Jeśli produkt nie wróci, sprawdź, czy następca jest faktycznie podobny; sam fakt, że należy do tej samej kategorii, nie zawsze uzasadnia przekierowanie.

Google Search Console pozwala sprawdzić, które adresy Google próbował crawlować i jak klasyfikuje ich stan. W raporcie indeksowania stron przejrzyj przykłady adresów z błędem, a w narzędziu Inspekcja adresu URL sprawdź pojedynczą stronę.

Otwórz Search Console, wybierz właściwą usługę i przejdź do raportu indeksowania stron. Jeśli problem dotyczy konkretnego URL, wklej go do Inspekcji adresu URL. Po poprawce użyj testu opublikowanego adresu, aby sprawdzić bieżący stan strony. Narzędzie może też wyświetlić informacje o załadowanych zasobach i pozwala poprosić Google o ponowne crawlowanie. Szczegóły opisuje dokumentacja Search Console.

Sprawdź soft 404 oddzielnie od prawdziwych 404. Jeśli usunięta strona zwraca 200 i wyświetla komunikat o braku treści, popraw odpowiedź serwera na 404 lub 410. Jeśli strona nadal istnieje, ale Google zgłasza soft 404, sprawdź wyrenderowaną wersję w Inspekcji adresu URL, blokowane zasoby, błędy JavaScript i to, czy główna treść rzeczywiście się ładuje.

Nie każdy 404 wskazany w Search Console wymaga przekierowania. Część adresów może być wynikiem literówki, automatycznych prób botów lub nieaktualnego linku z zewnętrznego serwisu. Najpierw ustal, czy adres powinien istnieć i czy nadal ma linki, ruch lub wartość dla użytkownika. Gdy taki adres ma prawidłowy odpowiednik, napraw go; gdy nie ma, prawdziwy status 404 może być właściwym wynikiem.

Powtarzającym się błędom zapobiega kontrola adresów przed publikacją, migracją i usunięciem treści. Zmiana URL bez planu przekierowań szybko tworzy niedziałające linki w menu, artykułach, kampaniach i zewnętrznych serwisach.

Przed zmianą struktury przygotuj listę starych adresów i ich docelowych odpowiedników. Wykonaj crawl witryny, eksportując adresy, kody odpowiedzi i linki wewnętrzne. Po wdrożeniu przejdź tę samą listę ponownie i sprawdź, czy stare adresy przekierowują do właściwych stron, a nowe zwracają 200.

Dla publikacji i wycofywania produktów ustal prostą regułę: strona zostaje, gdy oferta jest czasowo niedostępna; przekierowanie ma prowadzić do rzeczywistego następcy; treść bez odpowiednika ma zwracać 404 lub 410. Po zmianach monitoruj access log, linki w menu i raport Search Console. Wewnętrzny link do własnej strony 404 napraw u źródła, zamiast dodawać kolejne przekierowanie.

Jeśli adresy zmieniają się podczas przebudowy serwisu, testuj mapę URL na kopii witryny i zachowaj ją jako część dokumentacji wdrożenia. Pozwala to odtworzyć powód przekierowania, gdy po kilku miesiącach zmieni się struktura kategorii lub oferta.

Dobra strona 404 jasno informuje, że pod tym adresem nie ma treści, i pomaga użytkownikowi wrócić do właściwej części witryny. Powinna zachować nawigację i styl serwisu, ale nie może udawać, że brakująca strona nadal działa.

Umieść krótki komunikat, odnośnik do strony głównej oraz dostęp do najważniejszych kategorii lub wyszukiwarki, jeśli pomaga ona w odnalezieniu treści. W sklepie możesz wskazać kategorie produktów, ale unikaj automatycznego przekierowania na losową ofertę. Jeśli użytkownik trafił z uszkodzonego linku, możliwość zgłoszenia problemu ułatwia jego naprawę.

Sprawdź kod HTTP strony 404 po wdrożeniu. Niestandardowy szablon może wyświetlać właściwy komunikat, a mimo to zwracać 200, co tworzy soft 404. Google zaleca utrzymanie prawdziwego statusu 404 dla nieistniejącej strony i traktuje użyteczny szablon jako element doświadczenia użytkownika, nie zamiennik prawidłowego kodu odpowiedzi.

Jeśli nie masz pewności, czy problem wynika z treści, routingu czy konfiguracji serwera, naprawa WordPressa może objąć diagnozę i sprawdzenie przekierowań. Przy większej zmianie witryny zaplanuj również opiekę nad WordPressem, aby monitorować działanie po wdrożeniu.

Problemy z trasami po migracji mogą występować razem z innymi błędami aplikacji. Osobny opis znajdziesz w materiale o błędzie 500 WordPress, jeśli serwer zamiast 404 zwraca błąd wewnętrzny.

• WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji