HTTP Statuscode Checker: Status Code, 200, 301, 404 und 5xx prüfen
Kostenloser Einzelcheck · ohne Anmeldung
Prüfen Sie eine einzelne URL, mehrere URLs oder eine XML-Sitemap. Sie erhalten den HTTP-Status der finalen Antwort, die Anzahl der Weiterleitungen und die finale Ziel-URL. Alle Ergebnisse und der CSV-Export sind kostenlos.
Ergebnis des Statuscode Checks
Geprüfte URLs
Die URL-Tabelle lässt sich seitlich scrollen.
| URL | Finaler Status | Redirects | Finale URL / Details |
|---|---|---|---|
| Noch keine Daten. | |||
Passende Fehlerhilfe
HTTP-Statuscodes: Bedeutung, Ursachen und nächste Schritte
Ordnen Sie den gemessenen Code im Kontext der URL ein: Eine bewusst geschützte Seite braucht eine andere Maßnahme als eine öffentliche Produktseite. Die Ursachen sind typische Beispiele und müssen am betroffenen System geprüft werden.
Die Referenztabelle lässt sich seitlich scrollen.
| Statuscode | Bedeutung | Typische Ursache | Nächster Prüfschritt |
|---|---|---|---|
| 200 OK | Anfrage erfolgreich beantwortet. | Die angeforderte Seite wird ausgeliefert; auch eine Fehlerseite kann fälschlich 200 melden. | Inhalt im Browser prüfen. Eine leere Seite oder Fehlermeldung trotz 200 kann ein Soft-404 sein; Status und Inhalt müssen übereinstimmen. |
| 301 / 308 | Dauerhafte Weiterleitung. | Eine URL wurde dauerhaft ersetzt oder eine Host-/HTTPS-Variante wird vereinheitlicht. | Ziel fachlich prüfen und interne Links sowie Sitemap direkt auf die endgültige URL umstellen. Unnötige Weiterleitungsschritte entfernen. |
| 302 / 307 | Temporäre Weiterleitung. | Eine vorübergehende Umleitung oder eine dauerhaft eingerichtete Regel mit falschem Status. | Prüfen, ob die Umleitung wirklich vorübergehend ist. Bei dauerhaftem Umzug einen passenden permanenten Redirect verwenden. |
| 401 Unauthorized | Gültige Anmeldung fehlt. | Login-Schutz, abgelaufene Zugangsdaten oder eine Authentifizierung vor dem Inhalt. | Bei öffentlichen Seiten versehentlichen Login-Schutz prüfen. Geschützte Bereiche bewusst geschützt lassen; sie gehören nicht in eine öffentliche Sitemap. |
| 403 Forbidden | Zugriff wird verweigert. | Berechtigungen, WAF-/Firewall-Regeln oder eine Sperre für bestimmte IPs oder Clients. | Server- und WAF-Logs für die konkrete Anfrage prüfen. Eine erfolgreiche Browser-Anfrage beweist noch nicht, dass der Checker oder Googlebot zugreifen kann. |
| 404 Not Found | Ressource nicht gefunden. | Eine falsche URL, ein entfernter Inhalt oder eine defekte Verlinkung. | Interne Links und Sitemap bereinigen. Nur bei einem passenden Ersatz weiterleiten; dauerhaft fehlende Seiten dürfen 404 liefern. |
| 410 Gone | Ressource bewusst entfernt. | Ein Inhalt wurde dauerhaft zurückgezogen. | URL aus Sitemap und internen Links entfernen. Einen fachlich passenden Ersatz gegebenenfalls direkt verlinken. |
| 429 Too Many Requests | Zu viele Anfragen. | Rate-Limit bei Server, CDN, WAF oder einem vorgeschalteten Dienst. | Falls vorhanden Retry-After beachten, Anfragerate reduzieren und Limits sowie Logs prüfen. 401/403 nicht als Ersatz zur Crawl-Drosselung verwenden. |
| 500 Internal Server Error | Interner Serverfehler. | Beispielsweise ein Anwendungsfehler, eine fehlerhafte Konfiguration oder ein erschöpftes Ressourcenlimit. | Anwendungs- und Serverlogs zum Abrufzeitpunkt prüfen. Kürzliche Deployments und Ressourcenverbrauch eingrenzen; nach der Korrektur erneut abrufen. |
| 502 Bad Gateway | Ungültige Antwort des vorgeschalteten Zielservers. | Ein Proxy oder Gateway erhält vom Upstream keine gültige Antwort. | Origin-Erreichbarkeit, Proxy-Konfiguration und Upstream-Logs abgleichen. Den Fehler zwischen CDN, Webserver und Anwendung lokalisieren. |
| 503 Service Unavailable | Dienst vorübergehend nicht verfügbar. | Wartung, Überlastung oder vorübergehend fehlende Kapazität. | Wartung und Kapazität prüfen, nach Möglichkeit Retry-After senden und die Rückkehr zu einer erfolgreichen Antwort kontrollieren. |
| 504 Gateway Timeout | Upstream antwortet nicht rechtzeitig. | Ein Gateway wartet zu lange auf Anwendung, Datenbank oder einen anderen vorgeschalteten Dienst. | Langsame Upstream-Anfragen und deren Logs untersuchen. Die Ursache beheben, bevor Zeitlimits pauschal erhöht werden. |
200 OK ist kein Beweis für eine intakte oder indexierte Seite
Der Checker misst HTTP-Antworten. Er bestätigt weder den Inhalt noch eine Indexierung bei Google und erkennt Soft-404-Seiten nicht zuverlässig. Öffnen Sie die finale URL, prüfen Sie den eigentlichen Seiteninhalt und vergleichen Sie bei Bedarf die URL-Prüfung in der Search Console.
Grundlagen: HTTP Semantics (RFC 9110), 429 und Retry-After (RFC 6585) und Googles Umgang mit HTTP-Statuscodes.
HTTP-Status mit curl gegenprüfen
Ersetzen Sie die Beispiel-URL durch Ihre Adresse. Der Befehl sendet eine GET-Anfrage, zeigt die Antwortheader und verwirft den Seiteninhalt. Weiterleitungen werden zunächst nicht verfolgt, damit der erste Status und ein mögliches Location-Ziel sichtbar bleiben.
curl --silent --show-error --dump-header - --output /dev/null 'https://example.com/'Weiterleitungen verfolgen
Ergänzen Sie --location --max-redirs 5. So sehen Sie die Antwortheader der einzelnen Weiterleitungen bis zur finalen Antwort. Unter Windows können Sie curl.exe und --output NUL verwenden.
HEAD und GET unterscheiden
curl -I verwendet HEAD statt GET. Manche Server behandeln diese Methoden unterschiedlich. Bei Abweichungen mit GET gegenprüfen und auch User-Agent, Cookies und mögliche IP-Sperren berücksichtigen.
Was bedeuten HTTP-Statuscodes für SEO?
200 OK bedeutet, dass eine URL erfolgreich erreichbar ist. Für indexierbare Seiten ist das meist der gewünschte Zustand.
3xx-Statuscodes zeigen Weiterleitungen an. In Sitemaps und internen Verlinkungen sollten möglichst direkt die finalen Ziel-URLs verwendet werden.
4xx-Fehler wie 404 oder 410 können auf gelöschte, falsch verlinkte oder fehlerhafte URLs hinweisen.
5xx-Fehler deuten auf Serverprobleme hin und sollten priorisiert untersucht werden, da sie Crawling und Indexierung behindern können.
Typische Probleme bei Sitemaps und URL-Listen
Beim Prüfen von XML-Sitemaps oder URL-Listen tauchen oft nicht nur einzelne Statuscode-Fehler auf, sondern wiederkehrende technische Muster. Gerade nach Relaunches, Migrationen, Deployments oder URL-Umstellungen lohnt es sich, diese Probleme systematisch zu erkennen und zu priorisieren.
Redirects in der Sitemap
In XML-Sitemaps sollten möglichst direkt die finalen Ziel-URLs stehen. 301- oder 302-Weiterleitungen in Sitemaps sind ein Hinweis darauf, dass alte URLs noch eingetragen sind oder Umstellungen nicht konsequent bereinigt wurden.
404- und 410-Fehler
Nicht erreichbare URLs in Sitemaps oder URL-Listen deuten häufig auf gelöschte Inhalte, fehlerhafte interne Verlinkung, alte Importdaten oder unvollständig bereinigte Migrationen hin. Diese URLs sollten priorisiert geprüft werden.
5xx-Fehler und instabile Ziel-URLs
Serverfehler sind besonders kritisch, weil sie Crawling, Indexierung und Erreichbarkeit direkt beeinträchtigen können. Wenn URLs aus der Sitemap 5xx-Statuscodes liefern, spricht das oft für Serverprobleme, Timeouts oder fehlerhafte Deployments.
Falsche finale Ziel-URLs
Auch wenn eine URL am Ende erfolgreich auf einer 200-Seite landet, kann die finale Ziel-URL problematisch sein – etwa bei unnötigen Zwischenschritten, falschen Sprachversionen, veralteten Pfaden oder unerwünschten Parametern.
HTTP/HTTPS- oder www-/non-www-Mix
In URL-Listen und Sitemaps finden sich häufig noch alte Varianten mit HTTP statt HTTPS oder gemischten Hostnamen mit und ohne www. Das führt zu unnötigen Redirects und zeigt, dass Canonical-, Redirect- oder Sitemap-Setups noch nicht sauber harmonisiert sind.
Probleme nach Relaunch oder Migration
Nach Domainwechseln, CMS-Migrationen oder URL-Änderungen bleiben oft alte Ziel-URLs, Redirect-Ketten oder fehlerhafte Sitemap-Einträge zurück. Ein Statuscode-Check hilft, solche Migrationsfehler schnell sichtbar zu machen.
Worauf Sie besonders achten sollten
- Sitemaps sollten möglichst nur indexierbare URLs mit 200 OK enthalten.
- Redirects in Sitemaps sind oft ein Zeichen für veraltete oder nicht bereinigte URL-Einträge.
- 4xx- und 5xx-Fehler sollten priorisiert geprüft und behoben werden.
- Die finale Ziel-URL ist entscheidend – nicht nur der erste Statuscode.
Status Code Checker für SEO, Relaunch und technische QA
Wer nach HTTP Statuscode, Status Code, URL Status Code Checker oder HTTP Status Code Checker sucht, will meist nicht nur eine Zahl sehen. Entscheidend ist, ob wichtige URLs direkt mit 200 OK erreichbar sind, ob Sitemaps alte Redirects enthalten und ob Fehlerseiten Rankings, interne Links oder Crawling belasten.
Deshalb zeigt der Check pro URL den Status, die Anzahl der Weiterleitungen und die finale Ziel-URL. So lassen sich typische SEO-Probleme schneller unterscheiden: harmloser Einzelredirect, kaputte Sitemap-URL, falsche Zielseite, Serverfehler oder Relaunch-Restbestand.
Schnell sehen, ob eine wichtige Landingpage direkt 200 OK liefert oder weiterleitet.
Mehrere URLs zeilenweise testen und 3xx-, 4xx- oder 5xx-Muster priorisieren.
Erkennen, ob XML-Sitemaps veraltete Redirects, 404/410-URLs oder Serverfehler enthalten.
Nicht nur den ersten Status sehen, sondern die finale Ziel-URL und unnötige Umwege bewerten.
Nach dem Statuscode zählen Canonical, Robots und Header-Signale für die Frage, ob eine Seite indexiert werden kann.
Header-Signale wie X-Robots-Tag, Content-Type oder Cache-Regeln ergänzen die Statuscode-Auswertung.
Wann reicht ein Statuscode Checker nicht mehr aus?
Mit dem HTTP Statuscode Checker prüfen Sie Sitemaps oder URL-Listen schnell auf technische Probleme. Wenn jedoch viele Redirects, 404-Fehler, inkonsistente Ziel-URLs oder weitere Indexierungsprobleme auftreten, reicht ein Einzeltool oft nicht mehr aus.
Dann ist ein vollständiger Website-Check sinnvoll, um auch interne Verlinkung, Canonicals, Meta Robots, Sitemaps, Weiterleitungen und weitere technische SEO-Signale im Zusammenhang zu prüfen.
FAQ: HTTP Statuscode Checker
Häufige Fragen rund um HTTP-Statuscodes, Redirects, XML-Sitemaps, URL-Listen und typische technische SEO-Probleme.
Was ist ein HTTP Statuscode?
Ein HTTP Statuscode ist die Antwort eines Servers auf eine URL-Anfrage. Typische Beispiele sind 200 OK für erfolgreich erreichbare Seiten, 301 oder 302 für Weiterleitungen, 404 für nicht gefundene Seiten und 5xx für Serverfehler.
Was bedeutet HTTP Statuscode 200?
200 OK bedeutet, dass die URL erfolgreich erreichbar ist. Für wichtige indexierbare Seiten, Landingpages und Sitemap-URLs ist das meistens der Zielzustand, sofern Canonical, Robots-Signale und Inhalt ebenfalls passen.
Warum sollte ich URLs aus meiner Sitemap prüfen?
Eine XML Sitemap sollte möglichst nur saubere, indexierbare URLs enthalten. Wenn dort Redirects, 404-Fehler, 410-Statuscodes oder 5xx-Probleme auftauchen, ist das oft ein Hinweis auf veraltete Einträge, Migrationsfehler oder unvollständig bereinigte URL-Strukturen.
Sind Redirects in einer Sitemap problematisch?
Häufig ja. In Sitemaps sollten möglichst direkt die finalen Ziel-URLs stehen. Redirects in einer Sitemap verursachen unnötige Zwischenschritte und zeigen oft, dass alte URLs noch eingetragen sind oder URL-Änderungen nicht konsequent nachgezogen wurden.
Wann sind 301 oder 302 Redirects problematisch?
301 steht in der Regel für eine dauerhafte Weiterleitung, 302 eher für eine temporäre Weiterleitung. Für SEO ist wichtig, dass Weiterleitungen sinnvoll eingesetzt werden und möglichst direkt auf die korrekte finale Ziel-URL führen. Problematisch werden Redirects vor allem in Sitemaps, in internen Links, als Ketten oder wenn eine temporäre 302-Weiterleitung eigentlich dauerhaft sein sollte.
Sollten 404-URLs in der Sitemap stehen?
Nein. Eine XML-Sitemap sollte Suchmaschinen auf aktuelle, indexierbare Zielseiten führen. 404- oder 410-URLs in der Sitemap sind meist veraltete Einträge und sollten entfernt oder, falls es eine passende Nachfolgeseite gibt, sauber weitergeleitet werden.
Was ist der Unterschied zwischen 404 und 410?
Beide Statuscodes zeigen an, dass eine URL nicht verfügbar ist. 404 bedeutet „nicht gefunden“, während 410 klarer signalisiert, dass eine Seite dauerhaft entfernt wurde. Für technische Analysen ist beides relevant, vor allem wenn solche URLs noch intern verlinkt oder in Sitemaps enthalten sind.
Warum sind 5xx-Fehler besonders kritisch?
5xx-Statuscodes deuten auf Serverprobleme hin. Sie können Crawling, Erreichbarkeit und Indexierung direkt beeinträchtigen und sollten deshalb priorisiert geprüft werden – besonders wenn sie bei vielen URLs oder bei wichtigen Seiten auftreten.
Warum ist die finale Ziel-URL wichtig?
Für technische SEO-Fragen reicht es oft nicht, nur den ersten Statuscode zu kennen. Entscheidend ist, wo eine URL nach Weiterleitungen tatsächlich landet. Gerade bei Redirects, Domainumstellungen, HTTP/HTTPS-Wechseln oder falschen Sprachversionen ist die finale Ziel-URL oft der eigentliche Knackpunkt.
Kann ich mit dem Tool eine komplette XML Sitemap prüfen?
Das Tool ist für XML-Sitemaps und URL-Listen gedacht und eignet sich gut für schnelle technische Prüfungen. Je nach Umfang und Limits ist es ideal für Bulk-Checks, ersetzt aber keinen vollständigen Website-Crawler oder ein umfassendes SEO-Audit für sehr große Websites.
Was ist der Unterschied zwischen HTTP Statuscode und Status Code?
Beides meint im SEO-Alltag dasselbe Signal: den Antwortcode, den ein Server für eine URL liefert. Der Checker deckt beide Suchweisen ab und zeigt neben dem Status Code auch Redirect-Anzahl, Fehler und finale Ziel-URL, damit die technische Einordnung leichter fällt.
Wie prüfe ich mehrere URLs auf ihren Status Code?
Sie können mehrere URLs zeilenweise einfügen oder direkt eine XML-Sitemap angeben. Für größere URL-Mengen empfiehlt sich eine Prüfung nach Seitentypen: Startseite, Kategorien, wichtige Landingpages, alte Ranking-URLs und Sitemap-URLs getrennt auswerten.
Was ist der Unterschied zwischen Statuscode Checker und Redirect Checker?
Mit dem HTTP Statuscode Checker prüfen Sie, welchen Status eine URL liefert und ob Weiterleitungen, Fehler oder finale Ziel-URLs auftreten. Ein Redirect Checker fokussiert sich stärker auf die Logik einzelner Weiterleitungen und Redirect-Ketten. Für Sitemaps oder größere URL-Listen ist der Statuscode Checker meist der breitere Einstieg.
Wann reicht ein Statuscode Checker nicht mehr aus?
Wenn viele Redirects, 404-Fehler, 5xx-Probleme, inkonsistente Ziel-URLs oder weitere technische Auffälligkeiten auftreten, reicht ein Einzeltool oft nicht mehr. Dann ist ein vollständiger Website-Check sinnvoll, um auch interne Verlinkung, Canonicals, Meta Robots, Sitemaps, Indexierung und weitere technische SEO-Signale im Zusammenhang zu prüfen.
Passende nächste Checks
Statuscodes dort prüfen, wo Umsatz und Rankings hängen
Ein einzelner 404 ist selten das Problem. Kritisch wird es, wenn wichtige Kategorien, Produktseiten, Ratgeber, alte Ranking-URLs oder Sitemap-URLs nach einem Relaunch nicht mehr direkt erreichbar sind. Der Statuscode Checker hilft, diese Fälle aus URL-Listen, Sitemaps, Crawl-Exports oder Redirect-Mappings schnell in umsetzbare Gruppen zu sortieren.
Alte URLs gegen neue Ziele prüfen, falsche Redirects erkennen und 404-Verluste vor dem Go-live abfangen.
Nur indexierbare 200-URLs gehören in die XML-Sitemap. Redirects, 404 und 5xx sind klare Pflegehinweise.
Interne Links auf Weiterleitungen oder Fehlerseiten kosten Crawl-Budget, Nutzervertrauen und oft auch Conversion.
5xx, Timeouts und inkonsistente Zielversionen sollten zuerst geprüft werden, weil sie Crawling direkt blockieren können.
Eine scheinbar erfolgreiche Fehlerseite erkennen
Praxisbeispiel · zur Veranschaulichung
Ausgangslage
Prüfen Sie eine nicht mehr vorhandene Produkt-URL.
Befund einordnen
HTTP 200 bestätigt nur eine erfolgreiche technische Antwort. Ein sichtbarer „Produkt nicht gefunden“-Text kann dennoch eine Soft-404-Situation sein.
Konkrete Änderung
Für endgültig entfernte Inhalte einen passenden 404/410 liefern oder bei echtem Ersatz gezielt weiterleiten.
Kontrolle und Grenze
Status und Seiteninhalt erneut prüfen. Für Inhaltsindizien den Soft 404 Checker ergänzen; Googles Einstufung in der Search Console prüfen.