Kody odpowiedzi HTTP: kompletna lista statusów

Czym są kody odpowiedzi (statusy) HTTP?

Kody odpowiedzi HTTP (HTTP response status codes) są nieodłączną częścią komunikacji między przeglądarką internetową, a serwerem. Są to trzycyfrowe liczby (kody), które serwer wysyła w odpowiedzi na żądanie przeglądarki. Każdy kod ma swoje własne znaczenie oraz informuje użytkownika o wyniku żądania. Również silniki wyszukiwarek, takie jak Google, analizują kody odpowiedzi HTTP, aby lepiej zrozumieć oraz sprawniej skanować i indeksować napotkane witryny.

Tego typu odpowiedzi nie dotyczą jedynie błędów, ponieważ są zwracane za każdym razem, gdy przeglądarka wchodzi w interakcję z serwerem – nawet jeśli tego nie widzimy. Jeżeli jesteś właścicielem strony lub programistą, zrozumienie kodów odpowiedzi HTTP ma kluczowe znaczenie, ponieważ są nieocenionym narzędziem do diagnozowania (i ewentualnej naprawy) błędów konfiguracyjnych.

Kody odpowiedzi HTTP zostały podzielone na 5 różnych kategorii (Informacyjne, Sukces, Przekierowanie, Błąd Klienta oraz Błąd Serwera), a każda z nich zaczyna się inną cyfrą i zawiera unikalne kody.

Jak działają kody odpowiedzi HTTP?

W praktyce wygląda to tak: za każdym razem, gdy klikniesz w dany link lub wpiszesz domenę w pasku URL, Twoja przeglądarka wyśle żądanie do serwera www. Serwer sieciowy odbierze i przetworzy żądanie, a następnie odeśle dane zasoby w nagłówku HTTP.

Podczas gdy kody odpowiedzi są zwracane za każdym razem, przez większość czasu będą one niewidoczne (w przypadku statusów 1xx, 2xx czy 3xx). Kiedy jednak coś pójdzie nie tak, ujrzysz kod odpowiedzi HTTP informujący o błędzie (kody 4xx oraz 5xx). Krótko mówiąc, serwer wyśle do Ciebie wiadomość, że coś nie działa, a dodatkowo poinformuje Cię, co może być przyczyną.

Jakie znaczenie dla użytkowników i botów mają kody HTTP?

Od czasu do czasu zdarza się, że strona nie wyświetla się poprawnie – nie jesteśmy w stanie jej otworzyć, pojawia się strona błędu 404 lub następuje przekierowanie (i w konsekwencji trafiamy na stronę inną, niż się spodziewaliśmy). Dla zwykłych użytkowników witryny jest to z reguły rozczarowujące (bo nie dostali tego, czego oczekiwali) lub denerwujące (jeśli dostęp do konkretnych informacji jest konieczny lub ważny). W takich przypadkach zwykle próbujemy odświeżyć stronę lub wrócić i otworzyć ją ponownie. Czasami ten sposób działa – wtedy najpewniej był to tymczasowy problem z renderowaniem lub z połączeniem, jednak czasami problem jest większy – docelowa podstrona (lub plik) została usunięta, nieprawidłowo przekierowana lub dostęp do niej został ograniczony. Ma to swoje konsekwencje zarówno dla użytkowników, jak i robotów wyszukiwarek.

Kody odpowiedzi HTTP mają istotne znaczenie zarówno dla stron internetowych, jak i dla użytkowników. Służą do komunikacji między użytkownikiem korzystającym z przeglądarki oraz serwerem, czyli miejscem, gdzie zlokalizowana jest strona oraz wszystkie jej pliki wewnętrzne.

Kody te mają istotne znaczenie zarówno dla stron internetowych, jak i dla użytkowników, a ich właściwe zrozumienie i reagowanie na nie jest kluczowe dla zapewnienia pozytywnego doświadczenia użytkowników (UX) i optymalizacji strony pod kątem SEO. Statusy HTTP są używane do informowania przeglądarki i użytkowników o statusie żądania – dzięki nim użytkownicy dostają informację, czy strona działa prawidłowo czy też napotkała pewien problem. Właściciele stron mogą ustawić odpowiednie kody dla treści, które stanowią “gated content” (czyli dostępne pod pewnymi warunkami np. po zapisie do newslettera) zostały przekierowanie czy trwale usunięte.

