HTTP-Statuscode einer Seite prüfen
KIT ruft eine einzelne URL auf und meldet den zurückgegebenen HTTP-Statuscode – etwa 200 für erreichbar, 301 für dauerhaft verschoben, 404 für nicht gefunden oder 500 für einen Serverfehler. Gedacht für eine schnelle Einzelprüfung, wenn keine wiederkehrende Überwachung nötig ist.
Online ausführen
Führen Sie dies mit Ihrem Konto auf unseren Servern aus. Kostenlose Tools laufen in Ihrem Browser; dieses wird zum oben genannten Preis von Ihrem KIT-Guthaben abgebucht.
Der Unterschied zur Erreichbarkeitsüberwachung
Während die Uptime-Überwachung eine Adresse wiederkehrend in festen Abständen prüft, liefert diese Funktion das Ergebnis einer einzelnen, sofortigen Abfrage – gedacht für den Moment, in dem eine schnelle Antwort reicht und keine dauerhafte Beobachtung eingerichtet werden soll, etwa bei einer einmaligen Kontrolle vor einer Veröffentlichung. Für ein einmaliges Ergebnis lohnt sich der Aufwand einer dauerhaften Überwachung meist ohnehin nicht, gerade wenn es nur um eine einzelne, kurzfristige Kontrolle geht.
Was der Statuscode verrät
Ein 200 zeigt, dass eine Seite normal ausgeliefert wird; ein 301 oder 302, dass sie an eine andere Adresse weiterleitet; ein 404, dass die Seite unter dieser Adresse nicht existiert; ein 500 oder 503, dass der Server selbst ein Problem hat. KIT gibt den rohen Code zurück, wie ihn der Server tatsächlich sendet, ohne ihn zu interpretieren oder zu beschönigen.
Wo das in der Praxis hilft
Vor der Veröffentlichung eines Links, bei der schnellen Kontrolle, ob eine gerade behobene Störung tatsächlich wieder erreichbar ist, oder beim Prüfen einer langen Liste von URLs auf tote Adressen liefert eine einzelne Statusabfrage die schnellste Antwort, ohne den Umweg über eine eigene Skript- oder Kommandozeilenlösung. Gerade bei einem technischen Support-Kontakt lässt sich mit einer einzigen Zahl oft schon der erste Verdacht bestätigen oder entkräften.
Was ein einzelner Code nicht zeigt
Geprüft wird ausschließlich der HTTP-Statuscode einer einzelnen Anfrage; ob der Inhalt der Seite inhaltlich korrekt ist, zeigt diese Funktion nicht. Für eine Liste vieler Adressen auf einmal eignet sich die Prüfung auf defekte Links besser, die eine ganze Seite samt aller enthaltenen Verweise durchsucht. Für eine belastbare Aussage über den eigentlichen Seiteninhalt braucht es deshalb immer einen zusätzlichen, inhaltlichen Prüfschritt.
Anwendungsfälle
Link vor der Veröffentlichung prüfen
Ein Redakteur prüft kurz vor der Veröffentlichung eines Artikels, ob ein verlinktes externes Dokument noch mit Statuscode 200 erreichbar ist.
Störung schnell bestätigen
Ein Support-Mitarbeiter prüft nach einer gemeldeten Kundenstörung sofort, welchen Statuscode die betroffene Seite gerade liefert, bevor er die IT-Abteilung informiert.
Alte Kampagnenlinks kontrollieren
Eine Marketingabteilung prüft, ob eine vor Monaten verschickte Kampagnen-URL noch mit 200 antwortet oder inzwischen ins Leere läuft.
Häufige Fragen
Was kostet eine Statusabfrage?
$0.002 pro geprüfter URL, unabhängig vom zurückgegebenen Code.
Wird bei der Prüfung ein Konto oder Login der Seite genutzt?
Nein, geprüft wird ausschließlich der öffentlich erreichbare Aufruf der Adresse, ohne Anmeldung.
Reicht diese Prüfung, oder brauche ich die Uptime-Überwachung?
Für eine einmalige Kontrolle reicht diese Funktion; für eine wiederkehrende Beobachtung über einen längeren Zeitraum eignet sich die Uptime-Überwachung besser.
Zeigt KIT auch die Zieladresse bei einer Weiterleitung?
Der Statuscode zeigt, dass weitergeleitet wird; für die vollständige Kette mit allen Zieladressen eignet sich die Weiterleitungsketten-Prüfung besser.
Brauche ich ein Konto oder eine Mitgliedschaft?
Weder noch. Sie zahlen einzeln pro Abfrage, über PayPal oder auf Rechnung nach Absprache.
Kann ich damit viele URLs auf einmal prüfen?
Diese Funktion ist für eine einzelne Adresse gedacht; für eine ganze Seite mit vielen Links eignet sich die Prüfung auf defekte Links besser.
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/web/status \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/status", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/status",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/status", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/status", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"url": "https://ejemplo.com"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.status",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |