Kod 404 Not Found

TL;DR — Błąd 404 oznacza “tej strony tutaj nie ma”. Pojawia się, gdy URL został usunięty, wpisano go z literówką albo nigdy nie istniał. Zaskakująca część: błędy 404 są normalne, a pojedynczy brakujący URL nie jest karą rankingową dla całej witryny. Nie musisz panikować, gdy widzisz je w raporcie. Upewnij się tylko, że URL naprawdę zwraca 404 (a nie fałszywą stronę “sukcesu”), i przekieruj go tylko wtedy, gdy strona rzeczywiście została przeniesiona.

Krótka uwaga dotycząca zakresu: ta strona jest napisana dla osoby, która jest właścicielem witryny — podejmuje decyzję, co zrobić z błędami 404 pojawiającymi się w Search Console lub podczas crawlowania w Ahrefs. Jeśli jesteś odwiedzającym, który kliknął martwy link, nie masz tu nic do naprawienia. A jeśli serwer jest źle skonfigurowany i w ogóle nie zwraca strony 404, jest to kwestia hostingu/serwera, a nie SEO.

Czym jest błąd 404

Gdy odwiedzasz stronę internetową, przeglądarka prosi serwer o URL. Jeśli serwer go znajdzie, zwraca 200 OK i widzisz stronę. Jeśli serwer nie może znaleźć tego URL-a, zwraca 404 Not Found — kod oznaczający „nie ma tu tego, o co prosisz”.

Znasz te sytuacje. Klikasz stary link, wpisujesz błędny URL albo odwiedzasz stronę, która została od tego czasu usunięta, i trafiasz na ekran „Nie znaleziono strony”. To właśnie 404.

Najczęstsze powody pojawienia się błędu 404:

• Strona została usunięta (stary wpis na blogu, wycofany produkt).
• Ktoś podlinkował niewłaściwy URL albo link zawiera literówkę.
• Zmieniono URL, a starego adresu nie przekierowano.
• Ktoś błędnie wpisał adres w przeglądarce.

Czy takie błędy szkodzą SEO?

To główna obawa, więc odpowiem wprost: nie, nie same w sobie. Błędy 404 nie są karą, a własne wytyczne Google mówią, że fakt, iż niektóre URL-e w witrynie zwracają 404, nie obniża wyników innych, działających stron. Jeden z pracowników Google ujął to jasno — “404 errors are not to be afraid of and you don’t need to scramble to fix them, at least not most of the time.” (tłumaczenie) „Błędów 404 nie trzeba się bać ani gorączkowo ich naprawiać, przynajmniej przez większość czasu.” Uszkodzone linki są normalną częścią sieci i Google się ich spodziewa. (Strona zwracająca 404, która wcześniej przynosiła ruch lub linki zwrotne, nadal wymaga decyzji — omówiono to niżej — ale sam status 404 nie jest problemem.)

Co dzieje się zamiast tego, jest spokojne i pozbawione dramaturgii: z czasem Google przestaje pokazywać brakującą stronę w wynikach i sprawdza ją coraz rzadziej. Nic złego nie przenosi się na resztę witryny.

Kiedy naprawdę coś zrobić

Nie musisz naprawiać każdego błędu 404. Czasami jednak warto zareagować:

• Strona została przeniesiona. Jeśli treść jest teraz pod nowym URL-em, skonfiguruj 301 redirect ze starego URL-a na nowy, aby użytkownicy (i sygnały linków) trafili we właściwe miejsce.
• Strona po prostu zniknęła. Jeśli nie ma zamiennika, może pozostać stroną 404. To prawidłowy rezultat.
• Do dobrej strony prowadzi uszkodzony link. Napraw link, a nie błąd 404.

Jedna rzecz, której należy unikać

Nie udawaj. Niektóre witryny, próbując być “bezpieczne”, przekierowują każdy brakujący URL na stronę główną albo wyświetlają komunikat „nie znaleziono”, potajemnie zwracając kod powodzenia 200 OK. Oba rozwiązania powodują problemy (drugie ma nazwę — soft 404 — omówioną na karcie Advanced). Jeśli strona zniknęła, niech uczciwie zwraca 404. To nie pomyłka do naprawienia, lecz właściwa odpowiedź.

Chcesz poznać pełny obraz — sposób, w jaki Google usuwa te adresy z indeksu, różnicę między twardymi i miękkimi odpowiedziami, witryny JavaScript oraz audyt tych błędów? Przejdź do karty Advanced.

TL;DR — 404 to kod błędu klienta 4xx dla URL-a, którego serwer nie może znaleźć — specyfikacja (RFC 9110) definiuje go jako “no current representation, or unwillingness to disclose one,” (tłumaczenie) „brak aktualnej reprezentacji albo niechęć do ujawnienia jej” i sam kod nie mówi, czy brak jest tymczasowy, czy trwały. Nie jest to użyteczna treść do indeksowania, a fakt, że niektóre URL-e zwracają 404, nie obniża wyników innych, działających URL-i w witrynie. Usunięcie z wyników może być stopniowe, a nie natychmiastowe: Google usuwa wcześniej zindeksowany URL zwracający 404 i ponownie go crawluje coraz rzadziej; źródłowe sformułowanie mówi, że Googlebot “will probably” (tłumaczenie) „prawdopodobnie” ponawia próby przez pewien czas, a nie że robi to wiecznie. Rzeczywista różnica dotyczy twardego 404 i miękkiego 404: zwracanie 200 (albo masowe przekierowanie na stronę główną) dla nieistniejącej treści marnuje zasoby crawlowania i wprowadza analitykę w błąd. Przekierowuj 301 tylko wtedy, gdy strona rzeczywiście została przeniesiona do istotnego celu; w przeciwnym razie pozwól jej czysto zwracać 404 (albo 410). Niestandardowe strony 404 pomagają w UX i utrzymaniu użytkownika, a nie w indeksowaniu.

