Site Monitor

Site Monitor ist die kontinuierliche Health-Schicht über deinen Domains. Statt einmalig auditieren und vergessen, läufst du eine Domain im Dauerbetrieb: regelmäßige Crawls, Uptime-Checks, Statuscode-Beobachtung, Performance-Drift-Erkennung und Lighthouse-Scores. Jeder Monitor hat seinen eigenen Lebenszyklus mit Pause/Resume, Manual-Check-Trigger und Incident-Historie. Komplementär zum Page Deep Audit (einmalige Tiefenanalyse) und zum Content Audit (inhaltlich), Site Monitor ist die Infrastruktur-Linie.

Was es kann

• Monitor-Verwaltung — GET/POST /v1/site-monitor listet und legt neue Monitore an. GET/PUT/DELETE /v1/site-monitor/{id} für Detail, Update und Lösch-Workflow.
• Pause / Resume — Monitore sauber stoppen ohne sie zu löschen (POST /v1/site-monitor/{id}/pause und .../resume).
• Manual Check — POST /v1/site-monitor/{id}/check-now triggert sofort einen außerplanmäßigen Check.
• Check-Historie — GET /v1/site-monitor/{id}/checks listet alle Crawls mit Statuscode, Antwortzeit, Headers.
• Incidents — GET /v1/site-monitor/{id}/incidents zeigt erkannte Ausfälle und Statuscode-Änderungen mit Start/Ende.
• Lighthouse — GET /v1/site-monitor/{id}/lighthouse liefert Performance-, Accessibility-, SEO- und Best-Practices-Scores im Zeitverlauf.
• Team-scoped — alle Monitore gehören zum aktuellen Team; Cross-Team → 404.

Wann nutzen

• Du betreibst Production-Domains und willst über Statuscode-Drift (200 → 503), Redirect-Loops oder TLS-Probleme sofort Bescheid wissen.
• Du veröffentlichst regelmäßig Content und willst Performance-Regression (Lighthouse-Score-Abfall) früh sehen.
• Du willst eine Audit-Spur: „seit wann ist diese URL down?" → der Incident-Endpoint hat die Antwort.
• Du willst Uptime-Reports für Kunden — die Check-Historie ist die Datenbasis.

Workflow

1. Monitor anlegen — POST /v1/site-monitor mit URL, Frequenz und gewünschten Checks (HTTP, Lighthouse).
2. Checks beobachten — der Monitor läuft autonom; GET /v1/site-monitor/{id}/checks zeigt die Historie.
3. Incidents reviewen — bei Problemen liefert GET /v1/site-monitor/{id}/incidents Start, Ende, Statuscode-Übergang.
4. Lighthouse-Drift — GET /v1/site-monitor/{id}/lighthouse zeigt Scores im Zeitverlauf; signifikante Abfälle sind ein klarer Refactor-Trigger.
5. Pause / Resume / Manual — bei Wartungsarbeiten pausieren; nach Deploys einen check-now triggern, um die neue Baseline zu setzen.

Bei tiefer Einzelseiten-Diagnose wechsle ins Page Deep Audit — dort gibt es Vision-Analyse, KI-Renders und Persona-Bewertung. Site Monitor ist die kontinuierliche Schicht, Page Deep Audit die punktuelle.

API

Beispiel-Body für POST /v1/site-monitor:

{
  "url": "https://rankion.ai",
  "frequency": "hourly",
  "checks": ["http", "lighthouse"]
}

Credits & Limits

• Read & Steuerung: alle Endpoints credit-frei. Site Monitor ist eine Subscription-Funktion, nicht pay-per-use.
• Frequenz-Caps: typische Stufen sind hourly/daily/weekly — abhängig vom Plan.
• Lighthouse: Mobile-Profile per Default; Desktop-Variante optional.
• Incident-Schwelle: Defaults erkennen 5xx-Codes, Timeout >30s und unerwartete Redirects als Incident.
• Team-scoped: Cross-Team-IDs → 404.

Verwandte Module

• Page Deep Audit — punktuelle Tiefenanalyse einer einzelnen Landingpage; Site Monitor liefert die Trigger („Lighthouse-Drift erkannt → Audit starten").
• Content Audit — inhaltliche Probleme (Duplicate, Thin Content); Site Monitor erkennt infrastrukturelle.
• Action Center — aus Incidents lassen sich Todos generieren.
• Google Integrations — kombiniert mit GSC siehst du, wann ein Statuscode-Problem auch zu Crawling-Drops führt.