Website-Uptime-Monitoring für SEO- und Umsatzseiten

Ü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.

Website-Uptime überwachen Pläne vergleichen
Screpy-Uptime-Dashboard mit aktuellem Status, 30-Tage-Uptime, Antwortzeitverlauf, letzten Checks und Vorfällen
Uber-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Philips-Logo im Vertrauensbereich der Screpy-SEO-Plattform
FedEx Express-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Bosch-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Champion-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Iconfinder-Logo im Vertrauensbereich der Screpy-SEO-Plattform
T-Mobile-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Carrefour-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Stanley-Logo im Vertrauensbereich der Screpy-SEO-Plattform
Skoda-Logo im Vertrauensbereich der Screpy-SEO-Plattform

Website-Uptime einrichten

Aktivieren Sie regelmäßige Verfügbarkeitsprüfungen für die öffentliche Projekt-URL. Wählen Sie zuerst ein sinnvolles Ziel für Ihre Besucher.

  • Jedes Projekt überwacht eine HTTP- oder HTTPS-URL, keine separate Liste von Endpunkten.
  • Projekteinstellungen steuern Aktivierung, ein Intervall von 1–60 Minuten und eine optionale Benachrichtigungsadresse.
  • Geplante Prüfungen benötigen einen aktiven berechtigten Bezahltarif; Standardintervalle unterscheiden sich.
  • Bei Inaktivität des Projektteams verlängern sich Intervalle; nach 30 inaktiven Tagen stoppen die Prüfungen.
  • Letzte Prüfung zeigt die Aktualität; das konfigurierte Intervall garantiert keinen exakten Ausführungszeitpunkt.

Uptime-Prozentwert verstehen

Erkennen Sie, welcher Anteil der Prüfungen in den letzten 30 Tagen erfolgreich war. Berücksichtigen Sie auch Prüfungsanzahl und letzten Zeitpunkt.

  • Uptime entspricht erfolgreichen Prüfungen geteilt durch alle gespeicherten Prüfungen, mal 100.
  • Aktueller Status stammt aus der letzten abgeschlossenen Prüfung dieses Zeitraums.
  • Ohne Prüfungsdaten bleibt das Ergebnis unverfügbar, statt 100 % anzuzeigen.
  • Der Wert beruht auf Stichproben; er lässt sich nicht direkt in Ausfallminuten oder ein zeitgewichtetes SLA umrechnen.

Website-Antwortzeiten verfolgen

Erkennen Sie langsamere Antworten und wiederholte Fehler im Verlauf. Eine erreichbare URL kann trotzdem langsam antworten.

  • Das Diagramm verwendet bis zu 160 aktuelle Prüfungen aus 30 Tagen; die Bildschirmbreite bestimmt den sichtbaren Ausschnitt.
  • Die Trendlinie mittelt fünf Prüfungen; die durchschnittliche Antwortzeit nutzt erfolgreiche Prüfungen des gesamten 30-Tage-Zeitraums.
  • Gemessen wird HTTP-Antwortlatenz, nicht vollständiges Laden, Core Web Vitals oder ein Besucherablauf.

HTTP-Statusprüfungen ansehen

Prüfen Sie die acht neuesten Ergebnisse mit Status, Zeitpunkt, HTTP-Code und Antwortzeit gegen das erwartete Verhalten Ihrer URL.

  • HTTP 200–399 gilt als erreichbar; andere HTTP-Antworten als nicht erreichbar. Timeout und Fehler werden getrennt gespeichert.
  • Weiterleitungen werden nicht verfolgt; ein 3xx-Ergebnis bestätigt das Ziel nicht.
  • Prüfungen verwenden HEAD und wiederholen bei 405 oder 501 mit GET; bei Verbindungsfehlern kann der HTTP-Code fehlen.
  • Ein erfolgreicher Status bestätigt weder Inhalt noch Formulare oder Checkout; auch eine Fehlerseite mit HTTP 200 kann als erreichbar gelten.

Website-Ausfälle prüfen

Verfolgen Sie einen Ausfall vom ersten fehlgeschlagenen bis zu einem späteren erfolgreichen Check. Ursachen erfordern eine separate Untersuchung.

  • Der erste Fehler öffnet einen Vorfall, weitere Fehler aktualisieren ihn, die erste erfolgreiche Prüfung löst ihn.
  • Das Dashboard zeigt offene und gelöste Vorfälle über alle Zeiträume sowie die fünf neuesten mit Status, Beginn und Details.
  • Vorfallszeiten folgen Prüfungen, nicht dem exakten Beginn zwischen Stichproben; kurze Ausfälle können unbemerkt bleiben.

