How to track changes on a website over time

You already know the page changed. The alert came through, or you spotted it yourself. The harder question lands a week later, when someone asks what the page said before the edit, or whether this is the third price change this month or the first one all year. If the alert is all you kept, you can't answer either.

The fix is to track changes on a website over time, so the pages you care about build up a record you can go back to rather than a notification you dismissed on your phone. Setting the monitor up in the first place is covered in our guide to monitoring a website for changes. This one is about what accumulates once it's running.

What a change history gives you that an alert doesn't

An alert answers one question: did it change? A history answers the three you ask afterwards, which are when, how often, and what it said before.

Those three carry most of the value on any page worth watching for more than a week:

• A price that crept up in four small steps reads very differently from one that jumped once. You only see the pattern with the earlier captures next to each other.
• A clause you're relying on can be quietly reworded. Knowing the exact wording on the date you signed is the whole point of watching a vendor's terms of service at all.
• A stock flip or a policy update is far more useful with a timestamp on it. Knowing it landed Tuesday at 09:40 rather than sometime last week is often what tells you whether it was a scheduled release or a reaction to something.
• A web page you own changes without anyone telling you either. Agency edits, CMS updates and plugin changes all rewrite pages quietly, and a record is what tells you when a paragraph went missing rather than only that it's missing now.

The web will not keep any of this for you. When Harvard's Library Innovation Lab went through every link the New York Times published between the site's 1996 launch and mid-2019, a quarter of the deep links were already rotten, pointing at pages that no longer load. The links that did still resolve had often changed underneath. The researchers gave that second failure its own name, content drift: unannounced retractions, additions and replacements at a URL that looks exactly the same as it did before.

Pages get edited far more often than they get announced, and whatever you kept yourself is what survives that.

What the record looks like

A change history is a timeline of captures, newest first, with one entry for every check that produced something worth keeping.

In Webtingle, that timeline sits on the monitor itself, grouped by day, so the shape of the page's activity is visible before you read a single entry. Quiet weeks are short. A day when something happened three times shows three entries stacked under one date.

Each entry carries a thumbnail of the page as it looked at that moment, the time it was captured, and a label for what the check found:

• Initial capture is the baseline, the first look the monitor took.
• Notified means the change cleared your settings and an alert went out.
• Condition not met means the page moved but not in the way you asked to hear about.
• Check failed means the page didn't load properly, with a plain description of why. A gap in the timeline is worth being able to explain, so failed checks stay on the record instead of quietly disappearing from it.

Where a summary is available, the entry also carries a line describing what changed, so you can scan a month of activity without opening anything. Older entries load on demand, and captures stay available for months rather than days, so a before-and-after is still possible when the question comes up long after the fact.

Reading one change

Open any entry and you get the web page before and after, side by side, with the difference highlighted.

That view settles the question a text log leaves open, which is whether anything meaningful happened. Pages move for boring reasons all the time: a recommendation strip reshuffles, a countdown ticks over. Seeing the two versions next to each other tells you in a second whether the change was the number you were watching or the furniture around it.

Each change also has its own link, so the entry you're looking at is the thing you can paste into an email or a ticket. "The page said this on the 14th" stops being a claim and becomes something the other person can open.

Can't you just use the Wayback Machine?

Sometimes, and it should be the first thing you check, because it's free and it reaches back to 1996.

It's genuinely the citation of record for the web, and for a well-known page it may already hold years of captures you didn't have to set up. Before building anything, look up the URL there.

Where it stops helping is coverage you can't control. The Internet Archive is clear that there is no "crawl my site now" submission process, so the cadence is theirs, not yours. Pages go missing simply because the crawlers didn't know they existed. Anything password protected, blocked by robots.txt or otherwise closed to automated visitors won't be there, and site owners can ask for their pages to be excluded. Modern pages are the hardest case: the Archive notes that JavaScript elements are often hard to archive, and that JavaScript needing to call its own server will fail once archived. That covers a lot of what you'd want dated proof of, including prices, stock states and anything that loads after the page does.

