A server returning 200 OK is not the same as a page working. The most common "the site is down" ticket support teams open is not a 500 — it is a page that loads, returns a success status, and renders the wrong thing: a blank white screen from a broken JavaScript bundle, a "Database connection failed" message inside a 200 response, a product page that quietly swapped "In stock" for "Out of stock", or a soft 404 where a deleted page still returns 200 with a "Page not found" body. Keyword monitoring (also called content match, string monitoring, or HTML body monitoring) is the check that catches this class of failure. It asks not "is the server responding?" but "is the right content on the page?"
This is the layer between a basic uptime check and a full synthetic browser test. A ping or HTTP check confirms the server is reachable and returns a 2xx. A synthetic monitor runs a real browser through a multi-step flow. Keyword monitoring sits in the middle: it downloads the page body over a normal HTTP request and asserts that a specific string is present (or absent), so you find out the page is broken for users before a customer emails you. This guide explains what keyword monitoring is, the two modes every team uses, the failure classes it catches that uptime can't, and how to configure it without the false-alert problems that give the technique a bad name.
What keyword monitoring actually is
Keyword monitoring is an HTTP check with a body assertion. The monitor issues a GET (or any method you configure) to a URL, follows redirects, downloads the response body, and searches it case-insensitively for a string you chose. The verdict is pass or fail based on whether the string is there — and the alert fires when the verdict flips.
The defining trait is that the assertion is on the content, not the status code. A traditional uptime monitor trusts the HTTP status: 200 means up, 5xx means down. Keyword monitoring distrusts the status and validates the payload. That distinction matters because a large fraction of real user-facing failures happen inside a 200 response:
- A React app whose bundle failed to load renders an empty
<div id="root"></div>with a 200. - A misconfigured error handler catches an exception and renders "Something went wrong" with a 200.
- A CMS page whose database query timed out renders the shell with no content and a 200.
- A deleted product page renders the "Page not found" template with a 200 (a soft 404).
- A payment page that lost its Stripe key renders "Payment unavailable" with a 200.
In every one of these, a status-code-only monitor reports green. Keyword monitoring reports red, because the string you told it to expect — "Add to cart", "Sign in", "In stock", your brand name in the footer — is gone.
The two modes: presence and absence
Every keyword monitor runs in one of two modes, and most pages need both.
Presence (must-contain)
You specify a string that must appear on the page. If the monitor fetches the body and the string is missing, the check fails. This is the "is the right thing here?" check.
- The word "Checkout" must appear on the cart page.
- Your brand name must appear in the footer.
- "Sign in" must appear on the login page.
- A product's price string must appear on the product page.
Presence is the default mode and the one that catches the blank-page and broken-bundle class of failure: the page returned 200, but the content that makes it that page is gone.
Absence (must-not-contain)
You specify a string that must not appear on the page. If the monitor fetches the body and the string is present, the check fails. This is the "is a bad thing here?" check.
- "Database error" must not appear anywhere on the page.
- "Connection failed" must not appear.
- "Out of stock" must not appear on a critical product page.
- "Page not found" must not appear on a page that should return real content (soft 404 detection).
Absence is the proactive mode: you don't wait for the expected content to vanish, you watch for known failure strings to appear. It is especially powerful for catching the "200 but error message" class where the page still renders most of its chrome but inserts an error banner in the middle.
Most production setups pair one presence rule with one or two absence rules per critical page. The presence rule catches the page going blank; the absence rules catch the page going wrong.
What keyword monitoring catches that uptime can't
The failure classes that produce a 200 and a broken page are the entire reason keyword monitoring exists. They fall into five buckets:
- Broken JavaScript bundles. A deploy shipped a JS bundle that throws on load. The HTML shell returns 200, the
<div id="root">never populates, and users see a white page. The status code never moves. Only a body check onid="root"content (or a known rendered string) catches it. - Error messages inside 200 responses. A backend dependency timed out, your framework's error handler caught it, and the page renders "Something went wrong" with a 200. Status-code monitoring is blind; an absence rule on "Something went wrong" catches it in one check.
- Soft 404s. A page was deleted but the route still returns 200 with a "Page not found" body. Google can de-rank these, and users hit a dead end. A presence rule on the page's real content (or an absence rule on "Page not found") catches it.
- Content regressions on critical pages. A product page that silently flipped from "In stock" to "Out of stock", a pricing page that lost the price string, a signup page that lost the "Create account" button. These are business-critical and produce no error at all — only a content assertion catches them.
- WordPress and CMS plugin failures. A plugin update conflicts with another plugin and the page renders a blank or error template with a 200. This is the single most common cause of "the site is broken but the monitor says up" for WordPress sites, and it is invisible to a ping.
Each of these is a real user-visible outage that produces zero signal in a status-code-only monitor. Keyword monitoring turns each into a single pass/fail the monitor can alert on.
Where it sits in the monitoring stack
Keyword monitoring is not a replacement for uptime monitoring — it is the next layer up. The stack, from cheapest to deepest:
- Ping / TCP check — is the host reachable? See ping monitoring.
- HTTP uptime check — does the URL return a 2xx in time? This is what most "uptime monitoring" means.
- Keyword / content match — does the returned body contain the right content? This guide.
- Multi-step synthetic / transaction monitoring — does a full user journey (login → checkout) complete in a real browser?
Each layer catches what the one below it misses. A ping tells you the server is up; an HTTP check tells you the page returns 200; a keyword check tells you the page renders the right content; a transaction check tells you a user can actually get through a flow. Most teams need layers 2 and 3 on every critical page, and layer 4 on the few flows that carry revenue. Keyword monitoring is the highest-leverage of the four for the effort it takes, because the "200 but broken" class is the most common real outage and the cheapest to detect with a body assertion.
For the deeper comparison between the two layers above and below this one, see synthetic monitoring and our content change detection guide.
How to choose keywords that don't false-alert
The technique gets a bad name when teams pick bad keywords. A keyword monitor is only as trustworthy as the string it asserts on. The rules:
- Pick strings that are stable and meaningful, not layout. Your brand name in the footer is stable. The exact text of a headline is not — marketing rewrites headlines. A price string changes when the price changes. Choose strings that mean "this page is the page it should be" and survive normal content edits.
- Don't match on boilerplate that appears on every page. Matching on
<htmlor<!DOCTYPEproves the server returned HTML, not that the right page loaded. Match on something specific to this page. - For absence, match on strings that only appear in failure. "Error" is too broad — it appears in legitimate copy ("0 errors"). "Database connection failed", "Something went wrong", "Page not found" are failure-specific.
- Beware JavaScript-rendered content. A plain HTTP GET does not execute JavaScript. If your page renders the keyword client-side (a React/Vue app that populates the DOM after load), a body check on the raw HTML won't find it. For JS-rendered content, use a browser-based check (transaction monitoring) instead, or assert on a string present in the server-rendered HTML shell.
- Use two-check confirmation. A single failed fetch can be a transient network blip. Confirm across two consecutive checks, or across multiple regions, before alerting. This eliminates the false-positive problem that makes teams distrust the technique.
A well-chosen keyword rule with two-check confirmation is one of the lowest-noise, highest-signal monitors you can run. A badly-chosen one will page you every time marketing edits a headline. The difference is entirely in the string selection.
The five pages every site should keyword-monitor
You don't keyword-monitor every page — you monitor the pages whose breakage costs you money or trust. For most sites that is five:
- The homepage. Presence of brand name and primary navigation. Catches total template failure and CDN origin issues that still return 200.
- The checkout / conversion page. Presence of the checkout button or price string; absence of "Payment unavailable" or "Out of stock". This is the revenue-critical page and the one where a silent 200-but-broken failure is most expensive.
- The login / signup page. Presence of "Sign in" or "Create account". Auth pages break in ways that return 200 (a broken captcha script, a missing form action) and lock users out silently.
- The top product / landing page. Presence of the product's core content; absence of "Page not found". Catches soft 404s and content regressions on the page that drives the most traffic.
- A critical third-party-dependent page. Any page whose function depends on an external API (search, payments, search-as-a-service). Presence of the API-driven content catches the "the third party is down and we degrade to a 200 with empty results" failure.
For a deeper treatment of watching the configuration and markup that gate search traffic specifically, see SEO health monitoring.
How Webalert Helps
Webalert treats keyword monitoring as a first-class check type on every monitor, not a separate product. Each monitor runs an HTTP request, validates the status code and response time, and asserts a keyword rule (presence or absence) on the body — in the same check, from the same regions, with the same alerting. You don't stand up a second monitor to get content validation.
- Presence and absence rules on every monitor. Add a must-contain keyword, a must-not-contain keyword, or both, per page. The check runs at your configured interval from multiple regions.
- Two-check confirmation and multi-region majority. A keyword failure is confirmed across consecutive checks and a majority of regions before an alert fires, so a transient blip in one region doesn't page you at 3 a.m.
- Pairs with the rest of the stack. The same monitor covers HTTP uptime, response time, SSL expiry, and keyword assertions — so the "200 but broken" class is caught by the same monitor that catches the "500 down" class. See also SSL certificate expiration and domain expiry.
- Status page and on-call built in. When a keyword check fails, it opens an incident, updates your status page, and notifies your on-call rotation — the same workflow as a total outage.
Start keyword monitoring — free. Presence and absence rules, multi-region two-check confirmation, status pages, and on-call in one product — so a 200 with a blank page gets caught in minutes, not in next month's support tickets.
Frequently Asked Questions
What is keyword monitoring?
Keyword monitoring (also called content match or string monitoring) is an HTTP check that asserts a specific string is present or absent in the response body. It catches failures where a page returns 200 OK but renders the wrong content — blank pages, error messages, soft 404s, and content regressions that a status-code-only uptime check misses.
How is keyword monitoring different from uptime monitoring?
Uptime monitoring checks the HTTP status code — 200 means up, 5xx means down. Keyword monitoring checks the page body — it validates that the right content is on the page regardless of the status code. Uptime catches the server being down; keyword monitoring catches the server being up but the page being broken.
How is keyword monitoring different from content change detection?
Keyword monitoring asserts a specific string is present or absent right now — a pass/fail check. Content change detection watches for any change to a page over time and alerts on the diff. Keyword monitoring is for "is this page working?"; content change detection is for "did this page change?".
Does keyword monitoring work on JavaScript-rendered pages?
A plain HTTP keyword check reads the server-rendered HTML, not the JS-populated DOM. If your keyword is rendered client-side, the check won't find it. For JS-rendered content, use a browser-based transaction monitor instead, or assert on a string present in the server-rendered shell.
How do I avoid false alerts?
Pick stable, meaningful strings (your brand name in the footer, not a marketing headline), match on failure-specific strings for absence rules ("Database connection failed", not "error"), and use two-check confirmation across multiple regions before alerting. Bad keyword selection is the entire cause of the technique's false-positive reputation.