301, 302, 404, 410 i 5xx: co oznaczają kody HTTP dla SEO?

301 służy do trwałego przeniesienia strony, 302 do przekierowania tymczasowego, 404 i 410 informują o braku zasobu, a 5xx sygnalizują problemy serwera. Nie każdy taki status wymaga naprawy. Najważniejsze jest to, czy odpowiedź serwera odpowiada rzeczywistemu stanowi strony i zamierzonej zmianie.

Usunięta oferta bez zamiennika może prawidłowo zwracać 404. Ten sam kod na działającej, ważnej stronie usługi wymaga interwencji. Z kolei przekierowanie 301 jest właściwe przy zmianie adresu, ale nie rozwiązuje automatycznie problemu każdej usuniętej podstrony.

Kod	Znaczenie	Kiedy działać?
301	Trwałe przeniesienie	Gdy prowadzi do złego celu, tworzy pętlę albo niepotrzebny łańcuch.
302	Przekierowanie tymczasowe	Gdy zmiana miała być trwała lub zakończył się jej tymczasowy charakter.
404	Nie znaleziono zasobu	Gdy strona powinna istnieć albo prowadzą do niej nieaktualne linki wewnętrzne.
410	Zasób usunięty, prawdopodobnie trwale	Gdy usunięcie było przypadkowe lub istnieje właściwy zamiennik.
5xx	Problem po stronie serwera	Gdy utrudnia dostęp, powtarza się lub obejmuje ważne adresy.

Kod HTTP to odpowiedź serwera, a nie ocena SEO

Kiedy przeglądarka lub robot wyszukiwarki żąda strony, serwer odpowiada statusem HTTP. Kod opisuje rezultat obsługi tego żądania. Nie jest oceną jakości treści ani informacją, jaką pozycję strona powinna zajmować w Google.

W codziennej pracy wystarczy rozróżniać kilka grup: 2xx oznacza pomyślną obsługę żądania, 3xx obejmuje przekierowania, 4xx dotyczy błędów związanych z żądaniem, a 5xx problemów serwera. Szczegółowe znaczenie kodów określa standard HTTP Semantics, RFC 9110.

Nawet odpowiedź 200 OK nie zapewnia indeksowania. Google osobno ocenia, czy pobraną treść uwzględnić w indeksie. Dlatego celem nie jest zamiana wszystkich statusów na 200, lecz uporządkowanie odpowiedzi zgodnie z tym, co faktycznie znajduje się pod adresem.

301 czy 302? Najpierw ustal, czy zmiana jest trwała

301: treść na stałe zmienia adres

Przekierowanie 301 stosuj, gdy stary adres zostaje zastąpiony nowym na stałe. Według dokumentacji Google dotyczącej przekierowań trwałe przekierowanie jest sygnałem, że adres docelowy powinien być kanoniczny, czyli preferowany do prezentowania w wynikach wyszukiwania.

Przykład hipotetyczny: firma zmienia adres istniejącej usługi, ale zachowuje jej zakres. Stara podstrona powinna kierować kodem 301 bezpośrednio do nowej wersji tej usługi, a nie do strony głównej czy ogólnej listy ofert.

Po zmianie warto poprawić także linki wewnętrzne oraz mapę witryny, aby wskazywały nowy adres. Przekierowanie obsłuży wtedy wejścia ze starych odnośników, zamiast pozostawać obowiązkowym etapem każdej nawigacji wewnątrz serwisu.

302: zmiana ma charakter przejściowy

Kod 302 informuje o przekierowaniu tymczasowym. Google nie traktuje go jako takiego samego sygnału trwałej zmiany adresu jak 301. Wybór powinien wynikać z planu dla treści, a nie z uproszczenia, że „301 jest zawsze lepsze dla SEO”.

Przykład hipotetyczny: treść ma przez krótki okres działać pod adresem zastępczym, a później wrócić. Można zastosować 302, ale trzeba określić warunek zakończenia przekierowania. Bez tego rozwiązanie tymczasowe łatwo pozostaje w konfiguracji na stałe.

Istnieją również kody 307 i 308, odpowiednio dla przekierowań tymczasowych i trwałych. W odróżnieniu od 301 i 302 jednoznacznie zachowują metodę żądania. Ma to szczególne znaczenie w aplikacjach i formularzach. Dobór kodu w takich przypadkach warto uzgodnić z programistą.

Sprawdź cel, nie tylko sam kod

Prawidłowy 301 prowadzący do nieistniejącej strony nadal pozostawia użytkownika z problemem. Podobnie działa pętla, w której adres A kieruje do B, a B z powrotem do A. Przy kontroli przekierowania sprawdź więc jego cel, końcową odpowiedź i treść, którą rzeczywiście otrzymuje odbiorca.

