XML Sitemaps and lastmod: Limits, Fields That Matter, and Honest Dates

An XML sitemap is a list of the URLs you'd like search engines to know about. It's one of the simplest files on a website and one of the easiest to get subtly wrong. Most sitemap problems aren't syntax errors. They're things like lastmod dates that change on every deploy, priority values nobody reads, or URLs in the sitemap that the site itself redirects or blocks. This guide covers the format, the limits, which fields actually matter, and how to keep lastmod honest.

The minimum valid sitemap

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/tools/unit-converter/fuel-economy</loc>
    <lastmod>2026-10-30</lastmod>
  </url>
</urlset>

That's all a sitemap needs. Each url entry needs a loc. Everything else is optional. A few rules apply to every entry:

• URLs must be absolute and include the protocol: https://example.com/page, not /page.
• URLs must be on the same host as the sitemap, unless you've verified cross-site submission, for example through Search Console.
• Special characters must be escaped. An ampersand in a URL must be written as &. A raw & makes the whole file invalid XML, and a strict parser will reject every URL in it, not just the broken one.
• The file must be UTF-8.

Size limits and when to split

The sitemaps.org protocol sets two limits per file: 50,000 URLs, and 50 MB (52,428,800 bytes) uncompressed. You can gzip the file to save bandwidth, but the 50 MB limit applies to the size before compression.

In practice, you'll hit the URL limit long before the size limit. Written on a single line with no indentation, the entry in the example above is 105 bytes. Even at a generous 180 bytes per entry, 50,000 entries come to about 9 MB. You'd need URLs averaging several hundred characters to reach 50 MB.

When you have more than 50,000 URLs, split them across several sitemaps and list those in a sitemap index. A site with 120,000 URLs needs ceil(120,000 ÷ 50,000) = 3 sitemaps: two full ones and a third with 20,000. An index file can list up to 50,000 sitemaps.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemaps/tools.xml</loc>
    <lastmod>2026-10-30</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemaps/guides.xml</loc>
    <lastmod>2026-10-28</lastmod>
  </sitemap>
</sitemapindex>

Splitting by section, rather than by arbitrary chunks of 50,000, has a side benefit. Search Console reports indexing per submitted sitemap, so separate files for tools, guides and categories tell you at a glance which section has an indexing problem.

Which fields search engines actually use

Google has said plainly that it ignores changefreq and priority. They're harmless to include, and other crawlers might read them, but don't spend time tuning them. Setting every page to priority 1.0 doesn't make anything more important; priority was only ever relative within your own site.

Getting lastmod right

lastmod is the one optional field that matters, and it only matters if search engines trust it. Google's guidance is that it uses lastmod when the value is consistently and verifiably accurate, meaning it matches real changes on the page. If your dates turn out to be unreliable, they're likely to be ignored.

The most common way to lose that trust is setting lastmod to the build time. Many static site generators and frameworks make this the easy default. Every deploy stamps every URL with today's date. Suppose you deploy three times a week. Every page on the site then claims to have changed 156 times a year, including pages that haven't been touched since launch. A crawler that checks a few of those pages and finds nothing new has good reason to stop believing the dates.

What counts as a real change

• Real changes include rewritten or added body content, changed prices or specifications, corrected facts, new sections, changed structured data.
• Changes that don't count include a new footer year, a rebuilt CSS bundle, a changed copyright line, a reshuffled sidebar, a deploy with no content change.

The cleanest way to do this is to store a content-updated date with each piece of content and output that in the sitemap. For a site that keeps its pages in code, a small map of path to date that you update when you edit a page works fine. For a CMS, the post's "modified" field is usually right, as long as trivial saves don't bump it.

Date format

lastmod uses the W3C Datetime format. A date alone, like 2026-10-30, is valid and usually enough. If you include a time, include the timezone too: 2026-10-30T14:05:00+05:30 or 2026-10-30T08:35:00Z. A value like 30/10/2026 or Oct 30, 2026 is invalid.

What shouldn't be in a sitemap

A sitemap should contain only URLs you want indexed, in their final form. Each of these sends search engines a mixed signal:

• URLs that redirect. List the destination instead.
• URLs that return 404 or 410.
• URLs blocked in robots.txt. You're asking crawlers to visit a page you've told them not to fetch.
• Pages with a noindex robots meta tag.
• Non-canonical duplicates, such as tracking-parameter versions or a page whose canonical tag points somewhere else.

Telling search engines where the sitemap is

Add a line to robots.txt: Sitemap: https://example.com/sitemap.xml. It must be an absolute URL, and you can list several. Then submit it in Google Search Console and Bing Webmaster Tools, which also show you how many URLs were discovered and indexed. Google retired its old sitemap "ping" endpoint in 2023, so scripts that hit it after each deploy no longer do anything useful.

Checking a sitemap

The Sitemap Checker fetches a sitemap URL from our server, parses it, and lists every URL with its lastmod, changefreq and priority. For a sitemap index, it lists the child sitemaps so you can check each one. A few things to look for in the results:

1. Check the lastmod date range. The checker shows the oldest and newest dates. If every URL has today's date, your lastmod is probably the build time.
2. Check the URL count against how many pages you expect. A big gap usually means a section is missing from the generator, or junk URLs are leaking in.
3. Scan for unexpected URLs: staging hosts, http:// instead of https://, query strings, or paths you've redirected.
4. Run each child sitemap from an index separately to confirm it loads and parses.

Limitations

• A sitemap is a hint, not an instruction. Listing a URL doesn't guarantee it gets crawled or indexed. Search engines still judge each page on its own merits.
• The checker parses; it doesn't crawl. It doesn't request each listed URL to check for redirects, 404s or noindex tags. Spot-check important URLs with the Redirect Checker.
• Gzipped sitemaps aren't supported. Point the checker at the uncompressed .xml version if you serve both.
• It can't verify that lastmod is truthful. Only you know whether a page really changed on the date it claims. The tool shows the dates; judging them is up to you.
• Blocked fetches fail. If your server or firewall blocks unfamiliar user agents, the checker can't load the file even though Googlebot might.