Czym naprawdę jest 404

404 Not Found to kod błędu klienta HTTP (4xx), który serwer zwraca, gdy nie może znaleźć żądanego URL-a. Klasa 4xx oznacza, że problem dotyczy żądania — zasób nie istnieje pod tym adresem — w przeciwieństwie do błędów serwera 5xx, gdy zawodzi sam serwer.

Sama specyfikacja HTTP (RFC 9110) definiuje 404 węziej, niż sugeruje codzienna rozmowa o SEO: źródło nie ma aktualnej reprezentacji zasobu docelowego albo nie chce ujawnić, że taka reprezentacja istnieje. Sam kod statusu nie mówi, czy brak jest tymczasowy, czy trwały — tę decyzję podejmujesz, wybierając przekierowanie, 410 albo pozostawienie 404. Warto znać jeszcze jeden praktyczny szczegół: odpowiedź 404 jest domyślnie heurystycznie buforowana, więc przeglądarka lub pośredni cache może nadal serwować nieaktualny 404 dla URL-a, który znów zaczął działać, chyba że serwer wyśle nagłówki cache-control mówiące inaczej.

Pojawiają się wskutek zwykłych zmian w witrynie: usuniętych stron, wycofanych produktów, zakończonych kampanii, uszkodzonych lub błędnie wpisanych linków wewnętrznych i zewnętrznych oraz zmian URL-i, których nie przekierowano. Nic z tego nie jest niezwykłe ani samo w sobie problemem do rozwiązania.

Fakt, że URL zwraca błąd, nie szkodzi innym stronom

Zacznijmy od tego, bo większość niepokoju wokół 404-ów jest nieuzasadniona. Dokumentacja Google mówi wprost: “Google doesn’t use the content from URLs that return 4xx status codes.” (tłumaczenie) „Google nie korzysta z treści URL-i, które zwracają kody statusu 4xx.” Na stronie 404 nie ma niczego, co Google mógłby ocenić. Wytyczna Google precyzyjnie określa też zakres twierdzenia: fakt, że niektóre URL-e witryny zwracają 404, nie wpływa na skuteczność innych, działających URL-i tej witryny. To granica wynikająca ze źródła — nie jest to ogólna obietnica, że każda sytuacja związana z 404 jest nieszkodliwa. Strona, której Google nie może znaleźć, choć chcesz ją indeksować, dobra strona, która straciła linki przychodzące, albo zepsuta ścieżka użytkownika to odrębne problemy, których sam status 404 ani nie naprawia, ani nie powoduje.

Ludzie z Google od lat mówią to samo prostszymi słowami. Gary Illyes: “404s are not to be afraid of and you don’t need to scramble to fix them, at least not most of the time.” (tłumaczenie) „Błędów 404 nie trzeba się bać ani gorączkowo ich naprawiać, przynajmniej przez większość czasu.” John Mueller wielokrotnie określał 404-y jako “fine & expected.” (tłumaczenie) „w porządku i oczekiwane” Nawet witryny z ogromną liczbą URL-i 404/410 nie otrzymują za nie kary dla całej domeny. Konkretna obawa, że 404-y są sygnałem rankingowym lub jakościowym, jest mitem — choć strona zwracająca 404, która wcześniej przynosiła ruch lub linki, nadal wymaga decyzji opisanej niżej.

Jak Google usuwa URL zwracający 404 z indeksu

Usuwanie z indeksu jest rzeczywiste, ale stopniowe i pozbawione dramaturgii. Dokumentacja Google opisuje mechanizm: “the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed. The crawling frequency gradually decreases.” (tłumaczenie) „potok indeksowania usuwa URL z indeksu, jeśli był wcześniej zindeksowany. Nowo napotkane strony 404 nie są przetwarzane. Częstotliwość crawlowania stopniowo maleje.”

Dwie konsekwencje, które warto zapamiętać:

• Wcześniej zindeksowany URL, który zaczyna zwracać 404, wypada z indeksu, a URL po raz pierwszy odkryty jako 404 po prostu nie jest przetwarzany.
• Googlebot nadal ponawia próby pobrania URL-a, tylko coraz rzadziej. Jak ujmuje to pomoc Search Console: “Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often.” (tłumaczenie) „Googlebot prawdopodobnie będzie próbował pobierać ten URL przez pewien czas; nie ma sposobu, by kazać mu trwale o nim zapomnieć, choć będzie go crawlowć coraz rzadziej.” Zwróć uwagę na ograniczone sformułowanie — “probably” i „for some period of time” — Google nie obiecuje, że będzie to trwało wiecznie, tylko że nie ma przycisku wymuszającego wcześniejsze zakończenie. Dlatego znany 404 może przez jakiś czas pojawiać się w raportach — to oczekiwane, a nie oznaka awarii.

