XML Sitemap Chunker Free Tool

Paste your page URLs, one per line. The tool splits them into valid XML sitemap files with at most 50,000 URLs each (the sitemaps.org limit), and generates a sitemap index when more than one file is needed. Only absolute http:// / https:// URLs are used; duplicates are removed automatically. Processes up to 100,000 URLs total per submission, split into files of 50,000 URLs each; anything past that is truncated.

Enter one URL per line

About XML Sitemap Chunker

What an XML Sitemap Is (and Why Search Engines Use It)

An XML sitemap is a plain-text XML file that lists the URLs a site owner wants search engines to crawl and, ideally, index. Structurally, it's simple: a root <urlset> element declaring the sitemaps.org namespace, followed by one <url> entry per page, each wrapping a <loc> tag with the page's full URL. Optional per-URL fields exist too (<lastmod>, <changefreq>, <priority>), but the only field a search engine actually requires is <loc> itself.

The reason sitemaps exist at all is crawl discovery. A search engine finds most pages by following links — starting from pages it already knows about and crawling outward through internal and external links. That works well on a site with tight, consistent internal linking, but it breaks down in a few common situations: a large catalog where thousands of product pages are only reachable through paginated category listings several clicks deep, a site with orphaned pages that nothing else links to, a brand-new site with no external links pointing in yet, or a site migration where the old link structure hasn't been fully rebuilt on the new one. A sitemap hands the crawler a direct, flat list of URLs instead of asking it to discover every page by following links — a meaningful advantage for large or poorly-linked sites, and a much smaller advantage (though still a nice-to-have) for a small site with clean internal linking, since a crawler would likely find every page on its own anyway.

It's worth being precise about what a sitemap does and doesn't do. Listing a URL in a sitemap does not guarantee it gets crawled, and being crawled does not guarantee it gets indexed — a sitemap is a hint about which pages exist and roughly how important the site owner considers them relative to each other, not a command search engines are obligated to follow. It's also not a ranking factor in the way page content or backlinks are. What it reliably does is remove "the crawler never found this page" as a reason a valid page might be missing from search results, which is exactly the problem this tool exists to help solve once a URL list gets too large for a single sitemap file to hold.

Search engines don't require a sitemap to be submitted through a webmaster console before it's useful, either — a sitemap that's simply uploaded to a publicly reachable URL and referenced from robots.txt can be discovered and used on its own. Submitting it directly in Search Console or Bing Webmaster Tools is still worth doing, since it's the only way to see per-sitemap coverage reporting (how many of the listed URLs actually got indexed, and any errors found along the way), which is a big part of why the submission step matters even though it's technically optional for discovery.

The Real Sitemap Size Limit: 50,000 URLs or 50MB

The sitemaps.org protocol — the specification that Google, Bing, and every major search engine follow for sitemap files — sets two hard limits on a single sitemap file, and a file hits whichever one it reaches first:

In practice, almost every real-world sitemap hits the 50,000-URL count first, long before the file's raw size approaches 50MB. A typical <url> entry with a reasonably short URL and no optional fields runs well under 1KB, so 50,000 of them land somewhere in the low tens of megabytes at most — under the 50MB ceiling with room to spare. The byte-size limit becomes the binding constraint only in unusual cases: sitemaps built with unusually long URLs (deeply nested paths, long query strings), or ones that include the optional <lastmod>, <changefreq>, and <priority> fields on every single entry, which adds meaningful bulk across tens of thousands of repetitions.

Either way, the practical consequence for a site owner is the same: once a site has more URLs than fit under whichever limit is hit first, the list has to be split across multiple sitemap files. A single 80,000-URL sitemap isn't a "big but valid" file — it's an invalid one that violates the protocol, and there's no reliable way to know in advance whether a search engine will process the first 50,000 entries and silently drop the rest, reject the file outright, or handle it some other way. Splitting before you hit the limit, not after something looks wrong in Search Console, is the safer default.

The protocol also allows a sitemap file to be gzip-compressed before it's uploaded (a sitemap.xml.gz file instead of a plain sitemap.xml), which reduces the file's size on disk and over the wire but doesn't change the 50,000-URL or 50MB limits themselves — those limits apply to the uncompressed content, not to whatever smaller size the compressed file happens to end up at. Compression is a bandwidth and storage convenience, not a way around either limit.

Why You Need a Sitemap Index Once You Have Multiple Files

