Was ist Fehler 400 (Bad Request)?

Der Code 400 gehört zur 4xx-Familie, die für Fehler auf Seiten des Clients reserviert ist. Nach der aktuell gültigen Spezifikation, RFC 9110, antwortet der Server mit 400, wenn die Anfrage eine "fehlerhafte Syntax, ein ungültiges Nachrichtenformat oder eine irreführende Weiterleitung" enthält. In der Praxis reicht das von einer URL mit nicht kodierten Sonderzeichen bis zu einem Formular, das kaputtes JSON sendet, oder einem Cookie, das die vom Server erlaubte Größe überschreitet.

Einen einzelnen Auslöser gibt es selten. Ein intern generierter Link aus einer fehlerhaften Vorlage, ein Suchparameter mit nicht escapten Anführungszeichen oder ein beschädigter Sprach-Header können denselben Code auslösen. Deshalb tritt 400 fast nie einzeln auf, sondern gehäuft, meist im Zusammenhang mit einer kürzlichen Änderung an der URL-Generierung, einem Plugin oder einer Drittanbieter-Integration.

Der häufigste Denkfehler ist, 400 als Verwandten von 404 zu behandeln, dabei ist die Ähnlichkeit rein oberflächlich. 404 bedeutet, dass der Server die Anfrage verstanden, die Ressource gesucht und nicht gefunden hat. 400 bedeutet, dass die Anfrage diese Phase gar nicht erst erreicht hat: Sie wurde vorher verworfen.

400 teilt sich eine Fehlerfamilie mit Codes, die leicht verwechselt werden. Die Tabelle zeigt, wo jeder Fehler entsteht und was ihn typischerweise auslöst.

Für SEO zählt vor allem der Unterschied zu 404: 400 und 500 melden ein Problem beim Verarbeiten der Anfrage, während 404 bestätigt, dass die Verarbeitung abgeschlossen wurde und die Ressource schlicht fehlt.

Sendet ein Browser oder ein Crawler eine Anfrage, verarbeitet der Server sie in Phasen. Zuerst prüft er die Syntax: URL, Header, Cookies, gegebenenfalls den Body. Erst wenn diese Prüfung besteht, geht die Anfrage in die Routing-Phase über, in der der Server entscheidet, welche Ressource gemeint ist. 400 entsteht in der ersten Phase. Der Server erkennt etwas, das er nicht interpretieren kann, und bricht ab, bevor er überhaupt nach einer Ressource sucht.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:15:32 GMT

Dieser Unterschied zu 404 (das die Routing-Phase erreicht) und zu 500 (das erst später, in der Anwendungslogik, auftritt) hat praktische Folgen. Ein 400 lässt sich fast nie durch eine neue Seite oder eine Weiterleitung beheben, weil noch gar keine Seite im Spiel ist. Zu korrigieren ist, wie die Anfrage zusammengebaut wird.

Bei einer Website sind die häufigsten Ursachen technisch und unauffällig: eine Migration, die die Zeichenkodierung interner URLs ändert, ein Filtersystem im Onlineshop, das Parameter mit nicht kodierten Leerzeichen erzeugt, oder eine Analytics-Integration, die einen zu langen Header hinzufügt. Auch ein CDN oder ein Reverse Proxy davor setzt oft eigene Grenzwerte für Header- oder URL-Länge, die strenger sind als die der Anwendung dahinter. Googlebot und jeder andere Crawler erhalten denselben 400 wie ein Nutzer und protokollieren ihn genauso: als Fehler der Anfrage, nicht des Inhalts.

Ein einzelner 400-Fehler wirkt sich kaum auf das Ranking aus. Problematisch wird es, wenn er sich über ein URL-Muster wiederholt, weil sich das Crawling dann schlechter verteilt. Google verarbeitet den Inhalt einer URL mit 400 nicht: Die Systeme melden der nächsten Verarbeitungsstufe, dass der Inhalt nicht existiert, genau wie bei den übrigen 4xx-Fehlern außer 429. War die URL zuvor indexiert, verschwindet sie mit der Zeit aus dem Index.

Erschwerend kommt hinzu, dass die Search Console 400 nicht als eigene Kategorie ausweist. Im Crawling-Statistikbericht landet ein reiner 400-Fehler in der Sammelkategorie "Anderer Clientfehler (4xx)", zusammen mit Codes, die inhaltlich nichts damit zu tun haben, etwa 406 oder 411. Wer nur diesen Bericht liest, merkt oft nicht, wie viele dieser URLs tatsächlich 400 sind, bis er die Daten mit den Server-Logs abgleicht.

Genau davon hängt die Entscheidung ab: Steigt die Zahl der 400-Fehler nach einer technischen Änderung, lohnt sich die Prüfung, bevor das Crawling auf diesen Routen zurückgeht und interne Links mit echtem Wert mitreißt.

• Server-Logs gezielt nach Code 400 filtern, weil die Search Console sie in "Anderer Clientfehler (4xx)" bündelt und nicht einzeln ausweist.
• Die Zeichenkodierung dynamisch erzeugter URLs prüfen (Filter, interne Suche, Kampagnenparameter), bevor sie als interne Links veröffentlicht werden.
• Formulare und Endpunkte mit Grenzfällen testen: leere Felder, Sonderzeichen, sehr große Anfragen, um zu sehen, ob der Server dort mit 400 statt mit einer eigenen Validierung reagiert.
• Die Größenlimits für Header und Cookies nach der Installation neuer Analytics- oder Marketing-Tools prüfen, eine häufige und wenig sichtbare Ursache.
• Weiterleitungsketten nach einer Migration prüfen, denn ein falsch kodierter Parameter in einem Zwischenschritt kann aus einer gültigen Weiterleitung einen 400-Fehler machen.
• Im Anwendungscode zwischen einem echten 400 (fehlerhafte Anfrage) und einem 404 (Ressource nicht gefunden) unterscheiden; werden beide gleich behandelt, wird jede spätere Diagnose schwieriger.

• 400 und 404 im Anwendungscode verwechseln und für zwei unterschiedliche Probleme denselben Code zurückgeben.
• Die Kategorie "Anderer Clientfehler (4xx)" in der Search Console ignorieren, weil sie unwichtig wirkt, obwohl sich dahinter Hunderte URLs mit kaputten Parametern verbergen können.
• Die URL-Kodierung nach einer Migration nicht korrigieren, in der Annahme, es beträfe nur eine Handvoll Seiten.
• Sich allein auf die Stichprobe der Search Console verlassen statt auf die vollständigen Server-Logs, die das reale Volumen zeigen.
• Header- oder Cookie-Prüfungen zu streng konfigurieren, sodass am Ende legitime Anfragen von Crawlern oder echten Nutzern blockiert werden.