Short answer: decide which date you actually need before you start looking. Each method below answers a different question, and the mistakes almost always come from using the answer to one question as if it answered another.
Start with what you are really asking: published, updated or first seen?
The question “when was this published?” usually hides three separate questions.
- Published: when the publisher says the page first went live.
- Updated: when the publisher says it last changed.
- First seen: the earliest point at which something outside the publisher recorded the page. That shows the page existed by then and nothing more.
On a single page these three dates can sit far apart. If you take the first date you come across, you can easily end up citing an old article as current, or a heavily rewritten page as if it were the original. Work out which of the three you need, then pick the method that can actually show it.
Method 1: read the page itself (byline, footer, URL, comments)
Start with the cheapest check, which is simply to look. A byline often has a date next to the author’s name. Some sites put it at the end of the article instead, near the footer, where it is easy to miss. Note the label as well. A date marked “Last updated” answers a different question from one marked “Published”.
The URL can help too. Some sites put the year or month in the address. That is a reasonable hint, but sites restructure their URLs, so it is not a record.
Comments give you a lower limit. If the oldest comment has a date, the page existed by then. That is a floor, and it is not a publication date.
This method is quick and free, but it only shows what the publisher chose to display. If you find nothing, move on, because the page may carry dates that are not on screen.
Method 2: View Source and the date fields publishers hide there
Right-click the page, choose View Source, then search the text for “datePublished”, “dateModified” and “published_time”.
These are the fields you will usually find:
- datePublished in schema.org markup, defined as the date of first publication.
- dateModified, defined as the date the work was most recently modified.
- article:published_time and article:modified_time from the Open Graph protocol, which social platforms read when a link is shared.
The catch is that the publisher supplies every one of these. They are not independent records. A site might set them once and never revisit them, copy them from a template, or change them when it republishes the page.
Google’s guidance on byline dates gives you a useful test. It tells site owners to show a visible date and to make it match the dates in their structured data. When the date on screen and the date in the source disagree, that is worth noticing, and the worked example below shows how to read it.
You can also check the HTTP Last-Modified header in your browser’s developer tools, under the Network tab. MDN defines it as the date when the origin server believes the file last changed. That reflects the server’s view and not an editor’s note, and MDN describes it as a less accurate signal than other validators. Of the four, it is the weakest clue.
Method 3: Search tools and the Wayback Machine for first-seen evidence
When the page cannot help, look for evidence from outside it. Enter the URL in the Wayback Machine at archive.org and browse its history. The calendar marks each capture, and the Internet Archive suggests using the blue ones, which are successful page loads. Go back to the earliest year that has captures and open the first one.
The earliest capture is first-seen evidence, which means the page existed by that date. The real publication date may be earlier. The Internet Archive says plainly that it cannot guarantee any site has been archived, and that its records for a given site are not always complete. If the earliest capture shows different text from today’s page, you have also learned that the page has changed.
Do not use search-result dates to settle the question. Google describes the date it shows under a result as the date it estimates the page was updated or published, built from several signals. It is an estimate, and it may be a publish date or an update date.
Method 4: Browser extensions and date-finder sites, and what they just read for you
Date-finder extensions are convenient. Most of them collect the same clues you can find yourself. Timestamped, a Chrome extension, is one example. Its store listing says it reads metadata, structured data, time tags, Open Graph tags, URL patterns and Wayback Machine captures, and that its result is a likely date rather than a guaranteed one.
That is an honest description of what this kind of tool can do. If the publisher put a wrong datePublished in the markup, a tool that reads the markup will report it. Use these tools to save time, then ask which signal the date came from. A tool that names its source is far more useful than one that only gives you a date. Before you install one, read its own store or site page to see what it actually checks.
Worked example: three dates on one page and which to believe
This example is hypothetical. The page and its dates are made up to show the pattern. Picture an advice article on an invented site.
- The visible byline gives one date.
- The page source has a datePublished earlier than the byline, and a dateModified later than both.
- The earliest Wayback Machine capture of the URL falls between the source date and the byline date.
None of these is “the” date on its own. The byline is what the publisher wants readers to see. The datePublished field is what the publisher told search engines, and it may have been set once and never changed. The archive capture is the only date the publisher did not supply, but it only proves the page existed by then.
Read them together, though, and they tell a story. Because the archive capture comes before the byline, the visible date cannot be the first publication. The page was most likely republished under a new date, and the source field may still hold the original. When all three roughly agree, you can be fairly confident. Disagreement does not prove anyone was dishonest. It tells you to look harder.
Why the copyright year and ‘last updated’ mislead
The copyright year in the footer is the classic trap. It usually belongs to the whole site, is often updated automatically, and says nothing about when this particular page appeared.
A “last updated” stamp is subtler. It tells you that something changed, but not what changed or how much. Fixing a typo can refresh the stamp and make an old page look current, while a major rewrite can leave the stamp untouched. Either way, it is the publisher’s claim.
Search-result dates are the third trap. They sit right under the link and look official, which is why people trust them, but they are the search engine’s estimate.
When a date really matters (citing, fact-checking, spotting recycled content)
Most of the time a rough date is enough. Three jobs need more care.
- Citing: record the date the publisher gives and the date you accessed the page, so a reader can follow your trail.
- Fact-checking: the date tells you whether a claim is new or an old story circulating again.
- Spotting recycled content: an archive capture that comes before the visible date is often the giveaway.
Checking a date is usually one step in checking a source. If you are about to open an unfamiliar link, a website that can check if a link is safe is the place to start. If you also wonder whether the text was machine-written, see a tool that detects AI writing, and for pictures, a website that can detect AI images. To see how this site dates and checks its own pages, read how we check.
A short decision rule
- Read the page. If there is a visible date, it is clearly labelled, and a rough answer is enough, stop there.
- If it matters more, open View Source and check whether the markup agrees with the date on screen.
- If it still matters, find the earliest Wayback Machine capture and treat it as a floor.
- Use extensions to speed up these steps, never to replace them.
If the dates disagree, report the disagreement. That is often the most honest answer you can give.
Sources
- schema.org: datePublished
- schema.org: dateModified
- The Open Graph protocol
- Google Search Central: Add a byline date to Google Search results
- MDN: Last-Modified header
- Internet Archive help: Using the Wayback Machine
- Chrome Web Store: Timestamped
Questions people ask
How do I find the published date of a website if none is shown?
Open View Source and search for datePublished or article:published_time. Then look up the URL in the Wayback Machine and find its earliest capture. Neither one proves the publication date, but together they give you a sensible range.
Is the copyright date on a website the same as the publication date?
No. The year in the footer usually belongs to the site or its template, not to the page you are reading, so it cannot tell you when a particular article appeared.
Can I see when a page was first published, not just last updated?
Not with certainty. The publisher's own fields may say when it was first published, but the publisher sets those. The Wayback Machine can show that the page existed by a certain date, and the real date may be earlier.
How accurate are publish date finder tools?
They are only as accurate as the signals they read: metadata, structured data, time tags, URL patterns and sometimes archive captures. If the publisher's date is wrong, the tool repeats it. Some, such as Timestamped, say outright that their result is a likely date and not a guaranteed one.
How do I find out when something was posted online?
Start with the visible date, compare it with the dates in the page source, then check the earliest archive capture. If they disagree, use the earliest independent evidence as a floor and say so when you cite it.