Once a URL list is split across more than one sitemap file, there's a second file you need that isn't just another chunk of URLs: a sitemap index file. A sitemap index is a small XML file with its own root element, <sitemapindex>, that lists the location of every individual sitemap file rather than listing pages directly — each entry is a <sitemap> element wrapping a <loc> tag pointing at one chunk file's URL, the same way a regular sitemap's <url> entries point at pages.

The index exists to solve a specific coordination problem. Search Console (and Bing Webmaster Tools) lets you submit sitemap URLs one at a time, and each submission is tracked and reported on separately. Submitting five separate chunk files as five separate submissions means five separate coverage reports to check, five separate places an error could hide, and no single view of the whole set. Submitting one index file instead means Search Console reads the index, follows every <loc> inside it to discover all five chunks automatically, and reports on the whole group as one coherent unit. You still get to drill into each individual chunk's status from there — the index doesn't hide that detail, it just gives you one starting point instead of five.

An index also has a place outside Search Console: a site's robots.txt file commonly includes a Sitemap: directive pointing at the sitemap index URL, which is one of the ways other crawlers (not just the ones you've manually submitted to in Search Console) discover that a sitemap exists at all. The section on submitting your sitemaps, further down this page, covers this in more practical detail once the chunk files and index are actually built.

One detail worth being clear on: an index file only ever points at other sitemap files, never directly at pages. A search engine reading a sitemap index doesn't treat the entries inside it as URLs to crawl and index themselves — it treats each one as "go read this other file, which is where the actual page URLs are." Mixing the two up (listing a page URL directly inside a <sitemapindex> root, or vice versa) produces an invalid file, which is one more reason a purpose-built chunking tool that generates both file types correctly is worth using instead of hand-editing XML.

Common Situations That Need Sitemap Chunking

Most sites never come close to 50,000 URLs and never need to think about any of this — a sitemap of a few hundred or a few thousand pages fits comfortably in one file with room to spare. Chunking becomes a real, recurring need in a specific set of situations:

Large E-Commerce Catalogs

A catalog site with tens or hundreds of thousands of individual product pages — plus category pages, filtered listing pages, and often a separate set of URLs per size/color/region variant — is the single most common source of sitemaps that outgrow the 50,000-URL limit. A mid-size online retailer can cross that threshold with product pages alone, before category or variant pages are even counted.

Content Sites With a Large Back Catalog

A publisher, blog network, or content site that's been publishing consistently for years can accumulate tens of thousands of individual articles or posts. Each one is a legitimate, indexable page that belongs in a sitemap, and a back catalog built up gradually over a long publishing history is exactly the kind of URL count that a single sitemap file was never designed to hold once it's added up.

News and High-Volume Publishers

A news site publishing many articles per day builds up a very large total archive over time, on top of already needing fast, reliable discovery for new articles specifically. High page-count archives from years of daily publishing routinely exceed the single-file limit, and splitting older archive content into its own chunk (or set of chunks) separately from newer content is a common practical pattern for exactly this kind of site.

XML Sitemap Chunker vs. XML Sitemap Generator: Which One Do You Need?

This site also runs a separate tool called the XML Sitemap Generator, and the two names are close enough that it's worth being unmistakable about the difference before going any further, since landing on the wrong one wastes a step.

The short version: if you already have your list of URLs sitting in a spreadsheet, an export file, or an old sitemap that's grown too big, you want the tool on this page — it doesn't crawl anything, it just takes the list you give it and splits it correctly. If you don't have a URL list yet and want one built by crawling a live site, the Sitemap Generator is the tool that does that job; this one won't discover pages on its own, and pasting a single starting URL into this tool's input box won't make it go find the rest of the site's pages for you.

How This Tool's Chunking Boundary Works

Once a URL list is pasted in and submitted, this tool's own chunking logic is deliberately simple and predictable — no reordering, no alphabetizing, no attempt to group related URLs together:

• 50,000 URLs per chunk file, exactly. This matches the sitemaps.org per-file URL limit described above. The first 50,000 valid, deduplicated URLs from your list go into sitemap-1.xml, the next 50,000 go into sitemap-2.xml, and so on.
• Strict submission order. URLs are chunked in exactly the order they appear in your pasted list, top to bottom. There's no sorting or grouping applied — if you want related URLs to land in the same chunk together, you need to arrange your list that way before pasting it in, covered in more detail in the grouping section below.
• 100,000-URL total cap per run. This tool caps the total number of URLs it will chunk in a single submission at 100,000 — meaning one run can produce, at most, two 50,000-URL chunk files. This is the tool's own operational ceiling, separate from the sitemaps.org per-file limit; if your full list is larger than 100,000 valid URLs, you'll need to split your source list into batches and run each batch through separately.
• 200,000-line input cap. Before any of the above even applies, a paste larger than 200,000 total lines is rejected outright, so you know immediately if your input is too large rather than getting a partial or confusing result.

