Keyword monitoring: catch the error page that still returns 200

The pages that lie with a 200

A status code reports what the web server decided, not what the visitor sees. Plenty of broken states still answer 200: a CMS that prints a database error into the template, a PHP fatal error with display_errors on, a maintenance plugin that serves its splash page with a happy code, a CDN that cached an error body, an expired hosting account showing the provider's parked page, and a staging banner that went live by accident. Each of those has a recognisable sentence, and a keyword monitor turns that sentence into an alarm.

Typical absent phrases are "Fatal error", "Error establishing a database connection", "Briefly unavailable for scheduled maintenance", "Service Unavailable" and "This domain is for sale". Typical present phrases are the company name in the footer, a product page's "Add to cart", or the text of a login button.

Present, absent, or both

A keyword monitor has two optional fields: the phrase that must be present and the phrase that must be absent. Use both on important pages. The present phrase protects you from blank pages and unexpected redirects, the absent phrase from error text that appears next to normal content. If both are filled in, both conditions must hold, and the failure names the one that broke, for example Keyword "Add to cart" missing or Forbidden keyword "Fatal error" present.

Leave both fields empty and the monitor degrades to a status check with a note in its details, which is rarely what you want; use a plain website monitor for that.

Choosing a phrase that survives redesigns

The best phrases are boring. Legal footer text, the registered company name, a copyright line or a form label change far less often than headlines or promotional copy, so they will not trigger an alert every time marketing runs a test. Avoid text that varies by visitor (greetings, prices in a local currency, "3 items in your cart"), text from A/B experiments, and anything inside a cookie banner. Keep the phrase short enough to survive line breaks and word-wrap edits, but long enough to be unique: "Add to cart" is better than "cart".

Use two monitors with different phrases on the same page when you want to separate a missing header from a missing footer. It costs one more monitor and makes the failure message self-explanatory.

What the matcher actually does

The response is fetched like any other HTTP check, then scripts, style blocks, comments and tags are removed, a handful of common HTML entities are decoded, and whitespace is collapsed. The phrase is searched in that text with a case-insensitive, plain substring comparison. Consequences worth remembering:

• No regular expressions. A pattern such as order #[0-9]+ cannot be expressed; pick a fixed neighbour phrase instead.
• Only text nodes count. A word that appears in an alt attribute, a meta description tag or inside JavaScript is not visible to the matcher, while text in hidden elements still is.
• Only the HTML as served is searched, up to about 1 MB. Text that a framework inserts after load is invisible, so test single-page apps against their server-rendered output or the API behind them.
• All conditions use the same fetch, so the expected status range, redirects, basic auth and timeout settings apply to keyword monitors exactly as they do to website monitors.

Plans and interactions with other monitors

Keyword checks are included on every plan, Free too. JSON assertions begin on the Starter plan ($7 a month). A keyword monitor produces the same incident, alert and status-page data as any other monitor, and it can be switched into a maintenance window when you plan to change the page. If your site sits behind a bot filter, a challenge page will be recorded as a blocked incident rather than as a missing keyword, so a Cloudflare rule change does not look like a content problem.