Eine Website kann „online“ und trotzdem defekt sein: Der Server antwortet mit HTTP 200, doch die Seite zeigt einen Datenbankfehler, eine leere Produktliste oder die Standardseite des Hosters. Ein Check, der nur auf den Statuscode schaut, lässt all das durchgehen. Keyword-Monitoring schließt diese Lücke, indem es auch den Inhalt prüft: Text, der auf der Seite stehen muss, etwa „In den Warenkorb“, oder Text, der dort nicht stehen darf, etwa „Fatal error“. Ist die Bedingung nicht erfüllt, gilt die Seite als down und Sie erhalten einen Alarm.
Wie eine Website online und trotzdem defekt sein kann
Den Statuscode setzt die Komponente, die auf die Anfrage antwortet – und das ist nicht immer der Teil des Stacks, der ausgefallen ist. All das passiert mit einer 200 oder mit einem Code, den Ihr Monitor akzeptiert:
Eine Fehlerseite der Anwendung. Manche Frameworks, Themes und eigene Fehlerseiten geben Fehler mit 200 statt mit einem 5xx-Code aus.
Eine leere Seite. Ein PHP Fatal Error bei ausgeschalteter Fehleranzeige kann einen leeren Body erzeugen, oder ein Cache speichert eine leere Seite und liefert sie aus.
Fehlende Daten. Der Shop lädt, aber die Produkt-API dahinter ist ausgefallen, sodass jede Kategorie „Keine Produkte gefunden“ meldet.
Die falsche Website. Nach einem Hosting- oder DNS-Wechsel landet die Domain auf einer Standardseite wie „Welcome to nginx!“ oder einer Parkseite.
Eine vergessene Wartungsseite. Ein Wartungsmodus-Plugin, das mit 200 statt 503 antwortet, sieht für einen Status-Check wie eine funktionierende Website aus.
Eine verunstaltete oder manipulierte Seite. Ein Angreifer ersetzt Inhalte oder fügt Spam-Links ein, und der Server antwortet weiter ganz normal.
Google nennt eine Seite, die „nicht gefunden“ meldet oder nichts anzeigt und dabei mit 200 antwortet, einen Soft 404, und solche Seiten können aus der Suche fliegen. Nutzer sehen einfach eine kaputte Website.
So funktioniert Keyword-Monitoring
Bei jedem Check ruft der Monitor die Seite ab, liest das HTML, das der Server zurückgibt, und durchsucht es nach Ihrem Text. Es gibt zwei Modi:
Muss enthalten: Der Check schlägt fehl, wenn der Text fehlt. Nutzen Sie ihn als Beleg dafür, dass die Seite funktioniert, etwa mit einer Button-Beschriftung oder einem Produktnamen.
Darf nicht enthalten: Der Check schlägt fehl, wenn der Text auftaucht. Nutzen Sie ihn für bekannte Fehlermeldungen.
Zwei Details sind wichtig. Der Check liest den HTML-Quelltext, nicht die Seite, die Sie im Browser sehen – Text, den JavaScript erst später einfügt, ist also nicht da. Und der Abgleich ist meist exakt, inklusive Groß- und Kleinschreibung. Die Kurzdefinition finden Sie im Glossareintrag zu Keyword-Monitoring.
So wählen Sie ein gutes Keyword
Ein gutes „Muss enthalten“-Keyword erscheint nur, wenn die Seite funktioniert, und bleibt von Tag zu Tag gleich. Damit scheiden Preise, Datumsangaben, Lagerbestände, Zähler und alles aus, was gerade in einem A/B-Test läuft. Nehmen Sie lieber Text, den die Anwendung aus ihren Daten oder Templates rendert und der deshalb verschwindet, wenn die Anwendung ausfällt, als Text in einem statischen Header, den ein Cache weiter ausliefern könnte.
SeiteMuss enthaltenWarum es funktioniertProduktseiteIn den WarenkorbWird nur gerendert, wenn Produkt und Warenkorb funktionierenKategorieseiteEin Produktname, der immer vorrätig istFehlt, wenn die Produktdaten nicht ladenLogin-SeitePasswort vergessen?Teil des echten Login-Formulars, nicht einer FehlerseiteBlog- oder News-SeiteEine Zeile aus dem Footer, den das CMS rendertVerschwindet, wenn das CMS seine Datenbank nicht erreichtHealth-Endpunkt“status“:“ok“Wird von der Anwendung geschrieben, nachdem sie ihre Abhängigkeiten geprüft hat
Für eine API oder einen Health-Check-Endpunkt ist ein JSON-Check wie $.status gleich ok präziser als ein Keyword, weil er nicht von Leerzeichen oder der Reihenfolge der Felder abhängt.
„Darf nicht enthalten“-Checks für Fehlermeldungen
Ein negativer Check erkennt Ausfälle, die Sie vorab benennen können. Nützliche Zeichenketten, je nach Stack:
Error establishing a database connection bei WordPress. Der Core sendet die Meldung mit einer 500, eine eigene db-error.php-Seite aber womöglich nicht.
Fatal error oder Parse error bei PHP-Websites, die Fehler anzeigen.
Welcome to nginx! oder der Titel der Standardseite Ihres Hosters, um eine Domain zu erkennen, die auf den falschen Server zeigt.
Spam-Begriffe, die auf Ihrer Website nichts zu suchen haben, als einfacher Stolperdraht für eingeschleuste Inhalte.
Vorsicht bei Seiten, auf denen die Zeichenkette ganz legitim vorkommen kann. Ein Blogartikel über Datenbankfehler oder ein Hilfeartikel, der eine Fehlermeldung zitiert, würde einen „Darf nicht enthalten“-Check jedes Mal durchfallen lassen. Im Zweifel ist ein positiver Check auf Text, der beweist, dass die Seite funktioniert, die sicherere Wahl – denn er erkennt auch Ausfälle, an die Sie nicht gedacht haben.
Testen Sie das Keyword, bevor Sie sich darauf verlassen
Prüfen Sie, was der Server tatsächlich sendet, nicht, was der Browser anzeigt. Im Terminal:
curl -s –compressed https://example.com/product/blue-mug | grep -c „Add to cart“
Ein Ergebnis von 0 bedeutet, dass auch der Monitor den Text nicht findet. Die üblichen Gründe:
JavaScript rendert den Text. Sehen Sie sich den Seitenquelltext an (nicht den Inspektor), um das HTML zu sehen, das der Server zurückgibt, und wählen Sie Text, der darin steht.
HTML-Entities. „Terms & Conditions“ auf dem Bildschirm ist im Quelltext oft Terms & Conditions, und auch typografische Anführungszeichen können kodiert sein. Wählen Sie Text ohne Sonderzeichen oder kopieren Sie ihn aus dem Quelltext.
Groß-/Kleinschreibung und Leerzeichen. Ein Button, der per CSS in Großbuchstaben erscheint, heißt im HTML weiterhin „In den Warenkorb“. Auch Zeilenumbrüche im Text verhindern einen exakten Treffer.
Der Monitor sieht eine andere Seite. Websites, die Sprache oder Währung nach Standort wählen oder unbekannten Clients eine Bot-Abfrage zeigen, können einem Monitor anderes HTML schicken als Ihnen am Schreibtisch.
Wann ein Keyword nicht reicht
Der Inhalt hängt von JavaScript ab. Single-Page-Apps senden wenig HTML. Prüfen Sie sie mit einem Flow in einem echten Browser, der das JavaScript ausführt, bevor er nach dem Text sucht.
Der Fehler liegt ein paar Schritte tiefer. Die Produktseite funktioniert, das Hinzufügen zum Warenkorb aber nicht. Ein mehrstufiger synthetischer Check geht die Journey durch und prüft jeden Schritt.
Die Seite ist sehr groß. Monitore lesen meist nur den ersten Teil einer Antwort. Prüfen Sie Text weit oben auf der Seite oder einen kleineren Endpunkt.
Die Seite ist langsam, nicht defekt. Das ist eine Frage der Antwortzeit; legen Sie dafür ein Limit für langsame Antworten fest.
Die Checkliste, was Sie auf Ihrer Website überwachen sollten, zeigt, welche Seiten einen Inhalts-Check verdienen, und wie Sie Fehlalarme reduzieren deckt den Rest der Feinabstimmung ab.
Keyword-Checks in Uptimecheck
Jeder HTTP(S)-Monitor im Uptime-Monitoring von Uptimecheck kann neben den erwarteten Statuscodes einen Keyword-Check enthalten:
Enthält oder enthält nicht: ein Keyword pro Monitor, exakt abgeglichen inklusive Groß- und Kleinschreibung, in den ersten 2 MB der Antwort. Sie brauchen auf derselben Seite einen positiven und einen negativen Check? Legen Sie einen zweiten Monitor an.
JSON- und Header-Checks: bis zu 10 pro Monitor, etwa $.status gleich ok oder ein Content-Type-Header, der json enthält – für APIs und Health-Endpunkte.
Testanfrage: Sehen Sie die Antwort und ob die Checks bestehen, bevor Sie den Monitor speichern.
Bestätigt und erklärt: Ein fehlgeschlagener Check wird wiederholt, bevor ein Incident eröffnet wird, und der Incident nennt, was nicht stimmte – zum Beispiel, dass der erwartete Text nicht auf der Seite stand oder die Seite leer zurückkam –, zusammen mit dem Anfang der Antwort.
JavaScript und Journeys: Flows prüfen Text bei jedem Schritt, und Flows in einem echten Browser sehen auch Text, den JavaScript rendert – mit einem Screenshot des fehlgeschlagenen Schritts.
Die Checks laufen bis zu jede Minute aus Stockholm, London und New York. Eine Website, die die Sprache nach Standort wechselt, zeigt Uptimecheck also die Version, die sie für Schweden, Großbritannien oder die USA ausliefert; wählen Sie ein Keyword, das in jeder Version gleich ist, oder senden Sie die Header, die eine Sprache festlegen. Wie Sie einen Check einrichten, lesen Sie unter So legen Sie Ihren ersten Monitor an, und wenn ein Monitor down meldet, obwohl die Website bei Ihnen funktioniert, unter Warum ein Monitor down sein kann, obwohl die Website funktioniert.
Sorgen Sie dafür, dass „online“ auch „funktioniert“ heißt. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.