Pozorny błąd 404: dlaczego Google uznaje istniejącą stronę za pustą

Co oznacza pozorny błąd 404

Pozorny błąd 404, w dokumentacji technicznej nazywany też soft 404, to sytuacja, w której adres pokazuje użytkownikowi informację o braku strony albo nie zawiera prawie nic, a serwer zwraca przy tym kod 200 zamiast kodu 404. Tak opisuje to dokumentacja Google o rozwiązywaniu problemów z błędami indeksowania. Słowo "pozorny" bywa mylące: nie chodzi o to, że błąd jest nieprawdziwy, tylko o to, że serwer go nie zgłasza, choć treść na niego wskazuje.

Żeby zrozumieć ten status, trzeba rozdzielić dwie rzeczy, które zwykły użytkownik widzi jako jedną. Pierwsza to kod odpowiedzi HTTP, czyli krótka liczba, którą serwer wysyła przed treścią strony. Druga to sama treść: nagłówki, teksty, zdjęcia, lista produktów. Przeglądarka pokazuje tylko treść, robot wyszukiwarki czyta jedno i drugie. Gdy kod mówi "wszystko w porządku", a treść mówi "niczego tu nie ma", Google musi rozstrzygnąć, której informacji wierzyć.

Z dokumentu o wpływie kodów stanu HTTP na roboty Google wynika, że przy kodach z grupy 2xx treść trafia do dalszego przetwarzania, a jeśli sugeruje ona błąd, na przykład jest pustą stroną lub komunikatem o błędzie, Search Console pokazuje właśnie błąd soft 404. Ocena opiera się więc na tym, co robot zobaczył po pobraniu i wyrenderowaniu strony, a nie na deklaracji serwera. Szerzej o tym, jak roboty czytają poszczególne grupy odpowiedzi, piszemy we wpisie o kodach odpowiedzi HTTP a SEO.

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

Zwykły błąd 404 to uczciwa odpowiedź: serwer mówi, że pod danym adresem nic nie ma. W raporcie Search Console taki adres trafia do wiersza "Nie znaleziono (404)" i, jak podaje pomoc Google, nie wymaga naprawy, jeśli strona została usunięta bez zamiennika. Pozorny błąd 404 jest stanem niejednoznacznym. Serwer twierdzi, że strona istnieje, więc robot wraca do niej tak, jak do zwykłej podstrony, a właściciel serwisu często w ogóle nie wie, że coś jest nie tak, bo w przeglądarce adres się otwiera. O tym, kiedy prawdziwa odpowiedź 404 jest po prostu poprawna, piszemy osobno we wpisie o błędzie 404 a widoczności w Google.

Dlaczego ten status ma znaczenie dla widoczności

Adres oznaczony jako pozorny błąd 404 nie pojawia się w wynikach wyszukiwania, a jeśli dotyczy to strony, która powinna sprzedawać lub przyciągać klientów, firma traci widoczność bez żadnego wyraźnego sygnału ostrzegawczego. Dokumentacja Google wymienia dwa skutki: użytkownik dostaje kod powodzenia, a widzi komunikat o błędzie, natomiast sama strona zostaje wykluczona z wyszukiwarki.

Znaczenie statusu zależy od tego, jakich adresów dotyczy. Jeśli na liście są stare, dawno usunięte podstrony, które przypadkiem odpowiadają kodem 200, szkoda jest niewielka: i tak nie miały być w wynikach. Inaczej jest wtedy, gdy na listę trafiają działające kategorie sklepu, karty usług albo wpisy na blogu. Wtedy status oznacza, że robot nie zobaczył treści, którą widzą klienci, i trzeba ustalić dlaczego.

Drugi skutek dotyczy pracy robota. W dokumencie o optymalizacji budżetu indeksowania Google wskazuje, że strony z pozornym błędem 404 nadal są odwiedzane przez robota, co niepotrzebnie zużywa budżet, i zaleca wyszukiwanie ich w raporcie Indeksowanie stron. Ten sam dokument przypomina, że dla stron usuniętych na stałe należy zwracać kod 404 lub 410. W małym serwisie firmowym z kilkudziesięcioma podstronami nie ma to praktycznego znaczenia. W dużym sklepie, w którym filtry i wyszukiwarka tworzą tysiące pustych adresów, robot może tracić czas na strony bez wartości zamiast odwiedzać nowe produkty. Temat rozwijamy we wpisie o budżecie indeksowania.

Gdzie w Search Console znaleźć pozorny błąd 404