The one honest limitation worth stating plainly, not glossing over: this tool decides where to split a file based purely on URL count — the 50,000-per-file rule above — and does not separately measure the resulting file's byte size against the sitemaps.org 50MB uncompressed limit. As covered earlier, that's a genuinely rare edge case in practice, since a 50,000-URL file with normal-length URLs lands well under 50MB, but it's a real gap and it's worth knowing about if your URLs happen to be unusually long. If that's a concern for your specific list, check a generated chunk file's raw size directly after downloading it rather than assuming the URL-count split alone guarantees you're under the byte limit too.

What Happens to Invalid Lines and Duplicates

Before chunking happens, every line of your pasted input goes through validation and cleanup:

• Blank lines are dropped silently and don't count toward anything — no penalty, no note in the summary, they're simply ignored.
• Every remaining line is checked against a strict pattern: it has to be an absolute URL starting with http:// or https://, with no whitespace inside it. A bare domain without a scheme, a relative path, or a line with a stray space in the middle all fail this check and are skipped — never chunked into an output file, only counted as an invalid line in the summary.
• Duplicate URLs are removed, using an exact string match. If the same URL appears more than once in your pasted list, only the first occurrence is kept; every later repeat is dropped and counted separately in the summary as a duplicate removed, not an invalid line.

Both checks matter for a working sitemap, not just a tidy-looking one. An invalid line that somehow made it through as a <loc> value would produce a sitemap entry search engines can't resolve to an actual page — a wasted crawl request at best. A duplicate URL appearing twice in the same sitemap doesn't break the file's validity outright, but it's a wasted entry that adds nothing (a search engine only needs to see a given URL listed once to know it exists), and at scale, duplicate entries eat into your 50,000-per-file budget for no benefit — better to know your real, deduplicated count before deciding how many chunk files you'll actually need.

How to Use This Tool

This is the literal, step-by-step process for running the tool, separate from the mechanics explained above.

1. Gather the full list of page URLs you want in your sitemap — from a database export, a CMS export, a migration script, or an old sitemap file that's grown too large.
2. Format your list with exactly one URL per line, each a complete absolute URL starting with http:// or https://.
3. Paste your full list into the text box at the top of this page.
4. Click the submit button to process your list.
5. Read the summary line at the top of the results: URLs written, number of chunk files produced, whether an index file was generated, plus invalid-line and duplicate counts if any were found.
6. Copy or download each chunk file's XML source shown in the results.
7. Copy the sitemap index file's XML source too, if more than one chunk file was produced (a single-chunk run doesn't generate an index, since one file needs nothing to index).
8. Upload every chunk file, and the index if there is one, to an accessible location on your site (commonly the site root).
9. Submit only the sitemap index URL in Search Console if you generated one — not each individual chunk file separately.

Reading Your Results

The results page shows a few distinct pieces of information, and it's worth knowing what each one is actually telling you:

Because this tool's own ceiling is two chunk files per run, you won't run into a situation where the on-page preview hides files from you — everything a given run produces is shown. What can still get visually truncated is the raw XML source display for an unusually large individual chunk file, which is purely a display convenience; a truncated preview note there means only the on-screen text got cut short, not that the actual downloadable file is missing any URLs.

Grouping Your URLs Before You Chunk

Because this tool chunks strictly in the order URLs appear in your pasted list — first 50,000 into one file, the rest into the next — the order you paste them in is the only control you have over which URLs end up grouped together. The tool itself has no concept of URL paths, content types, or site sections; it doesn't know or care whether a URL is a product page, a blog post, or a category listing.

For a lot of sites, an arbitrary sequential cut is perfectly fine — if you just need every page in a valid sitemap somewhere, it genuinely doesn't matter which chunk any specific URL lands in. But if you're the kind of site owner who watches Search Console's per-sitemap coverage reports closely, there's a real practical benefit to grouping logically before you paste: one sitemap for product pages, a separate one for blog content, a separate one for category or landing pages, and so on. Done that way, Search Console's coverage report for each individual sitemap tells you something specific — "this many of my product pages are indexed" rather than a single mixed number spanning every content type on the site, which makes it much easier to spot a problem confined to one section of the site instead of one confusing aggregate figure.

