Here's a scenario that catches teams out constantly: your uptime check is green, every monitor says 200 OK — and yet the homepage is showing a blank white screen, a database error, or a half-rendered mess. How does a "healthy" check miss a broken page?
Because a status code only tells you the server responded, not that it responded correctly. The fix is keyword monitoring.
The "200 but broken" problem
A web server can confidently return 200 OK while the page is useless:
| What the user sees | What the status code says |
|---|---|
| Blank white page (JS/render failure) | 200 OK ✅ |
| "Database connection error" in the body | 200 OK ✅ |
| A maintenance placeholder | 200 OK ✅ |
| The wrong content / a defaced page | 200 OK ✅ |
| A login wall where content should be | 200 OK ✅ |
In every case, a status-only check says "all good" — while customers hit a wall. You need to check the content itself.
What keyword monitoring does
Keyword (or body-match) monitoring checks that the page's actual content contains — or doesn't contain — specific text:
- Must contain: require a word you know appears on a healthy page (your product name, a heading, "Add to cart"). If it's missing, the page is broken even with a 200.
- Must NOT contain: require the page to not contain error markers ("error", "exception", "maintenance"). If one appears, it's an incident.
It's the difference between "the server answered" and "the server answered with the right thing."
What to match on
Choose text that reliably proves the page is healthy:
| Good keyword | Why |
|---|---|
| A core UI label ("Sign in", "Add to cart") | Present only when the page actually rendered |
| Your product/brand name in a known spot | Disappears if the template breaks |
| A unique footer or heading | Stable across normal changes |
Avoid matching on text that changes often (prices, timestamps) — you'll get false alarms. And add a negative match for error strings as a catch-all.
Beyond defacement and outages
Keyword checks quietly cover several problems at once:
- Defacement / hacks — unexpected content triggers the negative match.
- Silent redirects — if you land somewhere without the expected keyword, it's caught.
- Broken deploys — a release that renders an error page still returns 200, but fails the keyword.
- Expired integrations — a third-party widget failing can break the page body.
How to set it up
On an HTTP monitor, alongside the status check:
- Add a "body contains" rule with a word that's always on a healthy page.
- Optionally add a "body does not contain" rule for error markers.
- Keep the keywords stable so normal content changes don't trip them.
- Confirm from multiple locations to avoid blips.
The bottom line
| In one line | |
|---|---|
| The gap | A 200 OK doesn't mean the page is correct. |
| The fix | Check the content contains expected text (and not errors). |
| Catches | Blank pages, errors, defacement, silent redirects, broken deploys. |
| Tip | Match stable text; add a negative match for error strings. |
A status code tells you the lights are on; a keyword check tells you someone's actually home. Add one to your important pages and you'll catch the "looks up but isn't" failures that pure uptime checks sail right past.
Learn the codes in HTTP status codes explained, and set this up via web monitoring.