Błędy soft 404: dlaczego Google usuwa strony zwracające 200

Błąd soft 404 pojawia się, gdy adres URL zwraca 200 OK, ale jego treść wygląda jak komunikat o błędzie, pusta strona albo brakujący zasób. Google traktuje taką stronę jak nieistniejącą i nie dodaje jej do indeksu. Widzisz takie adresy w Search Console i podejrzewasz, że Twój serwer źródłowy (albo stojące przed nim proxy) serwuje strony błędów z kodem sukcesu? Z tego poradnika dowiesz się, jak Google je klasyfikuje, skąd zwykle się biorą, jak potwierdzić prawdziwy kod odpowiedzi i jak naprawić go na serwerze źródłowym.

Co właściwie oznacza soft 404 w Search Console?

Search Console oznacza stronę jako soft 404, gdy serwer zwraca kod sukcesu, a sama strona wygląda jak błąd, pusta strona albo komunikat o błędzie. Krótkie przypomnienie: kod statusu to liczba, którą serwer wysyła przed treścią strony, a roboty odczytują go, zanim w ogóle dotrą do zawartości. Według przewodnika Google po kodach statusu HTTP odpowiedź 200 trafia dalej do procesu indeksowania, ale to nie znaczy, że strona zostanie zaindeksowana. Serwer mówi więc „sukces”, a strona mówi „brak”. Google wierzy stronie. I ją usuwa.

Dlaczego strona błędu z kodem 200 szkodzi bardziej niż prawdziwe 404

Prawdziwy kod 4xx jest jednoznaczny. Mówi Google, że treść nie istnieje, i tyle. Strona błędu serwowana z kodem 200 marnuje crawlowanie i zaciemnia sygnał. Google traktuje wszystkie kody 4xx poza 429 tak samo: zaindeksowane adresy, które zaczynają zwracać 4xx, są usuwane, nowo odkryte strony 404 nie są przetwarzane, a częstotliwość ich crawlowania z czasem spada. Błędy serwera i 429 to inna historia. Sprawiają, że Google na jakiś czas ogranicza crawlowanie i zostawia zaindeksowane adresy w indeksie, choć strony, które ciągle zwracają błąd, w końcu i tak wypadają. Przy porządkowaniu takich adresów popraw też linki wewnętrzne, które do nich prowadzą, i przy okazji zadbaj o opisowy tekst kotwicy linków.

W praktyce zasada jest więc dość prosta. 404 lub 410 dla treści, której już nie ma, 5xx dla prawdziwej awarii, 200 tylko dla prawdziwej strony.

Najczęstsze źródła błędów soft 404

Większość błędów soft 404 bierze się z szablonów i stron zastępczych, które wyświetlają komunikat o błędzie, ale zostawiają domyślny kod sukcesu. Typowi winowajcy:

• Własny szablon „nie znaleziono”, który CMS albo framework renderuje ze statusem 200.
• Puste strony kategorii, tagów, wyszukiwania lub list bez żadnych pozycji (klasyczny soft 404 przy ubogiej treści).
• Strony awarii zaplecza, np. przy niedziałającej bazie danych albo wyjątku w aplikacji, które serwer źródłowy zwraca z kodem 200.
• Treści błędów lub zaślepek przechodzące przez reverse proxy, gdy serwer źródłowy ustawił już 200. Jeśli zastanawiasz się, jaki kod statusu ma strona błędu proxy, najpierw sprawdź, co wysyła serwer źródłowy.
• Usunięte produkty lub artykuły przekierowane na ogólną stronę albo stronę główną zamiast zwracać 404 lub 410.

Dodatkowa warstwa między odwiedzającymi a serwerem może to wszystko ukryć. To jeden z problemów, które proxy potrafi ukryć, dopóki Search Console w końcu go nie zgłosi.

Jak sprawdzić, jaki kod statusu naprawdę zwraca strona

Nie ufaj przeglądarce. Wyślij żądanie bezpośrednio pod adres i odczytaj linię statusu. Przyjazna strona błędu wygląda tak samo niezależnie od kodu, z jakim przychodzi, więc sprawdzaj warstwa po warstwie:

1. Uruchom curl -I lub curl -sS -o /dev/null -w '%{http_code}' na oznaczonym adresie.
2. Wyślij to samo żądanie prosto do serwera źródłowego, z pominięciem proxy, żeby zobaczyć, która warstwa ustawia kod.
3. Użyj narzędzia Sprawdzanie adresu URL w Search Console, żeby zobaczyć, co faktycznie dostał Googlebot.
4. Przejrzyj logi dostępu pod kątem żądań Googlebota i kodów, które otrzymał.

Logi pomagają też w wyszukiwaniu błędów w logach serwera na dużą skalę. Przy okazji porównaj rozmiary odpowiedzi. Dużo małych, niemal identycznych odpowiedzi 200? Zwykle oznacza to wspólny szablon błędu.

Jak naprawić błędy soft 404 na serwerze źródłowym i w NGINX

Niech serwer wysyła status zgodny z treścią: 404 lub 410 dla brakujących stron, 5xx dla awarii, 200 tylko dla prawdziwej treści. W aplikacji ustaw kod w obsłudze „nie znaleziono”, a nie tylko w szablonie, który ta obsługa renderuje (łatwo to przeoczyć i to bardzo częsty błąd). Puste strony wyszukiwania lub list powinny albo zwracać 404, albo dostać prawdziwą treść.

W NGINX używaj error_page 404 /404.html; bez nadpisania =200 i upewnij się, że try_files kończy się na =404, zamiast przepisywać każdą nieznaną ścieżkę na index.php lub index.html z kodem sukcesu. Treści usunięte celowo powinny zwracać 410. Przekierowanie ma sens tylko wtedy, gdy strona docelowa jest naprawdę odpowiednikiem. Aplikacje jednostronicowe? Serwer powinien zwracać prawdziwe 404 dla nieznanych ścieżek, a przynajmniej tag noindex, a nie pustą powłokę. Po wdrożeniu kliknij Sprawdź poprawkę w Search Console i obserwuj raport przez kilka kolejnych crawlowań.

Ubogie i puste strony na odbudowanych lub wygasłych domenach

Stare domeny odbudowane z tekstem zastępczym albo pustymi szablonami to częste źródło soft 404 przy ubogiej treści. Dla adresów z historią masz dwie opcje: przywrócić wartościową treść albo pozwolić im zwracać 404 lub 410. Nie zostawiaj natomiast pustych powłok. Planowanie opłaca się przy odbudowie stron na starych domenach, bo każdy adres wymaga jasnej decyzji.

Serwisy, które potrzebują obecności w konkretnym regionie, mogą też działać za reverse proxy z adresami IP z UE lub z USA, a kody statusu nadal zostają pod Twoją kontrolą na serwerze źródłowym.

Błędy soft 404 znikają, gdy kod statusu mówi to samo co treść. Sprawdź prawdziwy kod, napraw go na serwerze źródłowym, zwracaj 404 lub 410 dla stron, których już nie ma, i przestań serwować puste szablony. To naprawdę wszystko. Więcej na pokrewne tematy znajdziesz w naszych poradnikach o indeksowaniu i crawlowaniu.

FAQ