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

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.
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.
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.
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.
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:
- Öffne einen bestehenden Website-Monitor oder lege einen neuen an.
- Geh in die erweiterten Einstellungen und aktiviere den Keyword-Check.
- 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.
- 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.
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.
Häufig gestellte Fragen
Keyword-Monitoring lädt den HTML-Body einer Seite und prüft, ob ein bestimmter Text darin vorkommt oder eben nicht. Damit erkennst du Website-Änderungen, die ein reiner Statuscheck übersieht: Die Seite antwortet mit 200 OK, zeigt aber eine leere Seite, eine Fehlermeldung oder einen fremden Inhalt. Bei Uptimeify läuft der Check nativ über den searchTerm im Uptime-Monitor, in zwei Modi: Alarm, wenn ein erwarteter Text fehlt, oder Alarm, wenn ein verbotener Text auftaucht.
Uptime-Monitoring prüft, ob der Server erreichbar ist und den erwarteten Statuscode liefert. Content-Monitoring prüft, was tatsächlich im Seiteninhalt steht. Ein Server kann fehlerfrei mit 200 OK antworten und trotzdem eine kaputte, leere oder manipulierte Seite ausliefern. Content-Monitoring, auch Keyword-Monitoring genannt, schließt genau diese Lücke, indem es den echten HTML-Body gegen ein Schlüsselwort abgleicht.
Ja. Du legst einen Must-not-contain-Check auf verräterische Zeichenketten wie 'Hacked by' oder typische Fragmente einer Übernahme-Seite. Taucht der Text im HTML-Body auf, öffnet Uptimeify ein Incident und alarmiert, bestätigt von mehreren EU-Standorten. Parallel dazu ein Must-contain-Check auf ein Kernelement deiner echten Seite, etwa den Firmennamen im Footer: Verschwindet der, weißt du, dass die Originalseite nicht mehr ausgeliefert wird.
Uptimeify pollt aus mehreren europäischen Standorten, darunter Nürnberg, Falkenstein, Paris, Amsterdam, London und Helsinki. Jeder Fehltreffer wird von mehreren Nodes bestätigt, bevor ein Incident aufgeht, sodass ein einzelner Netz-Aussetzer keinen Fehlalarm auslöst. Der Stack läuft ohne US-Sub-Prozessoren, was deine DSGVO-Argumentation im Kundengespräch einfacher macht.
Der Content-Check gleicht den searchTerm gegen den rohen HTML-Body ab, den der Monitor herunterlädt, und die Suche ist case-sensitive. 'Warenkorb' und 'warenkorb' sind also zwei verschiedene Treffer. Wähle den Suchbegriff so, dass er serverseitig gerendert wird und nicht erst per clientseitigem JavaScript nachlädt, sonst steht er nicht im Body, den der Check sieht. Für Flows hinter Login oder client-gerenderte SPAs greift stattdessen der Playwright-Monitor. Zwei Modi stehen zur Wahl: Must contain feuert, wenn der Begriff fehlt, Must not contain feuert, wenn er auftaucht.

Co-Founder von Uptimeify und verantwortlich für das gesamte Marketing. Übersetzt zwischen technischer Entwicklung und Marketing-Strategie: von Java, PHP und Shopware-Plugins zur Steuerung digitaler Wachstumsstrategien. Zertifizierter UX-Manager (IHK) und Digital-Marketing-Berater für drei gemeinnützige Organisationen.
Mehr aus dem Blog

Wartungsfenster richtig setzen: Geplante Downtime ohne Fehlalarm-Lawine
So pausierst du mit einem Wartungsfenster die Alarmierung bei geplanter Wartung und zeigst sie in der Status-Historie sauber als Wartung an.

Monitoring-Alerts in Slack, Teams & per Webhook einrichten
Einrichtung pro Kanal, Slack, Microsoft Teams, Webhook, plus die Webhook-Payload-Struktur (JSON) für eigene Pipelines. Mit Beispielen.

Eskalationsrichtlinien & On-Call-Routing für kleine Teams einrichten
Eskalationsketten ohne PagerDuty-Komplexität: Wie kleine Agenturen ohne 24/7-NOC ein verlässliches On-Call-Routing aufsetzen, Schritt für Schritt.