Czy można to przyspieszyć? Niespecjalnie. Narzędzie Removals w Search Console tymczasowo ukrywa URL (na około sześć miesięcy), co jest przydatne w pilnych przypadkach, ale nie jest trwałym usunięciem z indeksu. Przy rzeczywistym usunięciu zwróć właściwy kod statusu i pozwól, aby proces stopniowo się zakończył.

404 a 410 Gone

Zarówno 404 (Not Found), jak i 410 (Gone) usuwają stronę z indeksu, a praktyczna różnica SEO jest znikoma. 410 jest nieco silniejszym i szybszym sygnałem “this is intentionally gone” (tłumaczenie) „ta strona została celowo usunięta” — ale, jak mówił Mueller, różnica w przetwarzaniu jest tak mała, że rzadko uzasadnia wybór jednego kodu zamiast drugiego ze względów SEO. Użyj 410, jeśli CMS ułatwia jego ustawienie i chcesz zasygnalizować trwałe usunięcie; w przeciwnym razie zwykły 404 jest całkowicie właściwy. (W innym miejscu tego klastra znajduje się osobne porównanie tych dwóch kodów.)

Twardy 404 a miękki 404 — różnica, która ma znaczenie

Właśnie tutaj występują rzeczywiste problemy SEO, a nie w samym istnieniu takich odpowiedzi.

• Twardy 404 — serwer rzeczywiście zwraca kod statusu 404 dla brakującej treści. To prawidłowe działanie. Crawlery odczytują kod, rozumieją, że strona zniknęła, i obsługują ją poprawnie.
• Miękki 404 — serwer zwraca kod powodzenia (zwykle 200 OK) dla strony, której treść w rzeczywistości jest błędem: pustej strony, komunikatu “not found” (tłumaczenie) „nie znaleziono” albo przekierowania na stronę główną. Google wykrywa to algorytmicznie. Jego dokumentacja mówi: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tłumaczenie) „Jeśli treść sugeruje błąd dla wyszukiwarki Google, pustą stronę lub komunikat o błędzie, Search Console pokaże błąd soft 404.”

Powód, dla którego miękkie 404 są gorsze od prawdziwych, dotyczy efektywności crawlowania. Crawler nie może wywnioskować z 200, że treść zniknęła, więc nadal pobiera te URL-e. Illyes opisał to dokładnie: crawlery “use the status codes to interpret whether a fetch was successful, even if the contents of the page is basically just an error message. They might happily go back to the same page again and again wasting your resources, and if there are many such pages, exponentially more resources.” (tłumaczenie) „używają kodów statusu, aby ocenić, czy pobranie się udało, nawet jeśli zawartością strony jest właściwie tylko komunikat o błędzie. Mogą chętnie wracać do tej samej strony raz po raz, marnując zasoby, a przy wielu takich stronach zużywać wykładniczo więcej zasobów.” Wytyczna Google jest jednoznaczna: “We recommend returning a 404 response code for truly ‘not found’ pages.” (tłumaczenie) „Zalecamy zwracanie kodu odpowiedzi 404 dla stron rzeczywiście „nie znalezionych”.”

John Mueller dobrze ujmuje całość na swojej stronie: “Using soft-404s instead of real 404s is a bad practice, and it makes things harder for our algorithms,” (tłumaczenie) „Używanie miękkich 404 zamiast prawdziwych 404 to zła praktyka i utrudnia pracę naszym algorytmom”, a także “returning 404 — and having the URLs listed in the crawl errors in Webmaster Tools — is not a problem.” (tłumaczenie) „Zwracanie kodu 404 i umieszczanie URL-i na liście błędów crawlowania w Webmaster Tools nie jest problemem.” Innymi słowy: uczciwy 404 to dobry rezultat, a fałszywy kod powodzenia jest błędem.

Skąd biorą się przypadkowe miękkie odpowiedzi

• Masowe przekierowanie każdego 404 na stronę główną. Strona główna zwraca 200, więc z perspektywy wyszukiwarki “brakujący” URL zaczyna pomyślnie prowadzić do niezwiązanej treści — to wzorzec miękkiego 404 (niżej wyjaśniamy, dlaczego jest zły).
• Stany „nie znaleziono” w JavaScript/SPA. Routery po stronie klienta nie mogą natywnie rzucić serwerowego 404. Aplikacja jednostronicowa, która renderuje komponent „Nie znaleziono strony”, podczas gdy serwer nadal zwraca 200, generuje miękki 404 — i psuje też analitykę, bo kod statusu przestaje odpowiadać rzeczywistości, więc GA4, GSC i crawlery rejestrują „udane” wejście na martwą stronę. Rozwiązania: kieruj te URL-e po stronie serwera do prawdziwej odpowiedzi 404 albo (słabiej) renderuj stan braku strony z noindex i zaakceptuj kompromisy w śledzeniu.
• Błędna konfiguracja CMS-a lub szablonu, przez którą usunięty element trafia do ogólnego szablonu serwowanego z kodem 200.

Kiedy naprawić 404 (a kiedy go zostawić)

Drzewo decyzji jest krótkie:

