400 Bad Request

400 Bad Request to kod błędu HTTP, który serwer zwraca przeglądarce lub klientowi, gdy nie jest w stanie przetworzyć żądania z powodu błędu po stronie klienta — najczęściej nieprawidłowej składni, uszkodzonych parametrów lub złej struktury zapytania. Błąd ten należy do grupy kodów 4xx, oznaczających problemy leżące po stronie wysyłającego zapytanie, a nie serwera. W przeciwieństwie do błędu 404 (brak zasobu), kod 400 sygnalizuje, że żądanie jest technicznie wadliwe i serwer nie jest nawet w stanie go poprawnie zinterpretować.

• 400 Bad Request pojawia się, gdy przeglądarka lub aplikacja wysyła żądanie niezgodne ze specyfikacją HTTP.
• Przyczyny są zwykle po stronie klienta: uszkodzone ciasteczka, błędne nagłówki, zbyt długi URL lub złe dane formularza.
• Dla robotów Google błąd 400 może skutkować pominięciem strony podczas indeksowania.
• Diagnostyka wymaga analizy logów serwera oraz narzędzi deweloperskich przeglądarki.

Jak błąd 400 Bad Request działa w praktyce

Skąd pochodzi kod 400 i co dokładnie oznacza?

Kod 400 Bad Request jest zdefiniowany w specyfikacji RFC 9110 (wcześniej RFC 7230) jako odpowiedź serwera na żądanie, którego nie można przetworzyć z powodu błędnej składni lub naruszenia protokołu HTTP. Serwer w odpowiedzi zwraca status 400 zamiast próbować odgadnąć intencję klienta — to celowe zachowanie chroniące przed potencjalnie niebezpiecznymi lub zniekształconymi danymi.

W praktyce oznacza to, że po stronie użytkownika lub aplikacji coś poszło nie tak już na etapie formułowania zapytania. Serwer nawet nie dociera do etapu szukania zasobu — zatrzymuje się wcześniej, na walidacji samego żądania.

Najczęstsze przyczyny błędu 400

Błąd 400 Bad Request wywołuje kilka powtarzających się scenariuszy, które warto znać zarówno jako właściciel strony, jak i deweloper.

• Uszkodzone lub przestarzałe ciasteczka (cookies) — przeglądarka przesyła cookie, które serwer odrzuca jako nieprawidłowe.
• Zbyt długi URL — serwery Apache i Nginx domyślnie akceptują adresy do ok. 8 000–16 000 znaków; przekroczenie limitu skutkuje błędem 400.
• Błędnie zakodowane znaki w URL — np. spacje lub znaki specjalne bez poprawnego encodingu (powinny być zastąpione sekwencjami %20, %26 itp.).
• Uszkodzone nagłówki HTTP — nieprawidłowy format nagłówka Content-Type, Authorization lub Accept.
• Błędne dane w żądaniu POST/PUT — formularz lub API wysyła dane w formacie niezgodnym z oczekiwaniem serwera (np. JSON zamiast XML).
• Przekroczony limit rozmiaru żądania — przesłanie pliku lub danych przekraczających skonfigurowany próg serwera.
• Błędy w konfiguracji cache’u lub proxy — pośredni serwer proxy może zniekształcić żądanie zanim dotrze ono do docelowego serwera.

Jak wygląda błąd 400 z perspektywy użytkownika i dewelopera?

Użytkownik widzi stronę z komunikatem „400 Bad Request” lub podobnym, bez możliwości załadowania treści. Deweloper w narzędziach deweloperskich przeglądarki (zakładka Network/Sieć) znajdzie żądanie ze statusem 400 oraz — jeśli serwer go zwróci — szczegółowy komunikat błędu w ciele odpowiedzi. Logi serwera (np. access.log w Nginx) pokażą dokładną godzinę, IP i treść żądania, które wywołało problem.

Jak naprawić błąd 400 Bad Request?

Sposób naprawy zależy od kontekstu — inaczej działasz jako użytkownik, inaczej jako administrator strony.

Działania po stronie użytkownika:

• Wyczyść pamięć podręczną przeglądarki i usuń ciasteczka dla danej domeny.
• Sprawdź, czy wpisany URL nie zawiera błędnych znaków lub zbędnych spacji.
• Spróbuj otworzyć stronę w trybie incognito lub innej przeglądarce.
• Odśwież stronę (Ctrl+F5 wymusza pominięcie cache).

Działania po stronie administratora/dewelopera:

