Własna strona błędu 404. Jak ją ustawić i sprawdzić, czy zwraca właściwy kod?

Każda witryna prędzej czy później pokazuje komuś komunikat „nie znaleziono”. Wystarczy literówka w adresie, usunięty produkt, stary link na obcym portalu albo zmieniona nazwa podstrony. Od właściciela zależy tylko to, co odwiedzający wtedy zobaczy: surowy, techniczny komunikat serwera czy uporządkowaną stronę, która pomaga wrócić do treści.

Ten wpis jest instrukcją dla osób prowadzących firmową stronę lub sklep, także bez pomocy programisty. Opisuję w nim dwie sprawy, które trzeba załatwić razem. Pierwsza to wygląd i treść własnej strony błędu. Druga, ważniejsza dla Google, to kod odpowiedzi, który serwer wysyła razem z tą stroną.

Po lekturze będzie wiadomo, jak ustawić własną stronę 404 w WordPressie oraz na serwerach Apache i nginx, jak trzema sposobami sprawdzić, czy zwraca ona kod 404, oraz co zrobić, gdy zwraca inny. Osobno omawiam raport w Google Search Console, w którym widać skutki błędnej konfiguracji.

Po co stronie własny komunikat o błędzie 404?

Kod 404 to odpowiedź serwera oznaczająca, że pod podanym adresem nic nie ma. Sam w sobie nie jest usterką. Google w pomocy Search Console pisze wprost, że odpowiedź 404 nie stanowi problemu, jeśli strona została usunięta i nie ma zamiennika. Kłopot zaczyna się dopiero wtedy, gdy człowiek trafia w ślepy zaułek, a robot wyszukiwarki dostaje sprzeczne sygnały.

Domyślna strona błędu serwera to zwykle biała plansza z jednym zdaniem po angielsku. Nie ma na niej logo, menu ani żadnej drogi dalej. Odwiedzający najczęściej zamyka kartę i wraca do wyników wyszukiwania, gdzie czeka konkurencja. Własna strona błędu zatrzymuje go w serwisie: wyjaśnia, co się stało, i podsuwa kilka sensownych kierunków.

Druga korzyść jest mniej widoczna. Dobrze ustawiona strona 404 mówi robotom jasno: tego adresu nie należy indeksować. Dokumentacja Google podaje, że adresy zwracające kody z grupy 4xx nie są indeksowane, a te, które były w indeksie, z czasem z niego wypadają. Dzięki temu w wynikach nie zostają martwe podstrony, a robot nie traci czasu na puste adresy.

Czym różni się prawdziwy błąd 404 od pozornego?

Tu leży sedno całego tematu. Strona może wyglądać jak komunikat o błędzie, a mimo to serwer wyśle z nią kod 200, czyli informację „wszystko w porządku, oto treść”. Człowiek widzi napis „nie znaleziono”, a robot dostaje sygnał, że pod tym adresem jest zwykła, działająca podstrona. Google nazywa taką sytuację błędem soft 404, a w polskiej wersji Search Console widnieje ona jako „Pozorny błąd 404”.

Dokumentacja Google wymienia typowe źródła takich stron: brakujący plik na serwerze, zerwane połączenie z bazą danych, wewnętrzną wyszukiwarkę, która zwraca pustą stronę wyników, oraz plik JavaScript, który się nie wczytał. W praktyce dochodzi do tego jeszcze jedna przyczyna, czyli własna strona błędu podłączona w niewłaściwy sposób. To ona jest tematem dalszych rozdziałów.

Google opisuje skutki jednoznacznie: zwracanie kodu 200 i wyświetlanie przy tym komunikatu o błędzie nie jest dobrym rozwiązaniem, a takie strony są wykluczane z wyszukiwarki. Jeżeli algorytmy uznają na podstawie zawartości, że mają do czynienia ze stroną błędu, Search Console pokaże ten adres w raporcie „Indeksowanie stron”.

Ta sama dokumentacja podaje trzy drogi naprawy, zależne od tego, co stało się z podstroną. Jeśli treść zniknęła na dobre, serwer ma zwracać kod 404 albo 410. Jeśli treść przeniesiono pod inny adres, potrzebne jest przekierowanie 301. Jeśli podstrona nadal istnieje, a mimo to została uznana za pozorny błąd, trzeba ustalić, dlaczego robot nie widzi jej treści. Do wszystkich trzech przypadków wracam niżej.

