The two limits
Both apply to a single sitemap file, and you are bound by whichever you reach first.
The URL limit is 50,000. The size limit is 50MB uncompressed, which matters more than people expect: sitemaps that carry long URLs, or that include image or video extensions, can hit 50MB well before 50,000 URLs.
Gzip compression helps with transfer but not with the limit, because the 50MB ceiling is on the uncompressed size. Compressing a 60MB sitemap does not make it valid.
| Limit | Value | Notes |
|---|---|---|
| URLs per sitemap | 50,000 | Hard limit across all sitemap formats |
| File size | 50MB uncompressed | Compression does not raise it |
| Sitemaps per index | 50,000 | An index file is itself a sitemap and bound by the same count |
| Sitemaps you may submit | No stated limit | Google notes there is no limit on how many you reference |
What to do when you exceed them
Split the sitemap and list the parts in a sitemap index file. An index is a small XML file whose entries point at other sitemaps rather than at pages, and crawlers follow it automatically.
Split along lines that mean something rather than arbitrarily. Grouping by content type, such as products, articles and categories, makes the Search Console reporting genuinely useful, because you can see which section has an indexing problem instead of one undifferentiated number.
An index file is itself a sitemap, so it is bound by the same 50,000 count. In practice that ceiling, 50,000 sitemaps each holding 50,000 URLs, is not one most sites need to think about.
Smaller than the limit is usually better anyway
The limits are a ceiling, not a target. Several thousand URLs per file is easier to work with than one enormous file, for reasons that have nothing to do with validity.
Diagnosis is the main one. When Search Console reports errors against a sitemap of 50,000 URLs, you have learned very little. When it reports errors against your products sitemap and not your articles sitemap, you know where to look.
Regeneration is the other. Rewriting a 40MB file on every publish is slower and more fragile than rewriting one section.
The attributes inside, and which are ignored
Worth covering here because it is the same page of documentation and it saves you effort.
Google's documentation states that it "ignores <priority> and <changefreq> values." Filling them in carefully is wasted work. Many generators still emit them, which is harmless.
The lastmod value is different and it does get used, but conditionally. Google says it uses lastmod "if it's consistently and verifiably" accurate, and its guidance is that the value should reflect meaningful changes to the main content rather than trivial ones. A generator that stamps today's date on every URL at every build has made lastmod worthless, and arguably worse than absent, because it is verifiably inaccurate.
Common questions
What is the maximum number of URLs in a sitemap?+
50,000. Google's documentation states that all formats limit a single sitemap to 50MB uncompressed or 50,000 URLs. Beyond either limit, split into multiple sitemaps and use a sitemap index.
Does gzipping help me exceed the size limit?+
No. The 50MB limit is on the uncompressed size, so compression reduces transfer but does not make an oversized sitemap valid.
How many sitemaps can I have?+
Google notes there is no limit on how many sitemaps you reference. A single sitemap index file is itself bound by the 50,000 entry count.
Should I use priority and changefreq?+
There is no point for Google, which states it ignores both values. Leaving them in is harmless; spending time tuning them is wasted.
Does lastmod matter?+
Yes, conditionally. Google says it uses lastmod if the value is consistently and verifiably accurate. A generator that stamps the current date on every URL every build makes it useless, because it is demonstrably wrong.
Sources