404 czy 410? Kiedy brak strony jest prawidłowy

404 oznacza, że serwer nie znalazł zasobu, ale sam kod nie rozstrzyga, czy brak jest trwały. 410 informuje, że zasób nie jest już dostępny i ten stan jest prawdopodobnie trwały. To różnica semantyczna, a nie obietnica lepszego efektu SEO.

W opisie wpływu statusów HTTP na roboty Google kody 404 i 410 są traktowane tak samo w omawianym mechanizmie indeksowania: takie adresy nie są indeksowane, a wcześniej zaindeksowane są z czasem usuwane. Nie ma podstaw, aby obiecywać szybsze usunięcie dzięki zastosowaniu 410.

Przykład hipotetyczny: firma definitywnie wycofuje dawną ofertę i nie ma podobnej usługi w zamian. Prawidłowe 404 lub 410 jest wtedy uzasadnione. Nie trzeba tworzyć przypadkowego przekierowania tylko po to, aby zniknęła pozycja z raportu błędów.

Inna sytuacja występuje, gdy aktywna strona oferty zaczyna zwracać 404 po aktualizacji CMS. Wtedy nie należy akceptować kodu jako poprawnego. Trzeba przywrócić stronę, poprawić konfigurację adresu albo odtworzyć brakującą treść.

Osobno potraktuj stronę, która ma istnieć dla użytkowników, ale nie powinna pojawiać się w wyszukiwarce. To inne zadanie niż informowanie o usunięciu zasobu. Różnicę opisuje poradnik o meta robots noindex i jego zastosowaniach.

Dlaczego nie przekierowywać każdego 404 na stronę główną?

Strona główna zwykle nie jest odpowiednikiem konkretnego poradnika, produktu czy usługi. Automatyczne kierowanie do niej wszystkich usuniętych adresów zaciera informację o tym, co stało się z treścią, i niekoniecznie pomaga użytkownikowi znaleźć odpowiedź.

Google zaleca 404 lub 410, gdy treść usunięto i nie ma podobnego zamiennika. Jeśli została przeniesiona albo istnieje wyraźny odpowiednik, właściwe jest trwałe przekierowanie. Taką zasadę opisuje dokumentacja rozwiązywania problemów ze skanowaniem.

Dla każdego istotnego adresu przejdź przez krótką listę decyzji:

1. Czy treść nadal powinna działać pod tym adresem? Jeśli tak, przywróć dostęp zamiast maskować problem przekierowaniem.
2. Czy treść przeniesiono na stałe? Zastosuj 301 do jej aktualnej wersji.
3. Czy istnieje rzeczywisty odpowiednik? Oceń, czy odpowiada na tę samą potrzebę użytkownika. Samo podobieństwo kategorii może nie wystarczyć.
4. Czy treść usunięto bez zamiennika? Pozostaw prawidłowe 404 lub 410.

Jeśli do usuniętej strony nadal prowadzą linki w menu, artykułach lub modułach polecanych treści, popraw je niezależnie od decyzji o statusie. Prawidłowe 404 nie jest powodem, aby świadomie wysyłać tam użytkowników z działających podstron.

Soft 404: komunikat o błędzie ze statusem 200

Wygląd strony nie przesądza o jej odpowiedzi HTTP. Możesz widzieć duży napis „Nie znaleziono strony”, podczas gdy serwer wysyła 200 OK. Google może rozpoznać taką odpowiedź jako soft 404, czyli stronę wyglądającą na brak zasobu mimo statusu sugerującego prawidłową treść.

Własny szablon błędu jest przydatny: może zawierać wyszukiwarkę, odnośnik do oferty i prostą informację o braku strony. Powinien jednak nadal zwracać 404. Samo zastąpienie pustego ekranu estetycznym komunikatem nie naprawia błędnego statusu.

Przykład hipotetyczny: po usunięciu produktu sklep pokazuje szablon „Produkt nie istnieje”, lecz zwraca 200. Jeśli produkt faktycznie usunięto i nie ma zamiennika, należy poprawić odpowiedź serwera. Jeśli nadal jest oferowany, trzeba przywrócić właściwą kartę produktu. Decyzja zależy od stanu oferty, nie od etykiety w raporcie.

500, 502, 503 i 504: kiedy problem przekazać administratorowi?

Błędy 5xx wymagają diagnozy dostępności, a nie seryjnego tworzenia przekierowań. Mogą wynikać z działania aplikacji, infrastruktury lub komunikacji między serwerami. Sam kod zawęża obszar poszukiwań, ale nie wskazuje jeszcze konkretnej przyczyny.