Status znajduje się w Search Console w raporcie Indeksowanie stron, w tabeli "Dlaczego strony nie są indeksowane", w wierszu o nazwie "Pozorny błąd 404". Raport otwiera się z menu po lewej stronie, z grupy poświęconej indeksowaniu. Wiersz pojawia się tylko wtedy, gdy Google przypisał ten status przynajmniej jednemu adresowi w serwisie.

Według pomocy Search Console dotyczącej raportu Indeksowanie stron kliknięcie wiersza w tabeli otwiera stronę szczegółów problemu. Znajduje się tam odnośnik "Więcej informacji" z opisem statusu oraz tabela przykładowych adresów URL. Kliknięcie wybranego adresu pokazuje jego szczegóły, a ikona lupy obok adresu otwiera go w narzędziu do sprawdzania adresów URL. W tabeli przyczyn warto zwrócić uwagę na kolumny "Przyczyna", "Źródło", "Weryfikacja" i "Stan". Wartość "Witryna" w kolumnie "Źródło" oznacza według pomocy Google, że problem leży po stronie serwisu i właściciel może go naprawić.

Pomoc Search Console opisuje sam status krótko: strona wyświetla komunikat o nieznalezieniu treści, ale serwer nie zwraca kodu 404. Zalecenie jest dwojakie. Dla stron, które nie istnieją, należy zwracać prawdziwy kod 404. W pozostałych przypadkach trzeba dodać do strony treść, która pokaże, że nie jest ona pusta. Przegląd wszystkich statusów z tej tabeli znajdą Państwo we wpisie o tym, dlaczego Google nie indeksuje strony.

Listę przykładowych adresów warto od razu pogrupować według wzorca. Adresy kategorii, adresy z parametrem wyszukiwania, adresy z filtrami, stare adresy po przebudowie serwisu i pojedyncze karty produktów mają zwykle różne przyczyny i różne sposoby naprawy. Bez takiego podziału łatwo naprawić jeden przypadek i uznać sprawę za zamkniętą, podczas gdy pozostałe grupy zostają bez zmian.

Opis pozornych błędów 404 wraz z trzema wariantami postępowania Google zamieścił w dokumentacji Centrum wyszukiwarki, na stronie poświęconej rozwiązywaniu problemów z błędami indeksowania. To dobry punkt odniesienia w rozmowie z programistą, bo zalecenia są tam zapisane wprost.

Typowe przyczyny pozornego błędu 404

Przyczyny dzielą się na dwie grupy: strony, które faktycznie nie mają nic do pokazania, ale serwer tego nie zgłasza, oraz strony z prawdziwą treścią, której robot z jakiegoś powodu nie zobaczył. Dokumentacja Google wymienia wśród źródeł problemu brak pliku po stronie serwera, zerwane połączenie z bazą danych, pustą stronę wyników wyszukiwania wewnętrznego oraz niezaładowany lub brakujący plik JavaScript. W praktyce firm przekłada się to na kilka powtarzalnych sytuacji.

Puste kategorie i listy bez pozycji

Kategoria sklepu, w której nie ma żadnego produktu, zwykle wyświetla nagłówek, menu, stopkę i jedno zdanie o braku produktów. Serwer zwraca kod 200, bo kategoria istnieje w systemie. Z punktu widzenia robota taka strona nie różni się jednak od komunikatu o błędzie. To samo dotyczy pustych archiwów tagów na blogu, stron autorów bez wpisów czy działu realizacji, do którego nikt jeszcze niczego nie dodał. Weźmy hipotetyczny sklep z Poznania, który przed sezonem zakłada dwadzieścia nowych kategorii i planuje uzupełnić je później. Do czasu dodania produktów każda z nich jest kandydatem do tego statusu. Jak postępować z takimi stronami w sklepie, omawiamy we wpisie o pustych i ubogich kategoriach.

Wyniki wyszukiwania i filtry bez produktów

Wewnętrzna wyszukiwarka serwisu potrafi wygenerować adres dla każdego wpisanego słowa, także takiego, dla którego nic nie znajduje. Podobnie działają filtry: połączenie rozmiaru, koloru i producenta, którego nie ma w ofercie, daje stronę z napisem o braku wyników i kodem 200. W dokumencie o zarządzaniu adresami nawigacji fasetowej Google zaleca, żeby przy kombinacji filtrów bez wyników zwracać kod 404 pod tym samym adresem, i wyraźnie odradza przekierowywanie na ogólną stronę błędu. Ta sama zasada dotyczy nieistniejących numerów stron w podziale listy na strony.

Przekierowanie usuniętych stron na stronę główną