• Pozostaw 404 (albo 410), jeśli strona nie ma rzeczywistej wartości, ruchu ani linków zwrotnych. To domyślne i prawidłowe działanie — nie trzeba nic robić.
• Przekieruj 301 tylko wtedy, gdy strona rzeczywiście została przeniesiona albo ma wartościowe linki zwrotne/ruch, który chcesz zachować. Istotne przekierowanie odzyskuje sygnały linków; pomoc Search Console potwierdza: “If your page has moved, use a 301 redirect to the new location.” (tłumaczenie) „Jeśli Twoja strona została przeniesiona, użyj przekierowania 301 do nowej lokalizacji.” W moim procesie w Ahrefs używam raportu Site Explorer “Best by links” (tłumaczenie) „Najlepsze według linków”, filtruję URL-e odpowiadające 404, ustalam priorytet według domen odsyłających i przekierowuję wartościowe adresy do najbliższej właściwej działającej strony.
• Nie przekierowuj masowo na stronę główną. Martin Splitt mówi wprost: “If it moved somewhere else, use a redirect. If it’s gone, don’t redirect me to the homepage.” (tłumaczenie) „Jeśli została przeniesiona gdzie indziej, użyj przekierowania. Jeśli zniknęła, nie przekierowuj mnie na stronę główną.” Tworzy to sygnał podobny do miękkiego 404 i, jego słowami, “it annoys me as a user.” (tłumaczenie) „denerwuje mnie jako użytkownika”. 404, jak zauważa, to “a very clear signal this link is wrong and broken or this URL no longer exists.” (tłumaczenie) „bardzo wyraźny sygnał, że ten link jest niewłaściwy i uszkodzony albo ten URL już nie istnieje.” Przekierowuj wyłącznie do konkretnego, rzeczywiście istotnego celu.

W skróconej macierzy cała decyzja wygląda tak:

Niestandardowe strony 404: narzędzie UX, nie indeksowania

Dobra niestandardowa strona 404 nie zmienia sposobu, w jaki Google indeksuje URL — decyduje o tym kod statusu. Zmienia za to los człowieka, który trafił na martwy link. Pomocna strona 404 zatrzymuje go w witrynie zamiast skłaniać do wyjścia, chroniąc konwersje i zaangażowanie. Są więc dwa odrębne zadania:

1. Poprawność kodu statusu (strona SEO/crawlerów): strona nadal musi zwracać prawdziwy kod 404. Pięknie zaprojektowana niestandardowa strona 404, która zwraca 200, jest miękkim 404 — rozwiązujesz problem UX i tworzysz problem z crawlowaniem.
2. Pomocność strony (strona UX): jasny komunikat, że strona zniknęła, główna nawigacja i pole wyszukiwania oraz linki do popularnych lub powiązanych treści. Mueller radzi: “Think about ways that you can make your 404 pages useful to users, so that they recognize that the page no longer exists, and so that they can find something else that’s appropriate.” (tłumaczenie) „Zastanów się, jak sprawić, by strony 404 były użyteczne dla użytkowników, tak aby rozumieli, że strona już nie istnieje, i mogli znaleźć coś odpowiedniego.”

Jak znajdować i audytować takie odpowiedzi

• Google Search Console — raport indeksowania stron. Pokazuje zarówno status “Not found (404)”, jak i „Soft 404”, wraz z przykładowymi URL-ami.
• Ahrefs Site Audit / Site Explorer. Site Audit wykrywa 404-y i uszkodzone linki wewnętrzne; Site Explorer („Best by links”) pomaga znaleźć URL-e zwracające 404, które nadal mają linki zwrotne, aby ustalać priorytet przekierowań według domen odsyłających.
• Ahrefs Web Analytics. W przypadku danych o ruchu odfiltruj strony Possible 404 do kanału AI Search i posortuj je według sesji. W ten sposób znajdziesz kandydackie URL-e otrzymujące kliknięcia z odsyłaczy AI w wybranym oknie; nie dowodzi to, że odpowiedź jest 404 ani że URL został zhalucynowany. Kroki walidacji opisuję w artykule Monitorowanie halucynacji AI.
• Screaming Frog i analiza logów serwera zapewniają pełny widok na poziomie crawlowania oraz rzeczywistego ruchu: pokazują, które 404-y faktycznie odwiedzają boty i użytkownicy.

Bing w skrócie

Publiczne wypowiedzi Binga są tu znacznie skromniejsze niż materiały Google, więc nie zakładaj pełnej zgodności i traktuj poniższe szczegóły jako słabiej udokumentowane niż sekcję Google powyżej. Bing Webmaster Tools oferuje narzędzie Content Removal do powiadamiania Binga o URL-u, który ma być uznany za usunięty, oraz raport Crawl Information pokazujący 404-y i błędy serwera — te narzędzia są udokumentowane. W aktualnych źródłach pierwotnych nie zweryfikowano natomiast niezależnie konkretnego twierdzenia, że Bing używa klasyfikatora rozróżniającego „temporarily down” (tłumaczenie) „tymczasowo niedostępny” od “genuinely deleted” (tłumaczenie) „rzeczywiście usunięty”, ani że użycie Content Removal w istotny sposób przyspiesza usunięcie z indeksu w porównaniu z samym zwracaniem prawidłowego 404 i oczekiwaniem. Traktuj Binga jako źródło drugorzędne wobec dobrze udokumentowanego zachowania Google powyżej i nie powtarzaj twierdzeń o klasyfikatorze ani szybkości jako ustalonych faktów.

