Usunięta podstrona nadal zwraca kod 200. Jak wykryć i naprawić taki błąd?

Podstrona została usunięta, oferta wycofana, wpis usunięty z serwisu, a mimo to pod starym adresem nadal coś się otwiera: pusty szablon, napis „Nie znaleziono” albo strona główna. Dla człowieka sprawa wygląda na zamkniętą. Dla robota Google już nie, bo serwer wciąż odpowiada kodem 200, czyli informacją „wszystko w porządku, oto treść”. Google nazywa taką sytuację pozornym błędem 404.

Ten tekst jest instrukcją dla właścicieli firm, osób opiekujących się stroną i redaktorów, którzy widzą w Google Search Console status „Pozorny błąd 404” albo podejrzewają, że usunięte podstrony wcale nie zniknęły z serwisu. Nie wymaga wiedzy programistycznej, choć w kilku miejscach potrzebny będzie dostęp do plików na serwerze albo pomoc osoby, która taki dostęp posiada.

Po lekturze czytelnik będzie umiał sprawdzić kod odpowiedzi dowolnego adresu, znaleźć wszystkie błędne adresy w serwisie, ustalić przyczynę i dobrać właściwą naprawę: kod 404, kod 410 albo przekierowanie 301. Będzie też wiedział, jak potwierdzić w Google, że poprawka działa.

Czym jest pozorny błąd 404 i dlaczego szkodzi stronie?

Każda odpowiedź serwera zaczyna się od trzycyfrowego kodu stanu. Kod 200 oznacza, że strona istnieje i została poprawnie wysłana. Kod 404 oznacza, że pod danym adresem niczego nie ma. Kod 410 mówi, że zasób został usunięty na stałe, a kod 301, że został trwale przeniesiony pod inny adres.

Pozorny błąd 404 powstaje wtedy, gdy treść strony mówi jedno, a kod drugie. Odwiedzający widzi komunikat o braku strony albo pusty układ, natomiast serwer przesyła kod 200. Dokumentacja Google opisuje to wprost: jeśli serwer odpowiada kodem z grupy 2xx, a treść sugeruje błąd, na przykład jest to pusta strona albo komunikat o błędzie, Search Console pokazuje pozorny błąd 404.

Szkoda jest podwójna. Po pierwsze, robot Google wraca pod adresy, które według kodu nadal istnieją, zamiast poświęcić ten czas na nowe i ważne podstrony. W małym serwisie nie ma to dużego znaczenia, ale w sklepie z tysiącami wycofanych produktów już tak. Po drugie, nieistniejące podstrony mogą długo pozostawać w wynikach wyszukiwania, a klient, który w nie kliknie, trafia na pustą stronę i wraca do wyników.

Jest też trzeci, mniej oczywisty skutek. Dopóki serwer odpowiada kodem 200 na każdy adres, właściciel serwisu nie widzi prawdziwych błędów. Literówka w linku, uszkodzony odnośnik w menu albo błędny adres w kampanii reklamowej nie pojawią się w żadnym raporcie jako brakująca strona, bo formalnie żadnej strony nie brakuje.

Po czym rozpoznać problem i jak sprawdzić kod odpowiedzi adresu?

Samo oglądanie strony w przeglądarce niczego nie rozstrzyga. Dobrze przygotowana strona błędu z kodem 404 i wadliwa strona z kodem 200 mogą wyglądać identycznie. O tym, co otrzymuje robot, decyduje wyłącznie kod stanu, a ten jest dla odwiedzającego niewidoczny.

Są jednak sygnały, które powinny skłonić do sprawdzenia. Należą do nich:

• status „Pozorny błąd 404” w raporcie „Indeksowanie stron” w Google Search Console,
• usunięte podstrony, które po wielu tygodniach nadal widnieją w wynikach wyszukiwania,
• wymyślony, bezsensowny adres w domenie, który zamiast strony błędu otwiera stronę główną albo pusty szablon,
• brak jakichkolwiek adresów ze statusem „Nie znaleziono (404)” w Search Console, mimo że z serwisu regularnie znikają treści.

Sprawdzenie w przeglądarce

Najprostszy sposób nie wymaga instalowania czegokolwiek. Wystarczy przeglądarka Chrome albo inna z narzędziami dla programistów.