Zostańmy jeszcze chwilę przy przekierowaniach czy usuniętych treściach, ponieważ mają one również duże znaczenie dla pozycjonowania stron internetowych. Kategorie kodów odpowiedzi związanych z przekierowaniami umożliwiają przeniesienie użytkowników na inne strony lub adresy URL (nawet do innych serwisów internetowych). Warto skorzystać z nich, w sytuacji gdy chcemy przekierować użytkowników z nieaktualnych stron na nowe lokalizacje, kiedy planujemy migrację strony lub sklepu internetowego albo kiedy posiadamy kilka serwisów i chcemy przenieść moc ich profilów linków na jedną, wybraną domenę. Silniki wyszukiwarek analizują kody odpowiedzi, aby zrozumieć, czy strona działa prawidłowo i czy dostarcza wartościową treść. Witryny z wieloma kodami błędów mogą mieć negatywny wpływ na pozycję w wynikach wyszukiwania, dlatego warto raz na jakiś czas upewnić się, że nasz serwis zwraca poprawne kody odpowiedzi.

Kody HTTP są również przydatne do zdiagnozowania problemów związanych z komunikacją między przeglądarką a serwerem. Dzięki temu administratorzy witryn mogą identyfikować i naprawiać problemy techniczne, aby zapewnić lepszy UX oraz usprawnić nawigację klientom i robotom wyszukiwarek.

User-agent w akcji, czyli rodzaje użytkowników w sieci

Każdego dnia z sieci internetowej korzystają nie tylko ludzie, ale również wiele rodzajów botów, znanych jako “user-agenci” (ang. user-agents). Przykłady takich user-agentów to np. boty przeglądarek internetowych, roboty wyszukiwarek (jak Googlebot, Bingbot czy Slurp) albo zewnętrznych narzędzi do web scrapingu (jak AhrefsBot lub SemrushBot).

Różne rodzaje user-agentów służą innym celom, ale – jako właściciele domen – jesteśmy w stanie modyfikować ich dostęp do naszych treści. Aby ułatwić robotom poruszanie się po witrynie, możemy umieścić na serwerze mapę witryny (sitemapę), a jeśli chcemy zabronić określonym typom botów dostępu do wybranych plików, stron czy katalogów, możemy to zrobić za pomocą odpowiednich dyrektyw w pliku robots.txt.

Jakie są kategorie statusów odpowiedzi HTTP?

Lista statusów HTTP jest podzielona na pięć kategorii odpowiedzi:

Kody 1xx: kody informacyjne, które wskazują, że żądanie zainicjowane przez przeglądarkę jest kontynuowane.

Kody 2xx: kody powodzenia, które zwracane są, gdy żądanie przeglądarki zostało pomyślnie odebrane, zrozumiane, a następnie przetworzone przez serwer.

Kody 3xx: kody przekierowań, które pojawiają się, gdy nowa zawartość została zastąpiona żądanym zasobem.

Kody 4xx: kody błędów klienta, które informują o wystąpieniu problemu z danym żądaniem.

Kody 5xx: kody błędów serwera, które wskazują, że żądanie zostało zaakceptowane, jednak błąd na serwerze uniemożliwił jego spełnienie.

Kody odpowiedzi HTTP 1xx (Informacyjne)

• Kod HTTP 100 Continue (“Kontynuuj”)

Odpowiedź tymczasowa, która informuje użytkownika, aby kontynuował żądanie lub zignorować odpowiedź, jeśli żądanie zostało już zakończone.

• Kod HTTP 101 Switching Protocoles (“Przełączanie protokołów”)

Kod wysyłany w odpowiedzi na żądania nagłówka Upgrade od klienta. Wskazuje na protokół, do którego przełącza się serwer.

• Kod HTTP 102 Processing (“Przetwarzanie”)

Kod informujący, że serwer otrzymał i przetwarza żądanie, ale musimy jeszcze zaczekać na odpowiedź. Żądanie może zawierać wiele pod-zapytań, które obejmuje operacje na plikach, co wymaga dłuższego czasu na wykonanie żądania. Zapobiega to przekroczeniu czasu przez klienta i założeniu, że żądanie zostało utracone.

