Sitemap index: limits and lastmod (2026 guide)

A sitemap with more than 50,000 URLs does not get indexed, it gets cut. And if your generator still fills changefreq, priority or image:caption, it is writing fields Google stopped reading years ago. Here is what a sitemap index still does in 2026.

Start with the small print Google repeats in its own documentation: submitting a sitemap is a hint, not an instruction. The official overview is blunt about it: a sitemap helps search engines discover URLs, but it does not guarantee that Google downloads it or crawls what is inside.

What a sitemap index actually solves (and when you do not need one)

A sitemap index is an XML file that lists other sitemaps instead of pages. It uses the same protocol namespace (http://www.sitemaps.org/schemas/sitemap/0.9) and almost the same structure: each entry sits inside a <sitemap> tag with its <loc> and, if you want, its own <lastmod>.

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

There are three honest reasons to use one: you went past 50,000 URLs or 50 MB in a single file; you want to split by content type (pages, images, video, news) so Search Console shows which sitemap is failing; or you publish daily and would rather rewrite the small child file that changed than one giant one.

And there is a case where you do not need it. Google states that a site with 500 pages or fewer, all well linked from the homepage, probably does not need a sitemap at all. The index would add nothing your internal linking is not already doing.

The four limits almost nobody checks

These limits come from the sitemaps.org protocol, not from Google, and they have not moved in twenty years:

Per sitemap: 50,000 URLs and 50 MB uncompressed (52,428,800 bytes). You can serve it gzipped, but the limit is measured after decompression.
Per index: up to 50,000 <loc> entries (that is, 50,000 sitemaps listed) and 50 MB as well.
Per Search Console property: 500 index files per site.
Per extension: up to 1,000 <image:image> tags inside each <url>, and up to 1,000 <news:news> entries per news sitemap.

When to split for real

The technical ceiling is 50,000, but the limit that breaks first is weight: URLs with long parameters exhaust 50 MB long before they reach 50,000 entries, and the file is silently truncated. The practical rule is to split by section or by publication year, not into arbitrary halves. If you split, submit the index to Google: one submission is enough for it to discover the children.

Where the index must live: the directory rule

Two conditions that the large sitemaps documentation spells out. The referenced files must be hosted on the same site as the index, and they must live in the same directory or lower.

That is where the most common error comes from: a sitemap at https://example.com/blog/sitemap.xml cannot list the homepage, only /blog/ and below. Search Console flags it as "URL not allowed" and drops the file. The rest is basic hygiene: UTF-8, absolute and complete URLs (Google crawls literally what you write, including case and protocol), and publication at the root of the domain whenever possible.

lastmod: the only date field Google uses

This is the best effort-to-benefit ratio in the whole article. Google uses <lastmod> when it is consistent and verifiable, and since 2023 it describes the field as a signal for scheduling crawls. The format is W3C: 2026-10-26 or 2026-10-26T09:30:00-03:00; if it is invalid, Search Console tells you when you submit the file.

What counts as a significant change? New main copy, updated structured data or changed internal links: yes. A new copyright year in the footer or a promotional banner: no. That distinction is what separates a useful field from noise.

The lastmod that lies (and how it breaks)

The classic failure is a CMS one: every time anything is published, the generator stamps the deploy date onto all 50,000 URLs. By the third time, Google stops trusting the field and you lose the only scheduling signal you had. If 100% of your URLs share the same lastmod, that field is not measuring changes.

The honest fix is to set it only on URLs you are sure about and omit it on aggregated pages (homepage, category and listing pages) where no real date exists. Omitting is valid; lying is not.

changefreq and priority: zero effect, and why

Google ignores <priority> and <changefreq>. The company said so in its June 2023 announcement: changefreq conceptually overlaps with lastmod, and priority is a subjective value that does not reflect a page's real priority. Keeping them does not hurt, but they take up space and give a false sense of control. Use internal linking and an honest lastmod instead. Crawl priority is decided by Google, from its own data.

Image sitemaps: what survived the 2022 clean-up

An image sitemap matters mostly for images Google would not discover otherwise, typically the ones loaded by JavaScript. It works as an extension inside a regular sitemap, with the namespace http://www.google.com/schemas/sitemap-image/1.1, and the minimum syntax is <image:image> with <image:loc>. Each <url> can hold up to 1,000 of them.

In the May 2022 clean-up, effective August 6 of that year, Google retired image:caption, image:geo_location, image:title and image:license: they have no effect on indexing. Plenty of plugins still generate them. They do not break anything, they just add nothing. If your images sit on a separate CDN domain, verify that domain in Search Console too and check that its robots.txt does not block them.

Video and news sitemaps: the requirements people break

For video, the required fields are <video:video> with <video:thumbnail_loc>, <video:title>, <video:description> (2,048 characters maximum) and <video:content_loc> or <video:player_loc>. That last one can never be the same URL as the page's <loc>. <video:duration> is in seconds, between 1 and 28,800. The same clean-up removed video:category, gallery_loc, price, tvshow and the player_loc attributes.

For news, the rules are about expiry: only articles from the last two days, a maximum of 1,000 <news:news> blocks per sitemap, and a <news:name> identical to the name shown on news.google.com. <news:publication_date> is the original publication date, not the date you added it to the file. If the sitemap sits empty for a few days, Search Console reports an empty sitemap: that is expected behaviour.

How to submit a sitemap in 2026: the ping is gone

The protocol's ping endpoint was deprecated in June 2023 and returns 404 today. If a plugin "pings" Google, it does nothing useful and breaks nothing: you can switch it off. The current routes are the Sitemaps report in Search Console, its API, the Sitemap: line in robots.txt, and WebSub if you publish feeds.

robots.txt or Search Console: which one

robots.txt is passive discovery: it keeps the file from being lost, but tells you nothing about the outcome. Search Console gives status, last read time and errors per sitemap, with one important limit: only sitemaps submitted through the interface or the API appear in the report. Use both, each for what it does well.

Troubleshooting: the errors that matter

The report shows three states: Success, Couldn't fetch, and "sitemap had X errors", meaning it was read only in part. The real causes behind the second one, according to Search Console help, are a robots.txt that blocks the file, an unresolved manual action (sitemaps are not read while one exists), a 404 on the sitemap URL, or a server that is down.

The most common parsing errors are "URL not allowed" (above the level of the sitemap or a different domain), "URLs not followed" (redirects, meta-refresh or relative paths) and "some URLs are not accessible". The other half of the job is keeping the file clean: drop URLs with noindex, redirects, 404s and non-canonical duplicates. To find out whether Google really downloads it, log analysis beats any report.

A seven-point checklist

Count URLs and megabytes: past 50,000 or 50 MB, you need an index.
Check that the index and its children are on the same site and that no child sits above the index.
Confirm every URL is absolute, canonical and UTF-8.
Make sure lastmod reflects real changes, not the deploy date.
Remove changefreq, priority, image:caption and image:title if they are still generated.
Verify it is submitted in Search Console and referenced in robots.txt, with no read errors.
Validate the required tags on image and video sitemaps.

For other discovery routes, the IndexNow article covers why Google is not part of it, and the classic sitemap tutorial handles the basic setup.