1. Należy otworzyć nową kartę i nacisnąć klawisz F12, co uruchamia narzędzia dla programistów.
2. W górnym pasku narzędzi trzeba przejść do karty „Sieć” (w wersji angielskiej „Network”).
3. W pasku adresu wpisuje się adres usuniętej podstrony i zatwierdza klawiszem Enter.
4. Na liście żądań pierwszy wiersz od góry dotyczy samego dokumentu. W kolumnie ze stanem (w wersji angielskiej „Status”) widać kod odpowiedzi.
5. Jeśli w pierwszym wierszu widnieje 301 lub 302, a w następnym 200, serwer przekierował adres w inne miejsce. Trzeba wtedy zanotować oba kody i adres docelowy.

Prawidłowy wynik dla usuniętej podstrony to 404 albo 410. Wynik 200 oznacza opisywany tu problem. Wynik 301 prowadzący do strony głównej również wymaga uwagi, o czym niżej.

Sprawdzenie jednym poleceniem

Osoby, które korzystają z terminala (wiersz poleceń w systemie Windows, Terminal w systemach macOS i Linux), mogą użyć programu curl. Polecenie wypisuje sam kod odpowiedzi, bez treści strony:

curl -s -o /dev/null -w "%{http_code}\n" https://przyklad.pl/usunieta-podstrona/

W systemie Windows w miejscu /dev/null wpisuje się NUL. Po dodaniu parametru -L program podąża za przekierowaniami i pokazuje kod ostatniej strony w łańcuchu. Radzę wykonać polecenie w obu wariantach, bo dopiero porównanie wyników pokazuje, czy adres odpowiada bezpośrednio, czy odsyła gdzie indziej.

Próba z adresem, który nigdy nie istniał

Ten test zajmuje minutę, a mówi bardzo dużo. Do adresu domeny dopisuje się przypadkowy ciąg znaków, na przykład przyklad.pl/test-strony-ktorej-nie-ma-83kd/, i sprawdza kod odpowiedzi jednym z dwóch opisanych sposobów. Jeśli serwer zwraca 200, problem nie dotyczy jednej podstrony, tylko całego serwisu: każdy nieistniejący adres jest traktowany jak istniejący.

Jak znaleźć wszystkie takie adresy w Google Search Console?

Ręczne sprawdzanie ma sens przy kilku adresach. Pełną listę podstron, które Google uznał za pozorne błędy 404, podaje Search Console. Narzędzie nie wymaga opłat, ale witryna musi być w nim wcześniej zweryfikowana.

1. Po zalogowaniu do Google Search Console należy wskazać właściwą usługę (witrynę) na liście w lewym górnym rogu.
2. W menu bocznym, w grupie „Indeksowanie”, trzeba kliknąć pozycję „Strony”. Otwiera się raport „Indeksowanie stron”.
3. Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Należy odszukać w niej wiersz „Pozorny błąd 404” i go kliknąć.
4. Otwiera się strona ze szczegółami problemu i listą przykładowych adresów. Listę można pobrać przyciskiem eksportu w prawym górnym rogu raportu.
5. Kliknięcie dowolnego adresu na liście pozwala przejść do narzędzia do sprawdzania adresów URL i obejrzeć, co dokładnie zobaczył robot.

Tabela przykładów jest ograniczona do 1000 wierszy i według pomocy Google nie musi zawierać wszystkich adresów z danym błędem. W dużym serwisie należy więc traktować ją jako próbkę, na podstawie której ustala się wzorzec, a nie jako pełny spis.

Jeśli wiersza „Pozorny błąd 404” w tabeli nie ma, nie oznacza to jeszcze, że problem nie występuje. Google przypisuje ten status na podstawie oceny treści i nie zawsze rozpoznaje pustą stronę jako błąd. Dlatego raport należy uzupełnić próbą z nieistniejącym adresem opisaną wyżej. Więcej o samym odczytywaniu stanu podstron opisałem w tekście o tym, jak sprawdzić, czy Google zaindeksował stronę.

Jak obejrzeć stronę oczami robota?

