Czym różni się soft-404 od zwykłego błędu 404?

Dla użytkownika niczym: w obu przypadkach widzi stronę błędu. Różnica siedzi w kodzie odpowiedzi serwera. Zwykły błąd zwraca kod 404, więc roboty wiedzą, że strony nie ma. Soft-404 zwraca kod 200, więc roboty traktują stronę błędu jak pełnoprawną treść i mogą marnować czas na jej indeksowanie.

Czy przekierowanie nieistniejących adresów na stronę główną szkodzi?

Tak. Google traktuje takie przekierowania jak soft-404, bo strona główna nie jest odpowiednikiem treści, której użytkownik szukał. Do tego każdy test oparty na kodzie odpowiedzi zaczyna twierdzić, że dowolny plik w domenie istnieje, co fałszuje wyniki audytów SEO i GEO.

Jak sprawdzić, czy moja strona zwraca prawdziwy kod 404?

Otwórz wymyślony adres w swojej domenie, włącz narzędzia deweloperskie przeglądarki (F12), przejdź do zakładki Sieć i odśwież stronę. Status pierwszego wpisu to kod odpowiedzi: 404 lub 410 oznacza prawdziwy błąd, 200 oznacza soft-404, a 301 prowadzące na stronę główną to przekierowanie każdej ścieżki.

Kiedy użyć kodu 410 zamiast 404?

Kod 404 mówi „nie znaleziono”, kod 410 mówi „usunięto na stałe”. Jeśli strona zniknęła celowo i nie wróci, 410 jest precyzyjniejszy i bywa sygnałem do szybszego usunięcia adresu z indeksu. W praktyce oba kody załatwiają sprawę. Najważniejsze, żeby nieistniejąca strona nie zwracała 200.

Czy ozdobna strona błędu jest w porządku?

Tak, pod jednym warunkiem: musi iść w parze z kodem 404 lub 410. Możesz pokazać grafikę, wyszukiwarkę i linki do popularnych działów. Problem zaczyna się dopiero wtedy, gdy taka strona wychodzi z serwera z kodem 200, bo wtedy roboty biorą ją za zwykłą treść.

Status 200 to nie dowód: jak soft-404 i przekierowania psują audyty

Status 200 mówi tylko tyle, że serwer coś odpowiedział. Nie mówi, że plik istnieje. Do oszukania audytu wystarczą dwa mechanizmy: przekierowanie każdej nieznanej ścieżki na stronę główną oraz soft-404, czyli ozdobna strona błędu zwracana z kodem 200. Skutek? Narzędzie chwali Cię za llms.txt i sitemapę, których nie masz, a boty AI marnują czas na strony-wydmuszki.

Odpalasz audyt techniczny swojej strony i widzisz same zielone znaczniki: sitemapa jest, llms.txt jest, strona błędu działa. Brzmi jak dobra wiadomość. Problem w tym, że narzędzie mogło sprawdzić wyłącznie kod odpowiedzi serwera. A ten potrafi kłamać.

Poniżej pokażę, jak działają dwa mechanizmy, które fałszują takie testy, dlaczego Google traktuje je jako problem jakości i jak w dwie minuty sprawdzić, czy Twoja strona mówi robotom prawdę.

Dlaczego status 200 nie dowodzi, że plik istnieje?

Większość testów plików działa tak samo: narzędzie wysyła zapytanie pod adres, podąża za przekierowaniami i patrzy na końcowy kod odpowiedzi. Kod 200 znaczy „OK, mam treść”. Kod 404 znaczy „nie ma takiej strony”. Prosty test, szybki wynik.

Sęk w tym, że kod 200 potwierdza wyłącznie jedno: serwer coś zwrócił. Nie mówi, co zwrócił. To jak telefon do firmy: ktoś odebrał i powiedział „halo”, ale to jeszcze nie znaczy, że po drugiej stronie jest właściwy dział.

Dwa popularne mechanizmy wykorzystują tę lukę na masową skalę. Oba sprawiają, że nieistniejące pliki wyglądają w testach jak istniejące. Pierwszy to przekierowanie wszystkiego na stronę główną, drugi to soft-404.

Na czym polega przekierowanie każdej ścieżki na stronę główną?

Sporo sklepów internetowych ma w konfiguracji prostą regułę: każdy adres, którego serwer nie rozpoznaje, dostaje przekierowanie 301 na stronę główną. Wpiszesz adres promocji sprzed trzech lat? Lądujesz na stronie głównej. Wpiszesz losowy ciąg znaków? To samo.

Intencja bywa dobra. Zamiast pokazywać klientowi błąd, sklep prowadzi go do oferty. Część wdrożeń liczy też na to, że przekierowania „uratują” moc starych linków prowadzących do usuniętych produktów.

Skutek uboczny jest jednak poważny. Test „czy URL odpowiada kodem 200 po przekierowaniach” mówi „tak” dla każdego adresu w tej domenie. Również dla /llms.txt i /sitemap.xml, których nikt nigdy nie stworzył. Narzędzie widzi 200 i odhacza plik jako obecny.

Czym jest soft-404 i skąd się bierze?

