Content freshness and date consistency

How to use it

1. 1Enter the address you want to checkType or paste it into the field marked "Address to check", including the https:// at the front. Use an article, a guide or anything else where the date matters to a reader.
2. 2Press Check and wait a few secondsThe request runs from our server rather than from your browser, so your cache, your extensions and your login session cannot affect the answer. That is the point of it: you are seeing what an anonymous visitor sees.
3. 3Compare the visible date with the structured oneThe date a reader sees and the date in the structured data are reported side by side. When they disagree, each audience is being told something different, and neither of them knows.
4. 4Check which dates exist at allPublished and modified are separate fields with separate meanings. A page carrying only a modified date, or reusing one for the other, is reported.
5. 5Do not use this as a reason to touch a dateThere is deliberately no freshness score here, and the tool will never suggest updating a date. Refreshing a date without changing the content is what Google calls deceptive, and a tool nudging publishers toward it would do harm at scale.
6. 6Share or keep the result within 24 hoursThe result has its own link you can send to whoever needs to act on it. It is deleted 24 hours after the check ran, so save anything you need to keep — and re-run the check after a change rather than trusting an old link.

About this tool

A page can carry a date in five different places — the byline readers see, a <time> element, Open Graph article meta, JSON-LD structured data, and the Last-Modified header — and nothing keeps them in step. This tool collects all of them and shows them side by side, which is the view where a disagreement becomes obvious.

The disagreements matter because each audience only sees one side. When the byline says "Updated April 2026" while the structured data still says 2023, readers are told one thing and search engines another, and nobody notices — the template shows one field while the CMS emits a different one, and the drift survives for years.

Understanding the result

The table lists every date the page states, labelled by whether a reader or a machine sees it, with what it was written as and what it reads as. Disagreement between the two groups is the finding this tool exists for.

A date marked "cannot be read" is either not valid ISO-8601 (structured data needs 2026-03-12, not "March 12th") or ambiguous — 12/03/2026 is March in most of the world and December in the United States, so we report it as written rather than guessing.

Dates found in the page text are collected only where a publication or update label precedes them. A year mentioned inside a paragraph is content, not metadata, and reporting it as one would be noise.

Example

https://example.com/blog/guide

reader   Visible text (updated)  15 April 2026   → 2026-04-15
machine  article:published_time  2023-01-10      → 2023-01-10
machine  schema dateModified     2023-01-10      → 2023-01-10
1 warning: the date shown to readers matches none of the machine-readable dates.

Limitations

• There is no freshness score, and nothing here recommends updating a date. Changing a date without changing the content is the practice Google's guidance names as deceptive — this tool reports disagreement, which is a defect whatever your publishing policy is, and leaves what to publish as your editorial decision.
• Read from the raw HTML. Dates injected by JavaScript after load are visible to browsers but not here.
• A page's age is reported as a fact about its declarations, never as a fault. Plenty of pages should carry an old date.
• Requests to private and internal addresses are refused by design.

Questions