Website Change Monitor — Diff & Alert (Bulk)

Watch any set of web pages for changes on a schedule and get a clean per-URL diff. Point it at your URLs, optionally narrow it to a single CSS region, and every run tells you exactly what changed — added lines, removed lines and a change percentage.

What it does

• Monitors many URLs at once — fetches each page and extracts its content.
• CSS-region watching — pass a selector to track just a price, a status banner or a headline instead of the whole page.
• Text or HTML mode — compare visible text (ignores formatting noise) or raw HTML.
• Snapshots between runs — the previous state of each URL is stored, so scheduled runs compare against the last check, not a blank slate.
• Diff + change percentage — line-level added/removed counts and a changePct per URL.
• The first check of a new URL is a baseline (changed: false); every run after that reports real changes.

Use cases

• Get notified when a page changes — schedule the Actor (e.g. hourly) and trigger an n8n, Make or Zapier workflow whenever changed is true.
• Track prices, stock or status pages — narrow to a CSS region and watch a single value.
• Competitor & content monitoring — know when a rival updates pricing, docs or a landing page.
• Compliance / uptime signals — detect when terms, policies or published data quietly change.

Typical flow: schedule it, let it store a snapshot on the first run, then fire a workflow on every run where a page changed.

Running it on a schedule (you do NOT leave it running)

This Actor is not an always-on service — each run wakes up, checks your URLs, saves a fresh snapshot, and exits in seconds. You only pay for the checks it actually does, never for idle time. State is kept between runs, so the next run always compares against the last one. Set it up once:

1. Save your URLs as a Task (Console → the Actor → Create task), so you don't re-enter the input each time.
2. Add a Schedule (Console → Schedules → Create schedule → add your Task) and pick a cadence — every 15 min, hourly, daily, whatever fits. That's it: it now runs itself on that interval and remembers each previous snapshot.
3. Act on changes — route the runs where a row has changed: true to a notification (email/Slack) or another workflow.

From n8n / Make / Zapier instead: use a Schedule / Cron trigger node to run the Actor on your interval, then branch on changed === true to send an alert or kick off the next step. Same idea — the trigger does the timing, the Actor does one quick check per run.

Input

{
  "urls": ["https://example.com", "https://example.org/pricing"],
  "selector": "#price",
  "mode": "text"
}

Field	Type	Description
urls	array	One or more page URLs to monitor.
selector	string	Optional CSS selector — monitor only that region (e.g. #price, .status, main). Blank = whole page.
mode	string	text (visible text) or html (raw HTML).

Output

One dataset row per URL.

{
  "url": "https://example.com",
  "changed": true,
  "changePct": 12.5,
  "addedLines": 3,
  "removedLines": 1,
  "prevHash": "9f2a…",
  "newHash": "c17b…",
  "checkedAt": "2026-08-22T10:00:00.000Z",
  "ok": true
}

Output schema

Field	Type	Description
url	string	The page that was checked.
changed	boolean	Whether the content changed since the last snapshot.
changePct	number	Percentage of lines added or removed.
addedLines	integer	Number of lines added.
removedLines	integer	Number of lines removed.
prevHash	string	Hash of the previous snapshot (null on the first check).
newHash	string	Hash of the current content.
checkedAt	string	ISO timestamp of the check.
ok	boolean	false if the URL could not be fetched (with an error message).

FAQ

Can I automate it with n8n / Make / Zapier? Yes — connect it through integrations on the Apify platform and the Apify API. Schedule the Actor to run on an interval and trigger your workflow when a row has changed: true.

Does it remember previous runs? Yes. It stores a snapshot of each URL between runs, so a scheduled run always compares against the last check. The first check of a new URL is a baseline.

Why did the first run report no change? The first check of a URL establishes the baseline snapshot, so changed is false. Changes are reported from the second run onward.

What if a URL is down? That URL gets ok: false with an error and the run still finishes — one bad URL never fails the whole run.

Notes

Original clean-room implementation.