Artykuł ma status 200, ale pokazuje błąd: jak rozpoznać soft 404?

Adres URL otwiera się bez problemu, serwer zwraca HTTP 200 OK, a mimo to Google Search Console oznacza stronę jako soft 404. Na ekranie widać komunikat „Nie znaleziono artykułu”, pusty szablon albo sam nagłówek i stopkę. To sytuacja, w której serwer potwierdza poprawną obsługę żądania, chociaż użytkownik nie otrzymuje treści, której szukał.

Soft 404, czyli pozorny błąd 404, nie jest osobnym kodem HTTP. To sposób, w jaki Google klasyfikuje strony wyglądające na nieistniejące lub nieprawidłowo działające pomimo odpowiedzi sugerującej sukces. Skutkiem bywa wykluczenie adresu z indeksu, nawet gdy strona wcześniej generowała ruch. Rozwiązanie zależy od jednej rzeczy: czy artykuł rzeczywiście zniknął, został przeniesiony, czy tylko nie wyświetla się prawidłowo.

Dlaczego artykuł zwraca HTTP 200, chociaż nie istnieje?

Kod 200 OK informuje, że serwer pomyślnie obsłużył żądanie. Nie potwierdza natomiast, że odpowiedź zawiera właściwy artykuł. To rozróżnienie ma szczególne znaczenie w systemach CMS, które potrafią wyświetlić szablon błędu bez zmiany statusu odpowiedzi HTTP.

Przykład: redaktor usuwa publikację z WordPressa, ale niestandardowy mechanizm obsługi adresów nadal kieruje odwiedzających do szablonu strony. Użytkownik widzi logo, menu i komunikat „Nie znaleziono wpisu”. Serwer odpowiada jednak kodem 200, ponieważ aplikacja wygenerowała dokument HTML.

Dla przeglądarki żądanie zakończyło się powodzeniem. Dla Google zawartość wygląda jak strona błędu. Właśnie taki konflikt prowadzi do klasyfikacji soft 404.

Problem nie ogranicza się do WordPressa. Podobne sytuacje występują w:

• Aplikacjach SPA opartych na React lub Vue, gdy serwer zwraca plik index.html i status 200 również dla nieistniejących ścieżek.
• Sklepach WooCommerce i PrestaShop, gdy usunięta karta produktu wyświetla pusty szablon zamiast poprawnego błędu.
• Serwisach z rozbudowanym JavaScriptem, gdy główna treść nie ładuje się z powodu błędnego żądania API albo niedostępnego skryptu.
• Wyszukiwarkach wewnętrznych, które zwracają pustą listę wyników przy statusie 200.

Google analizuje nie tylko kod odpowiedzi, ale również treść strony, w tym wynik renderowania JavaScriptu. Jeśli zamiast artykułu znajduje komunikat o błędzie lub niemal pusty dokument, może zakwalifikować adres jako soft 404.

Nie każdy krótki artykuł jest jednak soft 404. Publikacja licząca 200 słów, która wyczerpująco odpowiada na konkretne pytanie, nie musi być błędem. Samo zwiększenie objętości tekstu również nie gwarantuje usunięcia oznaczenia. Decydujące jest to, czy pod wskazanym adresem istnieje rzeczywista, dostępna treść.

W serwisach mających kilka tysięcy publikacji konsekwencje niewłaściwego statusu są większe. Googlebot może wielokrotnie odwiedzać nieprzydatne adresy, a istotne artykuły oznaczone jako soft 404 nie trafiają do wyników wyszukiwania. Nie oznacza to automatycznie kary dla całej domeny, ale przy dużej liczbie takich stron pogarsza efektywność skanowania witryny.

Dlatego nie należy masowo ustawiać kodu 404 dla wszystkich adresów wskazanych przez Google. Jeśli artykuł naprawdę istnieje, taka naprawa tylko pogłębi problem.

Jak rozpoznać soft 404 w Google Search Console i sprawdzić odpowiedź serwera?

Pierwszym miejscem diagnostyki jest Google Search Console. W raporcie „Indeksowanie” → „Strony”, wśród powodów braku indeksowania, znajduje się pozycja „Pozorny błąd 404”. To polska nazwa komunikatu soft 404.

Po otwarciu raportu należy wybrać konkretny adres i sprawdzić go w narzędziu do inspekcji URL. Istotne są trzy informacje: data ostatniego skanowania, stan indeksowania oraz zawartość, którą Google rzeczywiście zobaczył.

Następnie trzeba uruchomić „Sprawdź URL wersji opublikowanej” i otworzyć widok przetestowanej strony. Warto porównać zrzut ekranu, wyrenderowany HTML i informacje o zasobach.