• Przeanalizuj logi serwera — znajdź dokładne żądanie wywołujące błąd 400.
• Sprawdź konfigurację limitów rozmiaru żądania (parametry client_max_body_size w Nginx lub LimitRequestBody w Apache).
• Zweryfikuj poprawność walidacji danych formularzy i API — upewnij się, że aplikacja wysyła dane w formacie zgodnym ze specyfikacją.
• Skontroluj nagłówki HTTP generowane przez aplikację lub serwer proxy.

Znaczenie błędu 400 Bad Request dla SEO i widoczności

Błąd 400 Bad Request ma bezpośredni wpływ na indeksowanie i pozycjonowanie strony. Gdy Googlebot napotyka kod 400 podczas crawlowania, traktuje dany URL jako niemożliwy do przetworzenia i pomija go w indeksie — lub usuwa z niego, jeśli strona była wcześniej zaindeksowana. Masowe błędy 400 uszczuplają crawl budget, czyli pulę zasobów, jaką Google przeznacza na pełzanie po Twojej witrynie.

W Google Search Console błędy 400 pojawiają się w raporcie „Pokrycie indeksu” jako strony z błędami. Jeśli dotyczą ważnych podstron — kategorii produktowych, wpisów blogowych czy stron usługowych — ich niedostępność przekłada się bezpośrednio na utratę ruchu organicznego. Regularne audyt SEO pozwala wychwycić takie problemy zanim zdążą poważnie zaszkodzić widoczności. Jeśli prowadzisz sklep internetowy i błąd 400 pojawia się na stronach produktów, ucierpi nie tylko SEO, ale też konwersja — użytkownicy po prostu nie dotrą do oferty. Skuteczne pozycjonowanie sklepów internetowych wymaga regularnego monitorowania logów serwera właśnie pod kątem takich błędów.

FAQ — najczęstsze pytania o błąd 400

Czy błąd 400 Bad Request zawsze oznacza problem po mojej stronie jako użytkownika?

W teorii tak — kod 400 wskazuje na błąd po stronie klienta, nie serwera. W praktyce jednak administratorzy stron mogą błędnie konfigurować serwer tak, że zwraca 400 zamiast innego, bardziej adekwatnego kodu. Jeśli błąd pojawia się tylko u Ciebie, przyczyną są prawdopodobnie Twoje dane lokalne (cache, cookies). Jeśli zgłaszają go wszyscy użytkownicy, problem leży po stronie aplikacji lub konfiguracji serwera.

Jak długo Google ignoruje stronę zwracającą błąd 400?

Google nie indeksuje stron zwracających kod 400 — jeśli Googlebot napotka ten błąd podczas crawlowania, strona zostaje pominięta lub usunięta z indeksu. Jeśli błąd jest tymczasowy i zostanie naprawiony, Google ponownie zaindeksuje stronę przy kolejnym crawlu, co może zająć od kilku dni do kilku tygodni, w zależności od częstotliwości odwiedzin robota na danej witrynie.

Czym różni się błąd 400 od błędu 422 Unprocessable Entity?

Oba kody dotyczą problemów z żądaniem po stronie klienta, ale mają różny zakres. Błąd 400 oznacza, że serwer nie może w ogóle przetworzyć żądania z powodu błędnej składni lub struktury. Błąd 422 (Unprocessable Entity) pojawia się, gdy żądanie jest technicznie poprawne składniowo, ale jego treść zawiera błędy semantyczne lub walidacyjne — serwer rozumie format, ale dane nie spełniają logicznych wymagań aplikacji.

Co zrobić, jeśli błąd 400 pojawia się tylko na urządzeniach mobilnych?

To sygnał, że przyczyną może być różnica w nagłówkach HTTP wysyłanych przez przeglądarkę mobilną (np. inny User-Agent lub Accept-Encoding) albo błąd w responsywnej wersji aplikacji generującej żądania. Należy sprawdzić logi serwera z filtrem na urządzenia mobilne i porównać dokładną treść nagłówków żądań z desktop i mobile. Pomóc może też test w Google Search Console — narzędzie „Sprawdź URL” pozwala zobaczyć, jak Google widzi stronę z perspektywy Googlebota.

Błąd 400 pod kontrolą — i co dalej?

Błąd 400 Bad Request to jeden z tych problemów technicznych, które łatwo przeoczyć w codziennym zarządzaniu stroną, a które mogą realnie osłabiać widoczność w wynikach wyszukiwania. Regularne przeglądanie logów serwera i raportów Google Search Console to minimum dobrej higieny technicznej. Jeśli chcesz mieć pewność, że Twoja strona nie traci pozycji przez ukryte błędy techniczne, skontaktuj się z Webiti — przeprowadzimy szczegółowy audyt SEO i zadbamy o skuteczne pozycjonowanie stron.