If logical grouping matters to you, sort or filter your source URL list by content type or site section before you paste it into this tool — put all the URLs you want grouped together consecutively in your list. The tool will then chunk them together automatically as a side effect of processing them in that order, without needing any grouping feature built into the tool itself.

A practical example: a site with 70,000 product pages and 40,000 blog posts could paste the whole 110,000-URL combined list in submission order and get back a slightly awkward split — the first chunk mostly products, the second chunk a mix of leftover products and early blog posts, cutting straight through the middle of one content type. Run the two groups through separately instead (products first, in their own submission; blog posts second, in a separate submission) and the result is two clean chunk sets, each one mapping to a single content type in Search Console's coverage report. The tool's total cap per run is 100,000 URLs, so a 70,000-product list and a 40,000-post list each need their own separate run anyway in this example — which works out well for keeping the groups clean.

Submitting Your Sitemaps to Search Console

Once you have your chunk files (and an index, if you generated one), there's a short remaining sequence to actually get them working for a live site:

1. Upload every chunk file, and the index file if there is one, to a location your site serves publicly — commonly the site root (example.com/sitemap-index.xml) or a dedicated sitemaps folder, as long as the path is publicly reachable over HTTP(S). Double-check that the URLs inside each chunk file match your site's actual final, public URLs (correct domain, correct protocol, no leftover staging or localhost addresses) before you upload — a sitemap pointing at the wrong host is a common, easy-to-miss mistake after a migration.
2. In Search Console, submit only the index file's URL if you generated one. Submitting the index automatically surfaces every chunk file it references — you don't need to add each chunk as a separate submission.
3. If you only produced a single chunk file (no index was generated because your list was under 50,000 URLs), submit that one file's URL directly instead.
4. Add a Sitemap: directive to your site's robots.txt file, pointing at the index URL (or the single chunk file's URL, if there's no index). This gives crawlers a way to discover your sitemap even outside a manual Search Console submission. If you need to build or check a robots.txt file, the Robots.txt Generator on this site handles that directly.

Repeat this same process any time your URL list changes meaningfully — a large batch of new pages published, an old set retired, or a URL structure change. There's no automatic "re-chunk on a schedule" behavior here; each run reflects whatever list you paste in at that moment, so a stale chunk file left live after a big content change can quietly point search engines at URLs that no longer exist, or leave out ones that are new.

Related Tools

A couple of other free tools on this site pair naturally with sitemap chunking, depending on where you are in the process:

• If you don't have a URL list yet and want one built automatically by crawling a live site instead of assembling it by hand, use the XML Sitemap Generator — covered in more detail in the comparison section above.
• Before you submit a large freshly-chunked URL list as a sitemap, it's worth checking that list for dead links first. The Broken Link Checker can run against the same list you're about to chunk, so you're not asking search engines to crawl and index pages that already 404.

Frequently Asked Questions

Is this the same tool as the XML Sitemap Generator on this site?

No. The Generator crawls a live site starting from one URL and builds a sitemap from what it discovers. This tool does zero crawling — it splits a URL list you've already assembled. See "XML Sitemap Chunker vs. XML Sitemap Generator" above for the full breakdown.

Does this tool check whether my generated sitemap files stay under the 50MB size limit too?

No, and this is a real, disclosed limitation rather than a hidden gap — it splits purely by URL count (50,000 per file), not by resulting file size. See "How This Tool's Chunking Boundary Works" above for why this is a rare edge case in practice, and how to check a chunk file's actual size yourself if your URLs are unusually long.

What's the maximum number of URLs I can chunk in one run?

100,000 total URLs per submission, which produces at most two 50,000-URL chunk files. If your full list is larger than that, split it into batches and run each batch through separately.

What happens to duplicate URLs or malformed lines in my pasted list?

Both are removed before chunking and reported separately in the summary line — duplicates removed (exact match, first occurrence kept) and invalid lines skipped (anything that isn't a valid absolute http:// or https:// URL). See "What Happens to Invalid Lines and Duplicates" above for the exact rules.

Do I need to submit every chunk file separately in Search Console, or just the index?

Just the index, if one was generated. Submitting the index automatically surfaces every chunk file it references, rather than needing a separate submission per file. See "Submitting Your Sitemaps to Search Console" above for the full sequence.

Can I control which URLs end up in which chunk file?

Only indirectly, by controlling the order you paste them in — the tool chunks strictly in submission order with no grouping logic of its own. Sort or group your source list by content type or site section before pasting if that matters to you. See "Grouping Your URLs Before You Chunk" above.