Keyword monitoring for websites
Upcheck's keyword monitor fetches a page you choose every five minutes and checks it for a word or phrase — the button that must be there, the error that must not — then tells your team the moment that changes, by email, Slack, Discord, Teams, or webhook.
$10/month base · $1 per website · keyword check included
The page can be up and still be broken
An uptime monitor asks one question: did the server answer? It is the right first question and a bad last one. A WordPress site with a broken plugin answers 200 and prints “Error establishing a database connection” where the shop used to be. A deploy that shipped an empty template answers 200 with a perfectly valid blank page. A checkout whose “Place order” button vanished in a CSS refactor answers 200 to every probe while taking no orders. To the status code, all three sites are fine.
Keyword monitoring reads the answer. You name a phrase that is always on the page when it is healthy, or one that only shows up when it is not, and Upcheck confirms that expectation every five minutes. The failures it catches are the ones customers report and monitors miss: the white screen, the error banner, the missing button, the maintenance page someone forgot to turn off.
The same detection math as the uptime check: frequent enough to catch a broken page in minutes, confirmed enough that a deploy caught mid-flight never pages anyone.
Website keyword monitoring in three steps
- 01
Name the text and the page
Pick a word or phrase that is always on the page when it is healthy — or one that only appears when it is not — and the path to check: the homepage, /checkout, /login, an API endpoint. One keyword check per website, on any page of it.
- 02
The page is fetched every 5 minutes
A real HTTPS GET from Cloudflare's edge, redirects followed, caching disabled, and the HTML the server sends is searched for your text. The same document View Source shows — which is also what search engines, curl, and a half-finished deploy see.
- 03
Failures are confirmed, then alerted
One probe where the expectation stops holding starts the clock; a second, five minutes later, confirms it and fires your keyword rules — to email, Slack, Discord, Teams, or webhook. When the text is back where it belongs, a recovery alert closes the loop.
Text that should be there, and text that should not
Every keyword check is one phrase and one expectation. Which expectation depends on whether the failure you fear takes something away or adds something.
For the thing a working page always has: the “Add to cart” button, the login form's submit label, a product name, the footer copyright, the JSON key an API always returns. A white screen, an empty template, a stray maintenance page, a deploy that shipped the wrong branch — all of them take the text away, and all of them still return HTTP 200.
For the thing a working page never shows: a framework's fatal-error banner, a database connection message, a stack trace, a “temporarily unavailable” notice, the phrase your CMS prints when a plugin breaks. These are the failures that hide behind a successful status code, and the most specific text you can name is the best detector of each.
A verdict with the evidence attached
“Failing” on its own sends someone to open the page and squint. So every probe keeps what it saw: whether the text was found, the HTTP status the page answered with, how long it took, where redirects landed, and — when unwanted text turned up — a short excerpt around the match, so the alert reads “Fatal error: Uncaught PDOException” instead of “keyword found”.
The status code is recorded separately from the verdict. A page can pass the content check while answering 404, and fail it while answering 200; the two facts are different, and the dashboard shows both.
Every state a keyword check can be in
- Passing
The page answered inside 10 seconds and the expectation holds: the text you want is there, or the text you fear is not. The status code and response time are on the board beside it.
- Failing
The expectation stopped holding — expected text missing, unwanted text found — or the page could not be read at all: a 5xx, a timeout, a refused connection. One failing probe starts the clock; the second confirms it and fires your rules.
- Checking
Just set, or just changed. The first probe runs the moment you save, so a new keyword check has a real verdict in seconds rather than at the top of the next five-minute slot.
- Not set up
Every website has a keyword check waiting. Until you name the text, it costs nothing, alerts nobody, and sits on the checks panel as a reminder that it exists.
One alert per failure, and one when it is fixed
A keyword rule fires when a failure is confirmed and, with the recovery trigger, again when the page passes — nothing in between unless you ask for it. The alert says which it was: “Expected text missing” when the phrase you rely on disappeared, “Unwanted text found” with an excerpt when an error surfaced, and “Keyword check failing” with the HTTP status when the page could not be read at all.
The first keyword check you set brings its own rule: an email to whoever set it, firing on failure and recovery, so nothing needs configuring before the alerts work. From there it behaves like every other rule — scope it to specific websites, set the cadence to once per incident or hourly while something stays broken, and point it at email lists, Slack, Discord, Microsoft Teams, or a webhook, where it arrives as a structured keyword.alert event your own tooling can route apart from an outage.
What makes a good keyword to monitor
The check is only as good as the phrase. These are the rules that keep it quiet when the page is fine and loud when it is not.
- 01
Stable, not decorative
Choose text that survives redesigns and campaigns: a navigation label, the checkout button, the company name in the footer. A hero headline changes the week marketing feels like it.
- 02
Check View Source, not the screen
The probe reads the HTML the server sends. If your text only exists after JavaScript runs — a React app that renders client-side, a widget loaded later — it is not there to be found. Right-click, View Page Source, search for the phrase.
- 03
Avoid anything personalised
“Welcome back”, a cart count, a city name from geolocation, an A/B test variant — all of these vary between requests and will trip a check that has no way of knowing why.
- 04
Prefer the specific error
For an absent-mode check, the exact string your stack prints when it breaks beats a generic word. “Error establishing a database connection” is unambiguous; “error” also matches an error-handling blog post.
- 05
Mind entities and casing
Matching is case-insensitive unless you turn on case sensitivity. HTML entities are not decoded, so text that appears as “Terms & Conditions” in the source will not match “Terms & Conditions” — pick a phrase without one, or match what the source really says.
- 06
One check, the page that matters
The homepage is the default, but the page that costs money when it breaks is usually /checkout, /login, or /pricing. Point the check there; the uptime probe already has the homepage.
What to look for in a keyword monitoring tool
Most keyword monitoring tools are the same feature under different pricing. These are the differences that matter once it is running.
- 01
Honest about what it reads
Every keyword monitor searches the HTML the server sends, not a rendered page. A tool that says so up front saves you a week of mystery failures on a client-rendered app; one that hides it will teach you the same lesson the hard way.
- 02
Both directions
Text that should be present catches the missing button and the blank template. Text that should be absent catches the error banner and the stack trace. A monitor that only does one leaves half the failures unwatched.
- 03
Confirmation before anyone is paged
Deploys take a few seconds to settle and origins have slow moments. A second probe before the alert is what separates a check the team trusts from one they mute.
- 04
Any page, not just the homepage
The page that costs money when it breaks is /checkout or /login, and neither is where an uptime probe looks. The check should take a path.
- 05
Evidence in the alert
Status code, response time, and an excerpt around the match. "Keyword found" sends someone to squint at the page; "Fatal error: Uncaught PDOException" tells them what to fix.
- 06
Priced with the website, not per keyword
When each keyword check is a separate monitor against a quota, teams ration them and the checkout page goes unwatched. It should come with the website, on the same dollar as the uptime probe.
Comparing keyword monitors? The honest UptimeRobot alternative page lists where its keyword monitoring goes further than this one, and where it does not.
What this keyword monitoring is not
“Keyword monitoring” is an overloaded phrase. If you arrived looking for one of these, this page will not help, and it would rather say so than waste your evening.
Not SEO rank tracking
“Keyword monitoring” also names the SEO practice of tracking where a page ranks for a search term. That is a different product with different tools. This one reads your own page for your own text.
Not brand or mention monitoring
It does not scan the web, social media, or the news for people talking about you. It fetches one URL you own and asks one question of the HTML.
Not visual or page-change diffing
It will not tell you a paragraph was reworded or a hero image changed. It confirms one exact phrase is present or absent, which is what makes its alerts specific and its false alarms rare.
Not a rendered browser
No headless Chrome runs on each probe. Text produced by client-side JavaScript is invisible to it, as it is to UptimeRobot, StatusCake, Better Stack, and every other keyword monitor that reads the response body.
Included in the dollar
$10 per month for the workspace, plus $1 per website per month — and the dollar covers everything Upcheck watches on that website: uptime every 5 minutes, the keyword check every 5 minutes once you set one, the SSL certificate every 12 hours, DNS every 6, and the domain registration daily. The per-website charge is metered daily, so adding a website mid-cycle costs only the days it was tracked. There is no separate keyword monitor to count, no tier that withholds it, and no cap on how many of your websites run one. A workspace can track up to 500 websites.
Want to see what a page is serving right now, without an account? The free HTTP status checker and website down checker answer the one-off question.
Frequently asked questions
What is keyword monitoring?
Keyword monitoring for websites is an automated check that fetches a page at a fixed interval and searches the HTML the server sends for a specific word or phrase, then alerts a responsible person when that text is missing — or, in the inverse mode, when an unwanted phrase such as an error message appears. It exists because a page can return HTTP 200 while showing a blank template, a database error, or an empty product grid; an uptime check sees a healthy status code, and only a check that reads the content notices the page is broken.
How is keyword monitoring different from uptime monitoring?
Uptime monitoring asks whether the server answered and how fast; keyword monitoring asks whether it answered with the right page. The two fail differently. A crashed origin fails both. A deploy that ships an empty template, a CMS plugin that prints a fatal error inside an otherwise normal response, a maintenance page left on, a checkout whose button vanished — those all pass uptime and fail keyword. Upcheck runs both on every website, on the same five-minute cadence, and confirms each with a second probe before alerting.
Is this the same as SEO keyword monitoring or rank tracking?
No. In SEO, “keyword monitoring” means tracking where your pages rank in search results for chosen search terms, using tools such as rank trackers and Search Console. Upcheck's keyword check does not look at search engines at all: it requests a page on your own website and confirms a phrase you chose is present on it (or absent from it). If you are looking for rank tracking, this is not it; if you want to know the moment your checkout page stops saying “Place order”, it is.
Does keyword monitoring work on JavaScript-rendered pages?
Only for text that is in the HTML the server sends. Each probe is an HTTP GET, not a browser session, so anything a script adds to the page after load — a single-page app's rendered content, a widget fetched later, a lazy-loaded section — is not there to be found. Check with View Page Source: if the phrase appears there, it can be monitored; if it only appears in the browser's Elements inspector, it cannot. Server-rendered sites, most CMS pages, static sites and JSON APIs all work as expected.
Is the match case sensitive?
Not by default: “Add to cart” matches “ADD TO CART” and “add to cart”. Turn on case sensitivity when the casing is the signal — for instance to catch “ERROR” from a logging library without matching the word in ordinary copy. Matching is an exact substring search on the raw HTML, so HTML entities are not decoded and whitespace is compared as written.
What text should I monitor?
For a present-mode check, something the healthy page always has and a broken one loses: the primary button's label, a navigation link, the company name in the footer, or for an API a key that is always in the JSON. For an absent-mode check, the most specific string your stack prints when it fails — the exact database error, the framework's fatal-error banner, “Out of stock” on a product that should not be. Avoid personalised or rotating text, anything rendered by JavaScript, and single common words.
Can I check a specific page rather than the homepage?
Yes. The keyword check takes a path on the website's hostname — /checkout, /login, /api/health, or anything else — and defaults to the homepage. Redirects are followed, so a path that moved still resolves. Each website has one keyword check; to watch several pages of the same site, add each hostname you care about, or put the check on the page whose failure costs the most.
What happens when the page returns an error or does not load?
A server error (any 5xx) fails the keyword check before any text is read, because an error page can contain your site's navigation and so the text you asked for, and passing on that would defeat the point. A timeout or a refused connection fails it too. A 4xx is evaluated like any other response: a 404 that still shows the expected text is a page that exists, whatever the status says. In every case the status code is recorded alongside the verdict, and the uptime check on the same website reports the outage in its own words.
How often is the page checked, and how are false alarms avoided?
Every 5 minutes, around the clock, with each probe fetching the page fresh and with caching disabled so a stale copy can never hide a live problem. No alert fires on a single failed probe: the check has to fail twice in a row, five minutes apart, before your rules fire, so a deploy caught mid-flight or a momentary slow origin never pages anyone. When the expectation holds again, a recovery trigger sends the all-clear. Worst case from the text disappearing to a confirmed alert is about ten minutes.
How much does keyword monitoring cost?
Nothing extra. Upcheck is $10 per month for the workspace plus $1 per website per month, and the dollar covers every check on the website: uptime every 5 minutes, the keyword check every 5 minutes once you set one, the SSL certificate every 12 hours, DNS every 6, and the domain registration daily. Every alert channel is included at every size, and there is no tier that withholds keyword checks or meters how many you run across your websites.
Know the page is right, not just reachable.
Add the websites you own, name the text that proves each one is working, and let the probes read the page for you.