Ausfall-E-Mails erhalten

Senden Sie berechtigte Ausfallmeldungen an Projektmitglieder und eine zusätzliche optionale Adresse. Vorfälle werden bereits vor der E-Mail-Berechtigung erfasst.

  • Ein späterer Fehler desselben Vorfalls kann bei unterstützten Codes wie 404, 500 oder 503 eine E-Mail auslösen.
  • Timeouts, Verbindungsfehler und nicht unterstützte HTTP-Codes werden erfasst, lösen diese E-Mails aber nicht aus.
  • Pro Projekt gelten separate Grenzen von einer Ausfall- und einer Wiederherstellungs-E-Mail je 24 Stunden.
  • Wiederherstellungs-E-Mails erfordern einen zuvor gemeldeten, nicht unterdrückten Vorfall; die gespeicherte Dauer beweist keine exakte Besucherausfallzeit.

Uptime-Daten über SEO MCP lesen

Lassen Sie einen verbundenen KI-Assistenten gespeicherte Ergebnisse eines zugänglichen Projekts erklären. Der Zeitstempel unterscheidet vorhandene Daten von einer neuen Prüfung.

  • SEO MCP liefert 30-Tage-Status, Uptime-Prozentwert, Mittelwert erfolgreicher Prüfungen und letzten Check.
  • Bis zu 160 aktuelle Datensätze enthalten Status, Antwortzeit und Zeitpunkt, aber keine HTTP-Codes oder Vorfälle.
  • Der Lesezugriff startet keine neue Prüfung und diagnostiziert oder behebt keinen Ausfall; fehlende Ergebnisse bleiben unverfügbar.

Uptime in SEO-Berichte aufnehmen

Teilen Sie Verfügbarkeitsdaten in einem gespeicherten SEO-Bericht. Ein Berichtsschnappschuss unterscheidet sich vom laufenden Monitoring.

  • Das Widget enthält 30-Tage-Prüfstatistiken, aktuelle Checks und Vorfälle, die den Berichtszeitraum überschneiden.
  • Vorfallszahlen können von den zeitübergreifenden Dashboard-Zahlen abweichen; gelöste Vorfälle können eine gespeicherte Dauer enthalten.
  • Der Bericht erfasst gespeicherte Daten bei seiner Erstellung und sendet keine Live-Ausfallmeldungen.

Über Uptime-Monitoring sprechen. Mit SEO MCP.

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.

  1. Screpy: Hallo! Sehen wir uns Uptime-Monitoring für example.com an. Was möchten Sie wissen?
  2. Sie: Erkläre gespeicherte Uptime und letzten Prüfzeitpunkt für example.com.
  3. Screpy: Illustratives gespeichertes Ergebnis: Der Check um 10:18 UTC meldete erreichbar, mit 99,95 % erfolgreichen Checks über 30 Tage. Der Anteil ist stichprobenbasiert und beweist keine aktuelle Erreichbarkeit. Nutzen Sie Dashboard-Vorfälle und Hosting-Protokolle für Ausfalluntersuchungen. Gespeicherte Uptime: Letzte Prüfung: 10:18 UTC. 30-Tage-Uptime: 99,95 %.
  4. Sie: Mach daraus einen kurzen Maßnahmenplan.
  5. Screpy: Ich trenne Befunde und Empfehlungen. Prüfen Sie die Belege, wählen Sie eine Änderung und kontrollieren Sie anschließend die Ergebnisse. Ihre nächsten Schritte: Prüfen: Quelle und Datum jedes Befunds kontrollieren.. Entscheiden: Die erste Änderung auswählen.. Verifizieren: Ergebnisse nach der Änderung vergleichen..
  6. Sie: Kannst du die Belege verständlich erklären?
  7. Screpy: Ja. Fragen Sie nach einem unterstützten Ergebnis. Ich erkläre, was es zeigt, woher es stammt und was unklar bleibt. Fehlende Daten bleiben nicht verfügbar; Empfehlungen sind keine automatischen Korrekturen.

