Komunikat „Nie udało się pobrać strony, kod statusu: 404” oznacza, że serwer działa, ale żądany adres nie istnieje lub został przeniesiony. Najczęściej winne są błędne linki, usunięte treści lub złe przekierowania. Poniżej wyjaśniam, jak to sprawdzić i naprawić.
Co oznacza błąd 404 i kiedy się pojawia?
Błąd 404 oznacza, że serwer działa, ale nie znalazł żądanej strony pod danym adresem. Najczęściej pojawia się po zmianie struktury adresów lub usunięciu treści, co w ciągu 24–48 godzin bywa nasilone po wdrożeniach. To komunikat warstwy HTTP (protokół przeglądarka–serwer), nie awaria całej witryny. Krótko mówiąc: adres istnieje, treści już nie.
Sygnałem 404 jest kod zwracany przez serwer po każdej próbie pobrania konkretnego URL. Może to dotyczyć pojedynczej podstrony, ale też serii adresów, np. 50–100 linków po migracji. Zdarza się to, gdy zmienia się slug, katalog lub rozszerzenie, a linki wewnętrzne pozostały stare. W praktyce użytkownik widzi komunikat po 1–2 sekundach, a roboty indeksujące odnotowują problem przy najbliższym crawl’u.
Poniżej krótkie zestawienie, kiedy komunikat „Nie udało się pobrać strony, kod statusu: 404” jest typowy, a kiedy trzeba szukać innej przyczyny. Tabela pomaga szybko odczytać, czy kłopot dotyczy adresu, treści, czy konfiguracji.
| Sytuacja | Co się dzieje technicznie | Typowy zakres/tempo | Na co zwrócić uwagę |
|---|---|---|---|
| Usunięta podstrona | Serwer zwraca 404 dla konkretnego URL | Pojedyncze adresy, wykrycie w 1–3 dni | Czy strona ma następcę do przekierowania 301 |
| Zmiana adresów po migracji | Stare linki wskazują nieistniejące ścieżki | Dziesiątki–setki 404 w 24–72 h po wdrożeniu | Mapowanie starych na nowe URL-e |
| Błąd w linku lub literówka | Żądany zasób nigdy nie istniał pod tym adresem | Pojedyncze przypadki, widoczne od razu | Znaki specjalne, wielkość liter w ścieżce |
| Brakujące zasoby statyczne | 404 dla obrazów/CSS/JS, strona ładuje się częściowo | 5–20 żądań na stronę przy złych ścieżkach | Ścieżki względne vs bezwzględne po zmianie domeny |
| Czasowe wycofanie treści | Świadome 404/410 dla wygaszonych materiałów | Okres 7–30 dni do deindeksacji | Czy przewidziano stronę alternatywną |
Jeśli objawy pasują do jednego z opisów, problem dotyczy konkretnego adresu i treści, a nie całego serwera. W dalszych częściach artykułu można sprawdzić, jak odróżnić 404 od błędów serwera czy DNS i jakie kroki podjąć.
W codziennym użyciu 404 oznacza utratę ciągłości między linkiem a zawartością. Przykład: ktoś zapisał adres z „/oferta-2023”, a nowa wersja ma „/oferta”, co generuje 1 błąd przy każdym wejściu. Dla użytkownika to krótkie „donikąd”, dla serwisu sygnał do aktualizacji linków lub przekierowania 301. Dzięki temu kolejne 10–20 wizyt trafia już pod właściwą stronę bez dodatkowych strat.
Jak odróżnić 404 od problemów z serwerem lub DNS?
404 oznacza, że serwer działa i mówi „nie ma takiej strony”, a problemy z serwerem lub DNS zwykle odcinają dostęp jeszcze wcześniej.
Najprostsza wskazówka to różnica w komunikatach i czasie odpowiedzi: 404 przychodzi szybko, często w 0,1–1,5 s, bo serwer znajduje domenę, ale nie plik. Gdy problemem jest DNS (system tłumaczenia nazwy na adres IP), przeglądarka długo „szuka” i po 5–30 s pokaże błąd „DNS_PROBE_FINISHED_NXDOMAIN” lub „Nie można znaleźć serwera”. Podobnie przy awarii serwera pojawiają się kody 5xx, np. 500 lub 503, a czas oczekiwania bywa dłuższy niż 3–10 s. Krótkie okno czasowe i jasny kod 404 to sygnał, że serwer działa, tylko adres nie prowadzi do istniejącej treści.
Pomaga szybki test z trzech źródeł w ciągu 2–3 minut: ta sama strona przez sieć komórkową zamiast Wi‑Fi, inne urządzenie oraz narzędzie ping lub traceroute. Brak odpowiedzi ping przez ponad 4–5 prób i przekroczenie czasu w traceroute zwykle wskazują na problem sieciowy lub DNS. Jeśli natomiast ping wraca poniżej 100 ms, a przeglądarka nadal pokazuje 404, przyczyna leży w adresie lub w samej stronie, a nie w łączności. To oszczędza czas przed sprawdzaniem literówek czy przeniesień w CMS.
Gdy potrzebny jest szybki przegląd sygnałów, można użyć poniższej listy i przejść od najkrótszych testów do dłuższych. Każdy punkt powinien zająć 30–60 sekund, całość mniej niż 5 minut.
- 404 w mniej niż 2 s oraz działająca strona główna tej samej domeny → problem z konkretnym adresem, nie z serwerem.
- Błąd „Serwer nie odpowiada” po 10+ s lub kody 5xx (500/502/503) → problem po stronie serwera.
- „DNS_PROBE_FINISHED_NXDOMAIN” lub „Brak adresu IP” po 5–30 s → problem DNS, nie 404.
- Ten sam adres działa w innej sieci w 1–3 s → lokalny DNS lub cache dostawcy internetu.
- Strona w cache Google z wczorajszą datą, a dziś 404 → treść usunięta lub przeniesiona po stronie witryny.
Po takim rozróżnieniu można przejść do sprawdzenia poprawności URL i ewentualnych przeniesień. Jeśli źródło problemu to DNS lub serwer, sens ma kontakt z administratorem i monitoringiem, a nie zmiany w linkach.
Czy adres URL jest poprawny i nie zawiera literówek?
Najpierw opłaca się sprawdzić, czy w adresie URL nie ma drobnej literówki lub zbędnego znaku. Już pojedyncza literka albo brak ukośnika potrafią wywołać 404 w mniej niż 1 sekundę. Często różnica między „/blog” a „/blogs” decyduje o wszystkim. Jeden błąd w 1 znaku unieważnia cały adres.
Do szybkiej weryfikacji przydają się małe, konkretne kroki wykonywane od ręki. Pomaga porównać adres ze źródłem linku i sprawdzić wielkość liter, bo na wielu serwerach „/Kontakt” i „/kontakt” to dwa różne zasoby. W 2–3 minuty można też podmienić znaki diakrytyczne, spacje i polskie litery na ich prostsze odpowiedniki, zwłaszcza w starych linkach. Prosty test z usunięciem wszystkiego po znaku „?” pokazuje, czy winne są parametry.
- Usuń lub dodaj ukośnik na końcu, np. „/oferta” vs „/oferta/”, i sprawdź w 10 sekund.
- Podmień „http” na „https” i odwrotnie; zmiana protokołu rozwiązuje problem w ok. 1 na 5 przypadków.
- Sprawdź myślniki i podkreślniki: „strona-glowna” nie równa się „strona_glowna”.
- Ogranicz adres do domeny, a potem dokładaj foldery krok po kroku, co 1–2 kliknięcia.
- Usuń parametry po „?” lub „#”, a potem przywracaj je po 1 elemencie.
Jeśli adres wciąż zwraca 404, przydaje się szybkie porównanie z mapą witryny „/sitemap.xml”, co zajmuje 2–4 minuty. Przy dłuższych URL‑ach lepiej skopiować adres znak w znak, niż przepisywać go ręcznie. W codziennej pracy pomaga też stały format linków w firmie, na przykład tylko małe litery i myślniki, bo 1 spójna konwencja zmniejsza liczbę literówek o kilkadziesiąt procent. Gdy wszystkie te próby zawodzą, następne kroki opisują kolejne sekcje artykułu.
Jak sprawdzić, czy strona istnieje w CMS lub została przeniesiona?
Najpierw należy sprawdzić w CMS, czy podstrona istnieje lub ma nowy adres. W praktyce zajmuje to 3–10 minut i pozwala uniknąć niepotrzebnych zmian. W panelu wpisuje się fragment tytułu albo starego URL i filtruje po statusie. To proste.
W WordPressie można zajrzeć do sekcji Strony lub Wpisy i użyć wyszukiwarki, wpisując 1–2 słowa kluczowe z tytułu. W Joomla i Drupal podobną funkcję ma lista artykułów z filtrem po stanie publikacji, gdzie status „nieopublikowany” lub „kosz” bywa przyczyną 404. Czasem strona jest szkicem od 7 dni i nie ma publicznego adresu (status draft oznacza wersję roboczą). Jeśli treści nie ma, test krótkiej scenki pomaga: „Administrator mówi, że usunął wpis 2 tygodnie temu”, co sugeruje przeniesienie lub kasację.
Następnie przydatne bywa sprawdzenie slugów i historii zmian, bo CMSy zapisują wersje przez 30–90 dni. W WordPressie log zmian lub wtyczka audytowa pokaże, czy 48 godzin temu zmieniono adres z /oferta na /uslugi. W CMSach „przekierowania” bywają w osobnym module, gdzie widać liczbę trafień, na przykład 12 wizyt w ostatnich 24 godzinach, co potwierdza migrację. Brak takiego wpisu zwykle oznacza, że przeniesienia nie skonfigurowano.
Gdy panel nie daje jasnej odpowiedzi, można użyć zewnętrznych narzędzi w trybie tylko do odczytu. Wyszukiwarka site:domena.pl + fraza z tytułu pokaże, czy strona żyje pod innym URL i kiedy była zaindeksowana, na przykład 5 dni temu. Kopia w Web Archive (archiwum.org) lub pamięci podręcznej wyszukiwarki pozwala porównać stare i nowe ścieżki, nawet jeśli minęło 180 dni. To szybki sposób na ustalenie, czy mamy usunięcie, czy faktyczne przeniesienie.
Jak naprawić 404: przekierowanie 301, przywrócenie strony czy aktualizacja linków?
Najpierw trzeba zdecydować, czy adres ma zostać przekierowany, przywrócony, czy zaktualizowany. Wybór zależy od celu strony i skutków dla użytkowników oraz SEO w ciągu 24–72 godzin.
Jeśli treść została trwale przeniesiona, najlepiej ustawić przekierowanie 301, bo przenosi do 90–99% mocy linków (mocy SEO przekazywanej między stronami). Taki ruch chroni ruch zewnętrzny i zakładki użytkowników, a roboty wyszukiwarki zwykle aktualizują indeks w ciągu 2–4 tygodni. W małych serwisach wystarczy 1 reguła w pliku konfiguracyjnym, w większych 10–100 reguł dobrze trzymać w osobnym pliku. Krótka scenka: ktoś wklepuje stary URL sprzed 6 miesięcy i od razu ląduje na nowej podstronie — nie traci czasu.
Gdy strona miała wartość i zniknęła przypadkiem, opłaca się przywrócić ją z kopii zapasowej sprzed 1–7 dni lub z cache do czasu pełnego odtworzenia. Taka decyzja zmniejsza liczbę błędów 404 w logach nawet o 80% w pierwszym tygodniu. W CMS wystarczy czasem aktywować wersję w szkicu i poprawić status publikacji, żeby po 5–10 minutach znów była dostępna. Jeśli treść jest nieaktualna, lepiej przygotować zwięzłą wersję zastępczą na 1–2 ekrany i dopiero potem rozbudować.
Poniżej praktyczne kryteria wyboru podejścia w typowych sytuacjach i z realnymi progami decyzji.
- Przekierowanie 301: gdy istnieje nowy odpowiednik treści w 1:1 lub 1: wielu, a stary URL ma min. 10 wejść miesięcznie albo 5+ linków zewnętrznych.
- Przywrócenie strony: gdy treść spełnia aktualny cel użytkownika i była aktualizowana w ciągu ostatnich 90 dni, a 404 pojawiło się po zmianie w CMS lub migracji.
- Aktualizacja linków: gdy 404 dotyczy linków wewnętrznych i nie ma sensownego odpowiednika treści; poprawa 20–50 odnośników bywa szybsza niż setki przekierowań.
- Strona celowo usunięta: ustaw 410 (treść trwale usunięta) i przekieruj tylko kategorie nadrzędne, jeśli mają min. 1% całego ruchu.
Po wdrożeniu trzeba przetestować 3–5 przykładowych adresów i odczekać 24 godziny na odświeżenie pamięci podręcznej. W narzędziu analitycznym można monitorować spadek 404 o 30–70% w 7 dni, a w Search Console sprawdzić raport Pokrycia po 2–3 tygodniach. Jeśli 404 nadal rosną o więcej niż 5% tygodniowo, plan działań warto rozszerzyć o mapę przekierowań na poziomie całych katalogów.