Jak radzę sobie z błędami 404

Czym są błędy 404

Błąd 404 to kod odpowiedzi serwera zwracany wtedy, gdy żądany zasób nie istnieje. Wyskakuje wtedy, gdy ktoś (lub coś) chce wyświetlić nieistniejący adres URL na stronie. To jedyna bezpośrednia przyczyna 404, ale do takiej sytuacji może dojść na wiele sposobów.

Błąd 404 może pojawić się, gdy:

• zmienimy adres URL podstrony i nie ustawimy przekierowania,
• usuniemy podstronę i nie ustawimy przekierowania,
• gdy gdzieś pojawi się link wewnętrzny lub zewnętrzny do nieistniejącej podstrony (np. z błędem),
• lub gdy użytkownik będzie wpisywał adres, który nie istnieje.

Co ważne, nie każdy z nich będzie wymagał jakiegoś działania, bo w wielu przypadkach błąd ten jest po prostu naturalny.

Kiedy zostawić w spokoju, a kiedy naprawiać?

Co do zasady sprawdzam każdą pojawiającą się 404-kę – to robię zawsze. Dalsze kroki podejmuje jednak tylko w niektórych przypadkach.

Najgorszy możliwy scenariusz występuje wtedy, gdy w serwisie pojawiają się błędy 404 dla adresów, które są zaindeksowane i widoczne w Google (oraz nie miały być usuwane). Wtedy trzeba działać nad przywróceniem podstron i to szybko.

Zignorowane 404 tego typu to strata ruchu, bo użytkownicy klikający w wynik trafiają na błąd. W dłuższej perspektywie taki problem może doprowadzić nawet do wyrzucenia adresu z indeksu i pogorszenia widoczności całego serwisu.

Jeśli roboty Google odwiedzają adresy, które były zaindeksowane i które pojawiały się w wynikach organicznych (czyli według Google były użyteczne) to ich nagłe zniknięcie jest dla nich oczywistym sygnałem, że serwis stracił na wartości.

Kolejny aspekt to częstotliwość wizyt. Gdy URL z błędem 404 jest często crawlowany, to znaczy, że Googlebot ciągle go gdzieś znajduje. Zwykle w formie linka wewnętrznego na stronie, w mapie strony, lub w jakimś serwisie zewnętrznym. Wtedy muszę podjąć kroki.

Jeśli z kolei błędy te pojawiają się z kolei jedno-/kilkurazowo, np. przez błąd użytkownika przy wpisywaniu adresu, to nie mamy czym się przejmować. Wtedy skupiam się na tym, aby pomóc użytkownikowi odnaleźć to, czego szukał – np. linkowaniem na stronie błędu.

No i na koniec, w przypadku gdy 404 wynika z tego, że intencjonalnie usunięta została jakaś podstrona/zmieniony adres i zabrakło przy tym przekierowania, to muszę je uzupełnić. To jest przypadek najprostszy.

Jak znajduje błędy 404

O błędach 404 u naszych klientów informuje mnie zwykle nasz Inteligentny Asystent SEO lub powiadomienie z raportu indeksowania z Google Search Console.

Błędów 404 szukam jednak także w trakcie audytu SEO lub gdy błędy nagle zaczną pojawiać się częściej. Zwykle skanuję wtedy stronę Screaming Frogiem, analizuję raport indeksacji w GSC lub śledzę rzeczywiste ruchy użytkowników w Google Analytics 4.

W bardziej złożonych sytuacjach wchodzę też głębiej w dane, np. sprawdzam statystyki indeksowania w Search Console, czy w skrajnych przypadkach analizuję logi serwera. W 99% nie jest to jednak potrzebne – podstawowe dane z GA i GSC w zupełności wystarczają.

Audyt i Screaming Frog

Screaming Frog w mojej pracy nad serwisem pojawia się zazwyczaj przy początkowym audycie. Gdy staram się przygotować strategię pozycjonowania strony i poznać lepiej jej techniczne aspekty (w tym obecność zepsutych linków).

Sprawdzam wtedy jakie są odpowiedzi serwera na konkretne adresy. Jeśli pojawia się przy tym 404, to wchodzę w dane głębiej, aby znaleźć linki prowadzące do danego URL-a. Dzięki temu jestem w stanie zlokalizować zepsute (błędne) linki i je poprawić.

Po stworzeniu skanu strony przechodzę do sekcji „Response Codes” i do zakładki „Client Error (4xx)”.

Następnie rozwijam listę „Inlinks” – to właśnie tam mogę znaleźć linki prowadzące do adresu zwracającego 404.

Taka analiza zwykle wyklucza ze strony wszystkie zepsute linki wewnętrzne, do których może dojść robot, ale czasem zdarza się, że Googlebot znajdzie coś jeszcze. Żeby to sprawdzić, przechodzę do GSC.

Search Console (GSC)

W przypadku GSC interesuje mnie lista z błędami 404, który znajduje się w raporcie „Strony” w zakładce „Indeksowanie”. Żeby się do niej dostać, po wejściu w „Strony” trzeba kliknąć na przyczynę „Nie znaleziono (404)” w sekcji „Dlaczego strony nie są zindeksowane”.

