Why VALORAE posts carry two dates, and what moves the second one

Every post on the VALORAE blogs carries two dates in its structured data: datePublished and dateModified.

Most readers only ever see one of them.

That is on purpose, and this page explains the rule behind it, what the blog engine does with each date, and one place where the engine gets it wrong.

I read the engine's code on 14 October 2026 to write this. Everything below about what renders where is what the code does, not what I remember it doing.

The complication first.

The blog index for each site is the one page where the two dates do not agree with each other, and it took reading the code line by line to see it. More on that in Step 4.

Step 1: what Google asks for

Google publishes a short page on this, Influence your byline dates in Google Search, which I read on 14 October 2026.

It asks for three things.

A visible date on the page, labelled with words like "Published" or "Updated".

The same dates in structured data, using an Article type such as BlogPosting with datePublished and dateModified.

And consistency: the visible date and the structured date should match, and other dates on the page should be kept to a minimum so the wrong one does not get picked.

It also says something worth holding onto. Google looks at several factors to estimate when a page was published or significantly updated, and it does not guarantee any date gets shown.

So none of what follows makes Google print our date. It makes our date easy to read and hard to misread.

Step 2: what the engine does with each date

Every post on the six blogs starts as a markdown file with a date field. Some also carry an updated field.

From those two fields, the engine writes the date in five places.

The post header shows the author, then the published date inside a time element, then the read time. If updated exists and differs from date, it inserts "Updated" and that date between them.

The Article markup always carries both. datePublished comes from date. dateModified comes from updated, and falls back to date when there is no update, so the field is never missing.

On five of the six blogs, the engine's sitemap gives each post a lastmod, using the updated date when there is one and the published date when there is not. This site is the exception. valoraehq.com builds its own sitemap, and that one takes each post's lastmod from the file's modification time, so a rebuild can move it with no edit behind it. The visible date and the markup are the dates to trust here.

The feed gives each post a pubDate, which is always the published date.

And the "Keep reading" cards at the foot of each post carry a category, a title and a read time. No date. That one I was glad to see, because Google's page asks for other dates on the page to be kept down, and three extra dates under every post would have been three chances to pick the wrong one.

Step 3: what moves the second date

This is the part the code cannot decide. The engine has no idea whether an edit mattered. It only reads a field I typed.

So the rule lives in how the posts are written, and there are two triggers.

A correction. A figure changes, a platform rule we quoted moves, or a claim stops holding. That is the same list set out in how a VALORAE page gets corrected, and I will not repeat it here.

A new FAQ answer that came from a real search query. If people are typing a question into search and the post does not answer it, adding that answer changes what the page says. A reader who saw the old version would not have got that answer. So the date moves.

Both triggers share one test: would someone who read the old version now know something different?

If yes, the date moves.

If no, it stays.

Step 4: what does not move it

A typo is not news.

A clearer sentence, a fixed link with the same destination, a new cover image, a change to the stylesheet across all six blogs: none of those change what the page claims, and none of them touch updated.

This is where a lot of sites go wrong in the other direction. A modified date that moves every time anything is touched stops meaning anything. A reader sees "Updated yesterday", opens the page, finds the same advice as last month, and learns to ignore the label.

And a date taken from the file system or the build clock would do exactly that. Every rebuild would look like an update.

The engine does not do that. dateModified on a post comes only from the hand-typed field, so rebuilding a site leaves every post's dates where they were.

Now the complication from the top.

The blog index and each topic hub get their own dateModified in markup from the newest updated-or-published date among their posts. That is right.

But until 14 October 2026 their sitemap entries took lastmod from the newest published date only, ignoring updates. So when an old post was corrected, the index markup said the index changed and the sitemap said it did not.

It was a small bug. It was also the exact kind of inconsistency Google's page asks sites to avoid. Writing this post is how it was found, and the sitemap now uses the same updated-or-published rule as the markup.

Step 5: where it falls short of the guidance

Two more gaps, in fairness to the reader.

The structured dates carry a time and a timezone, as Google recommends. But the time is the same fixed morning time on every post, a placeholder rather than the minute the post went up. The visible date carries no time at all, which Google's page says is allowed.

So the dates match, and the day is right. The hour in the markup should not be read as precise.

The other gap is the feed. It only ever carries the published date, so a feed reader will not notice when a post is corrected. The page and the sitemap will.

On the Group Ledger, six of the twenty posts written before this one carry an Updated date.

Step 6: how to read the two dates as a reader

If you are citing a VALORAE post, the published date tells you when the claim was first made. The Updated date, if there is one, tells you which version you read.

If a post has no Updated line, it has not changed since the day it went up.

If two VALORAE pages disagree, the later date wins, and the venture's own site wins over any blog post about it. The group is three running ventures, VALORAE Arc, VALORAE Media and VALORAE Cast, and one upcoming line, VALORAE Shop, where nothing has dropped.

You can check any of this yourself. View the page source of a post, find the BlogPosting block, and compare its two dates with the line under the headline. Who the byline points to is covered in one byline across six blogs, and how the sitemap side gets a new page found is in how a new VALORAE page gets found.

The thinking behind treating every post as something to keep true, rather than something finished, is in every post you publish is a promise to keep it true, on the founder's own blog.

The short version

• Put both dates in the markup on every post, and fall back to the published date when nothing has changed.
• Show the Updated line only once the two dates differ.
• Move the modified date for a correction or a new FAQ answer from a real search query.
• Leave it alone for typos, styling and rebuilds.
• Type the date by hand. Never take it from the build clock.
• Keep the visible date and the structured date identical, and keep other dates off the page.

The group's current facts, in one place, are at valoraehq.com.