Proof of Publication Date: Page Date, dateModified, lastmod

A publication date can be read from three places, and each place means something different. The date a reader sees on the page, the datePublished and dateModified fields in the page's structured data, and the lastmod value in the sitemap are three separate records, produced by three different systems. They do not have to match. For a sponsored post or a placed link, the delivery proof is strongest when it names which date came from which source and records mismatches as findings instead of treating them as errors. Buyers, publishers and agencies that skip this distinction end up arguing over "when did it go live" with nothing to point to.

The short recommendation: make the check time and the visible page date required fields in a buyer report, and treat datePublished, dateModified and lastmod as optional fields to record, with source, when they exist. None of the three is legal proof of the moment of publication.

Reading the three dates apart

The visible date

This is the date a visitor sees: a byline date, a "Published" label or an "Updated" note. An editor or a template sets it. It is the most natural evidence that a post was published, and also the easiest to change in the content system.

The structured data fields

Google's Article structured data documentation (Opens in a new tab) defines datePublished as the date and time the article was first published and dateModified as the date and time it was most recently modified, both in ISO 8601 format. It recommends providing timezone information so Google does not fall back to Googlebot's timezone. These fields sit in the page source, for example as JSON-LD, and readers never see them.

The sitemap value

Google's sitemap documentation (Opens in a new tab) says lastmod is used only when it is consistently and verifiably accurate, for instance when it matches the page's actual last modification. It should reflect the last significant update: changes to main content, structured data or on-page links count, while a copyright year change does not. The same page says Google ignores priority and changefreq.

Inspecting the visible date

What to look for

Check whether the page shows a date near the title or at the end, whether the label says published or updated, and whether both appear. Record the location and wording. A date that appears only in a sidebar, an archive list or small meta text has less connection to the post itself, and the note should say so.

Why it is not enough alone

A visible date is plain text and can be changed afterwards. That is not an accusation; it is a property of the evidence. When the visible date is recorded together with the exact time of your check, the report shows that on that moment the post was live and carried that label.

When only the update date shows

Some pages display only an update date. The first-publication date may be absent from view. Look at datePublished in the source for it. If neither exists, the publication date is unknown, and a guess does not belong in the report.

datePublished and dateModified in the source

Finding them

Open the publisher URL, view the page source and search for datePublished and dateModified. They may be in a JSON-LD block or in other markup. Copy each value exactly, including format and any timezone suffix.

What the documentation does and does not say

The article documentation asks for ISO 8601 and for timezone information. It does not state that these values must equal the date shown on the page; its microdata example simply places an ISO 8601 value beside human-readable text. So a sentence such as "Google does X when the two differ" has no support in that page. Practical suggestion: still record both side by side, because a gap is a reason to question one of the dates.

When dateModified moves

If a template rewrites dateModified on every page load, or an editor changes it for a typo fix, the field no longer reflects a meaningful content change. Before presenting dateModified as proof of an update, look for an update note or a content difference on the visible page. Seeing a different dateModified on two visits suggests dynamic output; log it without inferring more.

Author fields belong elsewhere

The same documentation also describes the author property, including that the name field should hold only the author's name. That is a separate topic. For publication proof, only the date fields are logged.

How reliable is sitemap lastmod

When it counts

Per the documentation, lastmod is taken into account when it is consistently and verifiably accurate. A value that tracks real significant updates is meaningful; a value that changes on every build is not. Treat it as an update indicator and nothing more.

Looking it up

Open the site's sitemap, which is often referenced in robots.txt or listed in the site's admin area, find the publisher URL and copy its lastmod. Large sites may use an index file that points to several sitemaps, so locate the right child file first. The documentation caps each sitemap at 50 MB uncompressed or 50,000 URLs, so several files on a large site are normal. Limits in Google's documentation can change; check the current page before relying on them.

Not a publication date

lastmod means the last significant update. If a post never changed, it may sit close to the publication moment, but that is a possibility, not a rule. In a buyer report call it "last update value in the sitemap," never "publication date."

Pages missing from the sitemap

Not every post appears in a sitemap, and absence alone does not mean the post is unpublished. Write "not found in the sitemap" and continue with the other sources. Practical suggestion: treat the sitemap check as supporting, not as a gate.

