Kiedy kod 410 jest lepszy niż 404 (i jak go naprawdę wdrożyć)

Kod 410 to nie jest po prostu bardziej rozgniewane 404

W naszym artykule 301 czy 404 kod 410 pojawiał się w jednej linii listy decyzyjnej, jako mocniejsza alternatywa dla 404 przy treści, która zniknęła na dobre. Zasługuje na własne wyjaśnienie, ponieważ spośród czterech kodów statusu (301, 302, 404, 410) tylko ten wymaga pewności, a nie tylko stwierdzenia faktu. Kod 404 jest prawie zawsze automatyczną odpowiedzią domyślną serwera lub aplikacji, gdy coś nie odpowiada: nikt nie „wybiera” go aktywnie, linia po linii, po prostu pojawia się, gdy nic nie pasuje. Kod 410 natomiast zawsze musi być zadeklarowany świadomie, regułą, którą ktoś celowo ustawił podczas budowy witryny, ponieważ przekazuje coś, czego serwer nie może wiedzieć sam: nie tylko „na razie nic tu nie ma” (to mówi już 404), ale „nigdy już nic tu nie będzie i wiemy to na pewno”.

Ta różnica ma praktyczny wpływ na zachowanie wyszukiwarek: robot, który natrafi na 404, pozostawia otwartą możliwość, że adres wróci (chwilowy błąd, niedokończone wdrożenie, produkt, który wraca do sprzedaży), i zwykle przez pewien czas nadal ponownie sprawdza ten adres, zanim naprawdę usunie go z indeksu. Kod 410 to świadomy sygnał trwałego usunięcia, a sam Google kilkakrotnie wskazywał, że zwykle szybciej go przetwarza, usuwając adres z wyników, choć żaden z tych dwóch przypadków nie jest natychmiastowy. Różnica nie polega więc na „powadze błędu”, lecz na tym, „jak bardzo mają Państwo pewność, że pod tym adresem już nigdy nic nie będzie”.

Kiedy kod 410 naprawdę wyrządza szkody

Właśnie dlatego, że 410 komunikuje pewność, użycie go, gdy tej pewności nie ma, jest najkosztowniejszym błędem spośród czterech kodów. Dwa typowe przypadki, w których obraca się on przeciwko Państwu:

• Treść sezonowa lub czasowo wstrzymana. Produkt wycofany na dobre to dobry kandydat na 410. Produkt, którego brakuje na magazynie i który wróci za dwa miesiące, już nie: kod 410 zniechęca wyszukiwarkę do ponownego sprawdzania tego adresu właśnie wtedy, gdy za kilka tygodni chcieliby Państwo, żeby to zrobiła. W takim przypadku właściwym narzędziem pozostaje 404 (albo, jeśli to naprawdę tymczasowe i znana jest data, 302 do strony informacyjnej), a nie 410.
• Zbyt szerokie reguły. Kod 410 ustawiony na wzorzec ogólny lub na warunek dotyczący query string trzeba pisać z taką samą starannością jak regułę zapory sieciowej: zbyt ogólny warunek może wywołać 410 na prawidłowych adresach URL, które pasują tylko do części wzorca, trwale zamykając drzwi przed prawdziwym ruchem zamiast przed jedynym ruchem, który chciano zatrzymać. W przeciwieństwie do 301, gdzie błąd w adresie docelowym i tak wysyła odwiedzającego gdzieś, błędne 410 po prostu zamyka drzwi, a jeśli nie były to właściwe drzwi, zauważa to tylko ten, kto w nie uderza.

Jak naprawdę wygląda dobrze wdrożone 410

