How to Monitor a Website for Changes and Get Notified

You are refreshing the same page every morning. Maybe it is a supplier’s availability notice, a job board, a status page or a policy document that quietly gets edited. You only care when something changes, but the only way you know is to go and look.

The usual fix is to set up a watcher and wait for an email. That works, until the watcher fires on every rotating banner and timestamp, and you start ignoring it. This post covers the two main routes, how to keep the alerts meaningful, and how to check the whole thing works.

The short answer

Pick one narrow part of one page, fetch it on a schedule, reduce it to the text you care about, compare it with the last saved version, and send yourself a message only when the two differ. You can do that with a hosted watcher tool you subscribe to, or with a small script you run on your own computer or server. Either way, check the site’s terms first, keep the schedule gentle, and test the alert by forcing a change before you trust it.

Hosted watcher or your own script

A hosted watcher is a ready-made service: you paste a URL, maybe highlight an area, choose how often to check and where to send alerts. Setup takes minutes, and you do not maintain anything. The tradeoffs are that you work within its options, your target list lives on someone else’s system, and pages that need a login or heavy scripting to render may not work well.

A script you run yourself is more work at the start. You decide exactly what counts as a change, how the alert reads, and where the data is stored. The tradeoffs are that you maintain it, and when the page layout changes, the script needs a small fix.

A rough guide:

  • One or two public pages, plain alert wanted: a hosted watcher is usually enough.
  • Several pages, a specific rule (“tell me only if this number drops below my threshold”), or alerts routed into your own tools: a script fits better.
  • A page behind a login: check the terms first. Many sites forbid automated access to logged-in areas, and that settles the question.

Pick one narrow target

Most noisy monitors fail for the same reason: the target is the whole page. A whole page contains ads, timestamps, session tokens, “recently viewed” lists and counters. Any of them can change on every load, so every check looks like news.

Narrow it down before you do anything else:

  1. Write one sentence describing the change you care about, such as “the notice text in the box at the top changes” or “a new row appears in this table.”
  2. Find the smallest part of the page that holds that information. Use your browser’s inspect tool to see its tag, class or id.
  3. Decide what counts as the same. Extra whitespace, capitalization and a “last updated” stamp usually should not count.

Check whether the site offers an RSS feed, a public data endpoint or an official alert signup. If it does, use that instead of reading the page. It is more stable, and it is what the site expects automated readers to use.

Build the check in four steps

The logic is the same whether you use a tool or write code.

  1. Fetch. Request the page on a schedule. An illustrative 15 minutes between checks is plenty for most pages. Frequent requests add load for the site and rarely help you.
  2. Extract. Keep only the narrow part you chose, as plain text.
  3. Compare. Check the extracted text against the version saved last time. A hash of the text is the simplest comparison. A line-by-line diff is better when you want the alert to show what changed.
  4. Notify and save. If the text differs, send the alert and then store the new version, so you are not alerted twice for the same change.

Here is a minimal version in Python that hashes a whole page. It is the skeleton only. In real use you would extract your narrow section before hashing.

import hashlib
import pathlib
import urllib.request

URL = "https://example.com/page"
STATE = pathlib.Path("last_hash.txt")

req = urllib.request.Request(
    URL, headers={"User-Agent": "page-check (contact: [email protected])"}
)
text = urllib.request.urlopen(req, timeout=30).read().decode("utf-8", "replace")

digest = hashlib.sha256(text.encode("utf-8")).hexdigest()
previous = STATE.read_text().strip() if STATE.exists() else ""

if previous and digest != previous:
    print("Page changed")  # replace with your email or chat alert
STATE.write_text(digest)

Schedule it with cron on Linux or macOS, or Task Scheduler on Windows. The first run only saves a baseline and says nothing, which is deliberate.

Make the alert useful and check it worked

An alert that says “page changed” sends you back to the page to hunt for the difference. Include three things instead: the page name, the old and new text of the section you watch, and the link. That is usually enough to decide in ten seconds whether to act.

Then test the monitor before relying on it:

  • Force a change. Point the script at a copy of the page you control, edit one word and confirm the alert arrives.
  • Check for false alarms. Run it for a few days with alerts going to a log file only. If it flags changes you cannot see on the page, your target is too broad or contains something dynamic. Narrow it, or strip the changing part.
  • Check for silence. A monitor that fails quietly looks the same as a page that never changes. Make the script alert you if a fetch errors out or returns a suspiciously empty result, and save a short log line on every run so you can see it is alive.
  • Plan for layout changes. If the site is redesigned, your selector may stop matching. An “empty section found” alert catches this before you miss real changes.

Respect the site’s terms and the law

Before you point anything at a site, read its terms of use and its robots.txt file. Some sites allow light automated reading of public pages, some forbid it, and some provide an official feed for exactly this purpose. Follow the target site’s terms and the law, including any rules on personal data and on accessing accounts.

Practical habits that keep you on the right side:

  • Check public pages only, and do not work around logins, rate limits or blocks.
  • Keep the schedule slow and identify your script with a contact address in the user agent, as in the snippet above.
  • Stop if the site asks you to or starts returning blocks.

This applies to anything you have built for you as well. Custom Builds will not take on a project that breaks a platform’s terms or the law, so if a request depends on getting around a site’s rules, the answer is a clear “not a fit.”

When to do it yourself and when to hand it off

Do it yourself if you are watching one or two public pages. Start with a hosted watcher and see whether its alerts are good enough. If you are comfortable with a little Python, the script above plus a scheduler covers a lot. You will learn quickly which parts of the page are noisy, and that knowledge helps whichever route you end up using.

Hand it off when the work around the check is the real cost: many pages with different selectors, a rule beyond “something changed,” alerts formatted for your team’s chat or email, or a setup that has to run unattended on your own server with a one-command install. If your time is worth more than the project price, or you do not want to debug selectors and schedulers, paying for the build is the more sensible route.

Custom Builds delivers code you run yourself. Projects start from $300, with a fixed price agreed in writing before any work starts. Qualifying projects are delivered in under 7 days as a single zip file with the source code, a README, an install guide for your operating system, a usage guide with troubleshooting, a one-command setup script and a sample config. It runs on your own computer or server, and you own the setup and any keys. Everything is handled by email, with no calls.

The takeaway

Choose one narrow section of one page, compare it with the last saved version on a gentle schedule, and alert only on real differences. Test it by forcing a change, make failures loud, and follow the site’s terms. Whether you use a hosted watcher or your own script, the discipline is the same: a small target and an alert you trust.

Custom Builds does not give financial, investment or betting advice.

If you would rather have this built for you: Custom Builds makes scanners, alert systems and scripts to your spec, with a fixed quote and delivery date, or a clear “not a fit,” within 24 hours of your request. Request a build at automatehive.net/custombuilds.

Custom Builds delivers software only. Nothing on this page is financial, investment or betting advice.