How to use modified timestamp from file as .Lastmod?


Is it possible to get Hugo to use the modified timestamp from the actual content file as the value of .Lastmod?

From my experiments, Hugo only uses the lastmod value set in the content frontmatter?



Yes, but it uses the date if lastmod is not set.


Thanks for the quick reply. I guess I’ll have to write a script that does modifies my lastmod data.


Just to add the why to this discussion:

In many (most?) cases, using the OS timestamp for the content file as lastmod would be misleading. I just did a quick check on my site, and even files I haven’t touched in many years are marked as changed last August (the date I did a clone of the repo to my computer?)

I have had some ideas about using the Git revisions to get a more real timestamp (for those who use Git), but I haven’t found a performant way to do it, yet.


I see what you mean. I sort of thought that git would preserve timestamps, but I do understand that that is a bad idea if its the content that matters.

A Git hook sounds like better idea then? Get git to update the lastmod of all files in /content that are committed?




Thanks, that might be an alternative if I choose to go with the modified date!


I’m using a Python-Script in my workflow to set a “correct” modtime (of all files, to get uploading by ftp a bit smarter). See

It uses the time of the last file-changing commit as mtime of a file.

I’m using this script in a post-receive hook of a git-bare-repo on my server. Maybe you can modify it to write a frontmatter in your .md files.


Thanks a bunch!


May I offer two suggestions to improve the documentation? They may make lastmod clearer for others:

  • The front matter page doesn’t list lastmod as an optional variable.
  • The variables page doesn’t mention that lastmod defaults to the date value in the front matter.

Like the topic starter, I also assumed based on the variables page that lastmod value uses the OS ‘last modified’ timestamp instead of a front matter variable.


Unfortunately, I failed to understand that updating files based on their last commit would produce new files to commit. So the script (after I modified it) was only good for one initial run.

However, I created another script ( that can either be used together with git attributes (use it as a clean filter which is run when you stage a file) or, run it from a script monitoring file changes (this is what I use).

If anybody is interested, the scripts can be found at


Also see


Nice! … so do I understand the pull correctly:

  1. set EnableGitInfo to true in site config
  2. use .GitInfo.AuthorDate in templates e.g. as fallback for .Lastmod or .Lastchange?

I’ll be sticking with my running solution for the moment, but when this gets merged into the homebrew formula I’ll probably use it. Sounds like a better setup than a file change monitor script!


Yes. And my initial thought was that this would also override whatever is set in Lastmod (which is probably stale and old by now).

So: If EnableGitInfo is true, lastmod will always equal the latest Git revision for that file. In addition you can use the rest of the attributes in the GitInfo object (author etc?)

I have figured a way to make this Git integration really fast, so I will probably cook up a complete solution in a day or two.


Brilliant @bep! Did you bake the solution into the code?



When you revive threads 1 year later, you need to give the questions some context.


Pardon, and I may have misunderstood this

“I have figured a way to make this Git integration really fast, so I will probably cook up a complete solution in a day or two.”

as meaning you were working on another solution for the automatic update of lastmod mentioned in the thread.



I have no idea what I meant in that remark. The GitInfo is the only “auto lastmod mode”.


Good, will implement it in my project as suggested in the thread.

Trevlig kväll