Sitemap lastmod: What It Is and How to Use It Correctly

What is the sitemap lastmod tag?

The sitemap lastmod tag is an optional date field in an XML sitemap that tells search engines when a URL last changed in a meaningful way. Google and Bing use it as a signal when they schedule recrawls of pages they already know, but only when the date stays consistent and accurate.

In short, lastmod is the cheapest way to tell a search engine that a page deserves another look. However, the same tag works against you when you misuse it. In this guide I walk through the protocol definition, the official positions of Google and Bing, the mistakes I see most often in audits, and a practical way to generate the right date.

If you need a sitemap right now, our free XML sitemap generator lets you give every URL its own lastmod date. First, though, let's pin down what the tag actually means.

What does the sitemaps.org protocol say about lastmod?

The shared standard for sitemaps is the sitemaps.org protocol, which the major search engines adopted in 2005. It defines lastmod as the date of last modification of the page and marks the field as optional. In other words, your file stays valid even if you never write the tag.

Above all, two details in the protocol matter. First, the date must follow the W3C Datetime format, and you may drop the time and write only YYYY-MM-DD. Second, the protocol says plainly that the date should reflect when the linked page changed, not when your system generated the sitemap.

The protocol also notes that lastmod is separate from the Last-Modified header your server sends. So a search engine can read both values independently. That separation sets up the consistency problem I cover later in this article.

• loc: the full page URL and the only required child element.
• lastmod: the date of the last meaningful change, optional.
• changefreq: an estimated change frequency, optional and practically inert today.
• priority: a relative priority inside your own site, optional and also inert.

How does Google use the sitemap lastmod value?

Google clarified its position in June 2023. In the announcement that retired the sitemaps ping endpoint, the Search team wrote that it uses lastmod as a signal for scheduling crawls of URLs it previously discovered. So the tag matters less for finding new pages and more for deciding when to return to known ones.

Google's current documentation on building a sitemap follows the same line. Google says it uses the value only if it is consistently and verifiably accurate. It adds that the value should reflect the date and time of the last significant update to the page.

Put simply, the key word here is "verifiably". Google does not accept the date blindly; when it crawls the page, it can see whether anything really changed. Therefore lastmod is not an instruction. It is a claim that earns or loses trust over time, and I manage it on client sites exactly like a trust account.

Why does Bing care so much about lastmod?

Bing speaks even more directly than Google on this topic. In a February 2023 post on the Bing Webmaster Blog, it called lastmod one of the most critical tags you can include in a sitemap. It also announced that it would revamp its crawl scheduling stack by June 2023 to make better use of the value.

In addition, the same post shared Bing's own numbers. Among the hosts it looked at, 58% had at least one XML sitemap, and 84% of those sitemaps carried a lastmod attribute. Still, Bing said the most common error was setting the date to the moment of sitemap generation instead of the moment of content change.

In July 2025 Bing repeated the message for AI powered search. That post describes lastmod as a key signal that helps Bing prioritize URLs for recrawling and reindexing. It also states that Bing ignores changefreq and priority entirely. Because Copilot answers draw on the Bing index, this stance also touches your AI visibility indirectly.

What counts as a "significant" change?

Google's 2023 post answers this clearly. When Google says "last modification", it actually means "last significant modification". If your CMS changed a small piece of text in the sidebar or footer, you do not have to update lastmod. If you changed the primary text, added or changed structured data, or updated links, you should update it.

In practice, I explain the distinction to teams with the table below. It maps Google's examples onto the changes I run into every week.

I write "usually" in the last row for a simple reason. A one letter fix does not change meaning, but correcting a wrong figure does. Your yardstick should always be the information the reader walks away with.

Which date format should you use?

Specifically, the protocol asks for W3C Datetime. In practice you have two options: a date only (2026-09-30) or a full timestamp with time and time zone (2026-09-30T14:20:00+03:00). The example in Google's documentation uses the date only, so that format is enough for Google.

Bing, on the other hand, recommends standard ISO 8601 formatting that includes both date and time in its 2025 post. On news and product pages that change several times a day, the time component makes a real difference. That is why I prefer full timestamps on dynamic sites.

