Our August posts were live, but the sitemap still said June

Short answer: The August posts were public. Sitemap lastmod did not change, because this site writes updated_at into the sitemap, and a future published_at does not touch updated_at when the date arrives.

How the queue was stored

In June 2026 I inserted 16 build logs with status = published and published_at spread Monday and Thursday through 21 August. Until published_at, the post 404s and stays out of the sitemap. After that timestamp it returns 200. There is no publish cron. The pattern is the one in scheduling posts without a cron job.

Every row's updated_at was the June insert.

What the sitemap showed in September

Posts were 200 on the live host. Sitemap lastmod months were still May, June, and July. August's count was zero.

Someone reading only sitemap dates would think nothing shipped in August.

What I changed

I re-saved those 16 posts on 13 September 2026 so updated_at moved, with a short note that the steps still matched the current host. Their sitemap dates became 13 September.

That corrects the timestamp. It does not invent a Monday/Thursday crawl trail. Freshness and cadence are different.

Rule

Field	Meaning here
`published_at`	When the URL became public
`updated_at`	When the sitemap claims the document changed

Batch-inserting a quarter of posts produces one lastmod day unless each row is edited again on its publish date.

FAQ

Was DNS the cause?

No. Public DNS for the apex is the current host. The August gap was updated_at.

Should lastmod be published_at?

For a first publication, published_at matches "this URL appeared". updated_at matches later edits. Pick one and know which story you are telling Search Console.