To jedna z najczęstszych przyczyn, a zarazem najmniej oczywista, bo wynika z dobrych intencji. Po usunięciu produktów, wpisów albo po przebudowie serwisu ktoś ustawia regułę, która każdy nieistniejący adres odsyła na stronę główną, żeby "nie tracić ruchu". Użytkownik, który szukał konkretnego produktu, ląduje na stronie głównej bez wyjaśnienia, a Google widzi wiele różnych adresów prowadzących w jedno miejsce niezwiązane z ich dawną treścią. W dokumencie o przenoszeniu witryny Google odradza kierowanie wielu starych adresów do jednego nietrafnego miejsca, takiego jak strona główna, i zaznacza, że może to zostać potraktowane jako błąd soft 404. Wyjątkiem jest sytuacja, w której treści kilku stron rzeczywiście połączono w jedną nową stronę.

Strona błędu podawana z kodem 200

Niektóre systemy i szablony wyświetlają ładnie zaprojektowaną stronę "nie znaleziono", ale z kodem 200. Bywa też, że błąd bazy danych albo brak pliku kończy się pustym szablonem z samym menu i stopką. Dokumentacja Google podkreśla, że własna strona błędu jest dobrym pomysłem: powinna jasno informować o braku strony, wyglądać jak reszta serwisu i zawierać odnośniki do popularnych treści oraz strony głównej. Niezależnie od wyglądu serwer musi jednak zwracać dla niej kod 404.

Błędy renderowania i zablokowane zasoby

Ostatnia grupa dotyczy stron, które istnieją i mają treść, ale robot jej nie zobaczył. Renderowanie to etap, w którym Google uruchamia kod strony podobnie jak przeglądarka, żeby zobaczyć jej ostateczny wygląd. Według dokumentacji wyrenderowana strona może wyglądać na pustą lub błędną, jeśli nie udało się załadować obrazów, skryptów lub innych zasobów. Jako powody Google podaje blokadę w pliku robots.txt, zbyt dużą liczbę lub rozmiar zasobów, wolne wczytywanie oraz błędy serwera. Jeśli więc lista produktów doczytuje się skryptem, a plik tego skryptu jest zablokowany dla robotów albo serwer nie zdążył go podać, Google widzi szkielet strony bez zawartości. O tym, jak nie zablokować potrzebnych plików, piszemy we wpisie o pliku robots.txt.

Do tej grupy zaliczamy również strony z bardzo skąpą treścią. Dokumentacja mówi o stronach pustych lub prawie pustych, a pomoc Search Console zaleca dodanie treści, która pokaże, że strona nie jest pusta. Nie ma tu żadnego progu liczby znaków podanego przez Google. Z naszych obserwacji wynika, że ryzyko rośnie, gdy poza menu i stopką na stronie jest jedno zdanie, a zwłaszcza zdanie brzmiące jak komunikat o braku: "brak wyników", "produkt niedostępny", "nie znaleziono".

Jak ustalić przyczynę dla konkretnego adresu

Przyczynę ustala się, porównując trzy rzeczy: to, co widzi człowiek w przeglądarce, kod odpowiedzi serwera oraz to, co zobaczył robot Google po wyrenderowaniu strony. Do tego ostatniego służy narzędzie do sprawdzania adresów URL w Search Console, na które wskazuje zarówno dokumentacja, jak i pomoc Google.

Pierwsze pytanie brzmi: czy ta strona w ogóle powinna istnieć. Wystarczy otworzyć adres w przeglądarce. Jeśli pojawia się komunikat o braku strony, pusta lista albo strona główna zamiast oczekiwanej treści, sprawa jest prosta i dotyczy kodu odpowiedzi lub przekierowania. Jeśli strona wygląda poprawnie i ma pełną treść, trzeba sprawdzić, co dostał robot.

W tym celu wkleja się adres w pole na górze Search Console albo klika ikonę lupy przy adresie w raporcie. Według pomocy dotyczącej narzędzia do sprawdzania adresów URL wynik pokazuje najpierw dane z indeksu, czyli stan z ostatniej wizyty robota, z polami takimi jak "Ostatnie skanowanie" i "Adres kanoniczny wybrany przez Google". Przycisk testu wersji opublikowanej pobiera stronę w czasie rzeczywistym. Po zakończeniu testu przycisk wyświetlenia przetestowanej strony otwiera panel z kodem HTML zwróconym po renderowaniu, kartą "Zrzut ekranu" oraz kartą "Więcej informacji", na której są załadowane zasoby strony i dane wyjściowe konsoli JavaScript. W sekcji "Dostępność" znajduje się pole "Pobranie strony" z informacją, czy pobranie się powiodło.

