Keyword monitoring: alert on the presence or absence of a word
Website Change Detection
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Keyword monitoring is a check that requests a web page at a fixed interval, searches the returned HTML for a word or phrase and alerts you when the result is not what you expect: either an expected keyword (your brand name, “Add to cart”) is missing, or an unwanted one (“error”, “out of stock”, a spam term) appears. It catches broken pages that still return 200 OK. Pick stable phrases that are in the raw HTML source, not text that JavaScript inserts later. monitordefend does not offer keyword monitors; it checks uptime, response time and suspicious changes such as spam terms and foreign redirects instead.
- “Keyword not exists” = alert when an expected phrase disappears.
- “Keyword exists” = alert when an unwanted phrase appears.
- Only the raw HTML counts – check “View page source” first.
expect “Add to cart” → found ok expect “Blue mug” → found ok forbid “Out of stock” → found ALERT forbid “Fatal error” → not found ok
A server can answer “200 OK” while the page it delivers says “Database connection failed”, shows an empty template or has lost its “Add to cart” button. Keyword monitoring closes that gap: instead of trusting the status code, it reads the page and checks whether a specific word or phrase is there – or whether one that should never appear has shown up. This guide explains how keyword-based monitors work, the difference between “keyword exists” and “keyword not exists”, which keywords to pick, how to set a monitor up with standard tools, and the mistakes that turn a useful check into a stream of false alarms.
What keyword monitoring is and how it works
Keyword monitoring is a type of website check that looks at content rather than connectivity. At a fixed interval – every one, five or fifteen minutes – the monitor sends an HTTP request to a URL, receives the HTML the server returns and searches that text for a word or phrase you defined. Depending on how you configured it, the monitor then raises an alert if the phrase is missing or if it is present. Everything else – the interval, the confirmation of a failure, the notification – works like an ordinary uptime monitor.
- 200
Server answered - HTML
Template rendered, product list empty - ×
“Add to cart” missing → keyword alert
The reason keyword-based monitors exist is that a successful status code says very little about what a visitor actually sees. Web applications routinely catch their own errors and render a friendly error page with status 200. A failed deploy can leave a blank template, a CDN can serve a stale maintenance page, and a plugin conflict can remove the checkout button while the rest of the page loads normally. To a plain HTTP check, all of these look like a healthy site. To a keyword check, they look exactly as broken as they are.
Because it reads the page, keyword monitoring is also useful beyond outages: it can tell you when a price or a stock note changes, when a legal notice disappears, or when unwanted text such as spam links has been injected. It is the simplest form of content verification you can add to a website.
Monitor the presence or absence of any word or phrase
Every keyword monitor works in one of two directions. A “keyword not exists” monitor – sometimes called “alert if missing” – expects a word or phrase to be on the page and alerts you when it disappears. You use it for content that must always be present while the site works: the product name on a product page, “Add to cart” on a shop, the login button on an app, the confirmation text on a thank-you page.
A “keyword exists” monitor works the other way round: it alerts you as soon as a specific word appears. Typical candidates are error strings such as “Fatal error”, “Warning:”, “Database connection failed”, “502 Bad Gateway” or “Service unavailable”, but also business signals such as “Out of stock” or “Sold out”. In both cases the monitor triggers when the condition you defined is met, and it recovers when the page returns to the expected state.
Most tools also let you decide whether the match is case-sensitive and whether the phrase must match exactly. Case-insensitive matching is the safer default for error strings, whose capitalisation varies between frameworks; exact matching is better for product names that should appear precisely as written.
- Keyword not exists: brand name, main navigation, “Add to cart”, “Sign in”
- Keyword exists: “Fatal error”, “Database error”, “Bad Gateway”, “Out of stock”
- Spam signals: casino, pharma or loan terms that should never be on your site
Keyword monitoring versus website monitoring
Website monitoring – an HTTP or uptime check – asks whether the server answered with a successful status code within a timeout. Keyword monitoring asks whether the answer contains the right content. The two questions overlap but are not the same: a page can return 200 OK while showing an error message, empty content or a broken checkout, and a keyword check will catch exactly those cases that an HTTP check reports as up.
In practice teams run both. The HTTP check is cheap, unambiguous and ideal for measuring an uptime percentage; the keyword check verifies that the most important pages render what they should. A sensible pattern is one HTTP monitor for the homepage plus keyword monitors for the two or three pages that make money or matter most – the checkout, the login, a key landing page. Ping and port checks sit one layer lower still: they tell you a host or service is reachable, not whether any page works.
| Check type | Answers the question | Misses |
|---|---|---|
| Ping / port | Is the host or service reachable? | Any problem in the web application |
| HTTP / website | Did the page return a success code in time? | Error pages and empty content served with 200 |
| Keyword | Does the page contain (or not contain) this phrase? | Text inserted later by JavaScript |
| Browser / transaction | Does a full user flow work in a real browser? | Little – but slower and costlier to run |
What keywords should you monitor?
The best keywords are phrases that are always present when the page works and absent when it does not. Stable, structural text works well: your brand name in the header, a navigation label, a heading that never changes, a product category name, “Add to cart” on a shop or “Forgot password?” on a login form. Avoid text that changes for legitimate reasons – dates, prices that move, rotating banners, personalised greetings or A/B-test copy – because every change will look like an incident.
<h1>Blue mug</h1> visible in source ✓ <button>Add to cart</button> visible in source ✓ <div id="price"></div> ← filled by JS empty in source ✗
For “keyword exists” monitors, collect the error strings your own stack actually produces. Look at your framework’s error page, your CMS’s maintenance message, your hosting provider’s default 503 page and your CDN’s error template, and add the distinctive phrase from each. Generic words such as “error” alone are risky: they appear in harmless places such as “error-free checkout” or a blog post title. A longer, specific phrase gives fewer false positives.
Finally, prefer a few meaningful keywords on a few critical pages over dozens of monitors on every URL. Each monitor is something you have to maintain when the site’s copy changes, and a forgotten keyword that was removed in a redesign will alert forever.
JavaScript-rendered content and the page source
A keyword monitor checks the raw HTML that the server returns – the same text you see under “View page source” in your browser – not the page after a browser has executed its JavaScript. On classic server-rendered sites this makes no difference. On single-page applications, headless shops and sites that load prices, stock levels or reviews from an API after the page loads, the text you see on screen may not exist in the source at all.
The test is quick: open the page, choose “View page source” (not the developer-tools element inspector, which shows the rendered DOM), and search for your keyword. If it is in the source, a keyword monitor will find it. If it is not, choose another phrase that is server-rendered, monitor the API endpoint that delivers the data instead, or use a browser-based synthetic check that actually renders the page. Also keep in mind that HTML entities and markup can split a phrase: “Add to cart” or a phrase broken by a <span> will not match a plain search.
How to set up keyword monitoring
Setting up a keyword monitor in any monitoring tool comes down to four decisions. First, the URL: one specific page, ideally a canonical URL without tracking parameters, so the monitor always fetches the same content. Second, the keyword: a phrase you have confirmed in the page source. Third, the condition: alert when the keyword exists, or when it does not. Fourth, the alerting: who is notified, by which channel, and after how many failed checks.
- Pick URL One page per monitor
- Keyword Stable phrase from the source
- Condition Exists or not exists
- Alert Confirm, then notify
If you want to see the mechanism before choosing a tool, a single command shows it. Fetching the page with curl and piping it into grep returns a match or nothing; wrapping that in a scheduled job that sends a mail on a non-match is the simplest possible keyword monitor. For example, curl -s https://www.example.com/checkout | grep -q "Add to cart" || echo "keyword missing" is the whole idea in one line. A hosted monitor adds what the script lacks: checks from outside your own network, confirmation of failures, an incident history and reliable notifications.
Set the interval to match the importance of the page – every few minutes for a checkout, hourly or daily for a stock watchdog – and send a realistic user agent, because some firewalls serve a challenge page to unknown clients, which would make the keyword vanish without the site being broken.
Alerts, confirmation and maintenance windows
A good keyword monitor does not alert on the first mismatch. Pages occasionally return a partial response, a cache hiccup or a short-lived error, and a single failed check is not an incident. Most tools therefore confirm a failure with a second request, or alert only after the condition has held for two or three consecutive checks. That small delay removes most false alarms while still telling you about real problems within minutes.
Recurring notifications are worth configuring for important monitors: if a keyword is still missing after an hour, a reminder makes sure the alert has not been lost in an inbox. Maintenance windows do the opposite – they pause the monitor while you deploy or edit content, so that a planned change does not page anyone. And choose the channel to fit the urgency: email works for most checks, while a missing checkout button on a busy shop may justify a channel that reaches someone faster.
- Confirm a mismatch with a second check before alerting
- Send reminders while an important keyword stays missing
- Pause monitors during deploys and content edits
- Route alerts by urgency – not every keyword deserves a phone call
Use cases: from error detection to a restock watchdog
The classic use case is error detection on your own site: catching the database error, the white screen of death, the empty product grid or the missing checkout button that an uptime monitor reports as healthy. A close second is deploy verification – a keyword that only exists in the new release confirms that the deploy reached production and that caches were cleared.
- “Out of stock” found – condition not met, no alert
- “Out of stock” still present
- “Out of stock” gone, “Add to cart” present → alert
Keyword monitoring also works as a watchdog for any website, including pages you do not control. If the product you want is out of stock and the shop offers no notification, a “keyword exists” monitor on “Out of stock” that alerts when the phrase disappears tells you when it is back. The same pattern tracks a price drop, the appearance of a new job posting, the publication of a document or a change in a supplier’s terms. Be considerate with other people’s sites: a check every few hours is enough for a watchdog, and respecting their terms of use is part of doing it well.
A third use case is a rough integrity signal. Monitoring that your brand name and legal footer are present, and that common spam terms are absent, can reveal a defacement or an injection of hidden links. It is not a security scanner, though: attackers often hide spam from normal visitors and show it only to search engines, which a single keyword check from one user agent will not see.
Common keyword-monitoring mistakes
Most keyword monitors that cause trouble fail in predictable ways. The phrase only exists after JavaScript runs, so the monitor alerts from the first minute. The keyword is too generic, so “error” in a blog headline triggers a false alarm. The phrase changes with every marketing update, so the monitor alerts after each redesign until someone deletes it. Or the page shows different content to the monitor than to a visitor – a cookie banner, a geo-redirect, a bot challenge – and the keyword is never there for the checker.
The opposite mistake is a keyword so stable that it survives the failure it should detect, such as a brand name in a header that is still rendered on an error page. Test each monitor by asking: if this page broke in the way I fear most, would this phrase really disappear? If the honest answer is no, pick a phrase deeper in the page’s main content.
Keyword checks and monitordefend
monitordefend does not offer keyword monitors – you cannot define your own word or phrase to watch. What it covers on the same pages is adjacent: an uptime check of the homepage every five minutes with a second attempt to confirm an outage, response-time alerts, and an hourly integrity check that flags spam terms, new external script, iframe and form domains, redirects to foreign domains and cloaking towards Googlebot. If you need custom keyword assertions, run them in a dedicated tool alongside it.
Frequently asked questions
What is keyword monitoring and how does it work?
Keyword monitoring regularly requests a web page, searches the returned HTML for a word or phrase and alerts you when an expected keyword disappears or an unwanted one appears. It catches error messages, missing content and broken checkout pages that standard uptime checks miss.
What is the difference between keyword monitoring and website monitoring?
Website monitoring checks whether a page returns a successful HTTP response; keyword monitoring checks whether the expected content is actually on the page. A page can return 200 OK while showing an error, so many teams run both.
What is the difference between “keyword exists” and “keyword not exists”?
“Keyword not exists” alerts you when a phrase disappears, for content that must always be present such as a login button. “Keyword exists” alerts you when a phrase appears, such as “error” or “out of stock”. Both trigger when the defined condition is met.
Does keyword monitoring work with JavaScript-rendered content?
Usually not. Keyword monitors read the raw HTML source the server returns, not the page after JavaScript has run. Check “View page source” in your browser: if the phrase is there, the monitor will find it.
Can keyword monitoring detect if my site has been hacked?
Sometimes. Watching for your brand name and for spam terms can reveal a defacement or injected links. It is no replacement for security scanning, because many hacks show spam only to search engines and hide it from normal visitors.
Does monitordefend offer keyword monitoring?
No. monitordefend checks uptime, response time and suspicious changes such as spam terms, foreign redirects and new external script domains, but it does not let you define custom keywords to watch.
Related pages
Know when a working server serves a broken page
Start for free and set up your first check in minutes.
Start for free