W narzędziu do sprawdzania adresów URL należy kliknąć „Sprawdź URL wersji opublikowanej”, a po zakończeniu testu „Wyświetl przetestowaną stronę”. Narzędzie pokazuje wtedy zrzut ekranu z tym, jak Google wyrenderował stronę, pobrany kod HTML oraz szczegóły odpowiedzi serwera. Jeśli na zrzucie widać pusty układ albo komunikat o braku treści, wiadomo już, dlaczego adres trafił do tej grupy.

Liczba takich testów na dobę jest ograniczona dla każdej usługi, dlatego przy dużej liście adresów sprawdza się po jednym przykładzie z każdego rodzaju podstron: jeden produkt, jedną kategorię, jeden wpis.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: sprawdzę kody odpowiedzi usuniętych podstron, ustalę, skąd bierze się kod 200, i doprowadzę do tego, żeby serwis odpowiadał prawidłowo.

Skąd bierze się kod 200 na nieistniejącej podstronie?

Przyczyn jest kilka i każda wymaga innej naprawy. Zanim cokolwiek zostanie zmienione, trzeba ustalić, która z nich zachodzi. Poniżej opisuję te, z którymi w praktyce spotykam się najczęściej.

Strona błędu ustawiona jako pełny adres

Na serwerach Apache własną stronę błędu wskazuje się dyrektywą ErrorDocument w pliku .htaccess. Jeśli jako cel podano pełny adres z nazwą domeny, serwer nie wyświetla strony błędu w miejscu brakującej podstrony, tylko odsyła przeglądarkę pod ten adres. Dokumentacja Apache zaznacza, że w takim układzie odbiorca nie otrzymuje pierwotnego kodu błędu. W efekcie robot dostaje przekierowanie, a po nim zwykłą stronę z kodem 200.

Reguła, która każde żądanie kieruje do jednego pliku

Wiele systemów działa tak, że serwer przekazuje wszystkie adresy do jednego pliku startowego, a dopiero aplikacja decyduje, co wyświetlić. To poprawne rozwiązanie pod warunkiem, że aplikacja sama wysyła kod 404, gdy nie znajdzie treści. Jeśli tego nie robi, każdy adres kończy się kodem 200. Podobny skutek ma na serwerze nginx zapis error_page 404 =200 /404.html;, który wprost zamienia kod błędu na 200.

Przekierowanie wszystkich brakujących adresów na stronę główną

Część wtyczek i szablonów oferuje opcję odsyłania każdego błędu 404 na stronę główną. Wygląda to na wygodne rozwiązanie, bo odwiedzający nie trafia na komunikat o błędzie. Google w zaleceniach dotyczących przenoszenia witryn ostrzega jednak, że kierowanie wielu starych adresów w jedno niezwiązane miejsce, takie jak strona główna, może zostać potraktowane jako pozorny błąd 404.

Treść usunięta, a szablon pozostał

To typowa sytuacja w sklepach i katalogach. Produkt został wycofany, ale system nadal generuje jego kartę: z nagłówkiem, stopką i napisem o braku towaru. Tak samo zachowują się puste kategorie, strony tagów bez wpisów, wyniki wewnętrznej wyszukiwarki bez trafień oraz filtry, które nie zwracają żadnej pozycji. Serwer wysyła kod 200, bo szablon istnieje, a Google ocenia, że treści nie ma.

Strona zbudowana w całości w JavaScripcie

W aplikacjach jednostronicowych serwer zawsze wysyła ten sam plik z kodem 200, a o tym, co się wyświetli, decyduje skrypt w przeglądarce. Komunikat o braku strony pojawia się więc dopiero po uruchomieniu skryptu, kiedy kodu stanu nie da się już zmienić.

Pamięć podręczna, która zapamiętała starą odpowiedź

Wtyczka pamięci podręcznej, serwer pośredniczący albo sieć CDN mogą przechowywać kopię podstrony z czasu, gdy jeszcze istniała. Treść w systemie została usunięta, lecz odwiedzający i roboty nadal dostają zapisaną kopię z kodem 200. Ta przyczyna zwykle ustępuje sama po wygaśnięciu kopii, ale bywa, że trwa to długo.

Jak ustalić, która przyczyna występuje w danym serwisie?

Rozpoznanie opiera się na trzech prostych obserwacjach. Wykonanie ich po kolei pozwala niemal zawsze wskazać źródło problemu bez zaglądania do kodu.