Co powinno się znaleźć na dobrej stronie 404?

Strona błędu ma jedno zadanie: w kilka sekund pomóc komuś, kto się zgubił. Nie jest miejscem na długie teksty ani na rozbudowane animacje. Google w swoich wskazówkach wymienia kilka elementów, które sprawdzają się w większości serwisów, i sam stosuję podobny zestaw:

• jasna informacja, że strony o tym adresie nie udało się znaleźć, napisana uprzejmym, zrozumiałym językiem,
• ten sam wygląd co reszta witryny, razem z logo, menu i stopką,
• odnośnik do strony głównej oraz do kilku najważniejszych miejsc, na przykład oferty, sklepu, bloga i kontaktu,
• pole wyszukiwarki, jeżeli serwis ma wyszukiwarkę wewnętrzną,
• prosta możliwość zgłoszenia niedziałającego linku, choćby adres poczty elektronicznej.

Radzę zrezygnować z żartobliwych grafik, jeśli nie pasują do charakteru firmy. Kancelaria prawna czy gabinet lekarski lepiej wypadną z krótkim, rzeczowym komunikatem. Dobrze brzmi na przykład zdanie: Nie udało się znaleźć strony o tym adresie. Mogła zostać przeniesiona albo usunięta. Poniżej znajdują się odnośniki do najczęściej odwiedzanych miejsc w serwisie.

Strona błędu powinna być lekka. Nie ma powodu, by ładowała pokaz slajdów, film czy kilkanaście skryptów. Roboty i automaty skanujące sieć odwiedzają nieistniejące adresy często, więc ciężka strona 404 niepotrzebnie obciąża serwer.

Dwie rzeczy są na stronie 404 zbędne. Znacznik noindex nie jest potrzebny, bo adresy z kodem 404 i tak nie trafiają do indeksu. Nie należy też blokować strony błędu w pliku robots.txt, ponieważ robot musi móc pobrać odpowiedź, żeby odczytać jej kod.

Jak ustawić stronę 404 w WordPressie?

WordPress ma tę zaletę, że sam wysyła kod 404, gdy nie znajdzie treści dla danego adresu. Właściciel strony nie musi niczego ustawiać na serwerze. Wystarczy przygotować szablon, który system pokaże w takiej sytuacji. Sposób zależy od rodzaju motywu.

Motyw blokowy i edytor witryny

W motywach blokowych strona błędu jest jednym z szablonów dostępnych w edytorze witryny. Dokumentacja WordPressa opisuje szablon 404 jako ten, który służy do dostosowania układu strony błędu. Zmiana wygląda następująco:

1. W panelu administracyjnym należy przejść do menu „Wygląd” i wybrać „Edytor”.
2. W edytorze witryny trzeba otworzyć listę „Szablony”.
3. Na liście należy odszukać szablon z liczbą 404 w nazwie i kliknąć go, aby otworzyć podgląd, a następnie przejść do edycji.
4. W treści szablonu wstawia się bloki: nagłówek z komunikatem, akapit z wyjaśnieniem, blok wyszukiwarki oraz przyciski lub listę odnośników do najważniejszych podstron.
5. Zmiany zatwierdza się przyciskiem „Zapisz”.
6. W nowej karcie przeglądarki wpisuje się adres, który na pewno nie istnieje, i ocenia efekt.

Jeżeli na liście nie ma szablonu 404, motyw korzysta z szablonu ogólnego. W takiej sytuacji edytor pozwala dodać brakujący szablon z poziomu tej samej listy. Dokładne nazwy pozycji różnią się między motywami i wersjami systemu, dlatego należy kierować się liczbą 404 w nazwie.

Motyw klasyczny i kreatory stron

W motywach klasycznych za stronę błędu odpowiada plik 404.php w katalogu motywu. Dokumentacja dla twórców motywów radzi, aby za punkt wyjścia przyjąć plik index.php, zostawić w nim wczytywanie nagłówka i stopki, a w środku umieścić komunikat oraz formularz wyszukiwania. Zmianę najlepiej wprowadzać w motywie potomnym, bo aktualizacja motywu głównego nadpisze poprawki.