When the dates disagree

A classification table

A decision rule

Practical suggestion: if the report needs a single publication date, choose by this order and name the source.

1. A visible "published" date, labeled "visible page date."
2. Otherwise the datePublished value, labeled "structured data."
3. Otherwise write "date unknown" with the check time. Do not substitute lastmod.
4. If sources conflict, give both values and say they conflict.

Putting dates in the delivery proof

Required versus optional

The decision question is whether date proof should be a mandatory report field. The practical answer: require the check time and the visible date, and keep the other three optional. Not every page carries structured data or a sitemap entry, and a mandatory field that cannot be filled makes reports incomplete for reasons outside the buyer's control.

Record layout

One row per publisher page: URL, check time, visible date and label, datePublished, dateModified, lastmod with its sitemap file, agreement status and notes. Copy dates exactly as they appear; reformatting is where errors creep in.

Example scenario: a craft coffee roaster

Example scenario: A craft coffee roaster pays for a post on a regional food magazine's website. On the check date the page shows a "Published" label with a date. The source holds datePublished on the same day, while dateModified is later because the magazine fixed a typo. The sitemap entry's lastmod matches dateModified. The report lists each value with its source and reads "consistent, later edited." The buyer then confirms in the page source that the link survived the edit. The row makes no claim about indexing or rankings.

After delivery

Dates can change. At the first check log the visible date and datePublished. In later checks add only what changed. When dateModified moves, re-verify the page content and the link, since edits can move or remove a link. Indexing evidence is a different record; the logic in how to check that a backlink page is indexed, with an evidence log and expectations fits alongside this one.

Notes for publishers and site owners

If you publish posts yourself, deriving the visible date, datePublished and dateModified from one database field reduces mismatches. Tying sitemap lastmod to real content changes follows the documented behavior; bumping it on every request or small template tweak weakens the value. For re-crawl steps after an update see updated page recrawl, URL inspection and sitemaps, and for the sitemap file's own problems see XML sitemap audit and error fixes.

Publisher checklist

• Do the visible date and structured data come from the same source?
• Are datePublished and dateModified in ISO 8601 with a timezone?
• Does dateModified change only on real content changes?
• Does lastmod track the last significant update?
• Is each sitemap file within the size and URL limits?
• Does a copyright-year change trigger lastmod? It should not.

Common mistakes in date proof

Trusting one date

Relying on a single date without naming its source, or without recording the check time, leaves the reader unable to interpret the value.

Calling lastmod a publication date

lastmod stands for the last significant update. A post edited later has a lastmod after its publication date. Mixing the two reports the wrong publication date.

Ignoring timezones

An ISO 8601 value with a timezone suffix can fall on a different calendar day than the visible date for posts published near midnight. That can be a timezone effect, not a contradiction. Copy the raw value with its suffix.

Proving dates by screenshot alone

A screenshot shows the visible date but not the source values. Capture it with the check time and the address bar visible, and save the source values as text.

One record, different readers

The same date record answers different questions depending on who reads it. Deciding the role first also decides which fields are essential and which are decoration.

Buyers: when to approve payment

A buyer needs date proof to answer two questions: was the post live within the agreed window, and is it still live at the time of checking? The visible page date and, where present, datePublished serve the first. The check time serves the second. If the publication date cannot be verified, the buyer writes "date unknown" and asks the seller for dated evidence. That request resolves a disagreement calmly. The documentation prescribes no format for such evidence; a record from the content management system or a dated capture of the live URL are both reasonable.

Publishers: who should generate the dates

On the publisher side, templates generate the date fields. If the visible date and the machine dates come from one source, mismatch questions rarely arise. When a post is edited later, adding a visible update note beside dateModified shows both readers and reviewers what happened. A sitemap generator that updates lastmod only for meaningful changes keeps its value as evidence.

Agencies: one vocabulary for every client

An agency reports placements from many publishers, each generating dates its own way. Fixed field names keep reports comparable: visible date, datePublished, dateModified, lastmod and check time. Write raw values exactly as found and leave interpretation to a notes column. A client then sees how date behavior varies between publishers through the labels alone.

A step-by-step check on one publisher page

