A keyword monitor can look correct and still answer the wrong question. "Text exists" tells you whether the current content contains a term. "Keyword appeared" asks whether the detected change added it. Confusing the two can produce notifications about unrelated edits while the term remains on the page.
Another subtle problem appears when a one-direction rule works once, then seems to miss the next cycle. If unmatched changes do not update the saved baseline, the later comparison may not represent the transition you expected.
This guide covers those advanced configuration choices: match modes, AND/OR logic, capture scope, and saved baselines. For a first monitor, start with the beginner keyword setup guide, then use this article to refine a rule you can already inspect.
How do keyword change rules differ from text-exists rules?
Keyword change rules evaluate additions or removals involving a term. Text-exists rules evaluate the current captured content, so they can remain true across multiple unrelated edits. Choose the rule that answers your actual question, then check its interaction with capture scope, other conditions, and the saved version used for comparison.
| Condition | Question it answers | Common use |
|---|---|---|
| Keyword appeared or disappeared | Was a specified keyword added or removed? | Watch changes involving a feature or clause |
| Keyword appeared | Was a keyword added? | Notify about additions only |
| Keyword disappeared | Was a keyword removed? | Notify about removals only |
| Text exists | Does the current text contain a specified term? | Require a contextual term alongside another condition |
| Text doesn't exist | Is the specified text absent from current content? | Exclude a known irrelevant state |
| Exact match | Does this individual element equal the specified text? | Check a known status value |
An occurrence can be added or removed while the same keyword remains elsewhere in the captured content. Do not interpret every keyword alert as "this page has never mentioned the term before" or "the word is now absent everywhere."
For example, a fictional product page already mentions "Beta" in a footer and adds it to a feature description. A keyword appearance alert may be relevant even though a simple present-versus-absent test would not change. The diff tells you which occurrence moved.
Which keyword matching mode should you choose?
Choose substring matching for terms whose longer forms are relevant, and whole-word matching when shorter text would collide with unrelated words. Case sensitivity is a separate choice. PageCrawl provides four matching modes for keyword change conditions; select one deliberately and validate it against the vocabulary of the page you monitor.
| Match mode | With keyword "assist" |
|---|---|
| Match any text | Matches "assist", "Assist", and longer forms such as "assistance" |
| Match any text (case sensitive) | Matches lowercase "assist" and "assistance", but not "Assist" |
| Match exact words only | Matches the word "assist" regardless of capitalization, but not "assistance" |
| Match exact words (case sensitive) | Matches the lowercase word "assist" |
Use Match exact words only for a short product or technology name when substring matches would be misleading. Use a specific phrase when a single word has too many meanings. Case-sensitive matching is useful only when capitalization is a reliable part of the signal; editorial capitalization changes can otherwise cause unexpected matches or omissions.
These controls belong to keyword change conditions. Do not assume every text operator exposes the same matching controls. The notification conditions documentation lists each operator and its scope.
Which method should you use to watch for a keyword?
Use whole-page text with a keyword condition when the term could appear throughout a document, and select a specific region when its relevant context is stable. A narrower capture reduces unrelated matches, but it also excludes material outside that area. Verify both the included text and the coverage you intentionally leave out.
Method 1: Watch the whole page text, alert on a keyword condition
You track the full page as text and apply a condition such as Keyword appeared or disappeared for a named term. The monitor still checks the entire page, but the notification rule filters down to your keyword. This is the right choice when the word could appear anywhere on the page and you do not know in advance which element will hold it. Compliance documents and news pages fit here.
Best for: long documents, pages where the keyword's location is unpredictable, "does this page mention X at all" questions.
Method 2: Track a specific element, alert when its text changes
You point a selector at the element that holds the value, such as a stock badge or a status line. This avoids matching the same term in unrelated navigation or recommendations. Use a stable container whose selector does not depend on the keyword itself: a selector that requires "Add to Cart" may stop matching when the button text changes. The CSS selector guide and XPath and CSS reference explain region selection.
Best for: stock status, prices, version numbers, any value that lives in one known, stable element.
If the page provides a stable attribute on that element, a CSS attribute selector can target it independently of its changing text. MDN's attribute selector reference explains matching by attribute presence or value. Verify the chosen selector against both relevant page states; an attribute can change too.
Here is how the two compare in practice.
| Factor | Whole-page text + condition | Specific element + change |
|---|---|---|
| Setup effort | Low (no selector needed) | Medium (write a selector) |
| Main tradeoff | More unrelated occurrences | Changes outside the selected area are excluded |
| Catches keyword anywhere | Yes | No, only in the element |
| Best for | Compliance docs, news, forums | Stock, price, status, version |
| Handles unpredictable location | Yes | No |
A practical rule: if you can point at one element that always holds the word, use Method 2. If the word could land anywhere in a block of prose, use Method 1.
How do you combine keyword conditions with AND and OR?
Use separate conditions when you need separate requirements, then choose Match all conditions to require all of them or turn it off to accept any one. Multiple keyword tags inside a single keyword-change condition have any-match behavior. Neither arrangement establishes that matching words belong to the same sentence or listing.
Configure the logic explicitly
- Open the monitor editor and enable Advanced Mode.
- Enable Conditions & Filters, then choose Add Condition.
- Select the operator and enter its keywords.
- Add any additional conditions.
- Set Match all conditions on for AND or off for OR.
- Enable Always record change detections when unmatched changes should still update the saved history and comparison baseline.
For an illustrative release-notes monitor, require Keyword appeared for "deprecated" AND Text exists for the product identifier. This asks whether the keyword addition qualifies while the current capture includes the identifier. It does not establish that the deprecation applies to that product.
Avoid cross-listing matches
A whole recall index might contain "recall" in one item and your model number in another. Two page-wide conditions can both pass without describing the same notice. Select the relevant item or product-specific source where possible; otherwise, treat the alert as a lead that requires opening the notice.
Similarly, a numeric threshold combined with a keyword condition does not mean "the number beside this word." Track the correct price or number element and verify the relationship. PageCrawl's numeric conditions are separate from keyword matching, as described in conditional alert rules.
Why do one-directional keyword alerts need an updated baseline?
A one-direction condition can skip the opposite change, leaving the saved comparison baseline in the wrong state for the next cycle. Enable Always record change detections to save unmatched changes while notifying only on matches. This is especially important when you expect a keyword to appear, disappear, and appear again.
Consider an illustrative monitor using Keyword appeared for "Applications open." The intended cycle is:
| Capture | Page wording | Intended treatment with Always record enabled |
|---|---|---|
| Baseline | Applications closed | Establish the starting content |
| Next change | Applications open | Record the addition and qualify for notification |
| Next change | Applications closed | Record the removal without an appearance notification |
| Next change | Applications open | Compare against the updated baseline and qualify again |
Without recording the unmatched removal, the last recorded content may still say "Applications open." A later return to the same wording then has no new appearance relative to that saved version.
This table describes the intended rule behavior, not a live test result. First-check notification settings, other filters, failed checks, and delivery settings still matter. A change that happens entirely between successful checks cannot be reconstructed from those captures.
Choose two directions when both matter
Keyword appeared or disappeared is often easier to maintain when both additions and removals deserve review. For one-direction workflows, write the recording choice into the monitor's setup notes so someone editing the rule later understands why unmatched changes are being saved.
A quiet monitor is not proof of a successful rule. Use a monitor validation checklist that includes the repeat cycle, then inspect both history and notifications.
How do you diagnose an unexpected keyword alert?
Inspect the captured text and the highlighted change before changing the keyword rule. Identify which occurrence matched, whether the selected region is correct, and whether the rule tests a change or a current state. Then check matching mode, combined conditions, and the saved baseline, changing one setting at a time.
The keyword was already on the page
Look for a newly added occurrence or a removed occurrence elsewhere. If you used Text exists, another edit can satisfy that state condition while the keyword stays present. Switch to a keyword-change condition if additions or removals are the event you want.
A longer word matched
Check whether Match any text is selected. Substring matching can be intentional for related word forms, but Match exact words only is better when those longer strings are unrelated to your task.
A removal looked like a restock
The disappearance of "Out of stock" can reflect a redesign, a missing capture region, or a changed variant. It is not conclusive evidence that you can buy the item. Confirm a positive availability state and the live product page, or use stock availability monitoring for that task.
A relevant change never appeared in history
Check whether the capture succeeded and included the expected content. Then check filters and Always record change detections: unmatched changes are not recorded by default. Faster checks will not fix a selector that excludes the text or a condition that asks the wrong question.
What should you document before sharing an advanced keyword monitor?
Record the intended event, capture scope, matching mode, condition logic, and baseline behavior before handing a monitor to another person. Include a positive example and a counterexample that should stay quiet. These notes make unexpected results easier to investigate and prevent later edits from silently changing the meaning of an alert.
A compact handover can use this format:
| Setting | Illustrative release-note monitor |
|---|---|
| Intended event | An addition involving the word "deprecated" |
| Capture scope | Release notes for the selected product |
| Match mode | Match exact words only |
| Other condition | Text exists for the product identifier |
| Logic | Match all conditions enabled |
| Unmatched changes | Always record change detections enabled |
| Counterexample | The word exists unchanged while an unrelated date changes |
| Reviewer action | Open the changed entry and confirm the affected feature |
Choose cadence independently of keyword complexity. One daily monitor uses about 30 scheduled checks in a 30-day month; one hourly monitor uses about 720. Compare the full watchlist against current plan limits, and use the check-frequency planning guidance to reserve room for setup and other checks.
The next useful step is to review one existing alert against its saved content and configuration. If the rule answers the intended question, keep it. If it does not, adjust its scope or operator, run the relevant acceptance checks, and record why the configuration changed.