Wiele motywów i kreatorów stron ma własne ustawienie strony błędu, zwykle w opcjach motywu albo wśród szablonów kreatora. To wygodna droga dla osób, które nie chcą edytować plików. Należy jednak zwrócić uwagę na jedno: kreator ma wyświetlać szablon pod błędnym adresem, a nie przenosić odwiedzającego na osobną podstronę o nazwie „404”. Druga metoda kończy się przekierowaniem i kodem 200.

Ostrożności wymagają też wtyczki, które wszystkie błędy 404 kierują na stronę główną. Wygląda to schludnie, ale odwiedzający nie wie, dlaczego zobaczył coś innego, niż szukał, a Google może potraktować takie adresy jako pozorne błędy 404. Bezpieczniej jest przekierowywać tylko te adresy, które mają rzeczywistego następcę.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: przygotuję stronę błędu, podłączę ją we właściwy sposób i sprawdzę, czy serwer wysyła z nią kod 404.

Jak ustawić stronę 404 na serwerze Apache lub nginx?

Strony, które nie działają na WordPressie ani innym systemie z własną obsługą błędów, wymagają ustawienia na poziomie serwera. Dotyczy to witryn złożonych z plików HTML oraz starszych, autorskich rozwiązań. Najpierw trzeba przygotować sam plik strony błędu, na przykład 404.html, i wgrać go do głównego katalogu witryny.

Serwer Apache i plik .htaccess

Na serwerach Apache stronę błędu wskazuje dyrektywa ErrorDocument. Według dokumentacji Apache można jej użyć w pliku .htaccess, o ile administrator serwera na to zezwolił. Na większości hostingów współdzielonych tak właśnie jest. Kolejność czynności:

1. Należy połączyć się z serwerem przez menedżer plików w panelu hostingu albo przez program do obsługi FTP.
2. Przed jakąkolwiek zmianą trzeba pobrać na dysk kopię obecnego pliku .htaccess z głównego katalogu witryny.
3. Do głównego katalogu wgrywa się przygotowany plik 404.html.
4. W pliku .htaccess dopisuje się w osobnym wierszu: ErrorDocument 404 /404.html
5. Po zapisaniu pliku należy od razu otworzyć stronę główną i jedną podstronę, aby upewnić się, że witryna działa.
6. Na końcu otwiera się nieistniejący adres i sprawdza, czy pojawia się nowa strona błędu.

Najważniejszy szczegół to ukośnik na początku ścieżki. Dokumentacja Apache rozróżnia ścieżkę lokalną, zaczynającą się od ukośnika, i pełny adres zaczynający się od http. Przy pełnym adresie serwer wysyła przekierowanie, nawet jeśli dokument leży na tym samym serwerze. Przeglądarka i robot nie otrzymują wtedy pierwotnego kodu błędu, tylko kod przekierowania. Dokumentacja ostrzega, że wprowadza to w błąd roboty, które po kodzie oceniają, czy adres jest poprawny.

Zapis ErrorDocument 404 https://example.pl/404.html jest więc błędem, choć strona błędu się wyświetla. Poprawny jest wyłącznie zapis ze ścieżką lokalną. Plik .htaccess wymaga przy tym ostrożności: jedna literówka potrafi wyłączyć całą witrynę i wywołać błąd serwera. Dlatego kopia pliku jest obowiązkowa. Więcej o bezpiecznej pracy z tym plikiem opisałem przy okazji przekierowań 301 w pliku .htaccess.

W witrynie na WordPressie dopisywanie tej dyrektywy zwykle nie jest potrzebne. System sam obsługuje adresy, których nie znalazł, i korzysta z szablonu motywu. Część paneli hostingowych oferuje też własny kreator stron błędów. Można z niego skorzystać, pod warunkiem że po zmianie kod odpowiedzi zostanie sprawdzony tak, jak opisuję dalej.

Serwer nginx

Na serwerach nginx nie ma pliku .htaccess. Stronę błędu ustawia się w konfiguracji serwera dyrektywą error_page, co wymaga uprawnień administratora. W bloku konfiguracji danej witryny dopisuje się wiersz: error_page 404 /404.html; Dokumentacja nginx wyjaśnia, że serwer wykonuje wtedy wewnętrzne przejście do wskazanego pliku, a odwiedzający pozostaje pod adresem, który wpisał.

Tu również są dwie pułapki. Pierwsza to zapis ze znakiem równości, na przykład error_page 404 =200 /404.html;, który według dokumentacji zmienia kod odpowiedzi na inny. Taki wiersz tworzy pozorny błąd 404 z całą pewnością. Druga to podanie pełnego adresu zamiast ścieżki: nginx wysyła wtedy do przeglądarki przekierowanie, domyślnie z kodem 302.

