Websites hinter einer Anmeldung überwachen

Eine Staging- oder Pre-Launch-Website ist oft mit HTTP-Basic-Auth geschützt oder mit einer Firewall, die nur Anfragen mit einem geheimen Header durchlässt. Die Prüfungen deines Monitors brauchen einen Weg an dieser Anmeldung vorbei, sonst sehen sie immer nur die Anmeldeseite.

Der Website-Zugang ist dieser Weg. Du legst ihn einmal pro Monitor fest, und jede Prüfung, die die Website abruft, verwendet ihn.

Einrichten

1. Öffne den Monitor und wechsle zum Tab Einstellungen.
2. Schalte unter Website-Zugang die HTTP-Basic-Auth ein und gib Benutzername und Passwort ein und/oder füge Zugangs-Header hinzu (zum Beispiel X-Access-Token: …).
3. Klick auf Speichern. Die Prüfungen verwenden ihn ab ihrem nächsten Lauf. Jetzt ausführen bei einer Prüfung zeigt das Ergebnis sofort.

Welche Prüfungen ihn verwenden

Uptime (auch die Gegenprüfung von einem zweiten Standort), robots.txt, Sitemap, Weiterleitungen, Security-Header, Mixed Content, GEO-Audit, Application Health, defekte Links und Lighthouse.

SSL, DNS, Domain-Ablauf, DNSBL, TCP, Ping und Core Web Vitals rufen deine Seiten nie ab und brauchen ihn deshalb nicht.

Die Uptime-Prüfung kann in ihren Einstellungen eigene Basic-Auth-Daten und Header haben. Sie ersetzen den Website-Zugang des Monitors nur für diese Prüfung, zum Beispiel wenn die Uptime-Prüfung einen Health-Endpunkt mit anderen Zugangsdaten abfragt.

Wohin er gesendet wird und wohin nicht

Der Website-Zugang wird nur an die Adresse deines Monitors gesendet: dasselbe Schema, derselbe Host und derselbe Port wie die Monitor-URL (https://staging.example.com). Jede Anfrage wird einzeln geprüft:

• Eine Weiterleitung auf einen anderen Host bekommt ihn nie. Ein Wechsel von https zu http auf demselben Host auch nicht.
• Lighthouse lädt deine Seite in Chrome. Ressourcen von Drittanbietern, die die Seite lädt (Schriften, Analytics, ein CDN), bekommen deine Zugangsdaten nie, und Chrome beantwortet eine Anmeldeaufforderung nur, wenn sie von deiner Website kommt.
• Der Crawler für defekte Links sendet ihn nur an Seiten deiner Website, nie an externe Links.
• Eine Prüfung, die nach einem Zertifikatsfehler ohne Zertifikatsprüfung wiederholt, sendet ihn nicht.

Sicher gespeichert

Das Passwort und jeder Wert eines Zugangs-Headers werden verschlüsselt gespeichert und nie wieder angezeigt: Dashboard und API zeigen ********. Wer ******** zurückschickt, behält den gespeicherten Wert. Auch Datenexporte zeigen sie maskiert.

Was die Ergebnisse bedeuten

Ergebnis	Bedeutung
Konnte nicht prüfen: Die Website verlangt eine Anmeldung (HTTP 401)	Die Website braucht eine Anmeldung, und der Monitor hat keinen Website-Zugang. Kein Alarm, und der Lauf zählt in keiner Kennzahl. Richte den Website-Zugang ein.
Die Website hat den Website-Zugang dieses Monitors abgelehnt (HTTP 401)	Der Website-Zugang wurde gesendet, aber die Website hat ihn abgelehnt. Wahrscheinlich hat sich das Passwort geändert. Das ist eine normale Warnung.

API und MCP

Der Website-Zugang ist das Feld site_access eines Monitors: PATCH /api/v1/monitors/{id} mit

{
  "site_access": {
    "http_auth": { "username": "staging", "password": "…" },
    "headers": { "X-Access-Token": "…" }
  }
}

null entfernt ihn, "http_auth": null entfernt nur die Basic-Auth. Das MCP-Tool update-monitor nimmt dasselbe Feld an. Beim Lesen kommen die Werte immer maskiert zurück.