Zrzut ekranu z testu jest najszybszą wskazówką. Jeśli widać na nim szablon bez listy produktów, biały ekran albo komunikat o błędzie, a w przeglądarce treść jest na miejscu, przyczyną jest renderowanie. Wtedy warto przejrzeć listę zasobów na karcie "Więcej informacji" i poszukać plików, których nie udało się wczytać, oraz komunikatów błędów w konsoli. Jeśli zrzut pokazuje pełną treść, a status w raporcie pochodzi sprzed kilku tygodni, problem mógł być chwilowy, na przykład serwer miał awarię bazy danych w dniu wizyty robota.

Pomoc Google zastrzega, że test wersji opublikowanej ma ograniczenia. Nie pokazuje przekierowań ani końcowego testowanego adresu, a pozytywny wynik nie gwarantuje obecności w wynikach wyszukiwania. Dlatego kod odpowiedzi i ewentualne przekierowanie warto dodatkowo sprawdzić w narzędziach dla programistów w przeglądarce, na karcie z ruchem sieciowym, gdzie przy każdym żądaniu widać kod stanu. Więcej o samym narzędziu piszemy we wpisie o sprawdzaniu adresu URL w Search Console.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jak usunąć pozorny błąd 404

Sposób naprawy zależy od odpowiedzi na jedno pytanie: czy pod tym adresem ma być treść. Dokumentacja Google opisuje trzy warianty: strona i jej treść już nie istnieją, strona została przeniesiona pod inny adres albo strona nadal istnieje i powinna być indeksowana.

Kody 404 i 410 informują wyszukiwarki, że strona nie istnieje i nie ma być indeksowana. Dla właściciela serwisu ważne jest, że jest to rozwiązanie poprawne, a nie porażka. Usunięty produkt bez następcy, wycofana usługa czy stary wpis bez wartości mogą po prostu zwracać błąd 404. Przekierowanie 301 ma sens tylko wtedy, gdy istnieje rzeczywisty odpowiednik: nowa wersja produktu, połączona kategoria, zaktualizowany wpis. Różnice między rodzajami przekierowań wyjaśniamy we wpisie o przekierowaniu 301 a 302.

Weźmy hipotetyczną kancelarię z Krakowa, która po przebudowie serwisu zrezygnowała z osobnych podstron dla trzydziestu wąskich usług i opisała je na pięciu szerszych stronach. Stare adresy usług, które mają odpowiednik na jednej z nowych stron, powinny prowadzić do niej przekierowaniem 301. Adresy usług, z których kancelaria całkowicie zrezygnowała, powinny zwracać kod 404 lub 410. Reguła "wszystko, czego nie ma, na stronę główną" jest wygodna dla wykonawcy, ale tworzy właśnie pozorne błędy 404. Przy większych przebudowach pomaga dobrze zaplanowana migracja z mapą starych i nowych adresów.

Sklep internetowy: kategorie, filtry i wycofane produkty

W sklepie pozorne błędy 404 powstają głównie tam, gdzie system sam tworzy adresy: w kategoriach, filtrach, wyszukiwarce i na kartach produktów, które zniknęły z oferty. Dla każdej z tych grup potrzebna jest osobna, stała reguła, a nie jednorazowa poprawka.

Pusta kategoria ma dwa rozsądne wyjścia. Jeśli produkty pojawią się wkrótce, warto wstrzymać jej publikację albo od razu dać jej treść: opis asortymentu, odnośniki do pokrewnych kategorii, informację o terminie dostawy. Jeśli kategoria nie będzie już używana, powinna zwracać kod 404 albo, gdy istnieje jej następczyni, prowadzić do niej przekierowaniem 301. Dla kombinacji filtrów bez wyników Google zaleca kod 404 pod tym samym adresem. O uporządkowaniu filtrów piszemy szerzej we wpisie o nawigacji fasetowej, a o stronach wyników we wpisie o wyszukiwarce w sklepie.

Karta produktu wycofanego na stałe podlega tym samym trzem wariantom co każda inna strona: kod 404 lub 410, gdy nie ma następcy, albo przekierowanie 301 na nowszy model, gdy taki istnieje. Inaczej jest z produktem chwilowo niedostępnym. Google nie podaje w otwartych przez nas dokumentach osobnej reguły dla takich kart, więc poniższa uwaga to obserwacja z praktyki agencji: karta, która zachowuje opis, zdjęcia i parametry, a jedynie informuje o braku towaru, jest pełnowartościową stroną. Ryzyko pojawia się wtedy, gdy system po wyczerpaniu zapasu usuwa z karty niemal wszystko i zostawia sam komunikat.

