Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To run an n8n workflow when a page’s text changes, schedule a fetch of the page, extract only the part of the page you care about, normalize that text, and compare it with the version saved on the previous run. The workflow should send an alert or take any other action only when the two versions differ. The first successful run records a baseline and sends nothing, because there is no earlier version to compare against.
How the workflow fits together
Every change-detection workflow built this way follows the same chain of steps. Each step has a job, and each one can fail in a different way.
| Stage | Node used in the examples | What it does | What goes wrong if it is misconfigured |
|---|---|---|---|
| Schedule | Schedule Trigger | Starts a check at a fixed interval | Checks run in the wrong timezone or more often than the site tolerates |
| Fetch | HTTP Request | Downloads the page | The response lacks the text you expect, often because it is built by JavaScript |
| Extract | HTML | Pulls out the element that holds the monitored text using a CSS selector | The selector matches nothing, or matches navigation and timestamps too |
| Normalize | A Code step | Strips leftover markup and standardizes whitespace | Cosmetic changes still register as changes |
| Compare | A hash or a stored snapshot | Decides whether the text differs from the last run | No saved state exists, so every run looks like a first run |
| Act | Email, Telegram, Google Sheets, or Google Drive | Delivers the alert or logs the change | Alerts fire on every run because the branch is not gated by the comparison |
The pattern is documented in the cited n8n template for webpage change detection, which runs on a schedule, hashes the content, and only continues when the hash differs from the stored value. Webpage change detection and alerts with Google Suite and hash tracking describes that design, and it also treats public documents such as company terms and government policies as typical monitoring targets.
Recommended Free Tools
Build the workflow
The steps below assume a new workflow in a recent n8n version. Node labels and menus change between releases, so confirm each name against your installed version. The official n8n documentation describes the Cloud and self-hosted deployment options, and the steps are the same on either.
#1 Best Overall
Set the schedule and fetch the page
- Add a Schedule Trigger node and choose an interval. One n8n template runs once a day and another defaults to every four hours. Those are starting points, not recommended rates; choose an interval that matches how often the page is likely to change and how often you can reasonably request it.
- Open the workflow settings and set the timezone deliberately. A daily trigger set to the wrong timezone runs at an unexpected hour, which matters when you compare results across days.
- Add an HTTP Request node and enter the page URL. For a public page this is usually enough. If the page requires a login or cannot be reached by a plain request, replace this step with a web-scraping service rather than trying to work around the access control.
Extract and normalize the text
- Add an HTML node after the request. Use a CSS selector that targets the specific element holding the text you want to monitor, such as the main article body or a policy paragraph. Do not compare the whole page: navigation menus, footers, visitor counters, and “last updated” stamps change for reasons unrelated to the content you care about.
- Normalize the extracted text in a Code step. The community Website Change Watcher template removes basic HTML, style, and script content and collapses whitespace before comparison. That removes the most common noise, but a page that injects dynamic elements inside the selected block will still need extra handling, such as removing those elements by their own selectors before normalization.
Compare against the saved state
- Compute a hash of the normalized text, or save the normalized text as a snapshot. Both approaches are covered in the next section.
- Read the previously stored value, compare it with the current one, and route the workflow through an IF node. The true branch continues to the alert. The false branch stops.
- Write the current value back to storage on every run, whether or not it changed. If you only update storage after a change, the workflow will keep alerting on the same difference.
Handle the first run and send the alert
- On the first run there is nothing to compare, so store the baseline and end the run. A community example makes this explicit by skipping its initial baseline rather than treating it as a change, which avoids a false alert the moment the workflow is activated.
- On later runs, connect the true branch to your action. Email and Telegram suit real-time alerts. Google Sheets works well as a log of dates and changes, and Google Drive can hold a copy of the changed content. One cited template uploads the changed content to Google Drive, logs it to Google Sheets, and can send a notification email. Another sends Telegram and email alerts that include a diff.
Hash or snapshot: which to store
Both approaches tell you whether the text changed. They differ in what you can do afterward.
| Approach | What is stored | Advantage | Trade-off |
|---|---|---|---|
| Hash comparison | A short fingerprint of the normalized text, computed with a cryptographic hash in the cited template | Compact, and the comparison is a simple equality check | It tells you that something changed, not what changed |
| Snapshot with diff | The full normalized text from the last run, kept in a sheet or file | You can show a human-readable diff in the alert, and filter unchanged content directly | More storage, and the stored text may contain private or lengthy content you need to manage |
If you only need a yes-or-no signal for a single page, a hash is enough. If the alert should tell a reader what was added or removed, store a snapshot. The snapshot example in the Telegram and email template filters unchanged content before it sends anything.
Choose the fetch method
A plain HTTP Request followed by HTML extraction works when the text you want is present in the server’s response. It does not work when the page builds that text in the browser with JavaScript after it loads. The community Website Change Watcher example states that its simple approach does not handle JavaScript-rendered pages well, so it is the wrong tool for those sites.
Test this before building anything else. Run the HTTP Request node once, open its output, and search for a sentence you can see on the live page. If the sentence is missing, the text is rendered client-side, and you will need a rendering-capable scraping service to retrieve it. If the sentence is present but your selector returns nothing, the problem is the selector, not the fetch.
Rank #3
Choose the alert destination
| Destination | Shown in the cited material | Best used for |
|---|---|---|
| Template notification email and Telegram and email alerts | Notifying a person who needs to act on the change | |
| Telegram | Telegram and email alerts template | Fast notifications to a phone or chat |
| Google Sheets | Change log in the Google Suite template and snapshot storage in a sheet | A dated record of every detected change |
| Google Drive | Upload of changed content in the Google Suite template | Keeping a copy of the content as it was when it changed |
Use more than one destination when the people who need the alert and the people who need the record are different. Keep the record in the same place every time, so you can compare the history of changes later.
Troubleshooting common problems
- Alerts fire on every run. The comparison is not gating the action, or the stored value is never updated. Check that the IF node reads the saved state and that storage is written on every run.
- Alerts fire for changes that do not matter. The selector is too broad, or the normalization misses dynamic content such as timestamps or counters. Narrow the selector to the content block and remove the dynamic elements before comparing.
- The workflow never detects a change. The selector returns empty text, usually because the page is rendered by JavaScript. Confirm the fetched response contains the expected text, as described above.
- The first run sends an alert. The baseline branch is not stopping the run. Make sure the first-run path saves state and ends without reaching the notification step.
- A run fails. Open the execution history for that run, find the first node that returned an error or unexpected output, and fix that node before changing anything else.
Limits to keep in mind
This pattern is polling-based. It can only detect a change at the time of the next check, so a page that changes and reverts between checks will not be caught. Choose the interval with that in mind, and keep it within what the site’s terms allow.
Selectors belong to the page’s current markup. When the site redesigns its layout or renames a class, the selector may stop matching and the workflow will report empty text. Plan to review the selector whenever the workflow stops producing output.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →A workflow that works on one page does not transfer to another. Each target needs its own URL, selector, and normalization rules.
Best Value
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
For the Website Change Watcher template, the most recent public reference is a community post dated August 31, 2026, Website Change Watcher workflow template. The n8n templates cited here do not state a specific n8n release that they require, so test them on the version you run.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Sources
- n8n documentation overview: describes n8n as a platform for connecting apps and APIs, with Cloud and self-hosted options.
- Webpage change detection and alerts with Google Suite and hash tracking: scheduled fetch, extraction, hashing, comparison, and timezone guidance.
- Website Change Watcher workflow template: normalized hash comparison, baseline handling, and the JavaScript-rendering limitation; posted August 31, 2026.
- Monitor website changes and send diff alerts via Telegram and email: snapshot comparison, unchanged-page filtering, and example alert channels.
The Bottom Line
Schedule the fetch, select only the text that matters, normalize it, and compare it against the value saved on the previous run. Let the first run set the baseline, and send alerts only on later runs where the comparison finds a difference. Confirm early that the page’s text is present in the HTTP response, because a plain fetch cannot see text that JavaScript adds later.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