• Always include the time zone, or convert to UTC and use Z.
• Never swap day and month; local formats such as 30/09/2026 are invalid.
• Avoid future dates; for scheduled content, use the actual publish moment.
• Mixing formats in one file is not an error, but consistency makes audits easier.

If the format breaks, Google tells you. After you submit the file, the Sitemaps report in Search Console flags an unsupported date format as an error.

What are the most common sitemap lastmod mistakes?

In the sites I audit, sitemap lastmod problems almost always come from the same handful of patterns. Most of them come from platform defaults, not bad intent. The list below shows the first things I check in a technical audit.

1. Today's date on every URL: the sitemap regenerates each night and every row gets the same date. Bing names this as the most common error.
2. Date jumps on trivial edits: a footer, menu or sidebar change bumps the date on every page.
3. Stuck on the publish date: you rewrote the article, yet lastmod still shows the first publish day.
4. Fake freshness: the date moves forward while the content stays the same, often with a visible "updated" label to match.
5. Redirected or noindex URLs: URLs that should not appear in the file at all carry fresh dates.
6. Wrong time zone: the server writes UTC, the app assumes local time, and the order gets scrambled.

Also, the fifth point hurts beyond lastmod. You can quickly spot redirects in your sitemap with the redirect checker and dead URLs with the broken link checker.

What happens if your lastmod dates are wrong?

Google spells this out in its 2023 post. If your page changed seven years ago but lastmod says it changed yesterday, Google eventually stops believing you about the last modified dates of your pages. So there is no sudden penalty; there is a quiet erosion of trust.

Still, the cost of that erosion is real. Once the signal turns unreliable, Google falls back on its own observations for crawl scheduling. As a result, your date gives you no edge when you ship an important update. On an ecommerce site with thousands of products, that means new prices and stock levels reach search results later.

Bing takes a similar view and says it may dismiss dates that look inaccurate. In short, a wrong lastmod can do more harm than no lastmod at all, because regaining trust takes time even after you fix the logic.

My practical advice is simple: leave the date out on pages where you are not sure. Google recommends exactly that, which brings us to the next section.

Do homepages and category pages need lastmod?

No, they do not. Google says you can provide lastmod for every page in the sitemap or only for the pages you feel confident about. For aggregating pages such as the homepage or a category page, the software may struggle to tell the last modification date. In that case Google says it is fine to leave the field out.

That said, there is a practical middle path. When a category listing changes because you added or removed a product, that is a meaningful change. So you can pass the newest child item's date up to the category. On paginated pages, I usually leave the date out entirely.

If your category tree is large, simplifying the architecture also makes lastmod easier to manage. Meanwhile, on multilingual sites each language version should carry its own date; an update in one language should not bump the others. My hreflang guide covers how those versions connect.

Should you remove changefreq and priority?

You do not have to, but keeping them gains you nothing. Google's documentation states that Google ignores both values. Bing's 2025 post says the same thing: neither tag influences crawling or ranking.

Likewise, Google explained the reasoning in 2023. changefreq overlaps conceptually with lastmod. priority is a highly subjective field and, according to Google's internal studies, it generally does not reflect the real priority of a page relative to others on the site.

I prefer to drop both. The file gets smaller, and the team stops expecting a ranking boost from "priority 1.0". That is also why our sitemap generator offers a "None" option for both fields. If you want to show which pages matter most, do it with internal links; a solid internal linking strategy does that job far better than any priority tag.

What does lastmod mean inside a sitemap index?

Specifically, this point confuses many teams. A single sitemap can hold up to 50,000 URLs or 50 MB uncompressed. Sites above that limit split the sitemap into several files and list them in a sitemap index file.

Next, in the index file, lastmod shows when the child sitemap file changed, not when its pages changed. Sitemaps.org says this explicitly: the date does not correspond to the time the listed pages changed. Thanks to that, a crawler can fetch only the child sitemaps that actually changed.