Soft-404 to strona błędu, która dla człowieka wygląda jak błąd, ale zwraca kod 200. Użytkownik widzi komunikat „ups, nic tu nie ma”, robot widzi status „OK, mam treść”. Nazwę spopularyzowało Google, które opisuje to zjawisko w dokumentacji dla webmasterów i raportuje je w Google Search Console jako „miękkie 404”.

Skąd się bierze? Najczęściej z wygody. Wiele stron renderuje komunikat błędu wewnątrz aplikacji: użytkownik dostaje ładny ekran z grafiką i przyciskiem powrotu, ale framework wysyła domyślny kod 200, bo nikt go nie zmienił. Strona błędu istnieje, tylko serwer twierdzi, że to zwykła, poprawna podstrona.

Dla testu opartego na kodzie odpowiedzi skutek jest identyczny jak przy przekierowaniu na stronę główną: każdy wymyślony adres „istnieje”.

Jak soft-404 i przekierowania psują audyty SEO i GEO?

Pierwsza ofiara to audyty. Narzędzie sprawdza, czy masz llms.txt, sitemapę i poprawną stronę błędu. Dostaje 200 na wszystko, więc chwali Cię za pliki, których nie ma. Fałszywy wynik jest gorszy niż brak wyniku, bo blokuje słuszne poprawki: skoro audyt twierdzi, że sitemapa jest, nikt jej nie doda.

Druga ofiara to indeks Google. Google traktuje soft-404 jako problem jakości: robot marnuje czas na adresy, pod którymi nic nie ma, zamiast indeksować wartościowe treści. Dokumentacja Google mówi wprost, że poprawne zgłaszanie nieistniejących stron kodem 404 lub 410 poprawia pokrycie indeksowania najlepszych treści serwisu.

Trzecia ofiara to widoczność w AI. Boty silników AI, jak GPTBot czy PerplexityBot, poświęcają Twojej witrynie ograniczony czas. Jeśli spędzą go na stronach-wydmuszkach, które udają treść, maleje szansa, że dotrą do stron z realną wartością, czyli do tych, które mają szansę trafić do odpowiedzi AI jako źródło.

Z własnego doświadczenia

Na przekierowanie każdej ścieżki trafiłem przy budowie własnego audytu w CiteLyzerze. Jeden ze sprawdzanych sklepów przekierowywał wszystkie nieznane adresy na stronę główną, a test statusu radośnie raportował, że sklep ma llms.txt oraz sitemapę. Nie miał żadnego z tych plików. Dokładnie dlatego test z sekcji poniżej robisz oczami, a nie samym kodem odpowiedzi.

Piotr Czerwiński · Założyciel CiteLyzer i HiddenJobs

Jak sprawdzić u siebie w dwie minuty?

Nie potrzebujesz żadnego narzędzia. Wystarczy przeglądarka i cztery kroki:

Otwórz wymyślony adres w swojej domenie, np. twojadomena.pl/nie-ma-takiej-strony-123. Jeśli wylądujesz na stronie głównej, masz przekierowanie każdej ścieżki. Jeśli zobaczysz stronę błędu, przejdź do kroku drugiego.
Sprawdź prawdziwy kod odpowiedzi. Otwórz narzędzia deweloperskie (F12), zakładkę Sieć (Network), odśwież stronę i spójrz na status pierwszego wpisu na liście. Prawdziwy błąd to 404 lub 410. Kod 200 przy stronie błędu to soft-404.
Otwórz swoją sitemapę, np. twojadomena.pl/sitemap.xml. Powinna wyglądać jak XML: surowa lista adresów ze znacznikami, a nie ostylowana strona. Jeśli zamiast tego widzisz stronę główną albo ozdobny błąd, sitemapa nie istnieje, choć „odpowiada”.
Powtórz to samo dla llms.txt, jeśli gdzieś deklarujesz jego obecność. To zwykły plik tekstowy, nie strona HTML.

Jak to naprawić?

Zasada jest jedna: serwer ma mówić prawdę. Nieistniejący adres dostaje kod 404. Strona usunięta celowo i na stałe może dostać 410, czyli „było, ale nie wróci”. Strona błędu może być ładna i pomocna, z wyszukiwarką i linkami do popularnych działów, byle szła w parze z uczciwym kodem.

Przekierowanie 301 zostaw dla sytuacji, w których treść naprawdę się przeniosła: stary adres produktu prowadzi do nowego adresu tego samego produktu, stara kategoria do nowej kategorii. Przekierowanie na stronę główną z adresu, który nigdy nie istniał, nie ratuje niczego. Myli użytkowników, roboty i Twoje własne narzędzia.

W większości frameworków i CMS-ów to drobna zmiana: ustawienie właściwego kodu odpowiedzi na stronie błędu albo wyłączenie globalnej reguły przekierowań. Po poprawce powtórz test z poprzedniej sekcji i zaglądaj do raportu indeksowania w Google Search Console. Wpisy „miękkie 404” powinny z czasem znikać.

Porządek w kodach odpowiedzi sam z siebie nie wprowadzi Cię do odpowiedzi AI, ale usuwa warstwę kłamstwa między Twoją stroną a wszystkim, co ją czyta. Audyty zaczynają pokazywać prawdziwe braki, Google przestaje przepalać czas robota na wydmuszki, a boty AI mają szansę trafić na treść zamiast na atrapy. Dwie minuty testu i jedna poprawka w konfiguracji potrafią odkłamać cały obraz.