# Keyword- und Content-Monitoring: Defacement und verschwundene Inhalte früh erkennen

> Status 200, aber die Seite zeigt Blödsinn? So fängst du Defacement, verschwundene Buttons und falsche Preise mit Keyword- und Content-Monitoring ab.

Source: https://uptimeify.io/de/blog/keyword-content-monitoring

Ein Statuscode von 200 OK bedeutet, dass der Server geantwortet hat. Er bedeutet nicht, dass deine Kunden das sehen, wofür sie zahlen. Keyword-Monitoring, auch Content-Monitoring genannt, prüft den echten Seiteninhalt statt nur den Server-Handshake: Es lädt den HTML-Body und gleicht ihn gegen ein Schlüsselwort ab. So erkennst du Website-Änderungen, die ein reiner Verfügbarkeits-Check komplett verschläft. Defacement, ein verschwundener Zahlungsbutton, ein falscher Preis: alles Fälle, in denen die Seite technisch online ist und trotzdem Schaden anrichtet.

- **Keyword-Monitoring prüft den Inhalt, nicht nur den Status.** Eine Seite kann mit 200 OK antworten und trotzdem leer, kaputt oder gekapert sein.
- **Zwei Modi decken die zwei Gefahren ab:** Must contain alarmiert, wenn ein erwarteter Text fehlt (toter Button, verschwundener Preis). Must not contain alarmiert, wenn ein verbotener Text auftaucht (Defacement, Datenbankfehler).
- **Für Agenturen ist das ein Sicherheitsnetz pro Kunde.** Du fängst den stillen Ausfall ab, bevor der Kunde ihn bemerkt, und belegst genau den Wert, den dein Retainer verspricht.
- **Bestätigt aus mehreren EU-Standorten**, ohne US-Sub-Prozessoren, nativ über den searchTerm im Uptime-Monitor.

## Warum ein Statuscheck den gefährlichsten Ausfall übersieht

Der klassische Verfügbarkeits-Check stellt eine einzige Frage: Antwortet der Server? Wenn ja und der Statuscode stimmt, gilt die Seite als online. Das Problem: Zwischen "Server antwortet" und "Kunde sieht das Richtige" liegt eine ganze Klasse von Ausfällen, die der Statuscode nicht abbildet.

Eine Datenbankverbindung bricht weg, das CMS rendert eine leere Seite, der Server liefert sie trotzdem mit 200 aus. Ein Deploy geht schief und ersetzt den Preis durch einen Platzhalter. Ein Angreifer übernimmt die Seite und legt seine eigene Botschaft darüber, technisch weiterhin ein sauberer 200er. In allen drei Fällen meldet dein Uptime-Monitor grün, während deine Kunden auf etwas Kaputtes starren.

Das ist der stille Ausfall, und er ist gefährlicher als eine klare Downtime. Eine tote Seite bemerkst du in Minuten. Eine Seite, die technisch läuft aber den falschen Inhalt zeigt, kann Tage überleben, bis jemand zufällig draufklickt. In dieser Zeit verliert dein Kunde Umsatz oder Vertrauen, und beides fällt am Ende auf dich zurück.

Ein grüner Uptime-Check beweist, dass der Server lebt. Er beweist nicht, dass die Seite das zeigt, was sie soll.

## Was Keyword- und Content-Monitoring tatsächlich macht

Content-Monitoring lädt den HTML-Body deiner Seite herunter und durchsucht ihn nach einer bestimmten Zeichenkette. Statt zu fragen "Antwortet der Server?", fragt es "Steht das Richtige drin?". Bei Uptimeify läuft dieser Check nativ über den searchTerm direkt im Uptime-Monitor, du brauchst keinen separaten Monitor-Typ dafür.

Es gibt zwei Betriebsmodi, und jeder deckt eine andere Gefahr ab:

**Must contain, also Alarm wenn der Text fehlt.** Du hinterlegst einen Begriff, der auf einer gesunden Seite garantiert vorkommt: der Firmenname im Footer, der Text auf dem "In den Warenkorb"-Button, eine Produktbezeichnung. Verschwindet dieser Begriff aus dem HTML, geht ein Incident auf. Das ist dein Netz gegen verschwundene Inhalte.

**Must not contain, also Alarm wenn der Text auftaucht.** Du hinterlegst einen Begriff, der niemals erscheinen darf: "MySQL Error", "Wartungsmodus", "Hacked by", "404 Not Found" im Fließtext. Sobald dieser Text im Body steht, alarmiert der Check. Das ist dein Netz gegen Fehlermeldungen und Defacement.

Beide Modi lassen sich kombinieren. Ein Must-contain-Check auf dein echtes Kernelement plus ein Must-not-contain-Check auf typische Ausfall-Signaturen decken zusammen fast jede Form von stillem Ausfall ab.

Wie du den searchTerm konfigurierst und welche Optionen der Uptime-Monitor mitbringt, steht auf der Feature-Seite zum Keyword-Monitoring.

## Drei Use-Cases, die ein Statuscheck verschläft

Die Theorie ist schnell erzählt. Interessant wird es an den konkreten Fällen, in denen Content-Monitoring den Unterschied zwischen "früh gemerkt" und "vom Kunden erfahren" macht.

### Use-Case 1: Defacement, die gekaperte Seite

Bei einem Defacement übernimmt ein Angreifer die Kontrolle über den ausgelieferten Inhalt und ersetzt ihn durch eigene Botschaften. Technisch bleibt die Seite oft erreichbar, der Statuscode sauber. Dein Uptime-Monitor sieht nichts.