• Split child sitemaps by content type: posts, products, categories, pages.
• Keep fast changing products in their own file, so the file for static pages rarely changes.
• Leave the index date alone if the child file did not really change.
• Reference the index file in robots.txt and submit it in Search Console.

Bing says it supports up to 50,000 child sitemaps in a single index. So a well segmented setup can carry even a very large catalog with ease.

How does sitemap lastmod work in WordPress and other platforms?

Most off the shelf platforms build the sitemap lastmod value from the content's "modified" field in the database. That usually works, but there are two traps. First, some plugins can reset the modified date of every record during bulk actions or imports.

Second, jobs that have nothing to do with content, such as cache rebuilds or theme changes, can mark records as "modified" on some systems. So before you trust your platform, run a quick test: change a single comma in one post and watch what the sitemap does.

After that, check how the platform dates the homepage and archive pages. Some systems always give them the date of the newest post, which is often reasonable. The platform does not change the rule, though: the sitemap should show the real change date of the page that really changed.

How do you generate an accurate lastmod in custom software?

On custom built sites you design the logic yourself, which is a big advantage. In the projects my team and I build, we do not leave the "meaningful change" decision to individual developers; we encode the rule. The basic approach looks like this.

1. Store a content_modified_at field separate from the generic updated_at field.
2. Update it when the title, body, price, stock, structured data or internal links change.
3. Leave it untouched when technical fields such as view counters, cache flags or ranking scores change.
4. For extra safety, store a hash of the main content; if the hash stays the same, the date stays the same.
5. Build the sitemap from that field and write the date with its time zone.

In practice, the hash approach shines on template driven pages. When a template changes, the HTML of every page changes, but the hash of the main content does not. That prevents a false wave of freshness across the whole site. We made this pattern standard in our custom software development projects.

Should lastmod, Last-Modified and the on-page date match?

Technically they are three separate signals, but they should never contradict each other. Sitemaps.org says lastmod is independent of the Last-Modified header. Still, when a search engine reads all three together, it expects a consistent picture.

For example, the page says "Updated: March 12", the sitemap says September 29, and the content matches the previous crawl. That is an inconsistency, and Google's emphasis on "verifiable" targets exactly this kind of case. So I recommend feeding all three dates from the same database field.

When the visible date, the dateModified property in structured data and the sitemap lastmod come from one source, the margin for error drops close to zero. You can set up the structured data side with our schema generator and read the basics in my schema markup guide.

What is the difference between sitemap lastmod and the publish date?

People mix these two up often, yet they do different jobs. The publish date marks when the page first went live and never changes. Sitemap lastmod marks the last meaningful change and moves forward with every real update. On a freshly published page the two dates naturally match.

Likewise, structured data draws the same line. datePublished holds the publish date, while dateModified holds the latest update. So the counterpart of lastmod is dateModified, not datePublished. I regularly see themes that map these fields the wrong way round, with the publish date in the sitemap and the update date on the page.

Moreover, readers notice this too. Showing both "Published" and "Updated" on a guide builds trust, but only if the update date matches a real content change. Changing the date without touching the text creates an inconsistency readers can spot, and that hurts the brand.

What should lastmod be for deleted and redirected pages?

Short answer: those pages should not appear in the sitemap at all. A sitemap lists the canonical URLs you want indexed. If a deleted page returns 404 or 410, keeping it in the file with a fresh date sends crawlers there for nothing.

Likewise, the same rule applies to redirects. Remove the old URL and add the new one with its own lastmod. That way the crawler goes straight to the final target instead of spending crawl capacity on a redirect chain.

• Keep noindex pages out of the sitemap.
• Remove pages whose canonical tag points to another URL.
• Do not add parameter or filter variants of URLs.
• For out of stock products that keep their page, update the stock info and the lastmod date too.

The last point is an important exception. If the product page lives on, a stock change is meaningful, so updating the date is the right call.

How does lastmod relate to crawl budget?

Crawl budget is the crawling capacity a search engine assigns to your site over a period of time. On small sites it rarely matters. On sites with tens of thousands of URLs, however, the crawler cannot revisit every page daily and has to choose.