1. Sprawdzenie kodu dla adresu, który nigdy nie istniał. Kod 200 wskazuje na ustawienia serwera lub aplikacji obejmujące cały serwis. Kod 404 oznacza, że mechanizm błędów działa, a problem dotyczy tylko określonego rodzaju podstron.
2. Sprawdzenie, czy po drodze występuje przekierowanie. Kod 301 lub 302 przed kodem 200 wskazuje na dyrektywę ErrorDocument z pełnym adresem albo na wtyczkę odsyłającą błędy na stronę główną.
3. Obejrzenie źródła strony (skrót Ctrl+U w przeglądarce). Jeśli w źródle prawie nie ma tekstu, a są tylko odwołania do skryptów, serwis jest aplikacją opartą na JavaScripcie.
4. Porównanie odpowiedzi z pominięciem pamięci podręcznej. Do adresu dopisuje się dowolny parametr, na przykład ?test=1. Jeśli adres z parametrem zwraca 404, a bez parametru 200, winna jest zapisana kopia.
5. Przejrzenie listy z Search Console pod kątem wzorca. Gdy niemal wszystkie adresy to produkty, kategorie albo wyniki wyszukiwania, przyczyną jest szablon wyświetlany mimo braku treści.

Wynik warto zapisać w prostej notatce: rodzaj podstron, kod odpowiedzi, ewentualny adres docelowy przekierowania. Taka notatka bardzo skraca rozmowę z administratorem serwera albo twórcą strony.

Kod 404, kod 410 czy przekierowanie 301: co wybrać dla usuniętej podstrony?

Naprawa pozornego błędu 404 zawsze sprowadza się do jednej z trzech decyzji. Wybór zależy od tego, co stało się z treścią, a nie od tego, co jest wygodniejsze technicznie.

Jeśli treść została usunięta i nie ma następcy, adres powinien zwracać kod 404 albo 410. Pomoc Google stwierdza, że odpowiedzi 404 nie muszą być problemem, gdy strona została usunięta bez zamiennika. Oba kody Google traktuje bardzo podobnie, a różnice i sytuacje, w których lepiej użyć drugiego z nich, omawiam w tekście o tym, kiedy stosować kod 410 zamiast 404.

Jeśli treść została przeniesiona albo ma bliski odpowiednik, właściwe jest przekierowanie 301 pod nowy adres. Bliski odpowiednik to nowsza wersja tego samego produktu, zaktualizowany wpis na ten sam temat albo usługa, która zastąpiła poprzednią. Strona główna ani ogólna kategoria takim odpowiednikiem nie są.

Jeśli podstrona powinna istnieć, a jedynie wygląda na pustą, nie należy jej usuwać, tylko uzupełnić. Google zaleca wtedy wzbogacenie strony o dodatkowe informacje, tak aby było jasne, że nie chodzi o błąd. Dotyczy to na przykład karty produktu chwilowo niedostępnego albo kategorii, do której wkrótce trafi asortyment.

Jak naprawić błąd w zależności od przyczyny?

Przed każdą zmianą w plikach serwera należy wykonać kopię pliku, który będzie edytowany, i zapisać ją na dysku. Błąd w pliku .htaccess albo w konfiguracji nginx potrafi wyłączyć całą witrynę, a przywrócenie kopii zajmuje kilka sekund.

Serwer Apache i plik .htaccess

W pliku .htaccess w głównym katalogu witryny należy odszukać wiersz zaczynający się od ErrorDocument 404. Jeśli po nim następuje pełny adres z nazwą domeny, trzeba zastąpić go ścieżką lokalną, zaczynającą się od ukośnika:

ErrorDocument 404 /404.html

Przy takim zapisie serwer wyświetla wskazany plik w miejscu brakującej podstrony i zachowuje kod 404. Plik strony błędu musi istnieć w podanym miejscu. Budowę samej strony błędu, jej treść i sposób sprawdzenia opisałem osobno w tekście o tym, jak ustawić własną stronę błędu 404.

Serwer nginx

W konfiguracji witryny należy odszukać dyrektywę error_page. Zapis ze znakiem równości i liczbą 200 trzeba zmienić na wersję bez zmiany kodu:

error_page 404 /404.html;