Content-Monitoring fängt das doppelt ab. Ein Must-not-contain-Check auf verräterische Fragmente wie "Hacked by" schlägt an, sobald die typische Übernahme-Signatur im HTML auftaucht. Gleichzeitig meldet ein Must-contain-Check auf ein Kernelement deiner echten Seite, etwa den Firmennamen im Footer, dass das Original nicht mehr ausgeliefert wird. Der erste Check erkennt, was neu da ist, der zweite, was fehlt. Zusammen erwischen sie auch eine Übernahme, deren genauen Wortlaut du nicht vorhersehen konntest.

### Use-Case 2: Der verschwundene Zahlungsbutton

Ein fehlerhafter Deploy, ein kaputtes JavaScript-Bundle, ein CSS, das ein Element ausblendet: Es braucht wenig, damit der "Jetzt kaufen"- oder "In den Warenkorb"-Button verschwindet. Die Seite lädt, sieht auf den ersten Blick normal aus, aber der eine Klick, der Umsatz bringt, ist weg. Für einen Shop ist das ein direkter Umsatzausfall bei voller Verfügbarkeit.

Ein Must-contain-Check auf den Button-Text oder ein eindeutiges Element des Checkout-Flows fängt genau das ab. Fehlt der Text im HTML-Body, geht der Alarm raus, lange bevor der erste Kunde vergeblich nach dem Button sucht. Wichtig: Der Begriff muss serverseitig gerendert sein, sonst steht er nicht im Body, den der Check herunterlädt. Bei rein client-gerenderten Checkout-Flows ist der Playwright-Monitor die robustere Wahl.

### Use-Case 3: Der falsche Preis

Ein Preisfeed importiert fehlerhaft, eine Währung kippt, ein Platzhalter wie "0,00" oder "NaN" landet in Produktion. Der Kunde sieht einen Preis, der nicht stimmt, und im Zweifel gilt der ausgezeichnete Preis. Auch hier: Statuscode 200, alles grün, und trotzdem ein handfestes Problem.

Content-Monitoring greift hier über einen Must-not-contain-Check auf typische Fehler-Signaturen im Preis, etwa "NaN", "undefined" oder einen offensichtlichen Platzhalter. Wo du einen festen erwarteten Wert hast, kehrst du die Logik um und prüfst per Must contain, dass der korrekte Preis-String noch da ist. In beiden Fällen erfährst du vom Fehler, bevor er zur Reklamation oder zum rechtlichen Ärgernis wird.

Defacement, toter Button, falscher Preis: drei Ausfälle, ein Muster. Die Seite ist online, der Inhalt ist falsch, und nur ein Content-Check sieht den Unterschied.

## So richtest du den Check ein

Content-Monitoring ist kein eigener Monitor-Typ, den du separat aufsetzt, sondern eine Option deines bestehenden Uptime-Monitors. Der Ablauf:

1. Öffne einen bestehenden Website-Monitor oder lege einen neuen an.
2. Geh in die erweiterten Einstellungen und aktiviere den Keyword-Check.
3. Trag deinen Suchbegriff ein und wähl den Modus: Must contain für einen Text, der da sein muss, Must not contain für einen, der nie erscheinen darf.
4. Speichern. Ab jetzt gleicht Uptimeify bei jedem Check den HTML-Body gegen deinen searchTerm ab.

Drei Dinge, die den Unterschied zwischen sauberem Signal und Fehlalarm machen:

**Case-Sensitivity beachten.** Die Suche unterscheidet Groß- und Kleinschreibung. "Warenkorb" und "warenkorb" sind zwei verschiedene Treffer. Nimm den String genau so, wie er im gerenderten HTML steht.

**Serverseitig gerenderte Begriffe wählen.** Der Check sieht nur, was im HTML-Body ankommt. Ein Text, der erst per clientseitigem JavaScript nachgeladen wird, steht dort nicht. Für solche Fälle und für Flows hinter einem Login ist der Playwright-Monitor der richtige Weg.

**Stabile Anker statt flüchtiger Formulierungen.** Wähl einen Begriff, der sich nicht bei jedem Content-Update ändert. Ein Footer-Firmenname oder ein fester Button-Text ist ein besserer Anker als eine Marketing-Zeile, die nächste Woche umgeschrieben wird.

## Warum das für Agenturen mehr ist als ein Feature

Für eine Agentur oder einen MSP, der ein Portfolio aus Kundenseiten betreut, ist Content-Monitoring kein technisches Detail, sondern ein Sicherheitsnetz pro Kunde. Jeder stille Ausfall, den du abfängst, bevor der Kunde ihn bemerkt, ist ein Anruf, der nie kommt, und ein Beleg dafür, dass dein Retainer seinen Preis wert ist.

Der Wert liegt im Vorher. Wenn dein Kunde dich anruft, weil sein Button weg ist, hast du bereits verloren: Er hat den Ausfall vor dir gesehen. Wenn du ihn anrufst, weil dein Monitoring den fehlenden Button gemeldet hat, drehst du die Beziehung um. Du bist nicht der Dienstleister, der Probleme repariert, sondern der Partner, der sie abfängt.

Jeder Check läuft dabei bestätigt aus mehreren EU-Standorten, bevor ein Incident aufgeht, sodass ein einzelner Netz-Aussetzer keinen Fehlalarm produziert. Der Stack läuft in Frankfurt und weiteren europäischen Nodes, ohne US-Sub-Prozessoren. Das nimmt dir in B2B- und Public-Sector-Gesprächen eine ganze Compliance-Diskussion ab.

Damit ein Content-Alarm die richtige Person erreicht und nicht im Rauschen untergeht, kommt die Alerting-Engine mit Eskalation und Multi-Node-Bestätigung ins Spiel.

Content-Monitoring schließt die Lücke zwischen "der Server läuft" und "der Kunde sieht das Richtige". Für dich ist das der Unterschied zwischen einem Portfolio, das du überwachst, und einem Portfolio, für das du gerade stehst.