Raport ten pokazuje nam listę adresów do których dotarł Googlebot, a które zwróciły nasz błąd.

Czy skoro Google podaje nam w swoim narzędziu takie adresy, to znaczy, że jest to już coś poważnego? Zazwyczaj tak nie jest, ale tak jak pisałem na wstępie, nie można lekceważyć tych komunikatów.

Na początek zawsze filtruję dane poprzez pokazanie tylko tych adresów, które znajdują się w przesłanej do Search Console mapie strony. Taka szybka, wstępna analiza może od razu pokazać, jak poważny jest problem.

Jeśli wykryte błędy 404 znajdują się w mapie strony, to coś jest nie tak – bo w pliku sitemap powinniśmy mieć tylko adresy istniejące, te, które chcemy wyświetlać w Google. 404 znaczy więc, że albo mamy błędy w mapie, albo z jakiegoś powodu nasze podstrony już nie istnieją.

Jeśli jednak w mapie ich nie ma, to najpewniej sprawa jest mniej poważna – ale i tak sprawdzam jakie konkretnie adresy zwróciły błąd.

Gdy znam dobrze stronę, którą analizuję, to od razu jestem w stanie powiedzieć czy URL-e znajdujące się na tej liście są wartościowe i czy rzeczywiście mogły zostać np. usunięte.

Szczegóły sprawdzam używając opcji „Sprawdź URL”. Interesuje mnie tutaj najbardziej to kiedy nastąpiło ostatnie skanowanie i czy istnieje strona odsyłająca.

W tym przypadku widać, że roboty musiały trafić na link do błędnej podstrony na jakimś spamowym serwisie – więc raczej nie ma czym się przejmować i czego poprawiać. Tym bardziej że taki adres nigdy nie istniał.

Czasem jednak zdarza się, że znajduje w ten sposób np. zepsute linki wewnętrzne, gdzie stroną odsyłającą jest inna podstrona w tym samym serwisie. Wtedy taki link warto usunąć lub poprawić.

Nie będę wypisywał tutaj wszystkich wariantów, bo może być ich dużo, a procedura postępowania i tak jest mniej więcej taka sama (filtrujemy przez obecność w mapie i analizujemy źródło błędu).

Najważniejsze, co warto zapamiętać, to że: komunikat z GSC o nowych błędach = sprawdzam „Strony” > „Błędy 404”.

Jak znajduję błędy 404 w GA4 (których nie pokaże GSC)

Nie byłbym sobą, gdybym nie wspomniał w moim artykule o Google Analytics 4 :D

Wcześniejsze akapity nawiązywały do błędów 404 wykrywanych czy to przez crawler, czy przez robota Google. Teraz pokaże Ci jak znajduje realne błędy, do których docierają użytkownicy.

W celu wyśledzenia 404-ek w GA4 tworzę sobie własny raport – który od momentu utworzenia będzie zbierał absolutnie wszystkie błędy jakie wystąpią na stronie. Również te jednorazowe, generowane przez użytkowników (które umkną Screaming Frog) i te na stronach zindeksowanych (których nie wykrywa GSC).

Żeby stworzyć sobie taki raport, wchodzę w eksplorację swobodną i w wymiarach dodaję ścieżkę do strony oraz tytuł strony. W danych wybieram wyświetlenia, a kolejno, przechodzę do ustawień karty po prawej.

W ustawieniach tych dodaję to samo: w wierszach wymiary: czyli ścieżka do strony i tytuł strony, a w wartościach dane, czyli wyświetlenia.

Wszystkie ustawienia raportu widać dokładnie na screenshocie niżej.

W ten sposób otrzymuje raport z adresami URL wraz z ich meta title i liczbą wyświetleń.

Pozostaje jeszcze tylko dodać filtr, który pokaże mi tylko podstrony z błędami 404, czyli z meta title takim, jak ten ustawiony na stronie błędu.

W tym celu przechodzę do filtrów. Wybieramy „tytuł strony” > „zawiera” i wklejam poniżej meta title podstrony błędu 404. Na stronie naszej agencji SEO będzie to „404 Strona nie istnieje - Top Online”.

Kolejno zapisuję i już – mam raport, który pokaże mi wszystkie 404-ki, jakie wystąpiły w serwisie.

Do takiej eksploracji warto wracam zwykle raz w miesiącu. Żeby zobaczyć, jak wygląda sytuacja, które podstrony generują najwięcej 404-ek, a jeśli jest potrzeba, to i żeby spróbować znaleźć i naprawić przyczyny ich występowania.

Więcej o tym, jak działa eksploracja swobodna i ogólnie o Analytics, dowiesz się z mojego darmowego kursu Google Analytics 4 – do które serdecznie zapraszam! :)

Jak naprawić błędy 404

Co robię z realnymi błędami 404 na stronie? W przypadku występowania błędu dla zaindeksowanych podstron konieczne jest jak najszybsze ich przywrócenie lub przekierowanie 301 (jeśli np. zostały celowo usunięte lub zmienił się ich URL).

