A sitemap is a plain-text list of the URLs you want search engines to crawl. That sounds simple, and the core of it is — but the optional tags that surround each URL are widely misunderstood, and getting them wrong can quietly hurt your crawl. Here is what the sitemaps.org protocol actually defines, and what Google does with each piece.

The basic structure

Every sitemap is an XML document rooted in <urlset>, containing one <url> element per URL:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/page-a/</loc>
    <lastmod>2026-07-11T14:30:00+00:00</lastmod>
  </url>
</urlset>

Only <loc> is required. It must be an absolute URL, including the scheme and host. Relative URLs are not valid and will be ignored.

The two hard limits

Per the sitemaps.org protocol, a single sitemap file may contain at most 50,000 URLs and must be no larger than 50 MB (52,428,800 bytes) uncompressed — whichever you hit first. The limits apply per file, not per site.

If you exceed either limit, you split your sitemap into multiple files and list them in a sitemap index:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-07-11T14:30:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

A sitemap index can list up to 50,000 child sitemaps, which in turn gives you a theoretical ceiling of 2.5 billion URLs — comfortably beyond what any normal site needs. The index file itself is also subject to the 50 MB cap, and both file types may be gzip-compressed for transfer (the 50 MB limit applies to the uncompressed size).

What Google actually does with the optional tags

This is where most sitemaps go wrong. The protocol defines three optional tags per URL — <lastmod>, <changefreq>, and <priority> — but Google does not treat them equally. Per Google’s sitemap documentation and consistent statements from Google Search Central staff:

  • <lastmod> — Google uses this, but only when it is accurate. It is a real crawl-scheduling hint. If a URL’s lastmod is recent and trustworthy, Google may prioritize recrawling it.
  • <changefreq> — ignored. Adding “daily” or “weekly” to every URL does nothing.
  • <priority> — ignored. Setting everything to 1.0 does nothing, and even honest relative values are not used.

The practical takeaway: spend your effort on <lastmod>, and drop the other two unless you have a specific reason to keep them.

Why a fabricated lastmod is worse than none

This is the trap. Because lastmod is the one tag that matters, some site owners decide to “help” by setting it to the current date on every URL — even pages that haven’t changed in years. Google detects this and stops trusting the value.

Google cross-checks lastmod against signals like the page’s actual content hash and its own crawl history. If the lastmod claims the page changed yesterday but the content is byte-identical to the version Google fetched six months ago, the tag gets demoted from “useful hint” to “ignore.” Once your sitemap earns a reputation for inaccurate lastmod values, even truthful updates get discounted.

A fabricated lastmod is actively worse than omitting the tag. With no lastmod, Google simply falls back to its own crawl signals. With a dishonest lastmod, you have trained Google to distrust your sitemap.

How to produce a truthful lastmod

The right way is to tie <lastmod> to the actual modification timestamp of the underlying content — the moment the database row was last updated, the file’s real mtime, or the CMS’s published-on field. The sitemaps.org protocol accepts several date formats, but the most reliable is full W3C Datetime with a time and timezone:

2026-07-11T14:30:00+00:00

Avoid date-only values like 2026-07-11 when you have finer granularity — they’re valid but less informative. Never derive lastmod from “when the sitemap was generated,” because that’s the fabrication trap: every page gets today’s date regardless of whether it actually changed.

What to put in a sitemap (and what to leave out)

A clean sitemap beats a bloated one. Include:

  • Canonical URLs you actually want indexed
  • URLs that return 200 OK
  • Pages with real, indexable content

Leave out:

  • Redirected URLs (301/302) — point the sitemap at the destination
  • URLs blocked by robots.txt
  • noindex URLs — there’s no benefit and some downside
  • Duplicate or parameterized variants of the same content
  • Soft-404s (pages that look like errors but return 200)

Validate before you submit

A malformed sitemap is silently ignored. Common breakages include non-absolute <loc> values, unescaped & characters in URLs (they must be written as &amp;), dates in the wrong format, and files over the 50 MB cap. A sitemap validator will catch these before search engines do — run one whenever you change how your sitemap is generated, and especially after a migration.