Aby zobaczyć szerszy obraz kodów statusu, przeczytaj moje teksty Kody statusu HTTP i ich wpływ na SEO oraz 11 rodzajów przekierowań i ich wpływ na SEO.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 404 Not Found to kod błędu klienta 4xx dla URL-a, którego serwer nie może znaleźć (usunięte strony, uszkodzone linki, literówki, zmiany URL-i). RFC 9110 definiuje go jako “no current representation, or unwillingness to disclose one” (tłumaczenie) „brak aktualnej reprezentacji albo niechęć do ujawnienia jej” — sam kod nie mówi, czy brak jest tymczasowy, czy trwały, a odpowiedź jest domyślnie heurystycznie buforowana.
• Nie jest sygnałem szkodzącym innym stronom. Google “doesn’t use the content from URLs that return 4xx status codes,” (tłumaczenie) „nie korzysta z treści URL-i, które zwracają kody statusu 4xx”, a fakt, że niektóre URL-e zwracają 404, nie wpływa na skuteczność innych, działających URL-i witryny. Obawa, że “404s hurt rankings” (tłumaczenie) „błędy 404 obniżają rankingi”, jest mitem; Illyes i Mueller wielokrotnie mówili, że 404-y są w porządku i oczekiwane — choć strona zwracająca 404, która wcześniej przynosiła ruch lub linki, nadal wymaga decyzji.
• Usunięcie z indeksu jest stopniowe, a nie natychmiastowe. Google usuwa wcześniej zindeksowany URL 404 i ponownie go crawluje “less and less often.” (tłumaczenie) „coraz rzadziej”. Sformułowanie źródłowe jest ograniczone — Googlebot “probably” (tłumaczenie) „prawdopodobnie” ponawia próby “for some period of time,” (tłumaczenie) „przez pewien czas”, a nie wiecznie. Narzędzie Removals tylko tymczasowo ukrywa URL (około sześciu miesięcy).
• 404 a 410: oba kody usuwają stronę z indeksu; 410 jest nieco szybszy/silniejszy, ale różnica SEO jest znikoma (Mueller).
• Prawdziwy problem to twardy i miękki 404. Miękki 404 zwraca kod powodzenia (200) dla nieistniejącej treści — marnuje zasoby crawlowania, bo boty nie rozpoznają, że strona zniknęła. Google zaleca zwracanie prawdziwego 404.
• Typowe przyczyny miękkiego 404: masowe przekierowanie każdego 404 na stronę główną, stany “not found” (tłumaczenie) „nie znaleziono” w JS/SPA zwracające 200 (co psuje też analitykę) oraz błędy konfiguracji CMS-a.
• Przekierowuj 301 tylko wtedy, gdy strona rzeczywiście została przeniesiona albo ma wartościowe linki zwrotne/ruch; w przeciwnym razie pozwól jej czysto zwracać 404. Splitt: nie przekierowuj usuniętych stron na stronę główną.
• Niestandardowe strony 404 pomagają w UX i utrzymaniu użytkownika, a nie w indeksowaniu — i nadal muszą zwracać prawdziwy 404.
• Audytuj za pomocą raportu indeksowania stron GSC, Ahrefs Site Audit/Site Explorer, Screaming Frog i logów serwera.

Oficjalna dokumentacja

Dokumentacja źródłowa wyszukiwarek.

Google

• Jak kody statusu HTTP oraz błędy sieci i DNS wpływają na wyszukiwarkę Google — sposób obsługi 4xx (w tym 404), mechanizm usuwania z indeksu i definicja miękkiego 404 w tekście.
• Raport indeksowania stron — statusy „Not found (404)” i „Soft 404” oraz wskazówki dotyczące naprawy.
• Przekierowania a wyszukiwarka Google — kiedy i jak przekierować 301 przeniesioną stronę zamiast pozostawiać ją jako 404.
• Usuwanie strony hostowanej w witrynie z Google — tymczasowe ukrycie a trwałe usunięcie.

Bing / Microsoft

• Pomoc Bing Webmaster Tools — raporty crawlowania i narzędzie Content Removal do zgłaszania rzeczywistych błędów tego typu.

Cytaty ze źródeł

Oświadczenia Google zapisane w źródłach. Każdy link do dokumentacji Google jest głębokim linkiem prowadzącym do cytowanego fragmentu; wypowiedzi przekazane przez inne źródła prowadzą do materiałów, które je przytoczyły.

Google Search Central — sposób obsługi tych odpowiedzi

• “Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time.” (tłumaczenie) „Google nie korzysta z treści URL-i zwracających kody statusu 4xx. Jeśli URL był wcześniej używany, ale teraz zwraca kod 4xx, systemy Google z czasem przestaną go używać.” Przejdź do cytatu
• “Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (tłumaczenie) „Google nie indeksuje URL-i zwracających kod statusu 4xx, a URL-e już zindeksowane i zwracające kod 4xx są usuwane z indeksu.” Przejdź do cytatu
• “In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed. The crawling frequency gradually decreases.” (tłumaczenie) „W wyszukiwarce Google potok indeksowania usuwa URL z indeksu, jeśli był wcześniej zindeksowany. Nowo napotkane strony 404 nie są przetwarzane. Częstotliwość crawlowania stopniowo maleje.” Przejdź do cytatu
• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tłumaczenie) „Jeśli treść sugeruje błąd dla wyszukiwarki Google, pustą stronę albo komunikat o błędzie, Search Console pokaże błąd soft 404.” Przejdź do cytatu (Polski gloss: cytaty powyżej opisują, że Google z czasem przestaje używać URL-i zwracających 4xx, usuwa wcześniej zindeksowane adresy, nie przetwarza nowo napotkanych stron 404 i stopniowo zmniejsza częstotliwość crawlowania; miękki 404 może zostać zgłoszony, gdy treść sugeruje błąd.)