• Kod HTTP 103 Early Hints (“Wczesne wskazówki”)

Ten kod statusu pozwala agentowi użytkownika rozpocząć wstępne ładowanie zasobów, podczas gdy serwer przygotowuje odpowiedź.

Kody odpowiedzi HTTP 2xx (Sukces)

• Kod HTTP 200 OK

Kod informujący, że żądanie zakończyło się sukcesem.

• Kod HTTP 201 Created (“Utworzony”)

Żądanie powiodło się i został stworzony nowy zasób. Jest to typowa odpowiedź wysyłana po żądaniach POST lub po niektórych żądaniach typu PUT.

• Kod HTTP 202 Accepted (“Przyjęte”)

Żądanie zostało odebrane, ale jeszcze nie jest wykonane. Kod jest przeznaczony dla przypadków, kiedy inny proces lub serwer obsługuje żądanie lub dla przetwarzania wsadowego (batch processing).

• Kod HTTP 203 Non-Authoritative Information (“Informacje nieautoryzowane”)

Ten kod oznacza, że zwrócone metadane nie są dokładnie takie same jak te, które są dostępne na serwerze źródłowym, ale zostały zebrane z kopii lokalnej lub strony trzeciej. Jest to najczęściej używane dla mirrorów lub kopii zapasowych innego zasobu.

• Kod HTTP 204 No Content (“Brak zawartości”)

Serwer pomyślnie przetworzył żądanie użytkownika i nie zwraca żadnej zawartości (brak zawartości sekcji “body”).

• Kod HTTP 205 Reset Content (“Resetuj zawartość”)

Kod przekazuje informacje, że serwer zrealizował żądanie i należy przywrócić domyślny wygląd dokumentu.

• Kod HTTP 206 Partial Content (“Zawartość częściowa”)

Ten kod odpowiedzi wskazuje, że żądanie zakończyło się częściowym sukcesem, a sekcja “body” zawiera żądane dane i informacje, opisane w nagłówku “Range” żądania.

• Kod HTTP 207 Multi-Status

Kod wskazuje, że może istnieć wiele odpowiedzi dla danego zapytania (wiele kodów statusu może być odpowiednich).

• Kod HTTP 208 Already Reported (”Już zgłoszone”)

Kod odpowiedzi HTTP 208 jest używany w statusie 207 (Multi-Status), aby zaoszczędzić miejsce i uniknąć konfliktów.

Kody odpowiedzi HTTP 3xx (Przekierowanie)

• Kod HTTP 300 Multiple Choices (“Wiele możliwości”)

Żądanie ma więcej niż jedną możliwą odpowiedź. User-agent powinien wybrać jedną z nich (ponieważ nie ma standardowego sposobu wyboru jednej z odpowiedzi, ten kod odpowiedzi jest bardzo rzadko używany).

• Kod HTTP 301 Moved Permanently (“Przeniesiono na stałe”)

Ten kod wskazuje, że żądany zasób został przeniesiony na stałe pod nowy adres URL. Przeglądarka przekierowuje użytkownika do nowej lokalizacji, a boty wyszukiwarek aktualizują swoje zasoby o tę informację (po jakimś czasie stary adres URL nie będzie już możliwy do odnalezienia za pomocą wyszukiwarki, w środowisku branżowym nazywa się to “przeindeksowaniem”). Adres ten jest jednym z najczęściej spotykanych podczas optymalizacji wyszukiwarek pod kątem SEO.

• Kod HTTP 302 Found (“Znaleziono”)

Kod odpowiedzi HTTP wskazuje, że żądany zasób został tymczasowo przeniesiony pod inny adres URL. Przeglądarka przekierowuje użytkownika na daną stronę, ale boty wyszukiwarek nie aktualizują swoich zasobów o tę informację (w przeciwieństwie do kodu 301, stary adres URL wciąż jest uznawany za nadrzędny i przez to nie dochodzi do przeindeksowania. Upraszczając, można powiedzieć, że kod 302 wysyła informację do wyszukiwarek, że jakiś zasób został chwilowo przeniesiony, ale niedługo wróci pod stary adres URL).

• Kod HTTP 303 See Other (“Zobacz inne”)