Kod	Co oznacza?	Co sprawdzić w pierwszej kolejności?
500	Wewnętrzny błąd serwera	Logi aplikacji i ostatnie zmiany w serwisie.
502	Nieprawidłowa odpowiedź serwera nadrzędnego	Komunikację między bramą lub proxy a aplikacją.
503	Czasowa niedostępność usługi	Przeciążenie, prace techniczne i dostępne zasoby.
504	Przekroczenie czasu oczekiwania na serwer nadrzędny	Czas działania aplikacji i jej zależności.

Google ogranicza tempo skanowania w odpowiedzi na błędy 5xx. Długotrwale niedostępne adresy mogą zostać usunięte z indeksu. Nie oznacza to, że pojedynczy incydent automatycznie powoduje utratę widoczności, ale powtarzających się awarii nie należy odkładać.

Przy krótkich pracach technicznych uniemożliwiających obsługę strony można zastosować 503. Opcjonalny nagłówek Retry-After wskazuje sugerowany czas ponowienia żądania. Nie gwarantuje jednak zachowania indeksacji podczas długiej niedostępności. Po zakończeniu prac trzeba potwierdzić powrót właściwych odpowiedzi, zamiast zakładać, że wyłączenie komunikatu konserwacyjnego wystarczyło.

Jak sprawdzić status i potwierdzić naprawę?

1. Zobacz rzeczywistą odpowiedź HTTP

W narzędziach deweloperskich przeglądarki otwórz kartę sieciową, przeładuj stronę i sprawdź żądanie głównego dokumentu. Nie pomyl jego statusu z odpowiedzią pojedynczego pliku CSS, obrazu czy skryptu. Przy przekierowaniu sprawdź także nagłówek Location oraz adres końcowy.

Osoba techniczna może pobrać nagłówki odpowiedzi na żądanie GET poleceniem:

curl -sS -D - -o /dev/null 'ADRES_DO_SPRAWDZENIA'

Podstaw pełny adres strony. Polecenie nie podąża automatycznie za przekierowaniem, więc pokazuje odpowiedź badanego adresu. Następnie sprawdź osobno wskazany cel. Ocena samego kodu bez obejrzenia końcowej treści jest niepełna.

2. Porównaj test z danymi Google i logami

W Search Console sprawdź raport indeksowania oraz inspekcję konkretnego URL-a. Zwróć uwagę na datę ostatniego skanowania: informacja historyczna nie musi opisywać obecnego stanu. Podstawy pracy z tymi danymi znajdziesz w poradniku jak sprawdzać widoczność i diagnozować SEO w Search Console.

Logi serwera pomagają ustalić, kiedy występował problem, jakich adresów dotyczył i jakie odpowiedzi otrzymywały żądania. Pojedyncze poprawne otwarcie strony nie wyklucza awarii okresowej. Z kolei historyczny błąd w raporcie nie dowodzi, że nadal trwa.

3. Zweryfikuj efekt po wdrożeniu

• Sprawdź dokładnie ten adres, którego dotyczyła zmiana.
• Potwierdź kod, cel przekierowania i końcową treść.
• Skontroluj linki wewnętrzne oraz mapę witryny.
• Przetestuj również podobne adresy, jeśli zmieniano regułę obejmującą całą grupę stron.
• Przy awarii obserwuj kolejne odpowiedzi i logi, a nie tylko jeden udany test.

Co naprawiać najpierw?

Poniższa kolejność jest praktyczną propozycją organizacji pracy, a nie regułą ustaloną przez Google:

1. Rozległa awaria 5xx: problem uniemożliwiający korzystanie z całego serwisu lub znacznej części strony.
2. Niedostępne kluczowe podstrony: aktywna oferta, ważne kategorie i inne strony potrzebne klientom.
3. Błędne przekierowania: pętle, nieprawidłowe cele, przekierowania kończące się błędem.
4. Pozostałe niezamierzone błędy: w tym nieaktualne linki wewnętrzne i soft 404.

Zamierzone 404 i 410 pozostają poza listą „napraw za wszelką cenę”. Przy większej liczbie adresów warto przygotować zestawienie: URL, aktualny status, oczekiwany stan, właściwy zamiennik, priorytet i osoba odpowiedzialna. Taka lista pozwala oddzielić prace redakcyjne od konfiguracji serwera.

Jeśli nie wiadomo, które błędy są skutkiem usunięcia treści, a które problemu technicznego, pomocny może być audyt SEO z planem dalszych prac. Celem powinno być ustalenie poprawnego zachowania adresów i kolejności zmian, nie wyzerowanie wszystkich komunikatów w narzędziu.