Source-aware sitemap modification dates

A sitemap modification date should answer a page question.

When did this public document meaningfully change?

Deployment time answers a different question.

When did the application get deployed?

Those dates sometimes match. They often do not.

The build step

Before the production build, the repository runs a last-modified generator.

For every tracked static source file and supported MDX content directory, the generator asks Git for the most recent commit date affecting that file.

The command is effectively:

git log -1 --format=%cI -- <file>

The result is normalized to a calendar date and written into a generated map.

If Git cannot produce a usable date, the system has a controlled fallback.

Why Git is useful here

Git already contains modification history for the files that define the application.

We do not need an editor to remember to update a metadata date because a template changed.

We also do not need every deployment to announce that every public URL is fresh.

The source history already has a more specific signal.

A route can depend on more than one file

A project case study is not defined only by its MDX file.

The shared portfolio route also affects how that case study renders.

The sitemap therefore uses the later meaningful date when the route combines a project content date with the shared template date.

Documentation hubs use the same idea with the shared docs route and the taxonomy configuration.

This is important because a template change can materially alter many public pages even when their individual content files were untouched.

What this avoids

A common shortcut is to write the current date into every sitemap entry during every build.

That produces valid XML.

It also makes the date much less informative.

A small footer change, dependency update, or unrelated deployment can make every public page look newly modified.

If the field is meant to help recrawl decisions, honesty is more useful than constant freshness.

How to reproduce the check

1. Choose an MDX page that has not changed recently.
2. Record its Git modification date.
3. Run the lastmod generator.
4. Inspect the generated map for that file.
5. Confirm the sitemap entry uses the source date rather than the current build date.
6. Change the relevant content or shared template.
7. Commit the change and rebuild.
8. Confirm the new source date flows into the sitemap logic.

That tests the full path from repository history to public XML.

What this system does not know

Git history is still a technical proxy.

A one-character punctuation correction and a complete rewrite both produce a new source date.

The system does not attempt to classify editorial significance.

What it improves is the relationship between the field and reality. A changed date means a relevant source file actually changed.

The broader principle

Search infrastructure becomes easier to trust when it is derived from the same source of truth as the page itself.

The sitemap should come from the route and content inventory.

The canonical should describe the production route.

The robots behavior should match the environment.

The modification date should come from the sources that define the public document.

That consistency matters more than making any one field look maximally fresh.