W naszym własnym module przekierowań kod 410 wybiera się w menu typu reguły, obok 301 i 302, a dla tego typu reguły adres docelowy nie jest potrzebny i jest ignorowany: nie ma „dokąd wysłać” odwiedzającego, jest tylko „nic tu już nie ma, definitywnie”. Technicznie interesujące jest miejsce, w którym generowana jest odpowiedź: musi ona wyjść jak najwcześniej w cyklu życia żądania, zanim aplikacja zbuduje motyw, pobierze produkt z bazy danych lub przygotuje renderowanie strony, w przeciwnym razie i tak zmarnowano całą pracę, której 410 ma oszczędzić. Poprawna odpowiedź składa się z trzech elementów, o których często zapomina się, gdy 410 pisze się ręcznie w pliku konfiguracyjnym:

• Prawdziwy status HTTP 410 Gone, a nie 200 z tekstem „produkt niedostępny” (ten sam błąd soft 404, omówiony już w poprzednim artykule, który stosuje się tu bez zmian).
• Nagłówek X-Robots-Tag: noindex, który wzmacnia sygnał dla robotów odczytujących ten nagłówek niezależnie od kodu statusu.
• Minimalna treść strony, przetłumaczona na język odwiedzającego, zamiast białej strony: kod 410 pozostaje odpowiedzią, na którą prawdziwa osoba może trafić, klikając stary link, a nie tylko czymś, co widzi robot.

Rzeczywisty przypadek: robot krążący w pętli po zatrutym parametrze

W naszym własnym sklepie robot (robot Meta) krążył w pętli po adresach URL w postaci /login?back=..., które w wartości parametru nadal zawierały dawną domenę sklepu sprzed zmiany adresu: ponad 36 000 żądań w ciągu jednej nocy, ponad 90% całego ruchu odbieranego przez serwer, a każde z nich obsługiwane odpowiedzią 200 i pełnym renderowaniem strony, czyli takim samym kosztem procesora jak prawdziwe żądanie. Problemem nie był sam adres URL (/login to w pełni prawidłowy adres), lecz jego połączenie z tą konkretną wartością parametru, której żaden prawdziwy odwiedzający nigdy by nie wygenerował.

Sprawdziliśmy, że jedna reguła 410 z warunkiem na query string rozwiązuje dokładnie ten przypadek, bez dotykania serwera WWW i bez dotykania prawidłowego ruchu: reguła uruchamia się tylko wtedy, gdy parametr back zawiera dawną domenę, a nie przy każdym żądaniu do /login. Wyniki testów na trzech różnych wersjach PrestaShop:

• /login?back=http%3A%2F%2Fold-domain.example%2Fx zwraca 410
• /login?back=https%3A%2F%2Fold-domain.example%2Flogin zwraca 410
• /login?back=/my-account (prawidłowy ruch) nadal zwraca 200, bez zmian

To najjaśniejszy przykład tego, co odróżnia dobrze zbudowane 410 od 410 zrobionego w pośpiechu: reguła nie mówi „zablokuj /login”, mówi „zablokuj wyłącznie dokładną kombinację, o której wiemy, że sprawia problem”, i sprawdza ten warunek, zanim zbuduje choćby jedną linię strony.

W skrócie

Kod 404 jest prawie zawsze wartością domyślną, 410 jest zawsze świadomym wyborem i należy go używać tylko wtedy, gdy istnieje prawdziwa pewność, że adres URL nigdy nie wróci. Dobrze wykonany, to prawdziwy status HTTP generowany jak najwcześniej w cyklu życia żądania, z odpowiednim nagłówkiem robots, bez marnowania pracy, której ma zapobiegać; wykonany zbyt szeroką regułą, może na stałe zamknąć drzwi przed ruchem, który był prawidłowy. Dla osób, które chcą zarządzać tymi regułami bez ingerencji w konfigurację serwera, opcją jest moduł taki jak cll_seoredirect, ale kryterium decydowania, kiedy 410 jest właściwym wyborem, pozostaje takie samo niezależnie od narzędzia.

Instrukcja instalacji i konfiguracji modułu

Przekierowania SEO - menedżer 301/302/404Zarządzanie przekierowaniami 301/302 (zwykłymi, z symbolami wieloznacznymi lub bezpiecznym regex), m…49,99 €Zobacz produkt