Sitemap lastmod: How to Keep Last-Modified Dates Accurate

Short answer: The lastmod value in an XML sitemap should show the date when the content of a page last changed in a meaningful way. It should not show the date the sitemap was generated, the date of a minor template change or today’s date for every address. If the dates are accurate, search engines can use them to decide what to recrawl. If they are wrong, they learn to ignore them, and you lose a useful signal.

Most sitemaps list addresses and, for each one, an optional last-modified date. Many sites fill in that date automatically, and many do it badly. A sitemap in which every page changed a minute ago tells a crawler nothing. This guide explains what lastmod is for, which fields are worth including, how to find the right source for the date and how to check it. For the basics of sitemap structure, read XML sitemap best practices.

What lastmod is meant to say

The lastmod field states when a page was last modified. Its purpose is to help a crawler decide whether a known page needs to be fetched again. A crawler that sees an address unchanged since its last visit can skip it and spend time on pages that have changed or are new. For a large site, this saves effort for both sides. The value helps only if it is reliable, so it should reflect changes to the main content, important structured data or other elements that matter to a reader, not trivial edits.

Common mistakes that destroy trust

The most frequent mistake is to set the date to the time the sitemap is built, so all addresses carry the same recent date every day. A second is to update the date when a sidebar widget, a footer, a cookie notice or a comment count changes. A third is to use the date of the file or the cache rather than of the content. A fourth is to leave out the field for some pages and to include it for others in an inconsistent way. Search engines compare the claimed dates with what they find after crawling. When they see that dates do not match changes, they ignore the field for your whole site.

Decide what counts as a change

Write down a rule for your site. A change that counts might be a new paragraph, a corrected fact, an updated price, a new image that adds meaning, a revised table or new structured data that alters what the page says. A change that does not count might be a fixed typo, a changed link in the navigation, a new related-posts list or an updated visitor counter. A simple approach is to store a separate “content updated” date that editors or the system change only for real updates, and to use that date in the sitemap. Keep it separate from the technical modified timestamp.

Find the right source for the date

In WordPress, the modified date of a post changes with every save, including automatic ones triggered by plugins. Many SEO plugins use it for lastmod. That is usually fine for sites where saves match real edits, but problems appear when bulk edits or plugin updates touch thousands of posts at once. In that case, consider a field for the real content date or a filter that ignores bulk operations. For custom sites, use the date from your database rather than the time of the request. For static sites, use the commit date of the file where content lives. Avoid using the file system date if files are redeployed in bulk.

Keep dates consistent with the page

If your page shows an updated date to readers, and the sitemap shows another, you create an inconsistency that machines may notice. The visible date, the date in structured data and the lastmod value should tell the same story. Do not change the visible date only to look fresh, since readers and assistants judge whether the content has really been revised. The guide to content dates and freshness explains how dates affect trust and citations.

Ignore the fields that are not used

Older guides recommend adding change frequency and priority values to each address. Major search engines ignore these fields, and they take time to maintain. Leave them out or keep them simple, and spend your effort on correct addresses and correct dates. Make sure the sitemap lists only canonical, indexable pages that return a normal status. Dates on addresses that redirect, return errors or carry noindex do not help and can make the file look careless. See sitemap errors in Search Console for the common problems.

Check your sitemap against reality

Open the sitemap and pick a sample of ten pages. For each, compare the lastmod value with the date of the last real change that you know of, and with the page’s visible date. Look for patterns: all dates equal, all dates in the last day, or dates that are far older than recent edits. Use a crawler or a script to compare lastmod with the response headers and the page content over time. If you run a large site, split the sitemap by section, so that you can find which section produces wrong dates, and keep a sitemap index that references each file.

Fix the cause, then wait

Once you correct the source of the dates, regenerate the sitemap and submit it again in Search Console. Do not expect an immediate effect. Search engines rebuild trust gradually, and the benefit shows mainly as faster discovery of real updates on large or frequently changing sites. On a small site that rarely changes, lastmod is a minor matter; the main thing is to avoid false information. Review the setting after every theme, plugin or platform change, and add a check to your monthly routine.

Think about news, shops and documentation separately. A news site with hundreds of new articles each day benefits from accurate dates and a dedicated sitemap for fresh content. A shop with price and stock changes must decide whether such changes count: a price update may matter to a reader, but a stock counter that changes every minute does not. A documentation site might tie lastmod to the version of the product it describes. In each case, the rule should reflect what a reader would regard as new information, not what your system happens to record.

Finally, remember that lastmod is only a hint. Crawlers also use links, server headers, the speed at which pages change and their own estimates of importance. A good sitemap supports these signals but does not replace them. Keep internal links clear, make sure new pages are linked from places that are crawled often and return correct conditional response headers so that unchanged pages are cheap to fetch. Together, these measures make crawling efficient and make your updates easy to find.

Handle special sitemaps and large sites

Large sites usually split their sitemaps into several files, listed in a sitemap index. Each file may hold up to fifty thousand addresses and a limited file size, and splitting by content type, such as articles, products and categories, makes problems easier to find. The index file can also carry a date for each child file; the same rules apply, so update it only when the contents of that file changed. If you add image, video or news sitemaps, keep their dates on the same principle. For multilingual sites, make sure every language version carries its own accurate date, rather than copying one date to all versions, since translations are often updated at different times.

Dynamic sites should generate the sitemap from the database on a schedule, or when content changes, rather than building it on every request. Cache the result, and make sure the cache is cleared when a page is published, deleted or changed. Compress the file if it is large, and serve it with the correct content type and a normal status code. Check that the file is reachable by crawlers and is not blocked by robots.txt, a firewall or a login. A sitemap that cannot be fetched is worth nothing, however accurate its dates are.

Also think about removing addresses. When a page is deleted, redirected or set to noindex, it should leave the sitemap on the next build. Old addresses with old dates make the file look neglected and waste crawl effort. Compare the sitemap with your list of live, indexable pages every month, and investigate gaps in either direction. Pages that are indexable but missing from the sitemap may be orphans, and pages in the sitemap that are not indexable usually point to a configuration error.

Site SEO AI Audit crawls your site and checks your XML sitemap together with status codes, redirects, canonicals, noindex tags and orphan pages, so you can see addresses in the sitemap that should not be there and indexable pages that are missing from it. It does not judge whether each lastmod date matches your real edit history. The first audit of up to 200 pages is free; larger sites can see the pricing page.

The bottom line

Use lastmod only for real content changes, take it from a trustworthy source, keep it consistent with the visible date and check a sample regularly, so search engines keep believing it.

FAQ

Is lastmod required in a sitemap?

No, it is optional. Include it only if you can keep it accurate. A wrong date is worse than no date.

Do changefreq and priority matter?

Major search engines ignore them. You can omit them and concentrate on addresses and dates.

Should I update lastmod for a typo fix?

Usually not. Use it for changes that matter to a reader, such as new facts, prices or sections.

Will correct dates improve my rankings?

Not directly. They can speed up the recrawling of real updates and keep your sitemap trusted.

Why does my plugin set every date to today?

It may use the build time or a bulk save. Check its settings, or use a field that records the real content update.