Po zmianie konfiguracji administrator powinien sprawdzić jej poprawność, zanim serwer wczyta ją ponownie. Błąd składni w konfiguracji nginx może unieruchomić wszystkie witryny na danym serwerze. Jeżeli hosting nie daje dostępu do konfiguracji, o dopisanie wiersza należy poprosić pomoc techniczną usługodawcy. W zgłoszeniu wystarczy napisać: Proszę o ustawienie własnej strony błędu z pliku /404.html dla domeny example.pl, z zachowaniem kodu odpowiedzi 404.

Jak sprawdzić, czy strona błędu zwraca kod 404?

Sam wygląd strony niczego nie dowodzi. Strona z dużym napisem „404” może zwracać kod 200, a strona zupełnie pusta może zwracać poprawny kod błędu. Kod odpowiedzi trzeba odczytać. Do testu potrzebny jest adres, który na pewno nie istnieje, na przykład https://example.pl/test-strony-ktorej-nie-ma, oczywiście z własną domeną.

Sprawdzenie w przeglądarce

Każda popularna przeglądarka na komputerze ma wbudowane narzędzia, które pokazują kod odpowiedzi. Poniżej opis dla przeglądarki Chrome, w pozostałych postępuje się podobnie.

1. Należy otworzyć nową kartę i nacisnąć klawisz F12, co otwiera narzędzia dla deweloperów.
2. W narzędziach trzeba przejść do karty pokazującej ruch sieciowy, w wersji angielskiej nazwanej „Network”.
3. W pasku adresu wpisuje się nieistniejący adres testowy i zatwierdza klawiszem Enter.
4. Na liście żądań pierwszy wiersz od góry to żądanie samej strony. W kolumnie stanu, w wersji angielskiej „Status”, widnieje kod odpowiedzi.
5. Jeśli na liście pojawia się więcej wierszy dokumentu, należy odczytać wszystkie po kolei. Wiersz z kodem 301 lub 302, a po nim wiersz z kodem 200, oznacza przekierowanie na osobną stronę błędu.

Prawidłowy wynik to jeden wiersz dokumentu z kodem 404 i niezmieniony adres w pasku przeglądarki. Zmiana adresu po załadowaniu strony jest pierwszym sygnałem, że konfiguracja opiera się na przekierowaniu.

Sprawdzenie w wierszu poleceń

Szybszą metodą jest polecenie curl, dostępne zwykle w terminalu systemów Windows, macOS i Linux. Wpisuje się: curl -I https://example.pl/test-strony-ktorej-nie-ma i zatwierdza klawiszem Enter. Pierwszy wiersz odpowiedzi zawiera kod, na przykład HTTP/2 404. Jeżeli zamiast tego widać kod 301 lub 302 oraz wiersz zaczynający się od słowa „location”, serwer przekierowuje.

Ta metoda ma dodatkową zaletę: pokazuje odpowiedź bez udziału pamięci podręcznej przeglądarki. Test dobrze jest powtórzyć dla kilku rodzajów adresów: nieistniejącej podstrony, nieistniejącego pliku graficznego oraz adresu w podkatalogu. Zdarza się, że serwer obsługuje je odmiennie.

Sprawdzenie w Google Search Console

Dwie pierwsze metody pokazują, co dostaje zwykły odwiedzający. Narzędzie do sprawdzania adresów URL w Search Console pokazuje, co dostaje robot Google. To istotne, bo serwer albo zapora mogą traktować roboty inaczej niż przeglądarki.

1. Po zalogowaniu do Search Console należy wybrać właściwą usługę, czyli swoją witrynę.
2. W pasku wyszukiwania na górze ekranu wpisuje się pełny nieistniejący adres testowy i zatwierdza.
3. Na stronie wyniku trzeba kliknąć „Sprawdź URL wersji opublikowanej” i poczekać na zakończenie testu.
4. Wynik testu informuje, czy Google ma dostęp do adresu. Przy poprawnie ustawionej stronie błędu narzędzie zgłasza, że adres jest niedostępny z powodu błędu 404.
5. Jeżeli test kończy się informacją, że Google ma dostęp do adresu, należy kliknąć „Wyświetl przetestowaną stronę” i obejrzeć zrzut ekranu oraz szczegóły odpowiedzi. Widok strony błędu przy udanym pobraniu oznacza pozorny błąd 404.

