How to Check When a Website Was Last Updated

Check the page in three steps

1. Look for “Updated” or “Last modified” on the page. Check near the title and at the bottom of the article. Ignore the copyright year.
2. Confirm the date in the source. Open View Source and search for dateModified, article:modified_time, or a time element containing the same date.
3. Check the exact page in the sitemap. Find the site’s sitemap through robots.txt, match the page URL, and compare its lastmod date.

If the three dates agree, report: “The publisher says this page was updated on [date].” If they disagree, do not automatically choose the newest date. Work through the methods below.

Method 1: Read the date shown on the page

Where to find it: Near the article title, byline, or footer. Look for a label such as Updated, Last updated, or Last modified.

Example value: July 24, 2024.

What it means: The publisher is saying that the page’s editorial content was revised on that date.

When to trust it: Trust it as the best first answer when the label clearly says updated and the same date appears in the source or sitemap. A Published date describes the original release, while a copyright year usually describes the site as a whole.

Method 2: Confirm the publisher’s metadata

Where to find it: Open View Source and search for these field names:

• dateModified
• article:modified_time
• time datetime="…"

Then open the site’s robots.txt, find a sitemap URL, and search that sitemap for the exact page. The matching entry may contain lastmod.

Example value: July 24, 2024. A raw sitemap may show the same day as 2024-07-24.

What it means: These are machine-readable dates supplied by the publisher. Schema.org defines the dateModified field as the date an item was modified, while the Sitemaps protocol says the lastmod field should describe the page rather than the sitemap file.

When to trust it: Confidence is strongest when the visible Updated date, source metadata, and the exact sitemap entry agree. These values are still publisher claims, not independent proof.

Method 3: Use the HTTP header as a cross-check

Where to find it: In Terminal, request only the response headers:

curl -I https://example.com/page

Look for the line beginning with Last-Modified.

Example value:

Thu, 13 Aug 2026 01:06:04 GMT

In plain English: August 13, 2026 at 1:06:04 a.m. in Greenwich Mean Time (UTC+0).

What it means: The server associates that time with the version of the page it delivered. A generated build or cache refresh can update this value even when the article text stays the same.

When to trust it: Use it as supporting evidence. A deployment, generated build, or cache refresh can change the delivered version without an editor changing the article. If the header conflicts with two matching publisher dates, report both instead of silently replacing the editorial date.

One MDN example, from values to answer

We checked MDN’s Document.lastModified reference on August 13, 2026. The result fits into four lines:

Visible page date
July 24, 2024 — MDN says the article content was last modified then.

Sitemap date
July 24, 2024 — the publisher’s machine-readable page date agrees.

HTTP header
Thu, 13 Aug 2026 01:06:04 GMT
In plain English: August 13, 2026 at 1:06:04 a.m. in Greenwich Mean Time (UTC+0). The delivered server version reports a later time.

Answer
MDN reports that the article was last modified on July 24, 2024. The later HTTP value likely describes a build or delivery event, not a two-years-later editorial rewrite.

Screenshot: MDN shows a visible modification date of Jul. 24, 2024. Captured 2026-08-13 at native 2× density.

The browser console returned the same underlying server value in Lisbon local time. That does not add a second independent signal; it is another presentation of the HTTP date.

Method 4: Use an archive when there is no reliable date

Where to find it: Enter the page URL in the Wayback Machine and compare the last capture with the old content against the first capture with the new content.

Example value: The older wording appears on August 1; the newer wording appears on August 8.

What it means: The page changed sometime between those two captures. A crawl date tells you when the archive saved a version, not when an editor pressed Save.

When to trust it: Use an archive to report a range: “The page changed between August 1 and August 8.” Do not report August 8 as the exact edit date.

If there are no useful captures, state that the update date is unknown and record your own access date. That is more accurate than presenting the current clock as the page’s modification date.

Technical appendix: why browser dates can mislead

The RFC 9110 definition of Last-Modified applies to the server’s selected representation, not specifically to an editor’s revision. MDN’s header reference also explains its role as a cache validator.

Typing document.lastModified in the browser console looks convenient, but it is not an independent source. The HTML Standard requires the browser to format the HTTP modification date when one exists. When it does not know that date, it returns the current time.

That creates a quick test: note the browser value, wait, then reload. If the value advances with the reload, the browser is showing its unknown-date fallback. If it matches the HTTP header, count the pair as one server signal, not two.

For technical or legal research, save the raw HTML, response headers, canonical URL, timezone, retrieval time, and archive URLs. A screenshot alone does not preserve enough context to reproduce the result.

Record the next change instead of reconstructing the last one

Historical dates cannot recover an edit that nobody recorded. If the real goal is to know when one part of a page changes next, select the smallest complete visible region and start with a dated baseline. Keep clocks and counters outside the selection by following the guide to reducing false website-change alerts.

PageDog can run scheduled checks on your Mac and retain before-and-after evidence for recorded changes. It cannot reconstruct earlier versions or know why a publisher changed a page. The guide to what PageDog keeps on your Mac explains that boundary.

Research sources

• Schema.org dateModified — the publisher-supplied modification field.
• Sitemaps protocol and Google Search Central’s lastmod guidance — how sitemap dates should describe significant page changes.
• RFC 9110 Last-Modified and MDN’s header reference — what the server header represents.
• HTML document.lastModified — the browser fallback when a modification date is unknown.
• Internet Archive’s Wayback Machine guide — capture gaps, exclusions, and JavaScript limitations.
• Visualping’s competing seven-method guide — a broader method roundup; Visualping is a monitoring vendor.