Sitemap Splitter and Merger

Two directions, one sitemap input

The mode field picks the job.

Split takes a long list of URLs and returns several <urlset> documents plus the <sitemapindex> that ties them together. Each file gets its own copy and download button, and the index is the one you submit.

Merge takes several sitemaps and returns one deduplicated <urlset>, with a count of how many duplicates it removed. This is the mode for the situation where your CMS emits one sitemap, your blog platform emits another, and nobody is sure how much they overlap.

Both modes run the same parse, validation and dedupe pass first. The mode only decides how the surviving URLs are packaged.

What the input accepts

The URLs field is deliberately forgiving, because real inputs are messy. It takes:

• Plain URL lines, one per line
• https://example.com/page | 2026-08-20 pairs, pipe or tab separated, to carry a lastmod
• Whole <urlset> or <sitemapindex> documents, pasted straight in
• Several XML documents back to back
• Loose <url> fragments from a half-copied file
• Any mix of the above

XML is pulled out of the text first and parsed properly, so entities and CDATA are decoded and namespace prefixes survive. If a blob is too malformed to parse, a regex fallback scrapes the <loc> values out of it anyway, which means a truncated paste still yields its URLs instead of silently producing nothing.

Lines starting with # are ignored. Anything that is not an absolute http or https URL is listed separately with the reason it was skipped: relative path, unsupported protocol, over the 2,048-character <loc> cap, or not a domain at all. Input is capped at 100,000 URLs, which is twice a full sitemap.

Choosing a sitemap split size

The chunk size field is how many URLs go in each output file. It defaults to 50,000 and is clamped there, because 50,000 is the hard per-file limit, not a suggestion.

Smaller is usually better. 2 reasons:

• The 50 MB cap can bite first. A URL with a long path plus a lastmod runs 120 bytes or more of XML. At 50,000 entries that is comfortably inside the limit for most sites, but deep e-commerce URLs with faceted paths can push a full file past 50 MB. The tool measures the encoded size of the largest chunk and warns when it crosses.
• Diagnostics. Search Console reports submitted-versus-indexed per sitemap file. 10 files of 5,000 URLs tell you which section of the site has a coverage problem. One file of 50,000 tells you only that something is wrong.

Anything above 50,000 is clamped down with a note. Anything at or below 1 becomes 1.

Naming the chunk files

The chunk URL pattern decides what the index points at. The default is https://example.com/sitemap-N.xml, and N is replaced by the file number: sitemap-1.xml, sitemap-2.xml, and so on. {n} works too if you prefer an explicit token.

The N has to be delimited by a hyphen, underscore, dot or the start of the filename, so NewsSitemap.xml is left alone rather than becoming 1ewsSitemap.xml. If the pattern contains no counter token at all, the number is appended before the extension.

The pattern is validated as a URL, and the index is generated either way with a warning if it is not absolute. The important part is that it matches where the files will actually live. The index is a set of promises about URLs; if the files land at /sitemaps/sitemap-1.xml and the index says /sitemap-1.xml, every entry 404s.

What counts as a duplicate

Dedupe is by normalized URL, not string equality. The key is:

• Scheme and host lowercased
• Trailing slashes stripped from the path
• Path case preserved
• Query string kept
• Fragment dropped

So https://Example.com/Blog/Post/ and https://example.com/Blog/Post are the same entry, while /blog/post and /Blog/Post are not, because path case is significant on most servers and you cannot assume otherwise. ?page=2 produces a distinct entry. #comments never does, since a fragment is never a separate URL to a crawler.

The first spelling encountered is the one kept. If a later duplicate carries a lastmod that the first occurrence lacked, that date fills in rather than being discarded.

Duplicates inside a single sitemap are worth knowing about on their own. They usually mean 2 templates are generating the same entry, and that is a bug in the sitemap pipeline rather than a formatting quirk.

A worked sitemap splitting example

128,000 product URLs, split at 25,000 per file, with the pattern https://example.com/sitemap-products-N.xml. You get 6 files: 5 with 25,000 URLs and one with 3,000, plus this 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-1.xml</loc>
    <lastmod>2026-08-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products-2.xml</loc>
    <lastmod>2026-08-26</lastmod>
  </sitemap>
</sitemapindex>

Each index entry takes the newest lastmod found inside that chunk, because that is the date that tells a crawler whether refetching the file is worthwhile. A chunk with no dates in it gets no <lastmod>, which is correct rather than lazy.

Uploading and submitting

Upload every chunk to the exact paths in the index, then add the index to robots.txt and submit only the index in Search Console. The child files do not need to be submitted separately and submitting them double-counts your URLs in the coverage report.

If you are replacing an older sitemap, leave the old URL returning 200 with an empty <urlset> for a while rather than 404ing it immediately. A 404 on a previously submitted sitemap generates an error you will be looking at for weeks.