Status wskazuje, że odpowiedź na żądanie znajduje się pod innym URI i użytkownik powinien się tam skierować.

• Kod HTTP 304 Not Modified (“Nie zmieniono”)

Kod odpowiedzi wskazuje, że nie ma potrzeby ponownego przesyłania żądania o wskazane zasoby. Jest to niejawne przekierowanie do buforowanego zasobu.

• Kod HTTP 305 Use Proxy (“Użyj Proxy”)

Kod wskazuje, że do żądanego zasobu lub treści należy odwołać się poprzez serwer Proxy podany w sekcji “Location” nagłówka odpowiedzi. Ze względów bezpieczeństwa wiele klientów HTTP (takich jak Mozilla Firefox czy Internet Explorer) nie korzysta z tego statusu.

• Kod HTTP 306 Switch Proxy (“Zmień serwer Proxy”)

Ten status HTTP nie jest obecnie używany. Oryginalnie oznaczał informację w stylu: “kolejne żądania powinny używać podanego serwera Proxy”.

• Kod HTTP 307 Temporary Redirect (“Przekierowanie tymczasowe”)

Kod odpowiedzi przekierowania 307 wskazuje, że żądany zasób został tymczasowo przeniesiony pod inny adres URL. Najważniejszą różnicą między kodem 307, a kodem 302 jest bezpieczeństwo połączenia – przekierowanie 307 nie zmienia metody zapytania i dlatego jest ono rekomendowane w przypadkach tymczasowych przeniesień. Przekierowanie 307, podobnie jak 302, nie ma wpływu na pozycjonowanie – tutaj również dajemy znać robotom wyszukiwarek, że pierwotny adres URL jest unikalny i dalej powinien być możliwy do odnalezienia za pomocą wyszukiwarek, a użytkownicy są przenoszeni jedynie chwilowo.

• Kod HTTP 308 Permanent Redirect (“Przekierowanie stałe”)

Kod wskazuje, że żądany zasób został definitywnie przeniesiony pod inny adres URL. Podobnie jak w przypadku przekierowania 301, pierwotny adres zostanie po jakimś czasie usunięty z index’u (nie będzie pojawiał się w wynikach wyszukiwania). Różnica między tymi dwoma przekierowaniami polega na tym, że status 308 nie pozwala na zmianę metody HTTP (podczas gdy przekierowanie 301 może nieprawidłowo czasami zostać zmienione na metodę GET, jeśli pierwotnie została użyta inna).

• Kod HTTP 310 Too Many Redirects (“Zbyt wiele przekierowań”)

Kod ten zostaje zwrócony, gdy podczas realizacji żądanie dochodzi do większej ilości przekierowań niż to akceptowalne. Przeglądarka nie dotarła do ostatecznej lokalizacji zasobów, a w konsekwencji użytkownik nie otrzyma żądanej treści.

Kody odpowiedzi HTTP 4xx (Błąd klienta)

• Kod HTTP 400 Bad Request (“Nieprawidłowe żądanie”)

Kod ten wskazuje, że serwer nie może lub nie będzie przetwarzał żądania z powodu czegoś, co jest postrzegane jako błąd klienta (na przykład nieprawidłowa składnia żądania, zbyt duży rozmiar czy niepoprawny routing żądania).

• Kod HTTP 401 Unauthorized (“Nieautoryzowany dostęp”)

Status 401 zostaje zwrócony, kiedy żądanie klienta nie zostało zakończone, z powodu braku ważnych poświadczeń uwierzytelniających dla żądanego zasobu.

• Kod HTTP 402 Payment Required (“Wymagana opłata”)

Ten kod statusu jest niestandardowy i obecnie jest w fazie eksperymentów. Wskazuje, że żądana zawartość nie jest dostępna, dopóki klient nie dokona płatności. Innymi słowy – konkretne treści ukryte są za tzw. “paywallem”.

Nie istnieje jednak standardowa konwencja użycia i różne podmioty czy organizacje używają go w różnych kontekstach.

• Kod HTTP 403 Forbidden (“Dostęp zabroniony”)

Kod ten zostaje zwrócony, gdy serwer zrozumiał przesłane żądanie, ale konfiguracja bezpieczeństwa zabrania mu zwrócić określoną treść lub zasób.

