GUIDE

How to prove when a web page changed

An alert says something moved. Proving it moved, and when, needs evidence on both sides of the moment — plus a way to stop a footer clock reporting a change every hour.

Written 19 August 2026

Monitoring and proving are different jobs

Change monitors — Visualping, Distill, changedetection.io and the rest — are good at noticing. They poll a page, diff it, and email you. If what you need is to know, one of those is the right tool and this page is not selling you anything better.

Proving is a different job. It means showing a third party that the page said one thing on Tuesday and another on Friday, when that party has no reason to take your word for either. An alert saying “this changed” is a claim by your monitoring tool. What settles it is a record of the content on each side of the change, made by someone with no stake in the answer, and timestamped by someone else again.

What the proof actually needs

  1. A record before. The content as served, hashed, with an independent time.
  2. A record after. The same, from the same source.
  3. A bound on when. The change happened between two times, and the narrower that window, the more useful it is. This is what the check interval buys you — nothing else.
  4. A comparison anybody can repeat. Two hashes that differ is a fact a reader can check themselves. A diff rendered in someone's dashboard is a picture of a fact.

Notice that the alert is the least important part. The evidence is the two records; the alert is only how you found out.

The problem nobody warns you about: false changes

Point a naive monitor at a real page and it will report a change constantly. Pages carry a rotating advertisement, a “last updated” stamp, a session token, a view counter, a CSRF field, a build hash. None of that is the thing you care about, and an alert that cries wolf daily gets muted within a week — at which point you have monitoring and no attention, which is worse than neither.

The fix is to compare a narrow thing rather than the whole page. Pin the specific field: a JSON Pointer such as /data/amount for an API, or an exact quoted passage for a document. Then a change means the value changed, and an alert is worth reading.

This also improves the evidence. “The page changed” invites the reply “the advert changed”. “The rate at /data/amount went from 4.20 to 4.35, here are receipts for both” does not.

Doing it yourself

A cron job, curl, a hash, and a stored history is genuinely most of this:

curl -s https://example.com/rates | jq -r '.data.amount' | sha256sum >> history.txt

Add an OpenTimestamps stamp of each day's history file and you have independent time for free — see timestamping a file for free. For internal purposes this is often the whole answer, and I would not talk anybody out of it.

Its ceiling is the familiar one: the record is yours. When the party you are showing it to is the party who changed the page, a history file you maintain is exactly the thing they will dispute.

What a watch does instead

An Elucora watch re-seals a source on a schedule and issues a receipt on every check, changed or not. When a check differs from the one before it, you have two receipts, each verifying on its own against published keys, with independent timestamps and Bitcoin anchors. The change is proved by the pair; the notification is just how you learn about it.

Two design choices worth knowing before you use it. Every check spends a receipt from your monthly allowance whether or not anything changed — because the unchanged capture is the evidence that nothing changed, and it cost the same work. And a selector narrows what counts as a change, so the footer clock problem above does not reach you.

A webhook posts watch.changed the moment a difference is found, carrying both receipt IDs, so the alert and the evidence arrive together.

Where this fits, and where it does not

Fits: terms of service and policy pages, published rates and indices, filings and regulatory notices, API fields a decision depended on, anything where “it always said that” is a claim someone might make later.

Does not fit: pages that build their content in JavaScript, since captures are HTTP and you would be watching an empty shell; anything behind a login; and situations where you need to show what a page looked like rather than what it served, which is a forensic capture with an affidavit.

The comparison guide covers those alternatives properly, including the ones we do not sell.