The sequence below collects complete date proof for a single page. Each step fills one cell of the record row.

1. Open the publisher URL and note the HTTP status. If the page does not load, date proof cannot be gathered, and that is a separate event.
2. Look for a visible date and label. Record the location and wording, or write "no visible date."
3. Open the page source and search for datePublished and dateModified. Copy each value raw.
4. Note whether the values carry a timezone suffix.
5. Find the sitemap, search for the URL and copy lastmod. If it is absent, write "not found in the sitemap."
6. Compare the three sources and choose the agreement label.
7. Write the check time and set the next check date.

How long the check takes

The documentation says nothing about how many minutes this takes; it depends on the page and on the size of the sitemap. If you run out of time, writing "not checked" in a cell is a more honest record than filling it with a guess.

Two layers in the row

A report row has two layers: raw values and a label. Raw values are copied unchanged. The label is a classification. If someone challenges the label, they can return to the raw values, and the raw layer stays valid even if your classification rules change later.

What happens when a post is updated

A published post can be edited afterwards: a correction, a new section, a moved link. Four fields can be affected.

• Visible date: some templates keep the date and add a separate update label; others overwrite the date.
• dateModified: expected to move with the edit, depending on the template.
• datePublished: expected to remain the first publication moment. If it changes, record it.
• lastmod: according to the documentation, it should change only for significant updates.

If you logged datePublished at the first check and it differs at the second, the publisher may have rewritten the date. Without knowing why, draw no conclusion; note the change and ask the publisher.

Re-checking the link after an update

An edit can alter a link's position, anchor or rel value. When dateModified moves, reopen the page source and compare the link details to the order again. The date record only says that a change took place. Whether the change touched the link is a question for the page source.

A fuller worked example of mismatched dates

Example scenario: A bicycle repair shop buys a placement on a neighborhood news site. At the first check the page shows a visible date, the source shows datePublished on the same day and dateModified identical to it, and the sitemap lastmod agrees. Everything is consistent. Three weeks later the shop checks again. The visible date is unchanged, datePublished is unchanged, dateModified is now a later day, and lastmod has moved with it. The log row reads "modified after first check." The shop opens the page source and confirms the link is intact, though the paragraph around it was reworded. It writes both facts: the date moved, and the link survived with its anchor and rel unchanged. A message to the publisher asks what was edited, with no accusation attached.

Now alter one fact: at the second check dateModified is later, but the sitemap lastmod still shows the original day. The row reads "sitemap stale or not refreshed." The shop gives the page source more weight and notes the sitemap value as unreliable for that page. It does not infer that the page was not actually changed, because the documentation says lastmod is used when accurate and says nothing about what a stale value implies.

Frequently Asked Questions

Which source should I trust for a publication date?

No single source is enough. The visible date is what readers see, datePublished and dateModified are structured data, and lastmod is the sitemap value for the last significant update. Report each date with its source.

What if datePublished and the visible date differ?

Record both raw values and note the conflict. Google's Article documentation does not say the two must be equal, but a gap is a reason to question which date is reliable.

Does sitemap lastmod show the publication date?

No. According to the documentation, lastmod is the date of the last significant update and is used only when it is consistently and verifiably accurate. Do not report it as the publication date.

Should a copyright year update change lastmod?

No. The sitemap documentation says a copyright date update is not a significant update. Changes to main content, structured data or on-page links are.

Why does the timezone matter?

The Article documentation recommends providing timezone information for datePublished and dateModified. Without it a value can be ambiguous, and posts published near midnight may land on a different day.

Should date proof be mandatory in a buyer report?

Practical suggestion: require the check time and the visible page date, and keep datePublished, dateModified and lastmod optional. Not every page has all three, so noting what could not be found is enough.

Conclusion

Three dates answer three questions. The visible date tells readers when the post claims to have been published, datePublished and dateModified tell machines the first publication and latest modification moments, and sitemap lastmod stands for the last significant update. In a delivery report, write each date with its source, raw value and check time, and handle disagreements as findings to classify. Making the check time and the visible date mandatory, and the rest optional, exposes missing information without making the report depend on data a page may not have.

If you want placements whose publication details are recorded clearly, take a look at our backlink packages.