Ten status jest podobny do kodu 401, ale tutaj ponowne uwierzytelnienie nie spowoduje żadnej różnicy. Dostęp do żądanej zawartości jest powiązany z ustawieniami aplikacji i obecnie użytkownik nie posiada wystarczających praw do niej.

• Kod HTTP 404 Not Found (“Nie odnaleziono”)

Kod statusu odpowiedzi HTTP 404 oznacza, że serwer nie może znaleźć danego zasobu. Linki, które kierują do strony błędu 404 są często nazywane zepsutymi lub martwymi linkami (tj. “broken links“) i warto ustawić im przekierowania z grupy 3xx lub podmienić docelowy adres URL (wtedy żądanie zwróci kod 200).

Kod statusu 404 wskazuje jedynie na brak zasobu: nie dostarcza jednak informacji, czy brak jest tylko tymczasowy, czy trwały. Jeśli zasób został (lub ma zostać) trwale usunięty, zaleca się zastosowanie statusu 410 (Gone).

• Kod HTTP 405 Method Not Allowed (“Niedozwolona metoda”)

Kod ten zostaje zwrócony, gdy że serwer zna metodę żądania, ale zasób docelowy nie obsługuje tej metody.

• Kod HTTP 408 Request Timeout (“Koniec czasu przeznaczonego na żądanie”)

Status 408 przekazuje informacje, że serwer przekroczył czas oczekiwania na żądanie. Klient nie dokonał żądania w czasie, w którym serwer był przygotowany do jego przyjęcia. Klient może powtórzyć żądanie bez modyfikacji w dowolnym późniejszym czasie.

• Kod HTTP 409 Conflict (“Konflikt”)

Status “Conflict” wskazuje, że zapytanie nie mogło zostać zrealizowane z powodu konfliktu w bieżących zasobach (jak np. konflikt edycji pomiędzy wieloma jednoczesnymi aktualizacjami). Kod odpowiedzi 409 jest zwracany jedynie w przypadku, kiedy klient może znaleźć przyczynę błędu i przesłać ponownie poprawne zapytanie (aby to ułatwić, odpowiedź serwera może, ale nie musi, zawierać dodatkowe informacje i wskazówki, aby ułatwić rozwiązanie problemu).

• Kod HTTP 410 Gone (“Usunięto”)

Kod ten zostaje zwrócony, gdy zażądany zasób został trwale usunięty. Klient powinien już więcej nie odwoływać się do tego zasobu. Jeśli nie wiesz, czy brak żądanego zasobu jest tymczasowy czy trwały, warto użyć kodu stanu 404 (“Not Found”). Odpowiedź 410 jest domyślnie buforowana (cache’owana).

• Kod HTTP 415 Unsupported Media Type (“Nieznany sposób żądania”)

Status ten wskazuje, że serwer odmawia przyjęcia żądania, ponieważ jego składnia jest niezrozumiała dla serwera.

• Kod HTTP 418 I’m a Teapot (“Jestem czajnikiem”)

Ten kod jest kwietniowym żartem z 1998 roku i wskazuje, że serwer odmawia zaparzenia kawy, ponieważ jest… czajnikiem. Protokół HTTP służący do kontrolowania, monitorowania i diagnozowania działania ekspresów do kawy (lub, jak niektórzy rozwijają żartobliwie ten skrót w języku polskim, “Hipertekstowy protokół kontroli ekspresu do kawy”) jest raczej easter eggiem, choć ma również swoje nawiązania w pop kulturze i jest od czasu do czasu faktycznie używany. Niekiedy zwracany przez serwery podczas blokowania żądania, zamiast bardziej odpowiedniego statusu 403, a w czasie wojny rosyjsko-ukraińskiej rosyjska strona wojskowa mil.ru zwracała kod statusu HTTP 418, gdy uzyskiwano do niej dostęp spoza Rosji (pierwszy raz zauważono to w grudniu 2021 roku, źródło: Twitter).

Lecz historia kodu 418 mogła zakończyć się już dużo wcześniej – 5 sierpnia 2017 roku Mark Nottingham, przewodniczący grupy roboczej IETF, wezwał do usunięcia kodu 418 “I’m a teapot” z platformy Node.js. Dzień później, firma Nottingham zażądała usunięcia wykreślenia kodu 418 “I’m a teapot” z języka programowania Go, a następnie również z Pythona i biblioteki ASP.NET.

