We ran the test
How to check when a website was last updated (and why you usually can’t)
It is a reasonable question with an unreasonable number of confident answers on the internet. We tested six of them, on six real websites, in one sitting. Most did not work, and the reason they do not work is more useful than the answer would have been.
The short version
- There is no such thing as “when this website was last updated”. There is only “when this page was last updated”, and the two answers can be a month apart on the same site.
- The HTTP Last-Modified header is the nearest thing to a real answer. Only two of the six sites we tested returned one.
- Three returned HTTP 200 with no such header at all. One refused the request entirely with a 405.
- The sitemap may carry a last-modified date, but it is optional — our own sitemap has none.
- The archive lookups could not answer us on either date — and on the re-run one of them returned a page saying it was temporarily offline, which is why we refused to conclude anything from the first reading.
- What does work is boring: the dates a site publishes deliberately.
The test
On 13 September 2026 we asked six websites the same question, with one HTTP request each, and recorded exactly what came back. The sites were GOV.UK, BBC News, legislation.gov.uk, W3.org, Hacker News, and our own. Nothing was scraped and nothing was rendered — we read the response headers, which is what every “check when a website was updated” guide is really describing.
| Site | Status | Last-Modified header |
|---|---|---|
| GOV.UK | 200 | absent |
| BBC News | 200 | absent |
| W3.org | 200 | absent |
| Hacker News | 405 | request refused |
| legislation.gov.uk | 200 | Fri, 11 Sep 2026 22:59:59 GMT |
| lolasquared.com | 200 | Thu, 13 Aug 2026 07:50:04 GMT |
Two out of six. Three of the largest, best-resourced sites on the British internet answered the request perfectly happily and simply did not include the field. That is not a fault: the header is optional, and for a page assembled fresh on every request there is often no meaningful single answer to give.
The finding that dissolves the question
Look at our own entry in that table: 13 August 2026. We publish something every single day. By that header, our website had not been touched in a month.
So we asked three of our own pages the same question, in the same minute:
| Page | Last-Modified |
|---|---|
| Homepage | Thu, 13 Aug 2026 07:50:04 GMT |
| /blog | Sun, 13 Sep 2026 04:54:45 GMT |
| A post published that morning | Sun, 13 Sep 2026 04:52:35 GMT |
A month apart, on one website, at one moment, and every figure correct. Our homepage genuinely had not changed since August. Our blog had changed a couple of hours earlier. Both are true, and neither is “when the website was last updated”, because that is not a thing a website has.
This is the part worth carrying away, because it is what makes every confident answer to this question slightly wrong. A website is not a document. It is a few hundred documents with a shared header. Asking when it was last updated is like asking when a filing cabinet was last written in — the honest reply is “which drawer?”
The other three methods
The sitemap. A sitemap may list a last-modified date for every address. It is an optional field, and it is optional in practice as well as in theory: our own sitemap.xml contains no last-modified dates at all — just a list of addresses. Where the field is present it is frequently generated by the publishing system and reflects a rebuild rather than anyone editing anything.
The cached copy. The old advice is to look at a search engine’s cached version and compare. Requesting that from our server returned a redirect to a consent page rather than a cached copy, so we could not retrieve one. We are telling you what happened on our machine on one day, not making a claim about the feature in general.
The web archive. This answers a different question — when a page was archived, which is not when it changed. And on the day we tested, the availability lookup returned an empty result for every address we tried, including BBC News, which is certainly archived. A second endpoint returned a single 2025 snapshot for our own domain and nothing for BBC News. We wrote that up as a lookup having a bad day rather than an empty archive, and declined to draw a conclusion from a single reading. Two days later that caution turned out to be the right call, and we now know why — see the re-run below.
We ran the whole thing again two days later
Every measurement above was taken on 13 September. Before publishing we re-ran all of it on 15 September, because a number taken once is a claim and a number taken twice on dated occasions is a finding.
The header result did not move at all. Same six sites, same two out of six: GOV.UK, BBC News and W3.org still answered with no Last-Modified field, Hacker News still refused the request with a 405, and legislation.gov.uk still supplied a precise timestamp — a fresher one, because it is a live site. Our sitemap still contains no last-modified dates, now across 106 addresses. The cached-copy attempt still ended at a consent page.
Our own three pages made the point better the second time. The homepage still reported 13 August — unchanged, now thirty-three days old. Our blog index had moved to 14 September, because we published something. The article we checked had not moved at all, because nobody touched it.
| Page | 13 September | 15 September |
|---|---|---|
| Homepage | 13 Aug 07:50:04 | 13 Aug 07:50:04 (unmoved) |
| /blog | 13 Sep 04:54:45 | 14 Sep 04:53:59 |
| One article | 13 Sep 04:52:35 | 13 Sep 04:52:35 (unmoved) |
One website. Three pages. On the same morning, one of them says 13 August and another says 14 September — a month and a day apart, every figure correct.
And the archive answered the question we had left open
On the 13th the archive lookups returned nothing and we refused to conclude anything from it. On the 15th we ran them again, and two things happened.
The availability lookup still returned an empty result for every address — our own domain, bbc.co.uk, BBC News, and gov.uk. Four sites, two dates, nothing.
But the second endpoint, asked about our own domain, this time replied with a page titled “Internet Archive: Temporarily Offline”. And asked about BBC News in the same minute, it returned two real snapshots, both from 14 September, both recorded as successful.
So the archive is plainly not empty: it captured BBC News twice the previous day. The service was simply unable to answer us reliably, and on the second attempt it said so in as many words.
We are including this not because the Internet Archive’s uptime is your problem, but because of what nearly happened. On Sunday the honest-looking conclusion was “the archive has no record of these sites”. That would have been wrong, it would have been published, and it would have been wrong in a way no reader could have caught. The only thing that prevented it was declining to draw a conclusion from one reading of a source that was behaving oddly. That is a habit worth having about any number, from any supplier, on any day.
What actually works
All the reliable signals have something in common: somebody published them on purpose.
- Dated posts, news items or case studies. The crudest and best signal. A news page whose most recent item is from 2023 has told you something the headers never will.
- A “last reviewed” line on terms, privacy or policy pages. Businesses that maintain these usually date them.
- Details that rot visibly — opening hours, prices, staff names, the copyright year in the footer. That last one is a surprisingly reliable tell, and we have written before about what a stale copyright year actually signals.
- For a mobile app, the store listing shows an Updated date, publicly, and it is reliable. If you want to know whether somebody is still maintaining their software, that is the single best free check available.
- Ask them. Unfashionable, and it answers the question you actually have.
Why you are probably asking
Almost nobody wants this date for its own sake. They want to know one of three things: is this information still true, is this business still trading, or is anyone still looking after this thing I am about to depend on.
Those are better questions, and they have better answers. For “is it still true”, look for the claim restated somewhere dated. For “are they still trading”, UK companies file publicly and the filing dates are free to look up. For “is anyone maintaining it”, the app store date, the blog, and whether anything on the site contradicts reality will tell you more in two minutes than any header.
There is a general version of this worth holding on to. A timestamp is evidence of a moment, not evidence of care, and it is easy to produce one that means nothing — which is the same problem we ran into when we looked at what a watermark on an image can and cannot prove. A mark that anyone can set to anything is not proof of anything.
What argues the other way
Three honest counterweights.
Six sites is not a survey. It is six sites, chosen because they are large, varied and safe to name. A different six would give different proportions. What it does establish is that the method fails on ordinary, well-run, major websites — which is enough to stop you relying on it.
Where the header exists, it is genuinely useful. Legislation.gov.uk gave us a precise timestamp from the previous evening. On a static site it is often exactly right. The failure is not that the header lies; it is that it is frequently absent, and that when present it describes one file.
And our archive result may simply be a bad day. We have used those endpoints successfully before. One session is not a verdict on a service, and we have written it up as an observation rather than a finding for exactly that reason.
Method, so you can repeat it. All six sites were queried on 13 September 2026 from a single machine, one HTTP HEAD request each, and the response status and Last-Modified header recorded verbatim as shown. The entire measurement was then re-run on 15 September before publishing — same six sites, same sitemap, same cache and archive attempts — and both readings appear above rather than the second replacing the first. The three-page comparison on our own site was run in the same minute on each date. Anyone can reproduce the whole thing with curl in about a minute. Nothing here is a claim about how these services behave in general — it is what they returned to us, on one day, and we have said so wherever it matters.