Ten trzeci test daje wynik odwrotny do intuicji: dla nieistniejącego adresu „niepowodzenie” pobrania jest dobrą wiadomością. Oznacza, że robot zrozumiał, iż strony nie ma.

Co oznacza wynik inny niż 404 i jak go naprawić?

Każdy z nieprawidłowych wyników ma inną przyczynę, więc naprawę należy dobrać do tego, co pokazał test. Poniżej trzy sytuacje, z którymi spotykam się najczęściej.

Kod 200 pod nieistniejącym adresem

Serwer twierdzi, że strona istnieje. W WordPressie przyczyną bywa wtyczka albo ustawienie motywu, które podmienia treść błędu na zwykłą podstronę. Należy wyłączać kolejno wtyczki związane z przekierowaniami i stronami błędów, a po każdej zmianie powtarzać test. Na serwerze nginx trzeba poszukać w konfiguracji zapisu ze znakiem równości przy dyrektywie error_page.

Drugą częstą przyczyną jest pamięć podręczna. Wtyczka przyspieszająca stronę albo sieć dostarczania treści może zapisać stronę błędu i podawać ją później z kodem 200. Trzeba wyczyścić pamięć podręczną, powtórzyć test poleceniem curl i sprawdzić w ustawieniach narzędzia, jak traktuje ono odpowiedzi z kodem 404.

W serwisach, w których treść buduje JavaScript, serwer często zwraca kod 200 dla każdego adresu, a komunikat o błędzie rysuje dopiero skrypt. To zadanie dla programisty: aplikacja powinna zwracać kod 404 po stronie serwera. Samodzielne obejścia w takich serwisach łatwo kończą się kolejnymi błędami.

Kod 301 lub 302, a po nim 200

Serwer przenosi odwiedzającego na osobną stronę błędu albo na stronę główną. Na Apache należy otworzyć plik .htaccess i sprawdzić, czy dyrektywa ErrorDocument zawiera pełny adres. Jeśli tak, zamienia się go na ścieżkę lokalną zaczynającą się od ukośnika. Na nginx postępuje się tak samo z dyrektywą error_page. W WordPressie trzeba przejrzeć reguły we wtyczce do przekierowań i usunąć regułę obejmującą wszystkie nieznalezione adresy.

Jeżeli przekierowań jest po drodze kilka, przyczyna może leżeć gdzie indziej, na przykład w regułach dotyczących wersji z www albo protokołu https. Różnice między rodzajami przekierowań opisałem we wpisie o tym, czym różni się przekierowanie 301 od 302.

Kod 500 lub inny z grupy 5xx

Kod z grupy 5xx oznacza błąd serwera, a nie brak strony. Najczęściej winna jest literówka w pliku .htaccess albo wskazanie pliku strony błędu, którego nie ma na serwerze. Dokumentacja Google podaje, że błędy serwera skłaniają roboty do spowolnienia odwiedzin, a adresy, które uporczywie zwracają taki błąd, są usuwane z indeksu. Naprawę należy zacząć od przywrócenia kopii pliku .htaccess i ponownego, ostrożnego wprowadzenia zmiany.

Kiedy zostawić błąd 404, a kiedy przekierować adres?

Własna strona błędu nie zwalnia z decyzji, co zrobić z każdym usuniętym adresem. Dokumentacja Google daje tu prostą regułę. Jeśli podstrona została usunięta i nie ma w witrynie strony zastępczej z podobną zawartością, serwer powinien zwracać kod 404 albo 410. Oba kody mówią wyszukiwarce, że strony nie ma i nie należy jej indeksować.

Jeśli treść przeniesiono pod nowy adres albo istnieje wyraźny następca, właściwe jest przekierowanie 301 na ten konkretny adres. Dotyczy to zwłaszcza podstron, do których prowadzą linki z innych serwisów albo które przyciągały odwiedzających z wyszukiwarki. Przy przebudowie całej witryny lista takich przekierowań jest podstawą bezpiecznej zmiany, o czym piszę szerzej we wpisie o migracji strony bez utraty pozycji w Google.

