How to check when a website was last updated

There is no single reliable "last updated" date for a web page. There are seven places a date can come from, and they often disagree.

Here is how to check when a website was last updated in two minutes: search the page source for dateModified, then confirm it against the Wayback Machine, which records what the page actually looked like on a given day. A date the site states is a claim. A Wayback capture is evidence. Use both.

Seven ways to check when a website was last updated

1. The date on the page

Bylines and "Updated 12 September 2026" banners. These are the weakest evidence, because some sites refresh the date without touching the content so the page looks current. Treat it as a claim to check.

2. The dates in the page source

Open the page, press Ctrl+U (Cmd+Option+U on a Mac) and use Ctrl+F to search for:

• dateModified and datePublished, in the structured data block search engines read
• article:modified_time and article:published_time, the Open Graph tags most WordPress sites add
• og:updated_time, used by some older themes

On a typical WordPress post you will find a pair like this:

"datePublished":"2018-09-10T12:31:00+00:00"
"dateModified":"2018-11-30T08:57:20+00:00"

These dates are written by the content system, and many systems bump dateModified on any save: a typo fix, or a plugin update that re-saves every post. A recent dateModified proves someone saved the page, not that anything meaningful changed. Google itself says it looks at several signals because "all factors can be prone to issues", in its guidance on publication dates.

3. The sitemap's lastmod

Add /sitemap.xml to the domain. Each URL has an entry like this:

<url>
  <loc>https://competitor.com/pricing/</loc>
  <lastmod>2026-09-18T09:14:02+00:00</lastmod>
</url>

Google's sitemap documentation says it uses lastmod only "if it's consistently and verifiably accurate", and ignores the priority and changefreq fields entirely.

So read the spread before you trust a single date. If every URL carries the same timestamp, the site stamps the build time on everything and the field tells you nothing. If old posts show old dates and the pricing page shows last month, the field is probably honest. Hand-maintained sitemaps go the other way and show dates years out of date. If the sitemap is not at /sitemap.xml, the guide to finding every page on a site lists where else to look.

4. The Last-Modified header

The server can send a Last-Modified date with the page. To see it in a browser: press F12, open the Network tab, reload, click the first request and read the response headers. In a terminal:

curl -sI https://competitor.com/pricing | grep -i last-modified

Most dynamic sites do not send it at all. Others send the time their cache was last refreshed or the site last deployed, which has nothing to do with the content. The WordPress post quoted above, checked on 4 October 2026, returned a Last-Modified time from that same afternoon while its own source said 2018.

When it is honest it is precise. The page at info.cern.ch/hypertext/WWW/TheProject.html, one of the first web pages, still returns Last-Modified: Thu, 03 Dec 1992 08:37:20 GMT.

One trap: typing document.lastModified into the browser console returns that header if it exists, and the current date and time if it does not. A result of "right now" usually means "unknown".

5. Google search

Google's search operator help documents before: and after: for finding pages "last updated" before or after a date. Combine them with site::

site:competitor.com after:2026-09-01

That lists pages Google believes changed since 1 September. It is Google's estimate, so it is weak for a single page and useful for spotting a cluster of recent changes across a site.

The old advice to check Google's cache no longer works. The cache links and the cache: operator were retired in 2024.

6. The Wayback Machine

Paste the URL into web.archive.org and you get a calendar of captures. Open one capture either side of the date you care about, or use the Changes view at web.archive.org/web/changes/ followed by the URL, pick two captures and press Compare to see added and removed text highlighted.

Captures give you a window, not a date. If the 3 March capture shows the old price and the 17 April capture shows the new one, the change happened somewhere between. That is the honest answer, and it is usually enough.

For a list of every capture where the page's content changed, the CDX index does it in one URL:

https://web.archive.org/cdx/search/cdx?url=competitor.com/pricing&collapse=digest&fl=timestamp,digest

Each row is a capture whose content differed from the one before. Pages with rotating tokens or timestamps in the HTML change on every capture, so expect it to over-report on those. The Wayback Machine guide covers the rest of the CDX options.

7. The RSS feed

Blogs publish a feed, at /feed/ on WordPress and usually linked in the page source as application/rss+xml. Each item has a pubDate. It is reliable for when a post was published and says nothing about later edits.

Which dates lie, and how

Freshness edits. "Updated for 2026" in the title and nothing else different. The Wayback Machine settles it in a minute.

Mass re-saves. A theme or plugin update re-saves every post and every dateModified jumps to the same day. If 300 posts were "updated" on one Tuesday, nobody edited 300 posts.

Build stamps. Static site generators and some sitemap plugins stamp every URL with the build time. So do CDNs with the Last-Modified header.

Capture timing. A Wayback capture date is when the crawler visited, not when the page changed.

The working rule: believe a date when two independent sources agree. A dateModified of 18 September plus Wayback captures showing the change between 12 and 20 September is a date you can put in a report.

Reading a competitor's update pattern

One date answers one question. The pattern across a competitor's site answers better ones.

Which sections they maintain. Sort their sitemap by lastmod. The sections with recent dates are where their effort is going this quarter.

A cluster of changes. Pricing page, homepage and three feature pages all changed in the same week is a relaunch or a repositioning. Compare the old and new versions and read what they changed their mind about.

Pages nobody touches. A comparison page about you that was last modified two years ago almost certainly contains claims that are no longer true, about your price or your features. That is worth knowing before a prospect quotes it to you.

Knowing next time it changes

Checking dates is archaeology. If a page matters, watch it from now on instead.

The free version: save their sitemap monthly and compare it with the last copy, and put a change monitor's free tier on their pricing page. The guide to tracking competitor website changes covers the setup that does not drown you in alerts, and the website change monitoring tools roundup compares the options.

Figo reads each tracked competitor's sitemap and pages every week and reports new and changed pages, blog posts with the publish date the page itself states, and pricing changes, in a Monday briefing. When a page states no date, it says when it first saw the page rather than guessing. Ours, so judge accordingly. It checks weekly, so if you need to know within the hour that a page changed, a dedicated page monitor is the better tool.