W odpowiedzi 15-letni programista Shane Brunswick stworzył stronę internetową save418.com i założył “Save 418 Movement”, twierdząc, że odniesienia do 418 “I’m a teapot” w różnych projektach służą jako “przypomnienie, że procesy leżące u podstaw komputerów są nadal tworzone przez ludzi“. Inicjatywa Brunswicka w zaledwie kilka godzin zebrała tysiące głosów Redditcie i wywindowała hashtag “#save418” na Twitterze. Słysząc publiczne oburzenie, zdecydowano się nie usuwać kodu “czajniczka” z projektów. Co więcej, poparcie ze strony internautów skłoniło Nottinghama do rozpoczęcia procesu oznaczania 418 jako zastrzeżonego kodu statusu HTTP, zapewniając, że kod 418 nie zostanie zastąpiony innym, oficjalnym kodem statusu w przyszłości.

• Kod HTTP 425 Too Early (“Za wcześnie”)

Kod ten zostaje zwrócony, kiedy serwer nie chce ryzykować przetwarzania żądania, które może zostać powtórzone ze względu na ryzyko ataku typu Replay.

• Kod HTTP 426 Upgrade Required (“Wymagana aktualizacja”)

Serwer odmawia wykonania żądania przy użyciu bieżącego protokołu, ale może zwrócić żądane zasoby po aktualizacji klienta do innego protokołu.

• Kod HTTP 428 Precondition Required (“Wymagany warunek wstępny”)

Kod ten zostaje zwrócony, gdy żądanie nie posiada nagłówka wstępnego (np. If-Match), który jest wymagany przez serwer.

• Kod HTTP 429 Too Many Requests (“Zbyt wiele żądań”)

Kod statusu odpowiedzi HTTP 429 wskazuje, że użytkownik wysłał zbyt wiele żądań w określonym czasie. Do tej odpowiedzi może być dołączona informacja, jak długo należy odczekać przed wykonaniem kolejnego żądania.

• Kod HTTP 431 Request Header Fields Too Large (“Zbyt duże pola nagłówka żądania”)

Kod 431 mówi nam, że serwer odmawia przetworzenia żądania, ponieważ nagłówki HTTP są zbyt długie i należy je zmniejszyć.

• Kod HTTP 451 Unavailable For Legal Reasons (“Zawartość niedostępna z powodów prawnych”)

Kod 451 zostaje zwrócony użytkownikowi, gdy zasób został zablokowany z powodu naruszenia prawa (lub także z powodu cenzury). Numer kodu jest nawiązaniem do powieści Raya Bradbury’ego pt. „451 stopni Fahrenheita”.

Kody odpowiedzi HTTP 5xx (Błąd serwera)

• Kod HTTP 500 Internal Server Error (“Wewnętrzny błąd serwera”)

Serwer napotkał nieoczekiwany stan, który uniemożliwił mu spełnienie żądania. Ta odpowiedź na błąd jest ogólną odpowiedzią typu “catch-all”. Zazwyczaj wskazuje na to, że serwer nie był w stanie znaleźć lepszego dopasowania do któregoś kodu z grupy błędu 5xx.

• Kod HTTP 501 Not Implemented (“Nie zaimplementowano”)

Serwer nie obsługuje funkcjonalności wymaganej do spełnienia żądania. Kod 501 jest właściwą odpowiedzią, gdy serwer nie rozpoznaje metody żądania i nie jest w stanie jej obsłużyć dla żadnego zasobu. Jedyne metody, które serwery muszą wspierać (i dlatego nie mogą zwracać 501) to GET i HEAD.

Jeśli serwer rozpoznaje metodę, ale celowo jej nie obsługuje, lepszą alternatywą jest status 405 Method Not Allowed.

• Kod HTTP 502 Bad Gateway (“Błąd bramki”)

Kod wskazuje, że serwer, działając jako brama lub proxy, otrzymał nieprawidłową odpowiedź od serwera nadrzędnego i nie jest w stanie zrealizować żądania.

