page dates checker
The dates this page
publishes about itself.
A page can say when it was written and when it last changed, in three different places, and a crawler reads whichever it finds. This reads all three, shows you what is there, and says whether they agree with each other.
It does not judge whether your content is current — nothing can, from outside. A page edited yesterday may carry five-year-old text, and a page untouched for a year may be exactly right. What is checkable is what the page declares, and that is what this reads.
This tool works differently from the generator. The generator never uploads your image — it runs in your browser. The checker cannot: it fetches the public address you type, from our server, and reads that page’s HTML in full, not only its head, and the response headers that came with it — both are read here, turned into findings and dropped: they are never stored, and never sent back. Only the address you enter is sent. The addresses you check are then kept in this browser, so it can tell you what changed since last time; they go nowhere, and you can clear them.
Questions
My page sends a Last-Modified header. Why is it not counted as a date?
Because on most real pages it is the server’s clock rather than the content’s. Nineteen pages were measured before this rule was written, seven carried the header, and five of those seven were not content dates: one moved between two fetches twenty-eight seconds apart, one equalled the second of the request while the page’s own tag said four days earlier, one sat at the moment of an earlier request and stayed there while cached, and one was the site’s deploy time. The header is shown with the response’s own Date and Age beside it, so you can see which case yours is. It becomes a content date the moment something else in the same response says the same day.
The page shows a date to readers, and the report found none. Why?
Because a date drawn on the page is not a date a crawler can read. This reads three machine-readable channels: a meta property, a JSON-LD value, and the response header. A date inside your text — even in a <time> element — is not one of them, and deliberately so: a comment’s timestamp is also a <time>, and picking which one is the page’s own is a guess. Ten of the nineteen pages measured published nothing in any of the three channels, so this is the common case rather than a rare one.
Why does it take two channels agreeing to call something a date?
Because one channel cannot corroborate itself, and the channel most likely to be wrong is the one most pages have. Of the seven real headers measured, exactly one was a content date — and the only reason that was knowable is that the same response carried a JSON-LD dateModified naming the same day. Two channels agreeing is the strongest thing a single reading can show, and even then the report says the page declares this date, not that the page changed then.
I ran it twice and got different dates. Which one is right?
Possibly both, and this is measured rather than theoretical. One of the pages checked answered six requests with two different date pairs — three said one date, three said another six months earlier — with its header and its JSON-LD moving together each time. That is two copies of the page behind a cache, not two channels disagreeing. Every report here describes the one response it read, which is why the address and the time of reading are printed under it.
Does this tell me whether my content is out of date?
No, and nothing can from outside. A page edited yesterday can carry five-year-old information, and a page untouched for a year can be exactly right — the edit timestamp and the accuracy of the text are unrelated. What is checkable is what the page declares: whether a date is there, whether a machine can read it, and whether the channels agree. This tool was nearly called a freshness checker, and the name was dropped for exactly this reason.