Keyword Monitoring: Catch Broken Pages Returning 200

Keyword monitoring checks that a specific string is still present in the HTML your server returns. It exists because a status code lies. A page can render a database error, an empty cart or a stack trace and still answer 200. A plain uptime check calls that healthy while customers see nothing useful.

What does a keyword check actually do?

The probe fetches the URL, reads the response body and searches it for the string you configured. You choose the direction: alert when the string is absent, or alert when it is present. Anything else about the request stays the same, including the status assertion and the response-time threshold.

UptimeRobot describes its own version as looking for a phrase in the HTML source and alerting when that string is present or absent. That is the shape every vendor ships as of September 2026. The differences are in what you point the check at, not in the mechanism.

Worth being precise about one thing. The probe compares bytes in a response body. It is not reading the page the way a browser would, and it has no opinion about layout, images or whether the button you matched is visible on screen.

Setting up keyword monitoring

Pick a URL that only renders correctly when the important parts of your stack are working. A marketing home page is a poor target. A product page that needs a database read and a template render is a good one.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "checkout page renders",
    "type": "keyword",
    "target": "https://example.com/checkout",
    "intervalSec": 60,
    "keyword": "Proceed to payment",
    "keywordMatch": "absent",
    "expectedStatus": [200]
  }'

The keywordMatch field sets the direction, so the alert fires when the phrase goes missing. Accepted values are listed in the reference. Keyword is one of ten monitor types, and the remaining fields are documented in the REST API reference.

Choosing a string that does not churn

This is where most setups fail. Teams pick a headline, marketing rewrites it three weeks later, the monitor pages at 2am and everyone learns to ignore it. Alert fatigue arrives on schedule.

A good target string has three properties. It is rendered server-side, it is owned by engineering rather than marketing, and it would genuinely be missing if the page were broken.

Candidate string	Verdict	Why
"Proceed to payment" on a button	Good	Server-rendered, stable, disappears on a template failure
"Welcome to our new spring sale"	Bad	Marketing rewrites it without telling you
A closing html tag	Bad	Present even on a truncated or half-rendered page
An order-total currency symbol	Good	Only renders after a successful price lookup
"Error" (alert when present)	Good	Catches a stack trace that still answers 200

We prefer a short phrase from a button or a form label over a heading. Buttons change less often than copy, and they usually sit behind the exact code path you care about.

Present or absent: which direction?

Absent checks watch for something that should always be there, so they catch broken renders, failed database reads and blank templates. Present checks watch for something that should never be there, so they catch error pages, maintenance banners left up after a deploy and injected spam.

Run both against the same site. One absent check on your most transactional page, one present check for the word your framework prints on an unhandled exception. That pair covers the two ways a 200 response can still be wrong.

What keyword monitoring misses

The check reads the HTML the server returns. A string that only appears after client-side JavaScript runs will not be found, because no browser executes on the probe. Single-page applications are the usual casualty: the initial document is a near-empty shell and the real content arrives later.

The workaround is to assert on something the server does send. Most frameworks emit meaningful data in the initial payload even when they render client-side, such as a JSON blob, a meta tag or a server-rendered title. Point the check at that instead.

Deeper content monitoring, meaning did the rendered price match the database, needs something with a view inside the application. An external probe compares bytes, nothing more.

How this fits with your other checks

One keyword check does not replace an uptime check, it narrows what a green result means. We run the pair together: a plain HTTP monitor for reachability and TLS, and a keyword monitor for whether the page said the right thing.

Confirm from more than one place before paging. A regional CDN fault can strip or stale a page in a single country. Running the check from two of the six probe regions available as of September 2026 separates a real break from one bad edge node. That is the same logic behind cross-region quorum confirmation, and the egress addresses to allowlist are on the probe IPs page.

Keyword monitoring also pairs well with a scheduled job that produces the content in the first place. If a nightly import populates the catalogue, a heartbeat proves the import ran and a content assertion proves it produced something. Heartbeat monitoring covers the first half of that pair.

Verify the string before you trust the check

Configure nothing until you have seen the response body yourself. The page you get from a terminal is the page the probe gets, minus cookies and client-side rendering. That is exactly the view you want to reason about.

curl -s -A "uptime-check" https://example.com/checkout \
  | grep -c "Proceed to payment"

A count of 1 is ideal. A count of 0 means your string lives in JavaScript or behind authentication. A count above 1 is usually harmless but worth understanding, because a phrase repeated in the header and the footer may survive the failure you meant to catch.

Check the status code in the same pass. MDN's reference on 200 OK is a reminder that the code describes the request, not the correctness of what came back. That distinction is the entire reason this kind of check exists.

Common mistakes

Matching on something inside a script tag. Your string may exist in an inline analytics payload rather than the visible page. The check passes while the page renders blank. Search the rendered markup first with curl -s URL | grep -c "your string".

Choosing a string that appears on the error page too. Some frameworks render the site chrome around a 500. If your phrase lives in the header, it survives the failure you were trying to catch.

Alerting on a case-mismatched string. Matching is literal. "Add to Cart" and "Add to cart" are different strings, and a CSS text-transform will not change what the server sent.

Using one check for twenty pages. A single keyword check covers one URL. Monitor the three or four routes that carry revenue rather than trying to cover everything.

Point your first keyword monitoring check at the page that would cost you money if it silently rendered empty, and give it a string an engineer owns. The free plan includes 10 monitors at a 1-minute interval as of September 2026, so the pairing of an uptime check and a content assertion costs nothing to try. If you are comparing tools, the trade-offs are laid out in our roundup of uptime monitoring tools.