# Keyword and Content Monitoring: Catch Defacement and Missing Content Early > A 200 OK that shows the wrong page? Here is how keyword and content monitoring catches defacement, dead buttons, and broken prices before your client does. Source: https://uptimeify.io/blog/keyword-content-monitoring A 200 OK status means the server answered. It does not mean your clients see what they pay for. Keyword monitoring, also called content monitoring, checks the real page content instead of just the server handshake: it downloads the HTML body and matches it against a keyword. That catches website changes a pure availability check sleeps right through. Defacement, a vanished payment button, a wrong price: all cases where the page is technically online and still doing damage. - **Keyword monitoring checks the content, not just the status.** A page can answer with 200 OK and still be blank, broken, or hijacked. - **Two modes cover the two dangers:** must contain alerts when an expected text is missing (dead button, vanished price). Must not contain alerts when a forbidden text appears (defacement, database error). - **For agencies this is a safety net per client.** You catch the silent failure before the client notices it, and you prove the exact value your retainer promises. - **Confirmed from multiple EU locations**, without US sub-processors, run natively through the searchTerm on the uptime monitor. ## Why a status check misses the most dangerous failure The classic availability check asks one question: does the server answer? If it does and the status code matches, the page counts as online. The problem: between "server answers" and "client sees the right thing" sits a whole class of failures the status code does not capture. A database connection drops, the CMS renders a blank page, the server still serves it with 200. A deploy goes wrong and swaps the price for a placeholder. An attacker takes over the page and lays their own message on top, still a clean 200 as far as the wire is concerned. In all three cases your uptime monitor reports green while your clients stare at something broken. This is the silent failure, and it is more dangerous than an outright outage. A dead page you notice in minutes. A page that runs technically but shows the wrong content can survive for days until someone happens to click it. In that window your client loses revenue or trust, and both land back on you in the end. A green uptime check proves the server is alive. It does not prove the page shows what it should. ## What keyword and content monitoring actually does Content monitoring downloads your page's HTML body and searches it for a specific string. Instead of asking "does the server answer?", it asks "is the right thing in there?". In Uptimeify this check runs natively through the searchTerm right on the uptime monitor, so you do not need a separate monitor type for it. There are two modes, and each covers a different danger: **Must contain, meaning alert when the text is missing.** You store a term that is guaranteed to appear on a healthy page: the company name in the footer, the text on the "Add to cart" button, a product name. When that term disappears from the HTML, an incident opens. This is your net against vanished content. **Must not contain, meaning alert when the text appears.** You store a term that must never show up: "MySQL Error", "Maintenance Mode", "Hacked by", "404 Not Found" in body text. The moment that text sits in the body, the check alerts. This is your net against error messages and defacement. Both modes combine. A must-contain check on your real core element plus a must-not-contain check on typical failure signatures together cover almost every form of silent failure. How to configure the searchTerm and what options the uptime monitor carries is laid out on the keyword monitoring feature page. ## Three use cases a status check sleeps through The theory is quick to tell. It gets interesting on the concrete cases where content monitoring makes the difference between "caught early" and "heard it from the client". ### Use case 1: Defacement, the hijacked page In a defacement, an attacker takes control of the served content and replaces it with their own message. Technically the page often stays reachable, the status code clean. Your uptime monitor sees nothing. Content monitoring catches this two ways. A must-not-contain check on telltale fragments like "Hacked by" trips the moment the typical takeover signature shows up in the HTML. At the same time, a must-contain check on a core element of your real page, such as the company name in the footer, reports that the original is no longer being served. The first check catches what is newly there, the second catches what is missing. Together they catch even a takeover whose exact wording you could not predict. ### Use case 2: The vanished payment button A faulty deploy, a broken JavaScript bundle, a CSS rule that hides an element: it takes little for the "Buy now" or "Add to cart" button to disappear. The page loads, looks normal at a glance, but the one click that brings revenue is gone. For a shop that is a direct revenue loss at full availability. A must-contain check on the button text or a unique element of the checkout flow catches exactly that. When the text is missing from the HTML body, the alert goes out long before the first client hunts in vain for the button. One caveat: the term must be server-rendered, otherwise it will not be in the body the check downloads. For purely client-rendered checkout flows, the Playwright monitor is the more robust choice. ### Use case 3: The wrong price A price feed imports badly, a currency flips, a placeholder like "0.00" or "NaN" lands in production. The client sees a price that is wrong, and in a dispute the displayed price often stands. Same story: status code 200, all green, and a real problem anyway. Content monitoring works here through a must-not-contain check on typical error signatures in the price, such as "NaN", "undefined", or an obvious placeholder. Where you have a fixed expected value, flip the logic and use must contain to verify the correct price string is still there. Either way you learn about the fault before it becomes a complaint or a legal headache. Defacement, dead button, wrong price: three failures, one pattern. The page is online, the content is wrong, and only a content check sees the difference. ## How to set up the check Content monitoring is not a separate monitor type you stand up on its own, it is an option on your existing uptime monitor. The flow: 1. Open an existing website monitor or create a new one. 2. Go into the advanced settings and enable the keyword check. 3. Enter your search term and pick the mode: must contain for a text that has to be there, must not contain for one that must never appear. 4. Save. From now on Uptimeify matches the HTML body against your searchTerm on every check. Three things that decide between a clean signal and a false alarm: **Mind case sensitivity.** The search distinguishes upper and lower case. "Cart" and "cart" are two different matches. Take the string exactly as it sits in the rendered HTML. **Choose server-rendered terms.** The check only sees what arrives in the HTML body. A text that loads later via client-side JavaScript is not there. For those cases, and for flows behind a login, the Playwright monitor is the right path. **Stable anchors over fleeting phrasing.** Pick a term that does not change with every content update. A footer company name or a fixed button text is a better anchor than a marketing line that gets rewritten next week. ## Why this is more than a feature for agencies For an agency or MSP running a portfolio of client sites, content monitoring is not a technical detail, it is a safety net per client. Every silent failure you catch before the client notices is a call that never comes, and proof that your retainer is worth its price. The value sits in the "before". When your client calls you because their button is gone, you have already lost: they saw the failure before you did. When you call them because your monitoring flagged the missing button, you flip the relationship. You are not the vendor who fixes problems, you are the partner who catches them. Every check runs confirmed from multiple EU locations before an incident opens, so a single network blip does not produce a false alarm. The stack runs in Frankfurt and further European nodes, without US sub-processors. That takes a whole compliance discussion off the table in B2B and public-sector conversations. For a content alert to reach the right person instead of drowning in noise, the alerting engine steps in with escalation and multi-node confirmation. Content monitoring closes the gap between "the server is up" and "the client sees the right thing". For you that is the difference between a portfolio you watch and a portfolio you stand behind.