That choice is where lastmod comes in. An accurate date tells the crawler which pages changed and which stayed the same. The capacity then goes to new prices, new sections and corrected facts instead of unchanged pages. Bing's 2023 post frames the goal the same way: less unnecessary crawling and more priority for freshly updated content.

The opposite scenario breaks the picture. If every page looks "changed" every day, the signal loses its meaning. The crawler either wastes visits on all of them or ignores the date and goes back to its own estimates. Both outcomes are costly for large sites, because the page that truly changed has to wait in line.

How can you audit your lastmod values?

I audit in three layers. The first layer is the file itself: are the dates valid, do all rows share one date, are there future dates? In practice, the same date repeated across hundreds of rows is the clearest sign that the sitemap writes its generation time.

The second layer is Search Console. There, the Sitemaps report warns you when Google cannot read the file or does not support the date format. I cover the basics of the report in my Google Search Console guide.

Finally, the third layer is your server logs. Only access logs show exactly when Googlebot came back to a page you updated. With our log file analyzer you can compare the crawl frequency of updated pages before and after the change.

• Compare the number of unique dates with the total number of URLs.
• Pick ten random pages and compare the visible date with lastmod.
• Track in your logs how long it takes for an updated page to get recrawled.

How do IndexNow and Search Console fit with lastmod?

We used to send a "ping" to search engines whenever a sitemap changed. Google announced the deprecation of that endpoint in June 2023 and shut it down within six months. According to Google, most of those unauthenticated submissions led to spam, and requests to the endpoint now return a 404 error.

Instead, the current path is simple. Reference your sitemap with a Sitemap line in robots.txt and submit it through Search Console. Our robots.txt generator helps you write that file. After that, Google rereads the sitemap on its own schedule and evaluates the lastmod values.

On the Bing side, IndexNow comes into play. Bing recommends pairing a complete sitemap with instant URL submission. In other words, lastmod keeps the overall inventory fresh, while IndexNow reports a single change right away. Google has not announced IndexNow support, so for Google an accurate lastmod remains the main lever.

Does updating lastmod improve rankings?

No. Lastmod is a crawl scheduling signal, not a ranking signal. Moving the date forward does not make your page more valuable; at best it brings Googlebot back sooner. If the crawler finds the same content, that "update" adds nothing to rankings.

Instead, the real value lies in getting genuine updates into the index quickly. A product with a new price, a guide with a new section or a page with a corrected fact helps users sooner when it gets crawled sooner. That supports clicks and satisfaction indirectly.

I cover the ways to genuinely refresh content in my post on content freshness and update strategy. The rule is short: content changes first, then the date. Do it the other way round and you spend both Google's trust and your readers' trust.

How should you handle lastmod during a site migration?

Above all, migrations are the riskiest moment for lastmod. When the new system generates its first sitemap, every page may get the same "today" date. That creates the impression that thousands of pages changed at once.

In reality, most content does not change during a migration; the URLs and templates do. So I recommend carrying the real modification dates over from the old system during data migration. For pages whose URL changed, the new URL is a new record anyway, so the migration date is a reasonable value.

I collected the remaining steps in my website migration SEO checklist, and the redirect mapping tool speeds up the URL mapping. Remember to list only final, indexable URLs that return a 200 status.

A short sitemap lastmod checklist

Finally, I turned everything above into a short list I use in technical audits. Run it on every new site and after every major release.

1. Does lastmod change only on meaningful edits?
2. Are dates in W3C Datetime format with the correct time zone?
3. Do hundreds of rows share the exact same date?
4. Are you leaving the date out on pages where you are unsure?
5. Do the on-page date, dateModified and lastmod come from one source?
6. Does the sitemap list only canonical, indexable URLs that return 200?
7. Is the sitemap referenced in robots.txt and submitted in Search Console?
8. Is IndexNow set up for Bing?

Of course, this list is not the whole of technical SEO. For the wider picture, read my technical SEO guide. If you want crawl budget, sitemap architecture and lastmod logic set up for the scale of your site, my team and I handle it end to end as part of our SEO consulting.