Hugo lastmod: Publication and Update Dates

Hugo lastmod is useful when it describes a real content update. Keep publication and modification dates separate, choose their sources explicitly, and render the same resolved values in the article and its metadata.

For editorial control, start with this site configuration:

# hugo.yaml or config.yaml
enableGitInfo: false
frontmatter:
  lastmod:
    - lastmod
    - date
    - publishdate

An explicit lastmod wins. Without one, the page falls back to its original date instead of acquiring an update every time the project is rebuilt.

Set Hugo lastmod when the article changes substantially

A published article might contain:

---
title: A Small Static Website
date: 2024-01-15T09:00:00+02:00
lastmod: 2026-10-28T10:00:00+02:00
---

These are example dates. Use the article’s actual publication date and the time of its substantive revision.

A corrected explanation, a working replacement example, or a useful new section can justify a new update date. A spelling fix, topic change, or layout deployment usually does not tell the reader that the article itself has been revised.

The front matter configuration reference documents Hugo’s source order. Check that order rather than assuming an explicitly written date will always override Git information in another configuration.

I prefer manual dates for articles because the editorial distinction matters. A repository timestamp can record a change without knowing why it happened.

Compare the update with the publication date

In an article template, show the original date and conditionally show the update:

<p>Published on <time datetime="{{ .PublishDate.Format "2006-01-02T15:04:05Z07:00" }}">{{ .PublishDate.Format "02/01/2006" }}</time></p>
{{ if .Lastmod.After .PublishDate }}
  <p>Last updated on <time datetime="{{ .Lastmod.Format "2006-01-02T15:04:05Z07:00" }}">{{ .Lastmod.Format "02/01/2006" }}</time></p>
{{ end }}

PublishDate is the publication value Hugo resolves from the configured sources. That matters when a project uses a separate publication field rather than treating .Date as publication in every situation.

Lastmod is the resolved modification value. Comparing the two prevents a fallback publication date from producing a redundant “updated” line.

The full timestamp belongs in datetime; the visible format can stay compact. Use the intended time zone in the stored value so an evening update is not accidentally presented as another calendar day.

Keep future publication separate from pre-publication editing

Editing a scheduled post before it appears is part of preparing the original publication. It does not need a later-looking update label on launch day.

Hugo normally excludes pages with a future publication date. Use --buildFuture when intentionally previewing those pages:

hugo --buildFuture

Do not move the publication date forward after a published article is revised. Preserve its address and original publication identity, then record the actual update separately.

If a project derives URLs from the date, changing that field can do much more than alter the byline.

Use Git history only when its meaning fits the content

For documentation maintained through commits, Git can be an appropriate fallback:

# Alternative configuration: hugo.toml
enableGitInfo = true

[frontmatter]
  lastmod = ["lastmod", ":git", "date", "publishdate"]

This is an alternative to the YAML policy, not another file to copy alongside it. An explicit update remains first, followed by the Git-derived value.

The GitInfo documentation explains the repository dependency. The build environment needs the relevant Git history; a shallow or differently prepared checkout can change the information available to Hugo.

The trade-off is editorial accuracy. A committed formatting or metadata edit can move a Git-derived date even when the explanation did not change. That may suit some documentation, but it is a different promise from “this article was substantially updated.”

Reuse Lastmod in metadata and the sitemap

Use .PublishDate for the publication timestamp and .Lastmod for the modification timestamp. In BlogPosting structured data, those correspond to datePublished and dateModified; article Open Graph metadata has its own publication and modification properties.

Keep the sitemap’s lastmod consistent with the same content update. Google’s sitemap guidance says it uses that field when the value is consistently and verifiably accurate.

A template rebuild should not advance every article’s modification date. Avoid replacing the page value with now simply because the deployment happened today.

For RSS, preserve each existing item’s identity and original publication date. An editorial update can inform a channel’s freshness without pretending that the old article is a newly published item.

Check the final page rather than only the source field

After building, compare the visible date, machine-readable time attribute, structured data, and sitemap entry for the same article. A correct front matter value does not help if another template still reads the wrong field.

Test a page without lastmod as well as a page with one. The first should keep its publication date without an update label; the second should show the later revision consistently.

For a blog, the useful policy is small: original publication stays original, meaningful revisions receive an actual date, and every public representation reads the same resolved values.

← Back to all articles