Praktyczny przypadek: artykuł o dofinansowaniu pomp ciepła działa w zwykłej przeglądarce, lecz Search Console pokazuje niemal pustą stronę. Okazuje się, że główna treść jest pobierana przez JavaScript, a żądanie do API czasami kończy się błędem 403. Serwer początkowo zwraca 200, ale Google nie otrzymuje zawartości artykułu.

W takim przypadku ustawienie kodu 404 byłoby błędem. Naprawić trzeba dostęp do treści, nie status istniejącej publikacji.

Drugi etap to sprawdzenie rzeczywistej odpowiedzi HTTP. Można to zrobić w Chrome, otwierając narzędzia programistyczne (F12), kartę „Network” i wybierając główne żądanie dokumentu. Kolumna „Status” pokazuje kod zwrócony przez serwer.

Alternatywą jest polecenie terminalowe:

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' 'https://twojadomena.pl/usuniety-artykul'

Polecenie wykonuje żądanie GET i pokazuje kod odpowiedzi oraz ewentualny adres przekierowania. Jeśli usunięty artykuł zwraca 200, choć na stronie widnieje „Nie znaleziono”, mamy techniczną przesłankę soft 404. Jeśli wynik to 404, serwer prawidłowo informuje o braku zasobu.

Warto użyć żądania GET, a nie polegać wyłącznie na curl -I, które wykonuje HEAD. Niektóre konfiguracje serwerów obsługują te metody inaczej.

Dobry test kontrolny polega na porównaniu trzech adresów: działającego artykułu, publikacji oznaczonej jako soft 404 oraz wymyślonego adresu, który nigdy nie istniał. Jeżeli wszystkie zwracają 200, problem prawdopodobnie dotyczy wspólnej obsługi tras lub szablonu błędu.

Trzeba też oddzielić bieżący stan witryny od historycznego raportu Google. Search Console pokazuje informacje z ostatniego przetwarzania adresu, dlatego poprawiona już strona może nadal figurować jako soft 404. Test wersji opublikowanej pozwala sprawdzić, czy naprawa jest widoczna obecnie, lecz sam pozytywny test nie gwarantuje indeksowania.

Gdy problem pojawia się tylko sporadycznie, pomocne są logi serwera, błędy JavaScriptu i odpowiedzi API. Jednorazowe otwarcie strony na komputerze właściciela nie wystarczy, żeby wykluczyć awarię widoczną dla Googlebota.

Jak usunąć soft 404 bez utraty wartościowych artykułów?

Naprawa zaczyna się od określenia, co powinno znajdować się pod problematycznym adresem. Nie istnieje jeden poprawny kod HTTP dla wszystkich przypadków soft 404. Wybór zależy od tego, czy publikacja została usunięta, przeniesiona, czy nadal powinna być dostępna.

1. Artykuł został trwale usunięty — zastosuj 404 lub 410.

Jeśli publikacja nie istnieje i nie ma odpowiedniego zamiennika, serwer powinien zwracać 404 Not Found albo 410 Gone.

Kod 404 oznacza, że zasobu nie znaleziono. Kod 410 wyraźniej wskazuje, że został usunięty. Oba są dla Google sygnałem, że adres nie powinien pozostawać w indeksie. Nie należy zakładać, że 410 zawsze zapewni szybsze usunięcie strony z wyników.

Przykładem jest usunięta relacja z nieaktualnego wydarzenia, której wydawca nie chce już udostępniać. Można zachować estetyczny szablon błędu z odnośnikami do innych publikacji, ale nagłówek HTTP musi nadal zwracać 404 lub 410.

Nie ma sensu przekierowywać takiego adresu na przypadkowy artykuł tylko po to, żeby uniknąć błędu.

2. Artykuł zmienił adres — zastosuj przekierowanie 301.

Jeśli publikacja została przeniesiona z /blog/jak-dobrac-pompe-ciepla do /poradniki/dobor-pompy-ciepla, odpowiednim rozwiązaniem jest przekierowanie 301 Moved Permanently.

Użytkownik trafia wtedy do faktycznego odpowiednika starej strony, a Google otrzymuje sygnał o trwałej zmianie adresu.

Problem pojawia się, gdy właściciel serwisu przekierowuje wszystkie usunięte artykuły na stronę główną. Takie przekierowania często nie odpowiadają intencji użytkownika i mogą zostać potraktowane przez Google jak soft 404.

Przekierowanie ma sens tylko wtedy, gdy strona docelowa rzeczywiście zastępuje poprzednią treść. Podobieństwo kategorii tematycznej nie zawsze wystarcza.

3. Artykuł istnieje — zachowaj 200 i napraw sposób wyświetlania.

To przypadek wymagający najwięcej ostrożności. Jeśli Google błędnie klasyfikuje wartościowy artykuł, nie należy go usuwać ani przekierowywać bez ustalenia przyczyny.