Search Console Help — raport indeksowania stron

• “404 responses are not necessarily a problem, if the page has been removed without any replacement. If your page has moved, use a 301 redirect to the new location.” (tłumaczenie) „Odpowiedzi 404 nie muszą być problemem, jeśli strona została usunięta bez zamiennika. Jeśli strona została przeniesiona, użyj przekierowania 301 do nowej lokalizacji.” Przejdź do cytatu
• “Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often.” (tłumaczenie) „Googlebot prawdopodobnie będzie próbował pobierać ten URL przez pewien czas; nie ma sposobu, by kazać mu trwale o nim zapomnieć, choć będzie go crawlowć coraz rzadziej.” Przejdź do cytatu
• “We recommend returning a 404 response code for truly ‘not found’ pages and adding more information on the page to let us know that it is not a soft 404.” (tłumaczenie) „Zalecamy zwracanie kodu odpowiedzi 404 dla stron rzeczywiście „nie znalezionych” oraz dodanie na stronie informacji, że nie jest to miękki 404.” Przejdź do cytatu (Polski gloss: cytaty wyjaśniają, że prawidłowy 404 po usunięciu strony bez zamiennika nie musi być problemem, przeniesioną stronę należy przekierować 301, a Googlebot może jeszcze przez pewien czas ponawiać próby coraz rzadziej.)

Gary Illyes, Google (za reprodukcją SEJ jego wpisów na LinkedIn — zweryfikuj oryginalne brzmienie na LinkedIn, które opiera się automatycznemu pobieraniu)

• “404 (Not found) errors are not to be afraid of and you don’t need to scramble to fix them, at least not most of the time.” (tłumaczenie) „Błędów 404 (nie znaleziono) nie trzeba się bać ani gorączkowo ich naprawiać, przynajmniej przez większość czasu.” Przekazano z posta Illyesa na LinkedIn.
• “Crawlers use the status codes to interpret whether a fetch was successful, even if the contents of the page is basically just an error message. They might happily go back to the same page again and again wasting your resources, and if there are many such pages, exponentially more resources.” (tłumaczenie) „Crawlery używają kodów statusu, aby ocenić, czy pobranie się udało, nawet jeśli zawartością strony jest właściwie tylko komunikat o błędzie. Mogą chętnie wracać do tej samej strony raz po raz, marnując zasoby, a przy wielu takich stronach zużywać wykładniczo więcej zasobów.” Przekazano za pośrednictwem Search Engine Journal; przed ostatecznym użyciem potwierdź w oryginale. (Polski gloss: cytaty ostrzegają, że zwykłych 404-ów nie trzeba panicznie naprawiać, natomiast miękkie 404-y mogą powodować wielokrotne, niepotrzebne pobieranie stron i marnowanie zasobów.)

John Mueller, Google — strona Johna Muellera o miękkich błędach

• “Using soft-404s instead of real 404s is a bad practice, and it makes things harder for our algorithms.” (tłumaczenie) „Używanie miękkich 404 zamiast prawdziwych 404 to zła praktyka i utrudnia pracę naszym algorytmom.”
• “Returning 404 — and having the URLs listed in the crawl errors in Webmaster Tools — is not a problem.” (tłumaczenie) „Zwracanie 404 — i obecność URL-i na liście błędów crawlowania w Webmaster Tools — nie jest problemem.”
• “Think about ways that you can make your 404 pages useful to users, so that they recognize that the page no longer exists, and so that they can find something else that’s appropriate.” (tłumaczenie) „Zastanów się, jak sprawić, by strony 404 były użyteczne dla użytkowników, tak aby rozumieli, że strona już nie istnieje, i mogli znaleźć coś odpowiedniego.” Z osobistej strony Muellera; przed generowaniem głębokich linków na ich podstawie ponownie zweryfikuj dokładne fragmenty na aktualnej stronie. (Polski gloss: Mueller określa miękkie 404 jako złą praktykę, prawdziwe 404 jako nieszkodliwe oraz zaleca, by niestandardowe strony 404 pomagały użytkownikom rozpoznać brak strony i znaleźć odpowiednią treść.)

Martin Splitt, Google (za relacją SEJ z krótkiego spotkania SEO Office Hours — zweryfikuj oryginalne nagranie)

• “If it moved somewhere else, use a redirect. If it’s gone, don’t redirect me to the homepage.” (tłumaczenie) „Jeżeli zasób ma nowy adres, zastosuj przekierowanie. Gdy został usunięty, nie odsyłaj użytkownika na stronę główną.”
• “A 404 is a very clear signal this link is wrong and broken or this URL no longer exists.” (tłumaczenie) „404 to bardzo wyraźny sygnał, że ten link jest niewłaściwy i uszkodzony albo ten URL już nie istnieje.” Przekazano za pośrednictwem Search Engine Journal. (Polski gloss: Splitt zaleca przekierowanie tylko wtedy, gdy strona została przeniesiona, a usuniętych stron nie należy masowo kierować na stronę główną.)

