Knowing how to check when a webpage was last updated takes under a minute, though the shortcut you may remember no longer works. Google retired the cache: operator in 2024 and now points searchers to the Internet Archive Wayback Machine instead, a record the publisher cannot edit. The methods that remain are quick: view the page source for an article: modified_time tag, read the HTTP Last-Modified header, or pull a page's capture history from the Wayback Machine. Reading the date is the easy part; reading whether you can trust it is the step every method skips, because these checks routinely return different dates, and the one a publisher stamps on its own page has the most reason to be wrong. The fastest answer and the dependable answer are rarely the same lookup.
Which Last Updated Date to Trust
To check when a webpage was last updated, rank the available dates by trust: an outside record like the Wayback Machine capture history is the most reliable, the HTTP Last-Modified header comes next, and the publisher's own visible date and sitemap entry are the least reliable, because the publisher sets those at will. The dates a publisher cannot touch sit at the top. The date printed on the page sits near the bottom.
From most trustworthy to least:
- Wayback Machine capture history. An outside crawler's record of when the page actually changed, which the publisher cannot edit.
- The HTTP
Last-Modifiedheader. The server's own report of when the file changed, dependable when it is present, frequently absent on modern sites. - A carbon-dated estimate. An inference drawn from the page's own signals, useful as a floor, never exact.
- The
article: modified_timeor JSON-LDdateModifiedin the source. The publisher's structured self-report, accurate when maintained, trivially stale when not. - The visible "updated" date on the page. The publisher's most public claim, and the one with the most incentive to look fresh.
- The sitemap
lastmodentry. A self-reported date that many systems regenerate automatically, so it is often the least connected to any real edit.
The split underneath that ranking is the entire point. The top of the list is evidence the web observed on its own; the bottom is what the publisher chose to tell you. If I had to keep one method and discard the rest, I would keep the Wayback capture history, because it is the only one no publisher can rewrite. Hold that line in mind, because it decides which date is worth believing every time two of them disagree.
Declared Dates the Publisher Controls
The visible date, the meta tag, and the sitemap entry have one thing in common: the publisher wrote every one of them. These are declared dates. They are fast to read and easy to fake, in that order, and on a marketing site they are the ones most likely to mislead you about when a website last changed.
The Visible On-Page Date
The first check is the date the page shows you, usually under the headline, beside the author, or in the footer. Press Ctrl + F or Command + F, search for "updated" or the current year, and you will often jump straight to it. Documentation, government pages, and edited news carry these honestly.
The trap sits everywhere else. A footer that auto-prints the current year reads as fresh on a page nobody has touched in three years. A visible date is frequently the original publish date, not the last edit, and a site chasing rankings will bump it on a one-word cosmetic change to look current.
The dateModified Meta Tag in the Page Source
Right-click, choose View Page Source, and search the head for article: modified_time, og: updated_time, or a JSON-LD dateModified field. These structured values are what search engines and social platforms read, so they tend to be maintained more carefully than the visible date. They are still the publisher's to write. Reading those values by hand is the same extraction a scanner can run automatically across many URLs at once.
The Sitemap lastmod Date
Add /sitemap.xml to the domain and find the page's <lastmod> tag. In theory it marks the last edit. By default a content system derives it from the build or the database row, not from a human decision.
Push a theme change to a 400-page site and the sitemap re-stamps all 400 URLs to the moment of that deploy, while the words on every page sit where they were in 2023. The date reads fresh on a page where nothing was written. That is a declared date in its purest form, a value the publisher's system sets with nothing forcing it to match a real change.
Observed Dates the Publisher Cannot Set
The methods worth trusting are the ones the publisher does not author. An outside record watched the page and wrote down what it saw, and that record does not move when a CMS re-saves a file. These are observed dates, and when one contradicts a confident on-page timestamp, the observed date is usually the one telling the truth.
Wayback Machine Capture History
Paste the URL into the Wayback Machine and you get a calendar of snapshots. The first capture approximates when the page went public; the most recent approximates the last real change. Open two side by side and you can see precisely what moved between them.
Not every capture marks a change, so scan for the snapshot where the visible content shifts, not the next routine re-crawl, and treat that as the real last-edit date. The publisher does not control the crawl schedule and cannot edit a past capture, which is why this sits at the top of the ranking.
The one limit is coverage. Low-traffic pages get crawled rarely, so the latest snapshot may predate a recent edit.
The Last-Modified HTTP Header
Open your browser DevTools, switch to the Network tab, reload, and read the Last-Modified value on the document request, or run curl -I against the URL from a terminal. When it is present, it is clean evidence. The caveat is that it reports when the origin server believes the resource was last modified, and it is less accurate than an ETag. A dynamically assembled page has no single static file to stamp, so a CMS or CDN often omits the header entirely or returns the moment the cache was written.
That same gap sinks the popular console trick. The document. lastModified property reads from that header, and the value it returns cannot easily be used for comparing modification dates because, when the header is absent, the browser falls back to the moment you loaded the tab. It always returns a date, which is exactly what makes it look authoritative when it is worthless.
If the header check also tells you the source you cited has moved or returns a 404, that is its own problem, and the fix is knowing what to do when a cited source goes dead.
Carbon Dating From Page Signals
When no date is exposed anywhere, you can estimate one from the page's own signals: the oldest dated comment, referenced events, asset filenames, the first Wayback capture. This gives you a floor, the earliest the page could plausibly have existed. It is an estimate, never a fact, and anyone who sells it as precise has not run it against a CDN-cached page.
Laid side by side, the split is easy to scan:
Why Google Cache No Longer Shows the Date
For years the quickest way to check when a website last changed was Google's cache. That move is gone. The cache: operator does not return a date anymore. It does not return a cached page.
Google removed the cache: operator, announced by its Search Liaison in March 2024, and in September 2024 it began adding Internet Archive links to the "About this result" panel instead. The replacement Google itself points you to is the same Wayback Machine you can open directly. If a checklist still tells you to read the date off a cached page, it was written before the feature died, which is worth remembering the next time a "seven methods" post lists it as live.
Why Last Updated Dates Disagree
Run three methods on the same website and you may get three dates. The first time I lined these up on a single page and watched them disagree, I stopped trusting any one of them on its own. The instinct is to assume two are broken, but all three are working correctly. They disagree because each one measures a different event.
The article: modified_time records the last save in the CMS. The sitemap records the last build. The Last-Modified header records a file write. The Wayback capture records the next time a crawler happened to visit. Four methods, four different events, and not one of them records the moment the information on the page became true.
This is the mechanical reality underneath content decay: a page has many clocks, they tick on their own schedules, and "last updated" was never a single number to begin with. Once you see the dates as records of different events, the disagreement stops being a bug and starts being the answer.
When the Date Moves but the Data Does Not
You can check when a webpage was last updated and still miss the thing that mattered. You view-source a page stamped "Updated 2026," find a clean article: modified_time, and relax. Then you read paragraph three, and the statistic still cites a 2023 figure. The date moved. The data did not.
A timestamp sits on the container. Trusting it is container bias: you read the freshness of the wrapper and assume it covers the contents. It tells you the file changed, and says nothing about whether the number in that third paragraph is still true, because the figure and the page that holds it age on separate clocks. A page can re-stamp its date on every deploy while the words sit perfectly still, a kind of fake freshness that no date check will ever catch. This is the gap between knowing a page was touched and knowing it is still right.
It is not a rare accident either. When we scanned 6,751 data claims across 938 SaaS posts, almost a quarter of the posts that cite data were carrying numbers two or more years old, 177 of 751, and a recent modified date sat on top of plenty of them.
That is the figure I keep coming back to whenever a recent timestamp tempts me to take a page at face value.
Knowing the file changed is one question. Knowing whether the numbers are still accurate is stale data detection, a different check entirely.
You have seen which methods to trust. Which one do you actually reach for first?
The four answers fall along one line. Options that read the date the page reports about itself are declared self-reports; the capture history is the only one that asks an outside witness what actually moved. Three of these methods ask the publisher. One asks a record the publisher cannot set. That gap is the entire reason the dates disagree.
The method you reach for first usually tracks how much you already trust the page in front of you. The checks that take one glance tend to be the ones the publisher controls, so the habit that feels efficient is also the one most likely to hand you a date nothing outside the page can confirm.
Checking one page by hand is a snapshot. Across a whole library that manual date-extraction stops scaling, which is where the Content Health Scanner takes over. Paste a URL and it reads the same published and modified timestamps you would pull from the source, then carries the check further: it extracts every statistical claim on the page and checks the freshness of each cited source. A recent modified date resting on top of a three-year-old figure surfaces as exactly that. You get the declared date and the currency of the numbers in one view, the comparison every method here otherwise leaves you to run on your own.
A single scan tells you where a page stands today. To watch a specific figure going forward rather than re-checking the page yourself, the move is to monitor the claim, not the page, and the automated version on a schedule runs that freshness check on a set cadence. Dedicated website change monitoring tools cover the broader category if recurring alerts are all you need.
The date you trusted and the currency you needed were never the same measurement. One is easy to read; the other decides whether the page is still telling the truth.
Frequently Asked Questions
How Do You Find Out When a Web Page Was Last Updated
Start with the fastest declared method, the visible date or the article: modified_time in the source, then confirm it against an observed record. The Wayback Machine capture history is the most reliable single answer, because the publisher cannot edit it.
Can the Last Updated Date on a Website Be Faked
Yes. Every declared date can be faked, because the publisher writes it, and a CMS re-save or a freshness plugin will bump it with no change to the content. The way around it is to stop asking the publisher and read a record it does not control, like the Wayback Machine or the Last-Modified header.
How Do You Find a Modified Date When None Is Shown
View the page source and search for dateModified or article: modified_time, read the Last-Modified header in your browser DevTools Network tab, or pull the page's capture history from the Wayback Machine. If none of those resolve, a carbon-dated estimate from the page's own signals gives you a floor.
Does Google Still Show a Cached Page With the Date
No. Google removed the cache: operator in 2024 and no longer serves cached pages or their dates. It now links to the Internet Archive from the "About this result" panel, so use the Wayback Machine for the same purpose.
How Do You Tell the Publish Date From the Updated Date
Compare the first and the latest Wayback Machine captures: the first approximates when the page was published, the latest approximates the most recent real change. A visible on-page date is often the original publish date, so do not assume it reflects the last edit.