Przekierowanie na stronę luźno związaną z tematem jest gorsze niż uczciwy błąd 404. Ktoś, kto szukał konkretnego produktu, a trafił na ogólną kategorię albo stronę główną, czuje się wprowadzony w błąd. Uważam, że lepiej pokazać mu dobrze przygotowaną stronę błędu z wyszukiwarką.

Osobna sprawa to linki wewnętrzne. Jeżeli do usuniętej podstrony prowadzą odnośniki z menu, stopki albo treści wpisów, trzeba je poprawić u źródła. Strona błędu ma obsługiwać sytuacje wyjątkowe, a nie zastępować porządek w serwisie.

Jak sprawdzić w Search Console, czy naprawa zadziałała?

Po poprawieniu konfiguracji należy wrócić do Search Console. Raport „Indeksowanie stron” pokazuje powody, dla których adresy nie trafiły do indeksu. Dwa z nich dotyczą tego tematu: „Nie znaleziono (404)” oraz „Pozorny błąd 404”.

1. W menu Search Console należy otworzyć raport „Indeksowanie stron”.
2. W tabeli z powodami niezindeksowania trzeba odszukać wiersz „Pozorny błąd 404” i kliknąć go.
3. Na liście przykładowych adresów należy ocenić każdy z osobna: czy podstrona powinna istnieć, czy została przeniesiona, czy usunięta.
4. Po wprowadzeniu poprawek dla całej grupy trzeba kliknąć „Sprawdź poprawkę”.
5. Postęp weryfikacji widać w tym samym miejscu raportu. Według pomocy Google weryfikacja zajmuje zazwyczaj do 2 tygodni, a w niektórych przypadkach znacznie dłużej.

Adresy z wiersza „Nie znaleziono (404)” przegląda się w inny sposób. Większość z nich nie wymaga żadnego działania, bo usunięta podstrona ma zwracać taki kod. Uwagi wymagają tylko adresy ważnych podstron, które nie powinny były zniknąć, oraz adresy powstałe z błędnych linków wewnętrznych. Google przez pewien czas wraca do takich adresów, więc lista nie znika z dnia na dzień.

Jeżeli pozorny błąd dotyczy podstrony, która istnieje i ma treść, przyczyną bywa bardzo uboga zawartość, pusta kategoria sklepu, pusta strona wyników wyszukiwania albo zasoby, których robot nie mógł pobrać. Dokumentacja Google wskazuje tu między innymi zasoby zablokowane w pliku robots.txt, zbyt liczne lub zbyt duże pliki i błędy serwera. Narzędzie do sprawdzania adresów URL pokaże, jak robot widzi taką podstronę.

Gdy weryfikacja się nie powiedzie, raport wskaże adresy, w których problem nadal występuje. Należy każdy z nich sprawdzić poleceniem curl i dopiero po poprawce ponownie uruchomić weryfikację. Jak czytać stan pojedynczego adresu, opisałem we wpisie o tym, jak sprawdzić, czy Google zaindeksował stronę.

Jakich błędów unikać przy stronie 404?

Większość kłopotów ze stroną błędu bierze się z kilku powtarzalnych pomyłek. Zebrałem je w jednym miejscu, bo każdą da się wychwycić opisanymi wyżej testami.

• Przekierowanie wszystkich nieistniejących adresów na stronę główną zamiast pokazania strony błędu.
• Pełny adres z http w dyrektywie ErrorDocument lub error_page zamiast ścieżki lokalnej.
• Utworzenie zwykłej podstrony o nazwie „404” i kierowanie na nią ruchu, co daje kod 200.
• Edycja pliku .htaccess albo konfiguracji serwera bez kopii zapasowej.
• Ocena strony błędu wyłącznie „na oko”, bez odczytania kodu odpowiedzi.
• Zablokowanie strony błędu w pliku robots.txt.
• Pomijanie testu po aktualizacji motywu, zmianie wtyczki do pamięci podręcznej lub przeniesieniu witryny na inny serwer.

Ostatni punkt jest w praktyce najczęstszy. Strona błędu działała poprawnie w dniu wdrożenia, a po kilku miesiącach i paru zmianach w serwisie zwraca już inny kod. Radzę powtarzać krótki test poleceniem curl po każdej większej zmianie technicznej. Zajmuje to minutę, a pozwala wychwycić problem, zanim pojawi się w raportach.

Najczęstsze pytania

Czy błędy 404 obniżają pozycję strony w Google?