Czego nie robić przy takich błędach

1. Masowe przekierowywanie każdego 404 na stronę główną. Odruch podpowiada: „przekierowanie wygląda bezpieczniej niż błąd”. Tak nie jest. Strona główna zwraca 200, więc URL, który rzeczywiście zniknął, zaczyna „pomyślnie” prowadzić do niezwiązanej treści — to wzorzec miękkiego 404, który Splitt wprost określa jako irytujący i niepomocny. Naprawa: przekierowuj tylko do konkretnego, istotnego celu, gdy strona rzeczywiście została przeniesiona; w przeciwnym razie pozostaw 404.

2. Tworzenie miękkiego 404 zamiast zwracania prawdziwego 404. Serwowanie komunikatu „Nie znaleziono strony” (albo pustej strony) z kodem 200 OK mówi crawlerom, że pobranie się udało. Nadal będą crawlowć stronę, marnując zasoby, a analityka zapisze „udane” wejście na martwy URL. Naprawa: dla usuniętej treści zwracaj prawdziwy kod 404 (albo 410) — Google wyraźnie to zaleca.

3. Panikowanie i „naprawianie” każdego 404 w raportach. 404-y w GSC lub audycie witryny są normalne i oczekiwane. Odruchowe przekierowywanie albo wskrzeszanie każdego z nich marnuje czas i często tworzy miękkie 404. Naprawa: przeprowadź triage — przekieruj kilka adresów z rzeczywistymi linkami zwrotnymi/ruchem, a resztę pozostaw.

4. Próba zmuszenia Google, by natychmiast „zapomniał” URL. Nie ma do tego przycisku. Narzędzie Removals to tymczasowe ukrycie (około sześciu miesięcy), a nie trwałe usunięcie z indeksu. Naprawa: zwróć właściwy kod statusu i pozwól, aby częstotliwość crawlowania sama stopniowo malała.

5. Wysyłanie ekranu „Nie znaleziono” w JS/SPA z kodem 200. Routery po stronie klienta nie mogą rzucić serwerowego 404, więc renderowany komponent braku strony nad odpowiedzią 200 jest miękkim 404, który psuje też śledzenie. Naprawa: kieruj te ścieżki po stronie serwera do prawdziwego 404 albo przynajmniej dodaj noindex do stanu braku strony i zaakceptuj kompromisy w analityce.

6. Traktowanie ładnej niestandardowej strony 404 jako naprawy SEO. Dobrze zaprojektowana strona 404 pomaga użytkownikom, a nie w indeksowaniu — a jeśli zwraca 200, jest miękkim 404. Naprawa: zachowaj prawdziwy kod statusu i spraw, aby strona była pomocna; to dwa odrębne zadania.

Dobre i złe postępowanie z błędem 404

Zła niestandardowa strona 404

• Zwraca kod statusu 200 OK, jednocześnie pokazując „Nie znaleziono strony” (miękki 404).
• Albo jest surową stroną domyślną serwera: samym „Not Found” na białym tle, bez nawigacji i bez dalszej drogi.
• Kończy ścieżkę użytkownika — nie ma pola wyszukiwania, linków ani elementów zgodnych z marką.
• Rezultat: crawlery nadal ją pobierają (miękki 404), użytkownicy wychodzą, a wszelkie sygnały linków prowadzące do URL-a zostają bez wykorzystania.

Dobra niestandardowa strona 404

• Zwraca prawdziwy kod statusu 404 (część dotycząca crawlowania i indeksowania jest obsłużona prawidłowo).
• Jasno mówi, że strona nie istnieje, prostym językiem.
• Zawiera główną nawigację i pole wyszukiwania, aby użytkownik mógł znaleźć to, czego szukał.
• Oferuje linki do popularnych lub powiązanych treści (najważniejszych artykułów, głównych kategorii).
• Jest zgodna z marką — ma ten sam nagłówek, stopkę i styl co reszta witryny, dzięki czemu użytkownik wie, że nadal jest we właściwym miejscu.

Te dwie właściwości są niezależne: kod statusu zadowala wyszukiwarki, a wygląd strony pomaga zatrzymać ludzi. Strona może świetnie spełniać jedno zadanie i zawodzić w drugim — efektowna strona 404 zwracająca 200 nadal jest miękkim 404, a poprawny 404, który kończy ścieżkę użytkownika, nadal traci odwiedzającego.

Dobre i złe postępowanie z przekierowaniem usuniętego URL-a

• Źle: każdy usunięty produkt przekierowuje 301 na stronę główną → sygnał podobny do miękkiego 404 i sfrustrowani użytkownicy.
• Dobrze: usunięty produkt z linkami zwrotnymi przekierowuje 301 do najbliższej właściwej działającej strony (kategorii nadrzędnej albo produktu zastępczego); usunięty produkt bez wartości i linków po prostu zwraca 404.

Lista kontrolna audytu i obsługi 404

