How to check when a website was last updated

There is no single button that reveals when a web page was last updated. Some dates are written by the publisher, some generated by the server, some reconstructed by a third party. The skill is knowing which ones to believe.

• Fastest check — run document.lastModified in the browser console.
• Most trustworthy publisher signal — the lastmod value in the site's sitemap.
• Best proof a change happened — compare two Wayback Machine snapshots.
• The only way to know about the next change — monitor the page.

1. Look at the page itself

Start with what the publisher tells you: a byline near the headline, an "Updated on" line, the copyright year in the footer. Then search the page source for dateModified — the structured-data field the site hands to search engines, usually more precise than anything visible.

The caveat: footers lie systematically. "© 2026" is usually one line of template code printing the current year: it tells you the server is running today, nothing about the content above it. "Updated" stamps are editorial too—some sites bump them for a typo fix, some re-stamp pages in bulk to look fresh.

2. The document.lastModified trick

Open the browser console (F12, or Cmd+Option+J on a Mac), type document.lastModified and press Enter. The address-bar version, javascript:alert(document.lastModified), still works, but type the javascript: prefix by hand—browsers strip it on paste.

The caveat: this only works on a static HTML file, where the browser reports the file's modification time. Web apps build the HTML when you request it, so the value is just when you loaded the page. A time matching the current minute does not mean "this page changed"—it means "this method does not work here."

3. The HTTP Last-Modified header

In DevTools, open the Network tab, reload, click the first document request, and read the response headers for last-modified. From a terminal: curl -sI https://example.com | grep -i last-modified. Where it exists, it is a real server-side timestamp.

The caveat: the header is optional and often absent. Servers that build pages on the fly omit it, and a CDN may return its own cached copy's timestamp—when the CDN last fetched the page, not when a human edited it. No header at all is normal, not an error.

4. The site's sitemap and its lastmod dates

Try /sitemap.xml first. If nothing is there, open /robots.txt, which nearly always carries a Sitemap: line pointing at the real location. Large sites publish an index linking to child sitemaps; follow the one covering your section, find your page's entry, and read its lastmod value. It is often the best answer available—a date the publisher declares to search engines, covering pages with no visible date.

The caveat: some build systems stamp every URL with the date of the last deploy, making the whole file useless. Others omit lastmod entirely. Treat it as strong evidence, not proof, and cross-check against a byline. When those agree, stop looking.

5. Google's date operators

Google's before: and after: operators take plain dates and combine with site: — so site:example.com/blog after:2026-06-01 sorts a section by recency without opening pages one at a time. Slugs containing a year and month are another free hint.

The caveat: every date here is Google's estimate, inferred from schema, sitemaps, or its own crawl. And the advice in older tutorials—"click the cached version"—no longer works: Google retired cached page links and the cache: operator in 2024. Where a guide says check the cache, use an archive.

6. Wayback Machine snapshots

Open web.archive.org/web/*/ followed by the URL for a calendar of every capture the Internet Archive holds. Two snapshots beat one: open one from before the period you care about and one from after, and you bracket the change—the page said this on March 3 and that on May 12, so it moved in between. The archive's changes view diffs two captures for you.

The caveat: an archive only proves what it happened to see. A busy news site may be captured hourly; a supplier's terms page once a year or never. The version you need is usually the one between two saves. Our comparison of Wayback Machine alternatives covers the other public archives.

7. RSS and Atom feeds

Where a feed exists it is clean machine-readable data. Try /feed, /rss, or /atom.xml, or search the source for an alternate link with an RSS or Atom type. Every entry carries its own timestamps.

The caveat: feeds announce new items, not edits to old ones, and outside blogs, news, and changelogs most sites publish none. The pages people most want to watch—pricing, terms, stock—have no feed.

Every method above looks backward

All seven reconstruct the past; none tells you when the page changes next. If you run these checks on the same URL twice, the question you are really asking is "has it changed since I last looked?"—by hand, on a schedule you have to remember.

Monitoring inverts that: instead of going to check, you get told. Urlooker loads the page on a schedule, compares the area you selected against the previous check, and sends a before-and-after diff of the exact text added and removed, plus a dated history of the last 12 months of checks. Alerts arrive by email, Zapier, or IFTTT, and a keyword filter narrows it to the words that matter.

One detail matters here: headless Chrome rendering is included on every plan. The pages where document.lastModified and the Last-Modified header give you nothing are the dynamically rendered ones—exactly the pages that need JavaScript rendering to monitor. That hard case costs no extra.

The honest limit is the one archives have in reverse: Urlooker cannot show you what a page looked like before you started watching it. For that, use the Wayback Machine. What it guarantees is that from today forward, you stop asking.