Po zmianie konieczne jest ponowne wczytanie konfiguracji serwera. Na hostingu współdzielonym właściciel strony zwykle nie ma do niej dostępu, dlatego zmianę zgłasza się pomocy technicznej. Zgłoszenie może brzmieć: „Proszę o zmianę konfiguracji tak, aby nieistniejące adresy w domenie przyklad.pl zwracały kod stanu 404 zamiast 200”.

WordPress

WordPress w standardowej konfiguracji sam wysyła kod 404 dla adresów, których nie rozpoznaje, i wyświetla przy tym szablon strony błędu z motywu. Jeśli serwis na WordPressie zwraca 200, przyczyna leży najczęściej w dodatkach. Naprawa przebiega w następującej kolejności:

1. W panelu, w sekcji „Wtyczki”, należy przejrzeć listę pod kątem dodatków do przekierowań i obsługi błędów 404. W ich ustawieniach trzeba wyłączyć opcję kierowania wszystkich błędów 404 na stronę główną.
2. W ustawieniach motywu lub kreatora stron należy sprawdzić, czy jako strona błędu nie została wskazana zwykła podstrona otwierana przez przekierowanie.
3. W pliku .htaccess trzeba sprawdzić, czy nie ma w nim własnych wierszy ErrorDocument z pełnym adresem, dopisanych poza blokiem oznaczonym jako WordPress.
4. Na koniec należy wyczyścić pamięć podręczną we wtyczce, która za nią odpowiada, i ponownie sprawdzić kod odpowiedzi.

Jeśli po wyłączeniu opcji w dodatkach kod nadal wynosi 200, radzę na chwilę wyłączać wtyczki pojedynczo, najlepiej na kopii testowej strony, i po każdej próbie sprawdzać adres, który nigdy nie istniał. Ta metoda jest żmudna, ale pewna.

Sklepy i katalogi z wycofaną ofertą

W sklepie o kodzie odpowiedzi decyduje to, co system robi z produktem. Produkt ukryty lub oznaczony jako niedostępny zwykle pozostaje pod adresem z kodem 200. Produkt przeniesiony do kosza albo trwale usunięty powinien zwracać 404. Jeśli towar nie wróci do sprzedaży, należy go usunąć lub przekierować na następcę, a nie zostawiać pustej karty.

Wyniki wewnętrznej wyszukiwarki i kombinacje filtrów bez trafień najlepiej wyłączyć z indeksowania znacznikiem noindex albo ustawić tak, by przy braku wyników aplikacja wysyłała kod 404. To zmiana po stronie oprogramowania sklepu, dlatego zwykle wykonuje ją twórca strony.

Aplikacje oparte na JavaScripcie

Dokumentacja Google dla takich serwisów podaje dwie metody. Pierwsza polega na tym, że po stwierdzeniu braku treści skrypt przekierowuje pod adres, dla którego serwer wysyła prawdziwy kod 404, na przykład /not-found. Druga polega na dodaniu skryptem do strony błędu znacznika noindex:

<meta name="robots" content="noindex">

Obie metody wymagają zmian w kodzie aplikacji. Trwalszym rozwiązaniem jest generowanie stron po stronie serwera, bo wtedy serwer zna stan treści i może od razu wysłać właściwy kod.

Pamięć podręczna i sieć CDN

Po usunięciu treści należy wyczyścić kopię danego adresu we wtyczce pamięci podręcznej oraz w panelu sieci CDN, jeśli serwis z niej korzysta. Warto też sprawdzić w ustawieniach, czy pamięć podręczna nie zapisuje stron błędów na długi czas, bo wtedy problem działa w drugą stronę: przywrócona podstrona przez wiele godzin zwraca 404.

Po czym poznać, że naprawa zadziałała?

Potwierdzenie ma dwa etapy. Pierwszy jest natychmiastowy i zależy wyłącznie od właściciela strony. Drugi wymaga cierpliwości, bo zależy od tempa, w jakim Google ponownie odwiedzi adresy.