• Brakujące URL-e zwracają prawdziwy kod 404 (albo 410) — sprawdź kod, nie ufaj komunikatowi na stronie.
• Brak miękkich 404: żadnej treści „nie znaleziono” z kodem 200 ani masowych przekierowań usuniętych stron na stronę główną.
• Sprawdzono raport indeksowania stron GSC pod kątem statusów „Not found (404)” i „Soft 404”.
• Zidentyfikowano URL-e zwracające 404 z rzeczywistymi linkami zwrotnymi/ruchem (Ahrefs Site Explorer „Best by links”, filtr dla 404) i przekierowano 301 do istotnej działającej strony.
• Usunięte strony bez wartości i linków pozostawiono jako 404 — nie przekierowano ich ani nie wskrzeszono.
• Przekierowania prowadzą do konkretnego, istotnego celu, nigdy do przekierowania zbiorczego na stronę główną.
• Niestandardowa strona 404 jest pomocna (jasny komunikat, nawigacja, wyszukiwanie, linki do popularnych treści) i nadal zwraca 404.
• W witrynach JS/SPA trasy braku strony zwracają prawdziwy serwerowy 404 albo mają przynajmniej noindex, a analityka nie rejestruje ich jako udanych wejść.
• Nie marnuje się wysiłku na „naprawianie” każdego 404 — przeprowadzono triage, a nie masowe działania.

Narzędzia do znajdowania i obsługi takich błędów

• Google Search Console — raport indeksowania stron — własny widok Google na statusy „Not found (404)” i „Soft 404”, z przykładowymi URL-ami i możliwością poproszenia o walidację po naprawie.
• Ahrefs Site Audit — wykrywa 404-y i uszkodzone linki wewnętrzne podczas crawlowania witryny.
• Ahrefs Site Explorer („Best by links”) — znajduje URL-e zwracające 404, które nadal mają linki zwrotne, posortowane według domen odsyłających, aby ustalić, które zasługują na przekierowanie 301.
• Screaming Frog SEO Spider — widok na poziomie crawlowania wszystkich 404-ów (i linków źródłowych) w witrynie.
• Analiza pliku logów serwera — pokazuje, które 404-y rzeczywiście odwiedzają boty i użytkownicy oraz jak często.
• Bing Webmaster Tools — raporty crawlowania pokazujące 404-y/błędy serwera oraz narzędzie Content Removal do oznaczenia URL-a jako usuniętego (własny klasyfikator Binga i szczegóły szybkości usuwania nie są niezależnie zweryfikowane, więc traktuj to jako uzupełnienie zachowania Google udokumentowanego w GSC).
• URL Inspection (GSC) — sprawdza pobrany kod statusu pojedynczego URL-a, aby potwierdzić, że to prawdziwy 404, a nie miękki 404.

Zasoby warte uwagi

Moje powiązane teksty

• Kody statusu HTTP i ich wpływ na SEO — pełny obraz kodów statusu, w tym miejsce 404, 410 i miękkiego 404.
• 11 rodzajów przekierowań i ich wpływ na SEO — kiedy przekierować 301 adres, który w przeciwnym razie zwracałby 404, a kiedy pozostawić 404/410.
• Przewodnik po technicznym SEO dla początkujących — miejsce kodów statusu w szerszym obrazie technicznego SEO.
• Problemy SEO JavaScriptu i dobre praktyki — kontekst renderowania stojący za pułapkami miękkich 404 w JS/SPA.

Moje wystąpienia

• Jak działa wyszukiwanie (SlideShare) — moje omówienie crawlowania, renderowania i indeksowania, czyli potoku, przez który przechodzą te odpowiedzi. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „Tak rozumiem te systemy… nie będzie to w 100% kompletne ani dokładne.”)

Z branży

• Jak kody statusu HTTP wpływają na wyszukiwarkę Google (Google Search Central) — podstawowe źródło o obsłudze 4xx/404.
• Raport indeksowania stron (Pomoc Search Console) — kanoniczne definicje twardego i miękkiego 404 oraz wskazówki dotyczące naprawy.
• Miękkie błędy 404 a Twoja witryna (John Mueller) — własne wyjaśnienie Google, dlaczego miękkie 404 są gorsze od prawdziwych.
• Google ostrzega przed miękkimi błędami 404 i ich wpływem na SEO (Search Engine Journal) — omówienie wypowiedzi Illyesa o miękkich 404 i marnowaniu zasobów crawlowania.
• John Mueller z Google wyjaśnia różnicę między 404 a 410 (Search Engine Journal) — wyjaśnienie, dlaczego różnica między 404 i 410 jest znikoma dla SEO.
• Martin Splitt z Google ostrzega przed przekierowywaniem błędów na stronę główną (Search Engine Journal) — argumenty przeciw masowym przekierowaniom 404 na stronę główną.
• Strony błędu 404: zalecenia i czego unikać (Yoast) — przykłady dobrych i złych niestandardowych stron 404.
• Wszystko, co trzeba wiedzieć o błędach 404 w SEO (Seer Interactive) — ramy z poziomami ważności do ustalania priorytetów napraw 404.

Sprawdź się: 404 Not Found

Pięć krótkich pytań o znaczenie tych błędów dla SEO i sposób ich obsługi. Wybierz odpowiedź na każde pytanie, a potem sprawdź wynik.

Dziennik zmian