Najpierw trzeba sprawdzić, czy pełna treść znajduje się w wyrenderowanym HTML, czy pliki JavaScript i żądania API działają prawidłowo oraz czy istotne zasoby nie są blokowane przez robots.txt.

Przy aplikacjach React i Vue problemem bywa renderowanie treści dopiero w przeglądarce. Jeżeli Google widzi pusty kontener zamiast artykułu, rozwiązaniem może być renderowanie po stronie serwera (SSR) lub generowanie gotowego HTML podczas budowania witryny. Nie trzeba jednak przebudowywać całego serwisu na SSR, jeśli wystarcza naprawa jednego błędnego skryptu.

Podobna zasada dotyczy e-commerce. Produkt chwilowo niedostępny w polskim sklepie nie musi otrzymywać 404. Jeśli karta nadal zawiera opis, parametry, zdjęcia i informację o niedostępności, status 200 jest uzasadniony. W danych strukturalnych produktu można wskazać dostępność OutOfStock.

Inaczej wygląda sytuacja, gdy karta pokazuje jedynie „Produkt nie istnieje”. Wtedy trzeba zdecydować, czy zasób usunąć, czy przekierować do rzeczywistego następcy.

W aplikacji SPA, w której nie można łatwo zwrócić prawidłowego 404 dla nieistniejącej trasy, alternatywą jest dynamiczne dodanie dyrektywy noindex na stronie błędu. To jednak sposób na ograniczenie indeksowania takiej strony, a nie pełny zamiennik poprawnego statusu HTTP.

Nie należy też blokować problematycznego adresu w robots.txt tylko po to, aby ukryć soft 404. Blokada może uniemożliwić Google sprawdzenie poprawionej odpowiedzi.

Po wdrożeniu zmian należy ponownie przetestować adres, sprawdzić odpowiedź HTTP i wyrenderowaną treść, a następnie skorzystać z funkcji weryfikacji poprawki lub prośby o ponowne zindeksowanie tam, gdzie jest dostępna. Aktualizacja raportu może potrwać od kilku dni do kilku tygodni, zależnie od częstotliwości skanowania. Nie ma gwarantowanego terminu ani gwarancji ponownego indeksowania.

Przy większej liczbie błędów priorytet powinny otrzymać artykuły obecne w mapie XML, powiązane z wewnętrznymi linkami i mające znaczenie dla ruchu organicznego. Jeśli kilkaset usuniętych adresów zwraca 200 przez jeden błędny mechanizm CMS, poprawienie wspólnej reguły jest pilniejsze niż ręczne naprawianie każdej podstrony.

FAQ – najczęstsze pytania o soft 404

Czy soft 404 i zwykły błąd 404 oznaczają to samo?
Nie. Zwykły błąd 404 to kod HTTP zwracany przez serwer. Soft 404 jest klasyfikacją Google wskazującą, że zawartość strony wygląda na niedostępną, mimo że odpowiedź HTTP nie informuje prawidłowo o jej braku.

Czy soft 404 zawsze oznacza problem z pozycjonowaniem?
Nie. Jeśli dotyczy celowo usuniętej, nieistotnej strony, wystarczy doprowadzić jej odpowiedź HTTP do prawidłowego stanu. Problem jest poważniejszy, gdy Google wyklucza aktywne artykuły, które powinny generować ruch.

Czy metatag noindex naprawia soft 404?
Nie naprawia błędnej odpowiedzi serwera. Może być rozwiązaniem pomocniczym, gdy strona błędu w aplikacji SPA nie powinna być indeksowana. Dla trwale nieistniejącego zasobu lepszy jest właściwy kod 404 lub 410.

Czy przekierowanie 301 na stronę główną usuwa problem?
Nie musi. Google może uznać takie przekierowanie za nieodpowiednie, jeśli strona główna nie zastępuje usuniętej publikacji. Lepiej skierować użytkownika do rzeczywistego odpowiednika lub zwrócić 404.

Jak szybko soft 404 znika z Google Search Console?
Nie ma stałego terminu. Poprawka musi zostać ponownie sprawdzona i przetworzona przez Google. Zmiana może pojawić się po kilku dniach, ale w mniej regularnie skanowanych serwisach potrwa dłużej.

Co należy sprawdzić w pierwszej kolejności?
Zacznij od jednego ważnego artykułu oznaczonego jako „Pozorny błąd 404”. Porównaj jego kod HTTP z treścią widoczną w teście Google Search Console. Jeśli artykuł nie istnieje, usuń błędne 200 i ustaw 404 lub 410. Jeśli istnieje, najpierw napraw wyświetlanie treści. Dopiero po tym sprawdzaj pozostałe adresy — inaczej łatwo usunąć wartościową publikację, której jedynym problemem był uszkodzony mechanizm renderowania.

Więcej informacji na: https://cmpress.pl