To monitor a website for changes, you set up something that re-fetches the page on a schedule, compares it against the copy it saved last time, and alerts you when the two differ. If a regulator quietly rewrites a guidance page or a competitor drops their price overnight, you find out in minutes instead of weeks. Most people can get a working monitor running in about fifteen minutes; the fiddly part is not setting it up, it is cutting out the noise.
Writers, editors, developers and small teams use this constantly. The newsroom case is straightforward: you publish a story citing a public agency page, and six weeks later the wording has changed. The web team case is uptime and defacement. The marketing case is watching what competitors do to their own pages. All of them use the same three-step mechanism, so the real work is choosing scope and filters.
Table of Contents
What You Need
Four things, and you can get through them in a single sitting.
The exact URLs or page areas to watch
A URL is a starting point, not a decision. The decision is which part of that page matters. A regulator’s guidance page might be worth watching as whole text; a competitor’s homepage might only be worth watching for the pricing section. Writing down the specific thing you expect to see is what makes the rest of the setup useful.
A defined schedule
Pick an interval you would actually act on. Fifteen minutes is sensible for appointment slots and ticket releases. Daily is enough for pricing pages and documentation. Hourly for something like that produces dozens of notifications you will learn to ignore.
A monitoring method
There are four tiers, and they differ more than most listicles suggest.
- Manual checks — reopening the page each day yourself. Fine for one page, useless for twenty, and nobody has ever done it reliably for a whole quarter.
- Browser-based tools — extensions and bookmarklets that capture a page or part of a page from your own browser. Good for a one-off comparison, weak for scheduling.
- Visual monitoring — a service takes a screenshot on a schedule and shows you the two images side by side, with differences highlighted. It catches anything a human eye would catch, including a background image swap or a layout shift, but it tells you “the pixels differ” rather than “this price went from 89 to 79”.
- Automated text or DOM change detection — a service re-fetches the page, strips out the parts you do not care about, and sends you a real diff showing the lines added and removed. This is what most people actually need, and it is the version most competitors never explain.
Alert delivery and a change record
Decide where the alert goes before you configure anything, because a monitor that emails you is half a monitor. Email is the baseline. A chat channel such as Slack or Teams is better if alerts need to be triaged by several people. A webhook is better still if a script will act on the result. A feed you can subscribe to in a reader is the most durable option, since nothing breaks when a vendor shuts down.
Keep a record too. Even a shared spreadsheet with four columns — page, date checked, what changed, whether it mattered — turns a pile of notifications into a usable history. Page owners get much better at acting on a monitor when they can see that the last four alerts on a page were all cosmetic.
Step-by-Step
Step 1: Define the Pages and Changes That Matter
Start with three to five URLs, not twenty. For each one, write down the trigger in plain language: “a new headline appears in the news section”, “the price in the subscription box changes”, “the page returns a defacement warning”. If you cannot phrase the trigger as a sentence, you do not yet know what to monitor.
Then decide the scope of the watch. Whole-page monitoring catches everything and floods you with alerts from rotating banners, view counters and session timestamps. Element-level monitoring watches one region of the page — a table cell, a heading, a specific paragraph — and stays quiet about everything else. For anything that matters, element-level is almost always the better choice.
Watch for two more traps here. The first is monitoring a page that changes every visit regardless of content, such as a live counter; it will generate an alert every single time. The second is a selector written against the current markup. Many sites generate hashed CSS class names on every deployment, so a selector captured today can break after next week’s rebuild. Prefer a stable element — a heading text or an item attribute — over a generated class name wherever the tool allows it.
Step 2: Choose a Monitoring Method
Match the method to the change you described in Step 1, not to whichever tool has the biggest list of features.
| Method | What it tells you | Good for | Main limitation |
|---|---|---|---|
| Manual check | Whatever you notice | One page, low stakes | You will forget |
| Browser capture | A saved copy of the page or element | One-off comparisons, archiving a source | No scheduling, no alerts |
| Visual screenshot diff | Two images with differences highlighted | Design regressions, defacement, layout shifts | Says nothing about the underlying values |
| Text or DOM diff | Exact lines and elements added or removed | Price, headlines, regulation wording, availability | Misses changes that do not alter text |
| Self-hosted open source monitor | The same diffs, on your own machine | Long-running archives, internal tools, sensitive data | You maintain it |
| Hand-written script | Whatever you code it to output | Pipelines that feed another system | You maintain it, and it breaks on markup changes |
Most people should start with a hosted text or DOM diff tool. Visual diffing earns its place when layout matters, which is common when you own the site and want defacement and redesign alerts. Self-hosting pays off once you have more than a handful of monitors, or once the history itself matters — an archive you control is an archive nobody can take away.
Step 3: Configure Alerts and Check Intervals
Set the interval before you set everything else, then set it once. Most hosted tools default to something aggressive enough to annoy you within a day. Raise it until the notification volume looks survivable.
Now narrow what counts as a change. Every serious tool offers some combination of these controls, and they are the difference between a monitor you keep and a monitor you mute:
- Element or region selection — watch only this block of the page.
- Ignore-text filters — ignore lines matching patterns such as timestamps, session IDs or rotating taglines.
- Remove elements — strip ads, cookie banners, share bars and comment counts before diffing.
- Trigger on text — only fire the alert when a specific word or phrase appears, which turns a page watcher into an appointment-slot watcher.
- Break a change into a text match — keep content changes out of your inbox while still letting keyword alerts through.
Pick the alert channel at the same time. Email is reliable and slow. Chat is fast and easy to triage. A webhook lets a script react without you reading anything. A feed works with a reader or an aggregator and survives a vendor disappearing. If you monitor several pages on one domain, space the checks out rather than running them all at once, so your own traffic pattern stays polite to the site you are watching.
Step 4: Review the Change and Its Impact
This is where most setups fail, because the alert arrives and nobody reads it properly. An alert tells you something changed. It does not tell you whether it matters.
Work through the diff in four layers. Text changes are the easiest: a sentence was added, removed or edited, and you can read both versions. Structural changes mean elements appeared or disappeared — a section removed, a table restructured, a link target changed. Visual changes are differences that never touch text, such as an image swap or a menu that moved. Metadata changes live outside the visible page: the title tag, the meta description, the canonical URL, structured data. Those matter enormously for anyone doing search work and almost nobody watches them.
Then record four fields: what changed, when it changed, whether it matters, and what happens next. That last column is the one that separates monitoring from an inbox subscription. “Wording on the eligibility section changed” is a fact. “Cite the archived snapshot from Tuesday, not the live page” is an action.
One thing to be careful about: a monitor that works from a plain HTTP fetch sees only what the server sends. Pages that build themselves with JavaScript can come back nearly empty, which produces a diff against a blank snapshot and an alert that means nothing. If a page loads its content in the browser, you need a tool that renders it with a real browser before comparing. Login-gated pages raise the same problem in a harder form, and most tools handle them badly.
Step 5: Test, Refine, and Maintain the Monitor
A monitor you have never tested is a guess. Test it deliberately rather than waiting for something real.
Make a change you control, if you own the site: edit a headline, adjust a date, add a paragraph. Confirm the alert arrives within one interval and that the diff points at the text you changed. Then test the noise filters by visiting the page in a private window, where consent banners and session-dependent elements appear, and see whether the monitor stays quiet. A monitor that fires on a consent dialog will train you to ignore it.
After a few weeks, review the history. Count the alerts that mattered as a share of the total. If that number is under half, your scope is too wide. Narrow the element, add an ignore-text rule, or drop the page entirely. Delete monitors nobody reads — a stale monitor is not neutral, because it teaches people to ignore the whole system.
Write down the settings somewhere the team can find them: which pages, which interval, which filters, who reviews it. When the person who set it up leaves, everything above stops without that note.
Common Mistakes
Monitoring too many pages at once. Fifty monitors started on day one produce fifty alerts and zero decisions. Start with three, prove the value, expand.
Tracking dynamic elements. Ads, cookie banners, live counters, “last updated” stamps and random session tokens will fire your monitor every visit. Filter them out before you filter anything real.
Choosing an interval that is too fast. Checking every two minutes against a site you do not own is a good way to get rate limited or blocked, and it does not make you any faster at reacting to a policy page.
Treating a failed fetch as a content change. A timeout, a 502 or a bot-protection page looks like a massive diff. Check the HTTP response and the saved snapshot before you report anything.
Ignoring visual-only changes. Text diffing is blind to a swapped logo, a moved menu and an injected image. If the look of the page matters, run a visual monitor alongside the text one.
Never documenting or reviewing the alerts. Alerts nobody reads are the same as no monitoring, except you pay for them in noise. Put the history somewhere a human actually opens.
Scraping a site aggressively or ignoring its terms. Keep request rates low, set a descriptive user agent where the service allows one, and check the site’s terms and robots.txt before monitoring anything you do not own. Watch public information, stay out of anything gated behind a login you have no authorisation for, and do not republish what you capture without checking the rights. Rules vary by country and site, so this is a question for a lawyer when it matters commercially.
Assuming a selector will last. If the site is rebuilt with generated class names, your element watch quietly stops matching. Add a periodic manual check that the element still resolves, and re-select it if not.
Frequently Asked Questions
How does website monitoring work?
A monitor re-fetches the page on a schedule you set, compares it against the last copy it saved, and checks the difference against your rules. If anything changed, it sends a notification containing a diff, a highlighted screenshot, or both. That re-fetch, compare, notify cycle is the whole mechanism behind every tool, whether it is a hosted service, a self-hosted one, or a script you wrote yourself.
How do I monitor only part of a webpage for changes?
Watch a single element rather than the whole page. Most tools let you pick a region with a visual selector or write a CSS or XPath expression, and only that region’s content gets compared. It is the practical fix for alert fatigue, because a page’s rotating banners and view counters stop generating notifications once they sit outside the watched region.
What is the best free website change monitoring tool?
Free tiers exist across most of the main services, but they differ sharply on how many monitors you get, how often they run, and whether you can watch a single element or only a whole page. Self-hosted open source monitors have no monitor limit and no vendor in the middle, at the cost of running the service yourself. Pick based on how many pages you need and whether you can maintain a small server.
Can these tools track changes behind a login screen?
Usually only with help. Most hosted services fetch pages anonymously, so anything behind a login comes back as a redirect and produces a meaningless diff. A few tools support scripted browser steps or cookie import so they can log in first. For anything sensitive, self-hosting a monitor and controlling the session yourself is usually the more reliable path.
Why do I get so many false change notifications?
Almost always because the whole page is being compared, including ads, cookie banners, timestamps and other rotating elements. Narrow the watch to a single element, add ignore-text rules for timestamps and session tokens, and remove the ad and share regions from comparison. If a page still fires constantly, watch for a keyword trigger instead of treating every diff as an alert.
Is it legal to monitor a website you do not own?
Watching publicly available pages at a low request rate is broadly normal, but the rules are not identical everywhere. Check the site’s terms of use and robots.txt, keep your request frequency polite, and stay away from anything behind a login you have no authorisation for. Republishing what you capture can raise separate copyright questions, so get advice if the data will be published or sold.
Conclusion
Pick one page that genuinely matters to you, decide in a single sentence what change you would want to know about, and set up one monitor for it. Read the first real diff it sends before you build anything else, because that single alert tells you more about whether your scope is right than an hour of setup will. Once that works, add a second page, tighten the filters, and only then consider self-hosting or writing your own script.