Richten Sie einen nützlichen Uptime-Überwachungskreislauf ein.

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.

  1. Öffentliche Projektwebsite-URL verwenden

    Verwenden Sie die vorgesehene öffentliche Projekt-URL ohne Login-Pflicht. Prüfen Sie Weiterleitungsziele separat, da Uptime-Prüfungen Weiterleitungen nicht verfolgen.

  2. Checks und Intervall konfigurieren

    Aktivieren Sie Monitoring in den Projekteinstellungen, speichern Sie Intervall und optionale Adresse und bestätigen Sie berechtigten bezahlten Zugang sowie aktuelle Checks.

  3. Neueste fehlgeschlagene Checks untersuchen

    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.

  4. Untersuchung und Wiederherstellung bestätigen

    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.

Priorisieren Sie Websites, bei denen Ausfallzeit echte Kosten verursacht.

Nutzen Sie wiederkehrende Checks für Projekte, bei denen Verfügbarkeit Verkäufe, Leads, Kampagnen, Kundenzugriff oder das Abrufen öffentlicher Inhalte durch Suchcrawler beeinflusst.

Umsatzwebsites

Überwachen Sie Shop, Buchungsseite, Abonnementprodukt oder Lead-Website regelmäßig auf externe Verfügbarkeit.

Organische Suchauftritte

Beobachten Sie die öffentliche Website, die Suchcrawler und organische Besucher erreichen müssen, bevor Content- oder Rankingarbeit Wirkung zeigt.

Launch- und Kampagnenseiten

Verfolgen Sie die Projektwebsite während Launches, Migrationen, Redesigns und aktiver Kampagnen, wenn ein Verfügbarkeitsproblem sofort mehr kostet.

Portfolios mit mehreren Projekten

Prüfen Sie die Uptime jedes Screpy-Projekts getrennt, damit Agenturen und interne Teams Kunden- oder Markenwebsites in einem Workflow verwalten.

Kennen Sie die Grenzen eines Uptime-Ergebnisses.

Screpy liefert externe HTTP-Nachweise und Vorfallverlauf für die konfigurierte Projektwebsite. Bei weitergehenden Fragen benötigen Sie Infrastruktur, Logs, Transaktionstests und Suchdaten.

Ein Ziel pro Projektwebsite

Uptime Monitoring prüft die öffentliche Website-URL des Screpy-Projekts. Es ist keine allgemeine Liste unabhängiger Endpunkt-Monitore.

Externer Check, keine Infrastrukturtelemetrie

Das Ergebnis beschreibt, ob das öffentliche Ziel antwortete. CPU, Speicher, Container, Datenbanken, private Netzwerke und Serverlogs werden nicht geprüft.

Vorfallnachweis, kein Ursachenbeweis

HTTP-Status, Zeit und Vorfallzeitpunkte grenzen die Untersuchung ein, beweisen aber nicht, ob DNS, TLS, Hosting, Deployment, Firewall oder Anwendungscode die Ursache war.

Verfügbarkeit ist keine SEO-Garantie

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.

Nutzen Sie den Website-Gesundheitsworkflow, der zum Fehler passt.

Ü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.

Screpy-Dokumentation

Lernen Sie, die Website-Uptime zu überwachen

Lernen Sie öffentliche Ziele auszuwählen, Monitoring und Meldungen einzurichten, Antwortzeiten zu interpretieren und Vorfälle zu untersuchen.

Uptime-Monitoring-Leitfaden lesen

Fragen zum Website-Uptime-Monitoring, beantwortet.

Antworten zu Stichproben, inaktiven Projekten, Weiterleitungen, fehlenden Prüfungen, E-Mail-Berechtigung und Seitenperformance.

Sendet Screpy Ausfallwarnungen?

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.

Wie oft prüft Screpy die Website-Uptime?

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.

Was zählt Screpy als verfügbar oder nicht verfügbar?

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.

Ersetzt Uptime Monitoring Server- oder Transaktionsmonitoring?

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.

Was misst Screpy Uptime Monitoring?

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.

Zeigt Uptime Monitoring den Antwortzeitverlauf?

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.

Wie funktionieren Ausfallvorfälle und Wiederherstellung?

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.

Kann ein Websiteausfall Crawling oder Indexierung beeinflussen?

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.

Stark in SEO. Schonend fürs Portemonnaie.

Ein umfassendes SEO-Toolkit zu einem angenehm günstigen Preis.

  • Technische Audits, Ranking-Tracking und KI-Sichtbarkeit
  • Keyword-Recherche, Backlink-Analyse und Verfügbarkeitsüberwachung
  • Ein Arbeitsbereich. Flexible Tarife. Weniger Ausgaben.