You can also save a page on demand, which is worth doing before an important deadline. It captures the moments you remembered, though, which puts you back to checking by hand.

The DIY route: let git keep the history

If you're comfortable with a scheduled job, git will keep the history for you.

Simon Willison named the pattern git scraping: run a scraper on a schedule, commit the fetched content to a repository only when it differs from last time, and let the commit history become the changelog. He ran it every 20 minutes against California's fire incident data, and the commit log recorded the granular movement, personnel counts falling from 968 to 798, containment ticking from 90% to 92%. The whole setup is a scheduled workflow that fetches and commits.

It's the most capable option on this list if you'll maintain it, and it costs nothing but your time. The trade is that you get text diffs rather than visual ones, you'll be the one debugging it when a site starts refusing your requests or a page renders its content in the browser, and a broken job is silent by nature, so the only sign the history stopped is that it isn't growing.

Five ways to keep a website's history, compared

These five differ less in what they capture than in who controls the cadence and who carries the upkeep.

Method	What you end up with	Who sets the cadence	Cost
Wayback Machine	Captures of pages their crawler happened to visit, sometimes going back decades	The Internet Archive	Free
Saving pages yourself	Exactly the moments you remembered, in whatever format you saved	You, manually	Free, plus the checking
Git scraping	A commit log of every text change, queryable and yours	You	Free within CI limits, plus build and upkeep
Browser extension	A local log on one machine, only while that machine is awake	You, within the tool's limits	Free tiers exist, capped on pages and frequency
Hosted monitor	A dated timeline of visual captures that runs without you	You, within your plan's check budget	Free trials and tiers, capped on pages and frequency

Extensions like Distill are the quickest to try and the easiest to lose, since the record lives in one browser profile and stops when the laptop sleeps. Hosted monitors such as Visualping, changedetection.io and Webtingle run on their own machines, which is the difference between a history with gaps and one without. If you're still choosing between the approaches themselves, we compared them properly in website change alerts: 3 ways to get them.

Making the history worth keeping

A record only earns its keep if you can still read it in three months, and two choices at setup decide that.

The first is what you watch. Pointing a monitor at a whole web page gives you a timeline dominated by whatever moves most, which is usually a promo strip or a carousel. Watching a single element instead, the price, the availability line, one clause, gives you a history of the thing you actually care about, and makes the pattern obvious when you scroll back through it.

The second is pace. A monitor compares each check against the last one it took, so the interval decides how precisely the record is dated. A page that moves in minutes deserves a tight interval; a policy page that changes twice a year doesn't, and spending your monthly checks there takes them from somewhere they'd do more good. Restricting a monitor to the hours and days when changes tend to happen has the same effect. Our post on getting notified when a website changes goes deeper on tuning this without drowning in alerts.

One thing worth knowing if you use conditions to keep your alerts quiet: a condition silences the alert, not the record. Every change the monitor detects still lands in the history, whether or not it was the kind you asked to be told about. You can run a page almost silently and still have a complete account of it when you need one. That combination does real work when you set a price alert at a target price, where weeks of silence are the expected behavior and the history is how you tell a waiting monitor from a broken one.

Put together, a competitor's pricing page looks like this. You watch the plan grid rather than the full page, so the timeline isn't filled with a rotating testimonial. Daily checks are plenty, because pricing pages get deliberated over rather than tweaked. Three months later the history answers questions nobody was asking in week one: the headline price moved once, in April, and the feature list under it moved twice, both times before the price did. That second pattern is the useful one, and no alert would have told you about it.

Start the record before you need it

The catch with change history is that you can't backfill it. A record starts the day you point something at the page, so the useful version is the one you set up before the question came up.

Pick the two or three pages where "what did this say last month?" would be an awkward question to be unable to answer. Watch the part of each page that carries the answer, at a pace that matches how fast it moves, and let the timeline build in the background.

Start free with Webtingle. 14-day trial, no credit card, and your first capture lands within minutes of setting it up.