Umsatzwebsites
Überwachen Sie Shop, Buchungsseite, Abonnementprodukt oder Lead-Website regelmäßig auf externe Verfügbarkeit.
Überwachen Sie Ihre öffentliche Projekt-URL, prüfen Sie 30-Tage-Verfügbarkeit und Antwortzeiten und untersuchen Sie fehlgeschlagene HTTP-Prüfungen. Nutzen Sie Vorfallsverlauf und berechtigte E-Mail-Meldungen in Ihrem SEO-Alltag.
Aktivieren Sie regelmäßige Verfügbarkeitsprüfungen für die öffentliche Projekt-URL. Wählen Sie zuerst ein sinnvolles Ziel für Ihre Besucher.
example.com60 s
Erkennen Sie, welcher Anteil der Prüfungen in den letzten 30 Tagen erfolgreich war. Berücksichtigen Sie auch Prüfungsanzahl und letzten Zeitpunkt.
Uptime
93,8 %Erkennen Sie langsamere Antworten und wiederholte Fehler im Verlauf. Eine erreichbare URL kann trotzdem langsam antworten.
Antwortzeit
240 msPrüfen Sie die acht neuesten Ergebnisse mit Status, Zeitpunkt, HTTP-Code und Antwortzeit gegen das erwartete Verhalten Ihrer URL.
HTTP-Status
200GET /HTTP/2 200Verfolgen Sie einen Ausfall vom ersten fehlgeschlagenen bis zu einem späteren erfolgreichen Check. Ursachen erfordern eine separate Untersuchung.
Zeitraum
12 minSenden Sie berechtigte Ausfallmeldungen an Projektmitglieder und eine zusätzliche optionale Adresse. Vorfälle werden bereits vor der E-Mail-Berechtigung erfasst.
Projektexample.com
PrüfungLassen Sie einen verbundenen KI-Assistenten gespeicherte Ergebnisse eines zugänglichen Projekts erklären. Der Zeitstempel unterscheidet vorhandene Daten von einer neuen Prüfung.
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Teilen Sie Verfügbarkeitsdaten in einem gespeicherten SEO-Bericht. Ein Berichtsschnappschuss unterscheidet sich vom laufenden Monitoring.
aACMEBerichtPDF
Lesen Sie mit SEO MCP gespeicherte 30-Tage-Uptime und aktuelle Status-/Antwortdaten. Prüfen Sie den Zeitstempel, bevor Sie den letzten Status als aktuelle Verfügbarkeit deuten; die Antwort enthält keine Vorfallsliste oder HTTP-Codes.
Wählen Sie ein öffentliches Ziel, aktivieren Sie Monitoring und richten Sie ein verantwortliches Postfach ein. Untersuchen Sie fehlgeschlagene Checks und bestätigen Sie eine spätere erfolgreiche Prüfung.
Verwenden Sie die vorgesehene öffentliche Projekt-URL ohne Login-Pflicht. Prüfen Sie Weiterleitungsziele separat, da Uptime-Prüfungen Weiterleitungen nicht verfolgen.
Aktivieren Sie Monitoring in den Projekteinstellungen, speichern Sie Intervall und optionale Adresse und bestätigen Sie berechtigten bezahlten Zugang sowie aktuelle Checks.
Lesen Sie Status, letzten Check, HTTP-Ergebnisse und Vorfallsdetails. Kritische Fehler benötigen zeitnahe Untersuchung; der 30-Tage-Wert liefert Kontext, keinen Grund zu warten.
Vergleichen Sie Fehler mit Deployment-, DNS-, TLS-, Hosting- und Anwendungsprotokollen. Bestätigen Sie einen erfolgreichen Check; ein gelöster Vorfall bestätigt nicht jeden Besucherpfad.
Nutzen Sie wiederkehrende Checks für Projekte, bei denen Verfügbarkeit Verkäufe, Leads, Kampagnen, Kundenzugriff oder das Abrufen öffentlicher Inhalte durch Suchcrawler beeinflusst.
Überwachen Sie Shop, Buchungsseite, Abonnementprodukt oder Lead-Website regelmäßig auf externe Verfügbarkeit.
Beobachten Sie die öffentliche Website, die Suchcrawler und organische Besucher erreichen müssen, bevor Content- oder Rankingarbeit Wirkung zeigt.
Verfolgen Sie die Projektwebsite während Launches, Migrationen, Redesigns und aktiver Kampagnen, wenn ein Verfügbarkeitsproblem sofort mehr kostet.
Prüfen Sie die Uptime jedes Screpy-Projekts getrennt, damit Agenturen und interne Teams Kunden- oder Markenwebsites in einem Workflow verwalten.
Screpy liefert externe HTTP-Nachweise und Vorfallverlauf für die konfigurierte Projektwebsite. Bei weitergehenden Fragen benötigen Sie Infrastruktur, Logs, Transaktionstests und Suchdaten.
Uptime Monitoring prüft die öffentliche Website-URL des Screpy-Projekts. Es ist keine allgemeine Liste unabhängiger Endpunkt-Monitore.
Das Ergebnis beschreibt, ob das öffentliche Ziel antwortete. CPU, Speicher, Container, Datenbanken, private Netzwerke und Serverlogs werden nicht geprüft.
HTTP-Status, Zeit und Vorfallzeitpunkte grenzen die Untersuchung ein, beweisen aber nicht, ob DNS, TLS, Hosting, Deployment, Firewall oder Anwendungscode die Ursache war.
Eine funktionierende öffentliche Seite ist für Besucher und Crawling nötig, aber eine hohe Uptime garantiert keine Indexierung, Rankings, Besucher, Umsätze oder Conversions.
Überwachen Sie Erreichbarkeit über die Zeit, prüfen Sie die gesamte Website bei wiederkehrenden Fehler- oder Crawlingmustern oder untersuchen Sie Seitenleistung nach stabiler Verfügbarkeit.
Prüfen Sie stichprobenbasierte 30-Tage-Uptime, Antwortzeiten, HTTP-Ergebnisse und gespeicherte Vorfälle der öffentlichen Projekt-URL.
Crawlen Sie die Website, um wiederkehrende Fehlerseiten, Weiterleitungsprobleme, defekte Ziele und technische Muster rund um eine Verfügbarkeitsstörung zu finden.
Führen Sie wiederkehrende Laborprüfungen aus, wenn die Website erreichbar ist, aber Ladezeit oder Reaktionsfähigkeit noch untersucht werden müssen.
Screpy-Dokumentation
Lernen Sie öffentliche Ziele auszuwählen, Monitoring und Meldungen einzurichten, Antwortzeiten zu interpretieren und Vorfälle zu untersuchen.
Antworten zu Stichproben, inaktiven Projekten, Weiterleitungen, fehlenden Prüfungen, E-Mail-Berechtigung und Seitenperformance.
Eine spätere fehlgeschlagene Prüfung eines offenen Vorfalls kann bei 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 oder 526 eine E-Mail auslösen. Empfänger sind Projektmitglieder und eine optionale abweichende Adresse. Ausfall und Wiederherstellung sind separat auf je eine E-Mail pro Projekt und 24 Stunden begrenzt. Unterdrückte Vorfälle werden später nicht erneut gemeldet; Wiederherstellung erfordert eine zuvor ununterdrückte Ausfallmeldung. Timeouts, Fehler ohne Code und andere Codes qualifizieren nicht.
Einstellungen akzeptieren 1–60 Minuten; bezahlter Zugang ist erforderlich. Innerhalb eines Tages nach Teamaktivität gilt das konfigurierte Intervall. Danach mindestens 10 Minuten, nach sieben Tagen mindestens 60 Minuten. Nach 30 inaktiven Tagen stoppen geplante Prüfungen. Prüfen Sie stets den tatsächlichen letzten Zeitpunkt.
HTTP 200–399 gilt als erreichbar, andere HTTP-Antworten als nicht erreichbar; Timeout und Anfragefehler bleiben eigene Zustände. Weiterleitungen werden nicht verfolgt und Inhalte nicht geprüft. Ein Redirect oder eine HTTP-200-Fehlerseite kann als erreichbar gelten, ohne die gewünschte Seite zu bestätigen.
Nein. Screpy prüft ein öffentliches HTTP(S)-Ziel, keine private Infrastruktur, Login- oder Checkout-Transaktionen, Seiteninhalte oder geografische Verfügbarkeit. Es diagnostiziert keine Ursache. Nutzen Sie dafür Protokolle und gezielte Prüfungen.
Screpy speichert Status, verfügbaren HTTP-Code, Antwortzeit und Zeitpunkt einer öffentlichen Projekt-URL. Das Dashboard nutzt 30-Tage-Prüfungen für Uptime und Antwortmittelwerte, zeigt acht aktuelle Checks und separat zeitübergreifende Vorfallszahlen sowie die fünf neuesten Vorfälle.
Ja. Das Diagramm lädt bis zu 160 aktuelle Antworten aus 30 Tagen; kleinere Bildschirme zeigen weniger. Der Fünf-Prüfungen-Trend unterscheidet sich vom 30-Tage-Mittel erfolgreicher Checks. HTTP-Antwortzeit misst weder Rendering noch Besucherinteraktion.
Der erste Fehler öffnet den Vorfall, weitere halten ihn offen, die nächste erfolgreiche Prüfung löst ihn. Das Dashboard zeigt Status, Beginn und Details; berechtigte Wiederherstellungs-E-Mails enthalten die gespeicherte Dauer. Stichproben bestimmen weder den exakten Beginn noch jeden kurzen Ausfall.
Anhaltende Serverfehler können Crawling verlangsamen und Inhaltsabruf verhindern. Ein erfolgreicher Screpy-Check beweist weder Googlebot-Zugriff noch Redirect-Ziel, Indexierung oder Rankings. Prüfen Sie die URL zusätzlich mit Crawl- und Suchdaten.
Ein umfassendes SEO-Toolkit zu einem angenehm günstigen Preis.