1. Ponowne sprawdzenie kodu odpowiedzi usuniętej podstrony i adresu, który nigdy nie istniał. Oba powinny zwracać 404 lub 410 albo, w przypadku przeniesionej treści, 301 prowadzące prosto do nowego adresu z kodem 200.
2. Sprawdzenie, czy istniejące podstrony nadal zwracają 200. Trzeba wybrać stronę główną, jedną kategorię i jeden wpis lub produkt. To zabezpieczenie przed sytuacją, w której poprawka wyłączyła więcej, niż powinna.
3. W Search Console, w narzędziu do sprawdzania adresów URL, należy wkleić jeden z naprawionych adresów i kliknąć „Sprawdź URL wersji opublikowanej”. Narzędzie powinno wykazać, że strona jest niedostępna z powodu błędu 404 albo że adres przekierowuje.
4. W raporcie „Indeksowanie stron” trzeba otworzyć szczegóły problemu „Pozorny błąd 404” i kliknąć „Sprawdź poprawkę”.
5. Postęp widać w historii weryfikacji. Według pomocy Google weryfikacja trwa zazwyczaj do 2 tygodni, a w niektórych przypadkach znacznie dłużej.

Przycisku „Sprawdź poprawkę” nie należy klikać ponownie, dopóki trwająca weryfikacja się nie zakończy. Wcześniej trzeba też naprawić wszystkie wystąpienia problemu, bo jeden nadal błędny adres wystarczy, aby cała weryfikacja zakończyła się niepowodzeniem.

Po udanej naprawie adresy znikają z grupy „Pozorny błąd 404” i pojawiają się w grupie „Nie znaleziono (404)” albo wśród stron z przekierowaniem. To prawidłowy stan, a nie nowy kłopot. Google przez pewien czas będzie jeszcze wracał pod te adresy, ale coraz rzadziej.

Co zrobić, gdy Google nadal zgłasza pozorny błąd 404?

Jeśli weryfikacja zakończyła się stanem „Niepowodzenie”, należy kliknąć „Sprawdź szczegóły” i zobaczyć, które adresy nie przeszły kontroli. Najczęściej okazuje się, że poprawka objęła jeden rodzaj podstron, a pominęła inny, albo że robot dostał kopię z pamięci podręcznej.

Bywa też, że Google oznacza jako pozorny błąd 404 podstronę, która naprawdę istnieje i zwraca 200 zgodnie z zamiarem. Dzieje się tak, gdy treści jest bardzo mało, gdy główna część strony ładuje się dopiero skryptem, którego robot nie mógł pobrać, albo gdy na stronie pada wyraźny komunikat w rodzaju „brak wyników” czy „produkt niedostępny”. Wtedy rozwiązaniem nie jest kod 404, tylko uzupełnienie treści i sprawdzenie na zrzucie w narzędziu do sprawdzania adresów URL, czy robot widzi to samo co odwiedzający.

Gdy usunięta treść musi zniknąć z wyników szybko, na przykład zawierała nieaktualną cenę albo dane, których nie powinno już być w sieci, pomocne jest „Narzędzie do usuwania” w Search Console. Na karcie „Tymczasowe usunięcia” należy kliknąć „Nowa prośba” i podać adres. Blokada działa około 6 miesięcy i nie zastępuje naprawy: trwałe usunięcie wymaga, aby adres zwracał 404 lub 410. Odświeżanie wyników dla treści, które już się zmieniły, omówiłem w tekście o usuwaniu nieaktualnych treści z Google.

Jakich błędów unikać przy naprawie?

Większość kłopotów po naprawie wynika z pośpiechu albo z chęci załatwienia sprawy jednym ruchem. Poniższe pomyłki widuję najczęściej:

• Blokowanie usuniętych adresów w pliku robots.txt. Robot nie może wtedy pobrać strony, więc nie dowie się, że zwraca ona 404, a adres może pozostać w indeksie. Pomoc Google wprost odradza używanie tego pliku do usuwania stron.
• Przekierowanie wszystkich usuniętych adresów na stronę główną. Zamienia to jeden pozorny błąd 404 na drugi i dodatkowo dezorientuje odwiedzających.
• Ustawienie kodu 404 dla całego rodzaju podstron bez sprawdzenia, czy nie ma wśród nich stron z ruchem i wartościowymi linkami. Takie adresy zasługują na przekierowanie 301 do odpowiednika.
• Pozostawienie usuniętych adresów w mapie witryny i w linkach wewnętrznych. Mapa powinna zawierać wyłącznie adresy z kodem 200, a menu i treści nie powinny prowadzić do stron, których nie ma.
• Edycja plików serwera bez kopii zapasowej i bez sprawdzenia po zmianie, czy istniejące podstrony nadal działają.
• Ocenianie wyniku wyłącznie po wyglądzie strony w przeglądarce, bez sprawdzenia kodu odpowiedzi.

