Look for a date on the page, then in its code, then in the server's Last-Modified header, the sitemap and the Wayback Machine. Most can be wrong, so check two.
To check when a website was last updated, start with the page itself: many show a "Last updated" line near the top or bottom. If there is none, look in the page's code for a dateModified value, then ask the server for its Last-Modified header, then check the site's sitemap, and finally open the page in the Wayback Machine to compare old copies. None of these is reliable on its own. A page built fresh on every visit often reports today's date whatever changed, so use two methods and trust the one that agrees with what you can see.
Look before you dig. News sites, government pages, help centres and blogs usually print a date, often labelled Published, Updated or Last updated. Google's guidance on byline dates asks sites to show one prominently with a label like that, so a lot of sites do. GOV.UK's VAT Notice 700, read on 19 September 2026, says "Last updated 25 June 2026" just below the title.
Two things catch people out. A copyright year in the footer is not an update date, since many sites roll it over automatically every January. And a date on a shop or listing page may be the date of an event, a sale or a product launch rather than the page itself. Google's own guidance tells sites not to use "the date of the action described on the page", but not every site follows it.
Press Ctrl+U in Chrome, Edge or Firefox to view the source, then Ctrl+F for dateModified. Sites that use structured data put a dateModified value in a block of JSON near the top, and that is the date Google reads alongside datePublished. Also search for modified_time and updated, which catch the article:modified_time tag many blogs use and similar tags on other platforms.
Sometimes the code holds more than one date, and they disagree. GOV.UK's VAT rates page, read on 19 September 2026, has a dateModified of 12 December 2014 in its structured data and a separate updated-at tag of 9 September 2026 in its head. Neither is wrong. They measure different things, and the page does not say which one you want. If the question is "did the rates change?", the visible content and the older date are the better guide. If it is "has anyone touched this page?", the newer one is.
Sometimes. MDN's reference defines Last-Modified as the date "the origin server believes the resource was last modified". So it is only as honest as the server. A static file, such as a PDF, an image or a plain HTML page, usually gets an honest date from the file itself. A page assembled from a database on every visit often gets none at all, or the time it was assembled. MDN also says the header is "less accurate than an ETag", which is a fingerprint of the content rather than a date.
To see it, open DevTools (F12), go to the Network tab, reload, click the first request and look under Response Headers. On a Mac or Linux terminal, or in PowerShell with curl.exe, run curl -I followed by the address. We tried it on a handful of pages on 19 September 2026.
| Page | Last-Modified header | What it tells you |
|---|---|---|
| sitemaps.org protocol page | Thu, 15 Dec 2022 10:54:02 GMT | A static page with an honest file date |
| GOV.UK robots.txt | Fri, 18 Sep 2026 09:50:21 GMT | A small file that changed the day before |
| GOV.UK home page | None (an ETag only) | Built on request, so no date to give |
| BBC News home page | None | No date to read |
The popular trick is to open the browser console (F12, then Console) and type document.lastModified. It reads the same Last-Modified header, and when the server sends none, the HTML standard says: "If the last modification date is not known, the current time is returned instead." So on GOV.UK's home page or BBC News it will tell you the page changed a second ago. The trick only means something when the date it gives is clearly in the past.
Often. Many sites name their sitemap in /robots.txt, and each URL in it can carry a lastmod date. The sitemaps.org protocol says that date should be when "the linked page was last modified, not when the sitemap is generated", but some sites stamp every URL with the build time anyway. If every page in a sitemap shares the same lastmod down to the second, it is the build date and tells you nothing about the page. Our guide to following a website with no RSS feed covers finding and reading a sitemap in more detail.
Use the Internet Archive's Wayback Machine. Type web.archive.org/web/*/ followed by the page address and you get a calendar of every copy it holds. Its Changes tool, at web.archive.org/web/changes/ followed by the address, lets you pick two copies and shows them side by side, "with changes highlighted in Blue and Yellow". That is the only method here that shows what changed rather than just when.
It has gaps. The Wayback Machine's help page says there is "a 3-10 hour lag" between a crawl and a copy appearing, that robots.txt or the owner can keep a site out, and that pages with no links pointing at them may never be found. Save Page Now will capture a page on request, but only that once.
Google's old Cached link used to do part of this job. Google has since retired it, and on 11 September 2024 the Internet Archive announced that Google results now link to the Wayback Machine instead: click the three dots next to a result, then More about this page. Guides that still tell you to use cache: are out of date.
Look for a date on the page
A Last updated or Updated line near the title or at the foot of the page. Ignore the copyright year.
Search the page source for dateModified
Press Ctrl+U, then Ctrl+F. Also try modified_time and updated.
Read the Last-Modified header
DevTools, Network tab, first request, Response Headers. No header, or a time of right now, means the server is not telling.
Check the sitemap
Find it in /robots.txt and look up the page's lastmod. Distrust it if every page shares one date.
Compare copies in the Wayback Machine
web.archive.org/web/changes/ followed by the address shows two copies side by side with the differences highlighted.
Every method above looks backwards. If the real question is "has this changed since I last looked?", which it usually is with a policy, a price list, a shop's terms or a stock page, checking dates by hand every few days is slow and easy to forget. A page monitor does it for you: it reads the page on a schedule and sends an alert when the text changes.
On StockWatch that is the Visual Selector, where you click the part of the page you care about and get a change alert when its text changes. Pick the smallest part that matters, so a rotating banner or a cookie notice does not set it off. If you only care about one word or phrase appearing, such as "in stock" or "closing date", watching for a specific word is tighter still. And if a monitor says nothing changed when you can see that it did, this guide to JavaScript pages explains why.
Look for a Last updated date on the page, then search the page source for dateModified, then read the Last-Modified header in DevTools, then check the sitemap's lastmod. The Wayback Machine shows what the page looked like on past dates. Use at least two, because each can be wrong.
Only when the server sends a Last-Modified header. The HTML standard says that if the date is not known, the current time is returned instead, so a date of right now usually means the server said nothing.
The page is built on request, and the server stamps it with the time it was built. MDN describes the header as the date the server believes the resource was last modified, and a server building a fresh page believes it is new.
No. Google retired its Cached link. Since 11 September 2024, the More about this page panel in Google results links to the Wayback Machine instead.
Use a page monitor. It reads the page on a schedule and alerts you when the part you chose changes. Dates only tell you about the last change, so a monitor is the way to hear about the next one.
Get told the next time a page changes Five monitors free, checked every 60 seconds. Alerts to email, Discord or Telegram.