Przekierowania to reguły, które pozwalają serwerowi automatycznie przenosić użytkownika z jednego adresu na drugi. Stosuje się je w SEO często – między innymi właśnie przy usuwaniu podstron.

Wdrażanie ich zwykle przebiega za pomocą systemu CMS strony, czy panelu administracyjnego sklepu, ale można to zrobić także poprzez modyfikację pliku konfiguracyjnego serwera.

Więcej na ich temat dowiesz się z jednej z części naszego kursu SEO, w którym omówione zostało właśnie przekierowanie strony internetowej.

Dla adresów, które były częścią serwisu, ale zostały usunięte staram się także, np. za pomocą Screaming Froga, wyłapać i zaktualizować wszystkie prowadzące do nich linki wewnętrzne.

Na koniec sprawdzam także, czy nie znajdują się one dalej w sitemapie, bo mogłoby być to pretekstem dla robotów Google do ich dalszego odwiedzania.

Jak przygotować stronę z błędem 404?

Na koniec jeszcze parę słów o błędach, które wynikają ze wpisywania przez użytkowników błędnych/nieistniejących adresów.

Użytkownik dociera do 404 i co dalej? W tym miejscu przydałoby się go gdzieś pokierować … a to można zrobić za pomocą strony błędu.

Jak widzisz na załączonym screenie, my postanowiliśmy na tej podstronie wykorzystać jedno z naszych haseł i dodaliśmy parę linków do najważniejszych sekcji naszej strony, które pomogą użytkownikowi się odnaleźć.

Linki na stronie błędu nie wpływają na jakość linkowania wewnętrznego w serwisie, dlatego skupiamy się maksymalnie na użyteczności podstrony.

Na stronie błędu można też zamieścić po prostu wyszukiwarkę wewnętrzną, aby użytkownik sam mógł poszukać tego, czego spodziewał się pod błędnym adresem. Robi tak np. OLX:

Jeśli chodzi o optymalizację takiej podstrony, to przede wszystkim adresowi błędu warto nadać unikalny meta title, dzięki któremu będzie można wyśledzić potem 404-ki w Google Analytics, o czym wspomniałem już wyżej.

Można w nim wpisać, co się tylko chce – ważne tylko, żeby taki sam tag nie występował pod żadnym innym adresem.

Chodzi tylko o unikalność w obrębie naszej strony, dlatego ja w title podstrony błędu zazwyczaj używam czegoś prostego w stylu:

• „404 strony nie znaleziono”
• „Strony nie znaleziono 404”
• „Nie znaleziono (404)”

Samo stworzenie takiej strony błędu to z kolei nic innego jak przygotowanie nowej podstrony z treścią błędu/linkami/wyszukiwarką/czymkolwiek innym. Później wystarczy opublikować ją pod nowym adresem, np. „/404” i ustawić jako stronę błędu.

To ostatnie robię zwykle w ustawieniach CMS/platformy, z której korzysta dany serwis, a jeśli takie opcji nie ma, to sięgam do pliku .htaccess.

O tym, jak to konkretnie zrobić przeczytasz na stronie pomocy oprogramowania, z którego korzystasz lub (w przypadku edycji .htaccess) w kursie SEO Samodzielni: Htaccess - wykorzystanie pliku w SEO.

Podsumowanie w punktach

1. Błędy 404 są zwracane wtedy, gdy adres URL żądany przez klienta (użytkownika lub robota) nie istnieje na serwerze.
2. Najistotniejsze 404-ki, to te, które występują na adresach zindeksowanych i widocznych w Google.
3. Zwykle o błędach 404 dowiesz się z powiadomienia z Search Console, ale możesz też poszukać ich samodzielnie.
4. Screaming Frog pozwoli Ci wykryć przede wszystkim 404 generowane przez zepsute linki na stronie.
5. W Search Console znajdziesz 404 stron, które nie zostały zindeksowane oraz źródła, w których znalazł je Googlebot.
6. A wszystkie występujące 404-ki wykryjesz tylko w GA4, korzystając z eksploracji swobodnej.
7. Stworzenie takiego raportu 404 w Google Analytics jest dość proste, ale wymaga posiadania unikalnego meta title na stronie błędu.
8. Naprawianie błędów 404 to w 95% przywracanie przypadkowo usuniętych lub zepsutych podstron albo wdrażanie przekierowań (gdy usunięcia lub zmiany adresów były zamierzone).
9. Własną podstronę 404 możesz stworzyć tak samo jak każdą nową podstronę – musisz tylko ustawić ją jako stronę błędu w panelu swojego systemu lub w pliku .htaccess.
10. Poza aspektem czysto użytecznym, najważniejsze na takiej stronie błędu jest ustawienie unikalnego meta title – który pozwoli potem stworzyć raport 404 w GA.
11. Warto jednak raz na jakiś czas przeprowadzić audyt strony i regularnie sprawdzać raporty, zarówno w GSC jak i w GA.