HTTP-Statuscode 400

Alle Statuscodes, die mit einer „4“ einleiten, zählen zu den Fehlercodes. Sie zeigen Fehler in der Kommunikation zwischen Client und Server auf. Auf welcher Seite der Fehler liegt, ist oftmals nicht sofort klar – weder für User*innen noch für Website-Admins. Bei einem 400-Error liegt meist jedoch ein Anfragen-Fehler aufseiten des Clients vor. 

SEO-Tools wie XOVI zeigen Euch übersichtlich an, welche Statuscodes auf Eurer Website aktuell sind.

Alles über den Request-Fehler HTTP 400 und wie Ihr ihn beheben könnt.

Um Euch genau zu erklären, was Ihr als Website-Betreiber*innen oder -User*innen bei einem HTTP-Statuscode 400 machen könnt, haben wir Euch alle wichtigen Infos kompakt zusammengefasst. Dafür gehen wir genau auf die Definition eines HTTP 400, dessen Ursachen und Lösungen ein. Außerdem empfehlen wir Euch Tools, die Admins dabei helfen, HTTP-400-Fehler zu identifizieren und zu beseitigen.

Was ein HTTP 400 ist

Optimalerweise läuft ein Website-Besuch im Hintergrund wie folgt ab: Der Client (Webbrowser wie Safari oder Google Chrome) fragt beim entsprechenden Server die Website-Daten ab, damit die User*innen die Website oder den Onlineshop sehen können. Das alles erfolgt binnen Millisekunden – vorausgesetzt, die eigene Internetleitung spielt mit.

Was ist aber, wenn der Server die Anfrage ablehnt und Ihr als User*in keine Website zu sehen bekommt? In diesem Fall liegt ein HTTP 400 Bad Request vor. Alle 4xx-Fehler (insgesamt 33) zeigen Missstände zwischen Client und Server auf. Meist liegt es am Client, während 5xx-Fehler den Servern zugeordnet werden. 

100 Prozent sicher können weder User*innen noch Website-Admins bei einem 400-Error sein. Aus dem Grund ist es ratsam, in beiden Rollen der Ursache für den Fehler auf die Spur zu gehen. Die Vorgehensweisen unterscheiden sich jedoch: User*innen brauchen nicht mehr als den PC und den Browser, die sie nutzen; Admins benötigen zusätzlich eine SEO-Software.

Welche Ursachen ein HTTP 400 hat

Meistens hilft es, die Website umgehend nochmal zu laden – das geht übrigens mit der Taste F5 noch schneller als auf den Reload-Button im Browser zu klicken. Manchmal wurde die Request einfach nicht ordnungsgemäß geschickt, welche ein Server grundsätzlich ablehnt. Schließlich sind Software und Netz nicht perfekt. Bedeutet: Eine zweite Anfrage kann durchaus erfolgreich sein, ohne dass Ihr groß Detektiv:in spielen müsst!

Ist das jedoch nicht der Fall, liegen folgende Ursachen vor, die zu überprüfen sind:

• Manchmal kann die Ursache so simpel sein, dass einfach nur die URL falsch eingegeben wurde – am besten Zeichen für Zeichen überprüfen. Häufig ist es ein Leerzeichen, was in keine URL gehört.
• Der Allrounder, Cookies und Verlauf löschen, hilft erfahrungsgemäß in 99 Prozent der Fälle.
• Wenn die Abfrage zu großer Datenmengen erfolgt, lehnen einige Server die Request ab. Das ist meist ein Schutzmechanismus, um den Server nicht zu überlasten.
• Kaum zu glauben, aber URLs können auch zu lang sein, weshalb Server Anfragen ablehnen. Das bezieht sich auf den Header, der als Kommunikationsfeld zwischen Client und Server dient. Wird durch die URL die maximale Zeichenlänge im Header überschritten, gibt es einen Bad-Request-Fehler. In diesem Fall müsst Ihr als User*in die URL kürzen, da auf den Header nur die Website-Administration Zugriff hat. Löscht einfach den Teil vor dem ersten „/“, womit Ihr zur Übersichtsseite kommen solltet. Beispiel: https://omr.com/de/reviews/contenthub/[beste-intranet-software]
• Auch Browser-Erweiterungen können ein Problem im Client-Server-Hin-und-her darstellen. Einzeln zu deaktivieren, kann Wunder bewirken.
• Möglicherweise liegen noch veraltete DNS-Daten vor, die Ihr auf Eurem Gerät löschen könnt. Das Domain-Name-System (DNS) kümmert sich darum, dass bei jedem Website-Besuch Eure IP-Adresse in Verbindung mit der Web-Adresse gespeichert wird. Das ist die Aufgabe Eures Betriebssystems, um Website-Servern die stetige Abfrage der Daten zu ersparen. Wie Ihr die DNS-Daten löscht, erklären wir Euch gerne in einer kurzen Anleitung, da das gewissermaßen kompliziert ist (je nach Know-how).

Wie Ihr Euren DNS-Cache löscht (für Windows 10 & 11 sowie macOS 10.5 bis 10.11)