Sam fakt, że nieistniejące adresy zwracają kod 404, jest zachowaniem prawidłowym i Google opisuje je jako niebędące problemem, gdy strona została usunięta bez zamiennika. Szkodzić mogą skutki uboczne: utracone podstrony, które przyciągały odwiedzających, linki z innych serwisów prowadzące donikąd oraz niedziałające odnośniki wewnątrz witryny. Dlatego każdy ważny adres wymaga decyzji, czy zostawić błąd, czy ustawić przekierowanie.

Czy kod 410 jest lepszy niż 404?

Oba kody należą do tej samej grupy i dokumentacja Google wymienia je obok siebie jako właściwe dla usuniętych stron bez następcy. Kod 410 oznacza, że zasób został usunięty celowo. Dla większości firmowych witryn kod 404 jest w pełni wystarczający, a zmiana na 410 nie wymaga pośpiechu.

Czy stronę 404 trzeba oznaczać znacznikiem noindex?

Nie ma takiej potrzeby, jeśli strona rzeczywiście zwraca kod 404. Google nie indeksuje adresów z kodami z grupy 4xx i ignoruje ich treść. Znacznik noindex bywa stosowany jako proteza przy stronach błędu zwracających kod 200, ale właściwą naprawą jest poprawienie kodu odpowiedzi.

Dlaczego Search Console pokazuje pozorny błąd 404 dla strony, która istnieje?

Algorytm ocenił, że zawartość przypomina stronę błędu. Zwykle chodzi o podstronę prawie bez treści, pustą kategorię, pusty wynik wyszukiwania wewnętrznego albo o stronę, której najważniejsze zasoby nie wczytały się robotowi. Należy sprawdzić adres narzędziem do sprawdzania adresów URL, obejrzeć zrzut ekranu z testu i uzupełnić treść albo usunąć przeszkodę w pobieraniu zasobów.

Czy stronę błędu można zbudować w kreatorze stron?

Tak, o ile kreator podstawia swój szablon pod błędnym adresem i nie zmienia kodu odpowiedzi. Po zapisaniu szablonu należy wykonać test w przeglądarce lub poleceniem curl. Jeżeli adres w pasku przeglądarki się zmienia albo kod wynosi 200, trzeba wybrać inne ustawienie kreatora lub wrócić do szablonu motywu.

Jak długo adres z błędem 404 pozostaje w wynikach wyszukiwania?

Google nie podaje jednego terminu. Dokumentacja mówi, że adresy z kodami 4xx, które były w indeksie, są z niego usuwane, a robot z czasem odwiedza je coraz rzadziej. W praktyce trwa to od kilku dni do kilku tygodni, zależnie od tego, jak często robot wraca do danej witryny.

Czy przy stronie błędu potrzebna jest mapa witryny?

Strona błędu nie powinna znajdować się w mapie witryny, podobnie jak adresy usuniętych podstron. Mapa ma zawierać wyłącznie działające adresy, które mają trafić do indeksu. Po usunięciu większej liczby podstron dobrze jest sprawdzić, czy mapa została odświeżona i nie podsuwa robotom martwych adresów.

Co zrobić, gdy hosting nie pozwala edytować pliku .htaccess?

Należy poszukać w panelu hostingu ustawień stron błędów albo zwrócić się do pomocy technicznej z prośbą o ustawienie własnej strony 404 ze ścieżką lokalną. Po zmianie trzeba samodzielnie odczytać kod odpowiedzi, bo kreatory w panelach bywają ustawione na przekierowanie. Jeżeli usługodawca nie umożliwia poprawnej konfiguracji, pozostaje obsługa błędów po stronie systemu zarządzania treścią.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zrozumiałe. Strona błędu wydaje się drobiazgiem, a wymaga zajrzenia do motywu, plików serwera i raportów Google jednocześnie. Mogę zająć się tym od początku do końca: sprawdzę, co witryna zwraca dziś pod nieistniejącymi adresami, przygotuję czytelną stronę błędu w stylu serwisu, podłączę ją tak, aby serwer wysyłał kod 404, a potem przejrzę raport w Search Console i uporządkuję adresy, które wymagają przekierowania.

Na koniec przekazuję krótkie podsumowanie z wynikami testów, zrozumiałe także dla osób bez przygotowania technicznego. W tej sprawie można zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Wystarczy podać adres witryny, resztę ustalę w rozmowie.