Sitemap lastmod is just the time the file was generated
sitemap_lastmod_uniformShort answer
In this sitemap almost every URL has the same <lastmod> value, and that value is the moment the file was generated: each time Glimana reads the sitemap, the date has moved to that time. Pages did not all change at once, so the date says nothing. Google uses lastmod only when it is consistently accurate; when it is not, Google ignores it, and the pages you really update lose that signal too. Set lastmod to the date the page's main content last changed, or leave it out until you can.
Why it matters
<lastmod> tells search engines which pages changed since their last visit, so they can recrawl those first. Google has said it uses the value only if it is consistently and verifiably accurate, for example when it matches the page's real last change. A sitemap that stamps every URL with "now" fails that test on the first comparison, and Google then ignores lastmod for that sitemap. Nothing is deindexed and traffic does not drop overnight, but on a large site new and updated pages are found later than they could be.
A "significant" change is a change to the main content, structured data or links. A new copyright year in the footer, a sidebar widget or a page view counter is not a reason to change lastmod.
How Glimana detects it
Glimana reads your sitemaps once a day and, for each sitemap file, records the most common lastmod value (rounded to the hour), the share of URLs that carry it and when the file was read. The issue is reported only when all of these are true:
- the sitemap file lists at least 50 URLs,
- at least 80% of its URLs share the same lastmod value,
- that value is within about a day of the time the file was read (it is the generation time, not a past edit date),
- this was seen on two consecutive reads, and the shared value moved between them.
The last condition keeps a real bulk update from being reported: if you updated all pages yesterday, the shared date stays the same on the next read. Glimana does not compare lastmod with the page content, and does not report a lastmod that is older than a content change. The evidence shows the sitemap file, the share of URLs with the shared date, and the value on the last two reads.
How to fix it
- Find the affected sitemaps in Glimana. Open Issues › Sitemap lastmod is just the time the file was generated. Each row names one sitemap file, the share of its URLs that carry the same date and that date on the last two reads.
-
Apply the fix on your platform.
- Find where lastmod comes from. Open the sitemap twice a few minutes apart. If the dates change between the two loads, lastmod is the request time; if they match the time of your last build or cache refresh, it is the build time.
- Use the content's real change date. For posts and pages, the modified date of the content; for products, the last change to the product itself; for category or listing pages, the date of the newest item they show.
- Can't get a real date? Leave lastmod out. A sitemap without lastmod is valid and loses nothing. A wrong lastmod costs the trust of the correct ones.
- Keep
<changefreq>and<priority>as they are or remove them; Google ignores both.
Yoast SEO, Rank Math and All in One SEO take lastmod from each post's modified date, which is correct. A shared stamp usually comes from a separate sitemap plugin or a custom sitemap that writes the generation time: switch to your SEO plugin's sitemap and remove the other one. Also check for a scheduled task or plugin that re-saves every post (bulk search and replace, "refresh dates" or import plugins): each re-save updates the modified date of all posts.
Shopify builds the sitemap itself and you cannot change how it sets lastmod. If the date moves for nearly every product on each read, an app that rewrites all products on a schedule (inventory, price or feed sync) is the usual cause. Check whether it can update only the products that actually changed.
Many generators fall back to the build time. In Hugo, set
enableGitInfo = trueso.Lastmodcomes from each file's last commit, or setlastmodin front matter. In Jekyll, use thejekyll-last-modified-atplugin or alast_modified_atfront matter field withjekyll-sitemap. In Astro, do not set a singlelastmodfor the whole@astrojs/sitemapintegration; set it per page withserialize, or leave it out. In Next.jssitemap.ts, replacelastModified: new Date()with the content's own updated date.The usual bug is
lastmod = now()while the sitemap is built. Read theupdated_at(or equivalent) of the record behind each URL instead, and update it only when the main content changes. Cache the generated file if you like; caching does not change the dates inside it. -
Publish and clear caches. Deploy the change and purge the sitemap URLs at your CDN. Open the sitemap and check that different pages now show different dates. Resubmitting it in Search Console › Sitemaps is optional; Google rereads it on its own.
- Verify in Glimana. Open the task under Tasks and click Mark as done. Glimana rereads the sitemap files, and the task closes when the shared, moving date is gone. If the pattern is still there, the task returns to New with a note. To check sooner, use I fixed it — re-check now on the issue.
How the fix is verified
Glimana rereads the sitemap files; the issue closes when most URLs no longer share a lastmod equal to the time the file was read.