Da diese Ursache gar nicht mal so selten vorkommt, ist es praktisch zu wissen, wie Ihr die Löschung vornehmt. Doch keine Panik: Das Löschen des Webadress-Zwischenspeichers – auch DNS-Flush genannt – in regelmäßiger Frequenz ist sinnvoll, macht aber nichts kaputt!

1. Öffnet die Ausführen-Maske mittels Windows-Taste + R.
2. Führt den Command „cmd“ aus – cmd eingeben und Enter drücken.
3. In der Konsole, die sich anschließend öffnet, gebt Ihr „ipconfig /flushdns ein.
4. Die Bestätigung mit Enter erledigt die Löschung.

Diese Anleitung gilt ausschließlich für Windows-Computer. Habt Ihr ein Apple-Gerät vor Euch stehen, sieht die Anleitung zum Löschen des DNS-Cache etwas anders aus. Nutzt Ihr die macOS-Versionen 10.7, 10.8, 10.9 oder 10.11 gebt Ihr folgenden Command ins Terminal ein:

sudo killall -HUP mDNSResponder

Geräte mit macOS 10.10 verlangen nach folgendem Befehl: 

sudo discoveryutil udnsflushcaches

Und für alles, was älter als macOS 10.6 ist, nutzt Ihr

sudo dscacheutil -flushcache

In allen drei Fällen müsst Ihr vor der Löschung des DNS-Cache Euer Admin-Passwort eingeben. Erst dann wird die Löschung umgesetzt.

Wie Ihr HTTP-400-Fehler identifiziert

Zurück zum eigentlichen Thema. Um die zutreffende Ursache für einen HTTP 400 herauszufinden, bleiben Euch als User*in mehrere Wege, als Website-Betreiber*in im Grunde nur einer. 

Möchtet Ihr einen Onlineshop oder eine Website aufrufen und Euch springt ein HTTP-Code-400 entgegen, reloaded zunächst die Seite. Hat das nicht den gewünschten Erfolg, findet Ihr am Ende des Artikels eine To-do-Liste, die 99 Prozent der eingangs genannten Ursachen beheben sollten.

Seid Ihr Website-Admin, empfehlen wir Euch laufend Eure Seiten im Blick zu behalten. Neben HTTP-400-Errors können weitere Probleme auftauchen. Beispielsweise Statuscodes wie 404 oder 500, die negative Auswirkungen auf Euer SEO haben, wenn sie zu lange existieren. Um einen HTTP 400 zu identifizieren, nutzt Ihr am besten Crawler-Software – eine Unterkategorie der SEO-Tools.

Welche Software bei einem HTTP 400 für Admins nützlich ist

Auf OMR Reviews findet Ihr eine große Anzahl SEO-Tools. Doch nur ein Bruchteil davon sind dafür geeignet, Statuscodes zu identifizieren. Sogenannte Crawler gehen dabei ebenso vor wie Suchmaschinen: Sie scannen Eure gesamte Website mit allen Unterseiten, um die jeweiligen Status Eurer URLs herauszufinden. Dabei erhaltet Ihr Rückmeldung, welchen Statuscode Euer Server pro URL ausgibt. Bad-Request-Fehler werden ebenso aufgezeigt.

Folgende 7 SEO-Tools bieten Euch Crawler-Features an: 

• Screaming Frog SEO Spider
• Ryte
• XOVI
• Audisto Crawling
• Sitebulb
• searchVIU
• Netpeak Spider

Je nach Anbieter findet Ihr kostenlose Versionen unter den sieben Tools, um Euch das Thema SEO-Software erstmal in Ruhe anzuschauen, ohne Euch festlegen zu müssen. Alle Softwares könnt Ihr Euch außerdem im Detail auf OMR Reviews anschauen, vergleichen und Feedbacks verifizierter User:innen lesen.

To-do-Liste: Wie Ihr einen HTTP 400 behebt

Wenn gleich Ihr im Part „Ursachen finden“ bereits mitlesen konntet, was bei jeder Ursache zu tun ist, schließen wir den Artikel mit einer glasklaren To-do-Liste. Arbeitet sie von oben nach unten ab. Am Ende werdet Ihr den 400-Fehler behoben haben. Sollte das nicht der Fall sein, kontaktiert am besten die Seiten-Administration, um serverseitige Probleme prüfen zu lassen.

Geht folgendermaßen vor:

• Überprüft die gewünschte URL auf Fehler
• Löscht Euren Browser-Cache und die Cookies
• Nehmt eine DNS-Cache-Löschung vor (Anleitung dafür siehe oben)
• Deaktiviert der Reihe nach Eure Browser-Erweiterungen, da sie gerne mal die Kommunikation zum Webserver stören können (startet mit den neu installierten).

Übrigens: Bevor Ihr die Liste abarbeitet, könnt Ihr einen kleinen Test machen. Ist die Website auf anderen Geräten erreichbar? Wenn ja, werdet Ihr das Problem zu 100 Prozent mit einem der To-dos beheben können. Wenn nein, könnt Ihr Euch die Liste fast schon sparen, da es in diesem Fall nach einem Server-Problem aussieht.