Uważam, że najważniejsza jest zasada zgodności: kod stanu ma mówić to samo co treść. Strona, która istnieje, odpowiada kodem 200. Strona, której nie ma, odpowiada kodem 404 lub 410. Strona przeniesiona odsyła kodem 301 dokładnie tam, gdzie znajduje się jej następca.

Najczęstsze pytania

Czy pozorny błąd 404 obniża pozycje całej witryny?

Google nie opisuje go jako kary. Skutek jest pośredni: robot traci czas na adresy bez treści, nieistniejące podstrony dłużej pozostają w wynikach, a właściciel nie widzi prawdziwych błędów w raportach. W małym serwisie szkoda jest niewielka, w dużym sklepie lub katalogu może wyraźnie spowolnić indeksowanie nowych podstron.

Czy zwykły błąd 404 jest czymś złym?

Nie. Pomoc Google stwierdza, że odpowiedzi 404 nie muszą być problematyczne, jeśli strona została usunięta bez zamiennika. Kod 404 jest prawidłową i oczekiwaną odpowiedzią dla adresu, pod którym niczego nie ma. Problemem są dopiero linki wewnętrzne prowadzące do takich adresów, bo te należy poprawić.

Ile trwa zniknięcie statusu z Search Console po naprawie?

Zależy to od tego, jak często Google odwiedza dane adresy. Weryfikacja uruchomiona przyciskiem „Sprawdź poprawkę” trwa zazwyczaj do 2 tygodni, lecz pomoc Google zastrzega, że może potrwać znacznie dłużej. Rzadko odwiedzane adresy w dużych serwisach bywają sprawdzane z dużym opóźnieniem.

Czy da się przyspieszyć ponowne sprawdzenie adresów przez Google?

W ograniczonym stopniu. Uruchomienie weryfikacji w raporcie informuje Google, że problem został naprawiony, i rozpoczyna ponowne sprawdzanie znanych adresów. Pojedyncze adresy można zgłosić w narzędziu do sprawdzania adresów URL, ale liczba takich próśb na dobę jest ograniczona. Pilne przypadki obsługuje tymczasowa blokada w „Narzędziu do usuwania”.

Czy przekierowanie 302 zamiast 301 rozwiązuje problem?

Nie jest to właściwy wybór dla treści przeniesionej na stałe. Kod 302 oznacza zmianę tymczasową, więc dla trwałego przeniesienia należy stosować 301. Niezależnie od rodzaju przekierowania cel musi być rzeczywistym odpowiednikiem usuniętej podstrony, w przeciwnym razie Google nadal może uznać adres za pozorny błąd 404.

Co zrobić z produktem, który jest chwilowo niedostępny?

Takiej karty nie należy usuwać ani oznaczać kodem 404. Powinna pozostać pod swoim adresem z kodem 200 i pełnym opisem, informacją o przewidywanej dostępności oraz odnośnikami do podobnych produktów. Im więcej rzeczywistej treści, tym mniejsze ryzyko, że Google uzna stronę za pustą.

Czy sam znacznik noindex wystarczy zamiast kodu 404?

Znacznik noindex usuwa stronę z wyników, ale nie informuje, że treści już nie ma, a robot nadal będzie ją odwiedzał. Dla podstron naprawdę usuniętych lepszy jest kod 404 lub 410. Znacznik noindex sprawdza się tam, gdzie strona ma działać dla odwiedzających, lecz nie powinna trafiać do wyszukiwarki, na przykład w wynikach wewnętrznego wyszukiwania.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Kody odpowiedzi, pliki serwera i raporty Search Console to dla wielu właścicieli firm obcy teren i trudno się temu dziwić. Mogę przejąć tę sprawę od początku do końca: sprawdzę, jak serwis odpowiada na usunięte i nieistniejące adresy, ustalę przyczynę, przygotuję listę podstron do przekierowania i do zamknięcia kodem 404 lub 410, wprowadzę poprawki albo przekażę je twórcy strony, a na koniec uruchomię weryfikację w Google i dopilnuję jej wyniku.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę po pierwszym sprawdzeniu i co proponuję zrobić dalej.