If each sitemap export resets every date to today, lastmod no longer describes the pages. It should represent an actual, significant change to that page, rather than the time the file was generated.
Which timestamp is being used?
Fictional example: an editor expands an article on Monday. Thursday’s deployment changes only a shared icon file. Thursday is therefore not a new substantive revision date for that article.
Find the database field or function supplying the date. A general updated_at value may change because of internal notes, migrations or automatic saves. Agree with the editorial team which changes matter on the published page.
Google gives significant changes to main content, structured data or links as examples. Updating a copyright year alone does not justify changing the page’s modification date.
Leave it out rather than invent it
When the system cannot provide a reliable timestamp, omitting the optional lastmod field is more accurate than recalculating it on every request. Add the date once its origin is traceable.
After the fix, compare an unchanged article following another export with an article that was genuinely revised. Only the latter should receive a new value. A recent timestamp does not promise an immediate crawl or a better ranking.
Related check: Remove redirects from a sitemap.
If the incorrect timestamp has been traced to frontend output, you can request a defined change through Frontend optimisation.