Brama (Gateway) może odnosić się do różnych rzeczy i ten błąd zwykle nie jest czymś, co można samodzielnie naprawić z poziomu user-agenta, (wymaga raczej poprawki w serwerze lub proxy, przez które próbujemy uzyskać dostęp do zasobów).

• Kod HTTP 503 Service Unavailable (“Usługa niedostępna”)

Kod odpowiedzi błędu serwera 503 Service Unavailable wskazuje, że serwer nie jest gotowy do obsługi żądania. Typowe przyczyny to wyłączenie serwera z powodu konserwacji lub jego przeciążenie (nagłówek Retry-After powinien, jeśli to możliwe, zawierać szacowany czas do przywrócenia usługi).

• Kod HTTP 504 Gateway Timeout (“Przekroczono czas bramy”)

Serwer działał jako brama lub proxy i nie otrzymywał terminowej odpowiedzi od serwera nadrzędnego, której potrzebował do zakończenia żądania.

• Kod HTTP 505 HTTP Version Not Supported (“Nieobsługiwana wersja HTTP”)

Kod 505 Version Not Supported wskazuje, że wersja HTTP użyta w żądaniu nie jest obsługiwana przez serwer lub odmawia on obsługi wskazanej przez klienta wersji HTTP.

• Kod HTTP 509 Bandwidth Limit Exceeded (“Przekroczenie limitu transferu danych”)

Ten status HTTP wskazuje, że serwer jest chwilowo niedostępny, z powodu przekroczenia limitu transferu danych.

• Kod HTTP 510 Not Extended

Kod 510 informuje, że dalsze rozszerzenia żądania są wymagane, aby serwer mógł je prawidłowo spełnić.

• Kod HTTP 511 Network Authentication Required (“Wymagane uwierzytelnienie”)

Kod HTTP 511 Network Authentication Required wskazuje, że klient musi się uwierzytelnić, aby uzyskać dostęp do sieci.

Ten status jest generowany przez serwery pośrednie proxy, które kontrolują dostęp do sieci (np. wymaganie potwierdzenia zasad użytkowania przed udostępnieniem połączenia).

Jak monitorować witrynę pod kątem kodów odpowiedzi HTTP?

Obsługa i interpretacja kodów odpowiedzi HTTP są istotne dla właściwego zarządzania komunikacją między przeglądarką, a serwerem. Warto bliżej przyjrzeć się podstawowym kodom odpowiedzi HTTP, takim jak: “200 OK” (sukces), “404 Not Found” (Nie znaleziono), “500 Internal Server Error” (Wewnętrzny błąd serwera) czy grupie kodów 3xx (Przekierowania) itp. Ich zrozumienie pozwoli Ci na sprawne odczytywanie danych z Google Search Console (gdzie można sprawdzić stopień indeksacji podstron), narzędzi deweloperskich, na analizę logów serwera czy podejmowanie właściwych decyzji, kiedy coś wydarzy się na serwisie.

Pozostając jeszcze chwilę przy logach serwera – warto je monitorować, ponieważ są cennym źródłem wielu informacji m.in. na temat kodów odpowiedzi HTTP, potencjalnych błędów i problemów technicznych, indeksacji stron czy liczby żądań oraz czasu, jaki serwer musiał na nie poświęcić. Warto też od czasu do czasu przecrawlować (tj. przeskanować) serwis, aby sprawdzić, jakie kody są zwracane i czy któreś strony nie potrzebują dodatkowej uwagi. Wiele narzędzi do crawlowania (jak np. Screaming Frog czy JetOctopus) potrafi przejrzyście wizualizować zebrane dane i stanowi to duże ułatwienie podczas podejmowania dalszych decyzji.

Zwracaj również uwagę na kody 4xx i 5xx: oznaczają one błędy po stronie klienta lub serwera. Na ich występowanie najbardziej narażone są serwisu często modyfikowane, zmieniające się lub z problemami technicznymi. Jest to niebezpieczna sytuacja, zwłaszcza kiedy mówimy o e-commerce, ponieważ odpowiednia indeksacja i nawigacja po serwisie jest jednym z kluczowych filarów pozycjonowania sklepów internetowych i jednym z najważniejszych elementów audytu SEO.

Jeśli więc dostrzegasz, że Twój serwis może potrzebować pomocy z optymalizacją i/lub pozycjonowaniem, wypełnij poniższy formularz.