W WordPressie z WooCommerce, w PrestaShop czy Shopify zachowanie pustych kategorii i wycofanych produktów zależy od szablonu, ustawień i dodatków, dlatego nie da się podać jednej instrukcji dla wszystkich. Zawsze warto sprawdzić na żywym serwisie, jaki kod zwraca nieistniejący adres, pusta kategoria i usunięty produkt. Takie testy są stałym elementem prac, które prowadzimy w ramach pozycjonowania sklepów.

Strony oparte na JavaScript

W serwisach, w których treść składa przeglądarka za pomocą skryptów, pozorny błąd 404 powstaje szczególnie łatwo, bo serwer oddaje zawsze ten sam szkielet z kodem 200, a o tym, czy produkt istnieje, decyduje dopiero skrypt. Dotyczy to zwłaszcza aplikacji jednostronicowych, czyli serwisów, które wczytują się raz i podmieniają treść bez przeładowania strony.

W dokumencie o podstawach JavaScript a SEO Google zaleca używanie znaczących kodów stanu i podaje dwa sposoby uniknięcia pozornych błędów 404 w takich aplikacjach. Pierwszy to przekierowanie skryptem na adres, dla którego serwer zwraca kod 404. Drugi to dodanie skryptem znacznika meta robots z wartością noindex na stronie błędu. Poniższy przykład, wzorowany na dokumentacji, pokazuje pierwszy sposób.

fetch(`/api/products/${productId}`)
  .then(response => response.json())
  .then(product => {
    if (product.exists) {
      showProductDetails(product);
    } else {
      // produkt nie istnieje: przejście na adres,
      // dla którego serwer zwraca kod 404
      window.location.href = '/not-found';
    }
  });

Ten sam dokument wyjaśnia, że Google kieruje do renderowania strony z kodem 200, a strony z innym kodem, na przykład 404, mogą ten etap pominąć. Zwraca też uwagę na pułapkę związaną z noindex: jeśli znacznik jest w pierwotnym kodzie strony, Google może pominąć renderowanie, więc usuwanie go skryptem może nie zadziałać zgodnie z oczekiwaniami. Strona, która ma być indeksowana, nie powinna zawierać noindex w kodzie źródłowym. Więcej o tym znaczniku piszemy we wpisie o meta robots.

Sprawdzenie poprawki i typowe pomyłki

Po wprowadzeniu zmian zleca się weryfikację na stronie szczegółów problemu w raporcie Indeksowanie stron, przyciskiem służącym do sprawdzenia poprawki. Pomoc Search Console zaleca, żeby wcześniej naprawić wszystkie wystąpienia problemu, bo jeśli choć jedno pozostanie, weryfikacja zostanie przerwana. Zwykle trwa ona do 2 tygodni, ale może potrwać dłużej, a jej stan widać w kolumnie "Weryfikacja".

Adresy, które po naprawie zwracają kod 404, przejdą do wiersza "Nie znaleziono (404)", a przekierowane do wiersza "Strona zawiera przekierowanie". Nie są to nowe błędy, tylko poprawny opis stanu. Dla pojedynczych ważnych stron, którym przywrócono treść, można dodatkowo poprosić o zindeksowanie w narzędziu do sprawdzania adresów URL.

• Adresy z raportu pogrupowane według wzorca i przyczyny.
• Nieistniejący adres zwraca kod 404, także wtedy, gdy wyświetla własną stronę błędu.
• Brak reguły odsyłającej wszystkie usunięte adresy na stronę główną.
• Przekierowania 301 prowadzą wyłącznie do rzeczywistych odpowiedników.
• Zrzut ekranu z testu wersji opublikowanej pokazuje pełną treść ważnych stron.
• Pliki skryptów i stylów potrzebne do wyświetlenia treści nie są zablokowane w robots.txt.
• Usunięte adresy zniknęły z mapy witryny i z odnośników wewnętrznych.

Najczęstszą pomyłką jest próba pozbycia się statusu przez dopisanie kilku zdań do strony, która w rzeczywistości nie powinna istnieć. Drugą jest blokowanie takich adresów w pliku robots.txt: robot przestaje je odwiedzać, więc nie zobaczy też poprawnego kodu 404. Trzecią jest naprawianie pojedynczych adresów zamiast reguły, która je tworzy. Gdy przyczyna leży w szablonie, konfiguracji serwera lub renderowaniu, potrzebna jest praca programisty według jasnych wytycznych. Takie wytyczne przygotowujemy w ramach usługi SEO techniczne, a pełny przegląd serwisu obejmuje audyt SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl