A keyword check confirms that a page returns the content it is supposed to show. A plain status code check can’t tell you that. If you run an online store, a SaaS product or a client’s WordPress site, you have probably had a page return a perfectly healthy 200 OK while visitors saw a blank template, a PHP error or a “Product not found” message. This guide covers how to set up keyword checks that catch broken page content, how to choose the right words to match and where these checks fail if you configure them carelessly.
Why a 200 OK Doesn’t Prove a Page Works
Many people believe that if the server answers with a 200, the page is fine. That is wrong. A status code only says the web server finished handling the request. It says nothing about whether the page itself rendered correctly.
Here is a pattern that keeps repeating. A WooCommerce store installs a routine plugin update on a Friday evening. The homepage keeps returning 200 in about 300 ms, so the uptime check stays green. But the product grid is now empty because a shortcode stopped rendering. Nobody notices until Monday morning, after two days of almost no orders. A keyword check looking for the text “Add to cart” would have flagged the problem within a minute or two.
Status codes still matter. The complete guide to HTTP status codes explains what each one tells you. Keyword monitoring adds the content layer on top: a check on what the user actually receives.
How Keyword Monitoring Works Under the Hood
The monitor sends an HTTP GET request, downloads the response body and searches it for a string. There are two modes. In positive matching, the check fails if the expected text is missing. In negative matching, the check fails if a forbidden string shows up, such as “Fatal error” or “Error establishing a database connection”.
The important detail is that most uptime checkers read the raw HTML the server returns. They don’t run JavaScript. A React or Vue single-page app that fills in its content in the browser sends back an almost empty shell like
. A keyword check against that shell only proves the shell loaded. For client-rendered pages, you either check the server-rendered parts or use a synthetic browser check with Playwright or Puppeteer.
Setting Up Keyword Checks Step by Step
An experienced SRE starts by choosing the pages before choosing any keywords. Start with three to five URLs where broken content costs money or leads: the homepage, one high-traffic product or pricing page, the login page and the checkout or signup entry point. Then work through these steps:
1. View the raw page source with curl -s https://example.com/pricing/ or the browser’s “View Source” (not the DOM inspector) and confirm the keyword actually appears in the server response.
2. Pick a positive keyword that only renders when the database, the template and the business logic all work. Footer text or the site name is a poor choice, because it often comes from a cached partial.
3. Add one negative keyword per platform. For WordPress, “There has been a critical error” is the message shown since version 5.2. For Laravel, look for “Whoops” or “Server Error”. For Django, look for “Traceback”.
4. Set a reasonable timeout, around 10-15 seconds, and require two consecutive failures before alerting.
5. Break the page deliberately in staging (rename the keyword in a template) and confirm the alert actually arrives.
Step 5 is the one most teams skip. A keyword check that has never failed is a check you haven’t verified.
Choosing Keywords That Actually Mean Something
A good keyword is dynamic enough to prove the backend works and stable enough to survive routine edits. On a product page, a currency string like “€” next to a price is reasonably robust. A specific product name breaks the first time marketing renames it. On a news site, a CSS class that wraps article cards, such as class=”post-card”, is often more stable than any visible text, and it still proves the query returned results.
Case sensitivity catches people more often than it should. Some monitors match exactly, so “Add to Cart” and “Add to cart” are different strings. HTML entities are another trap: an apostrophe can be served as ’, which is why copying text from the rendered page often fails to match the source. Always copy keywords from the raw response.
Edge Cases Where the Standard Advice Breaks
Multilingual sites serve different text depending on the Accept-Language header or a geo-IP lookup. A probe in Frankfurt may get German content while a probe in Virginia gets English, so one monitor fails and the other passes. The fix is to pin the language in the URL (/en/pricing/) or to match on markup instead of text.
A/B testing tools like Optimizely or VWO can swap headlines between requests, which makes text-based checks flaky. Cloudflare’s “Just a moment…” challenge page and bot-fight mode can serve a challenge page to monitoring IPs, so the real content never loads. Either allowlist the monitor’s IPs or add the challenge text as a negative keyword so you learn about the block.
Pages behind authentication need a dedicated health endpoint or a scripted login. A keyword check against a login-protected dashboard only ever sees the login form.
Common Mistakes to Avoid
The first mistake is matching on text that appears on the error page too. The site name and navigation labels usually render on the 404 template and on most maintenance pages. A check for “Acme Store” will happily pass while every product page shows “Page not found”.
The second mistake is checking only the homepage. Homepages are usually the most heavily cached page on the site, often served straight from Varnish or a CDN edge. The cache can hide a dead database for hours until the TTL expires. Deeper pages with shorter cache lifetimes expose backend failures much sooner.
The third mistake is alerting on the first failure. A single missed match during a deploy, while PHP-FPM restarts, is noise. Requiring two or three consecutive failures cuts false alerts sharply. Reducing false positives without missing real issues covers this balance in more depth. For agencies running dozens of client sites, these false alarms quickly train people to ignore alerts.
FAQ: Keyword Checks for Page Content
How many keyword checks does a typical website need?
A small business site usually needs 3-5. An e-commerce store with separate category, product and checkout templates benefits from one check per template type, which usually means 6-10 monitors. Following WordPress monitoring best practices, you also add a negative check for the critical error message.
Should I use positive or negative keyword matching?
Use both. Positive matching catches empty or partial pages. Negative matching catches error messages that still render inside an otherwise intact layout. Together they cover the failures a status code misses.
Will keyword checks slow down my website?
No. A check running every minute adds 1,440 requests per day, which is negligible even on shared hosting. Exclude the monitor’s user agent from your analytics so the extra requests don’t skew your traffic reports.
Summary: Make Your Monitor Read the Page
Status codes tell you the server answered. Keyword checks tell you the page actually works. Pick keywords from the raw HTML that only appear when the backend is healthy, pair each one with a negative match for your platform’s error message, and require two consecutive failures before alerting. Then break a page in staging on purpose and confirm the alert arrives. That one test tells you more about your monitoring than months of green dashboards.