Błąd 404 Not Found oznacza, że serwer działa i odebrał żądanie, ale pod wskazanym adresem nie ma żadnej strony ani pliku. Sam w sobie nie jest problemem: każda strona ma adresy, które nie istnieją, i poprawną odpowiedzią dla nich jest właśnie 404. Kłopot zaczyna się, gdy 404 zwracają adresy, do których prowadzą linki, ruch z Google albo kampanie reklamowe. W tym wpisie pokazuję, jak znajduję błędy 404, które faktycznie warto naprawić, i jak decyduję, czy ustawić przekierowanie, przywrócić stronę, czy zostawić błąd.
Skąd bierze się błąd 404
| Przyczyna | Typowa sytuacja |
|---|---|
| usunięta strona bez przekierowania | wycofany produkt, usunięty wpis, wygaszona kategoria |
| zmiana adresów | migracja, nowa struktura kategorii, zmiana sluga wpisu, przejście z adresów z .html na adresy bez rozszerzenia |
| błędne linki | literówki w linkach wewnętrznych, linki względne, które po zmianie struktury prowadzą w złe miejsce |
| konfiguracja serwera | po przeniesieniu WordPressa na Nginx brakuje reguły przekazującej adresy do index.php, więc działa tylko strona główna |
| nieaktualna mapa witryny | w pliku sitemap zostały adresy usuniętych stron |
Jak znajduję i naprawiam błędy 404
1. Zbieram błędy 404 z kilku źródeł
Żadne pojedyncze narzędzie nie pokazuje wszystkich błędów 404, więc łączę cztery źródła:
- Search Console, raport indeksowania stron, pozycja „Nie znaleziono (404)”, czyli adresy, które zna Google,
- crawl serwisu, np. w Screaming Frogu, który pokazuje błędne linki wewnętrzne razem ze stroną, na której się znajdują,
- logi serwera, które pokazują błędy 404 zgłaszane przez prawdziwych użytkowników i roboty, wraz z adresem strony odsyłającej,
- narzędzia do analizy linków, np. Ahrefs, które wskazują nieistniejące adresy z linkami z innych domen.
Z logów najszybciej wyciągam listę najczęściej odwiedzanych adresów z błędem:
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 30Przy tej liście od razu oddzielam ruch ludzi od botów skanujących, tak jak przy każdej analizie logów serwera.
2. Decyduję, co zrobić z każdym adresem
| Sytuacja | Co robię |
|---|---|
| strona przeniesiona pod nowy adres | przekierowanie 301 na nowy adres |
| strona usunięta, ale istnieje bliski odpowiednik | przekierowanie 301 na odpowiednik, np. wycofany produkt na nowszy model lub kategorię |
| strona usunięta bez odpowiednika, z linkami zewnętrznymi | przekierowanie na najbliższą tematycznie stronę albo przywrócenie treści |
| strona usunięta celowo, bez linków i ruchu | zostawiam 404 albo zwracam 410, które mówi, że usunięcie jest trwałe |
| błędny link wewnętrzny | poprawiam link w treści lub szablonie, a nie dokładam przekierowania |
| przypadkowe adresy, np. skanowanie przez boty | nic nie robię, poprawne 404 to tu właściwa odpowiedź |
Nigdy nie przekierowuję wszystkich błędów 404 na stronę główną. Google traktuje takie przekierowania jak tzw. soft 404, czyli stronę, która udaje istniejącą, a użytkownik zamiast odpowiedzi dostaje stronę bez związku z tym, czego szukał. Przekierowania wdrażam regułami serwera w pliku .htaccess lub konfiguracji Nginx i sprawdzam, czy nie tworzą łańcuchów ani pętli przekierowań.
3. Sprawdzam, czy strona błędu zwraca właściwy kod
Własna strona 404 z wyszukiwarką, linkami do najważniejszych kategorii i krótkim komunikatem zatrzymuje użytkownika w serwisie. Musi jednak zwracać kod 404, a nie 200. Sprawdzam to na wymyślonym adresie:
curl -I https://example.pl/adres-ktory-nie-istnieje-123Jeśli odpowiedź to 200, każdy nieistniejący adres jest dla Google osobną stroną z tą samą treścią, co prowadzi do błędów soft 404 i marnowania zasobów robota.
4. Sprawdzam konfigurację, gdy 404 dotyczy wszystkich podstron
Gdy działa tylko strona główna, a każda podstrona zwraca 404, problemem nie są treści, tylko przepisywanie adresów. W WordPressie na Apache
zwykle wystarcza ponowne zapisanie ustawień bezpośrednich odnośników, które odtwarza reguły w .htaccess. Na Nginx dodaję
regułę przekazującą nieistniejące pliki do aplikacji:
location / {
try_files $uri $uri/ /index.php?$args;
}Błąd 404 a SEO
Pojedyncze błędy 404 nie obniżają pozycji całej strony. Szkodzą wtedy, gdy dotyczą adresów, które miały ruch lub linki, bo ta wartość przepada razem ze stroną. Duża liczba błędów w linkach wewnętrznych i mapie witryny spowalnia też indeksowanie, dlatego sprawdzam, czy mapa strony XML zawiera wyłącznie istniejące adresy, a na dużych serwisach traktuję to jako element, który obejmuje optymalizacja crawl budgetu. Najwięcej błędów 404 powstaje przy zmianie struktury serwisu, więc każda migracja strony zaczyna się u mnie od pełnej mapy przekierowań.
Pozostałe błędy HTTP
Każdy kod błędu wskazuje na inną warstwę, więc diagnozę zaczynam od innego miejsca: