Bulk extracting URLs from a sitemap means parsing one XML file into a deduplicated, one-URL-per-line list — without uploading the file or running a crawler. The Sitemap URL Extractor reads a complete <urlset> or <sitemapindex> document pasted into its editor, pulls out every direct <loc> value, normalizes each one through the browser's WHATWG URL parser, and reports the root type, unique count, duplicate count, and full output in a single pass. Because parsing happens locally, the XML never leaves your device, which matters when you are working with staging environments, prelaunch URL inventories, or private sitemaps that should not be transmitted to a third-party service. The tool is built around the Sitemaps protocol's two core structures rather than around heuristics, so what you paste is exactly what gets extracted — nothing more, nothing less, and nothing guessed. First-seen order is preserved, deduplication is transparent, and every limit is disclosed up front, which is what makes the result usable as audit evidence rather than as a black-box report.
What "Bulk" Means for Sitemap URL Extraction
Most sitemaps reach into the thousands, and large publisher or e-commerce sitemaps routinely push past 10,000, 25,000, or even 50,000 entries before a <sitemapindex> splits the work across sibling files. A bulk extractor must therefore handle three jobs at once: read the entire XML document in one pass, separate the page URLs from the structural metadata, and report scale honestly without silently dropping entries.
The Sitemap URL Extractor is designed around exactly that definition of bulk. It takes the full text of one urlset or sitemapindex file, walks every direct <loc> child in document order, and returns a deduplicated list whose length is bounded by hard, disclosed limits rather than by what the browser happens to tolerate. There is no streaming promise that quietly truncates at the end, and there is no silent fetch step that quietly expands a sitemapindex into every referenced file. The output reports the root type that was recognized, the unique count that was accepted, and the duplicate count that was removed — three numbers that make scale easy to verify before the list is used anywhere else.
How to Bulk Extract URLs From a Sitemap
The actual workflow is short, but each step protects the integrity of the result.
- Open the XML source of your sitemap in any text editor, browser view-source panel, or terminal cat sitemap.xml output. Copy the entire document, from the opening <?xml ... ?> declaration (if present) to the closing </urlset> or </sitemapindex> tag.
- Paste the complete XML text into the editor of the Sitemap URL Extractor. Do not paste a remote URL into the editor — the widget does not download anything, and compressed .gz files must be decompressed on your machine before they are pasted in.
- Run the extraction. The tool reports which root type was recognized, how many unique URLs were accepted, and how many normalized duplicates were removed. First-seen order is preserved, so the output can be lined up against the source XML line by line.
- Copy the complete one-URL-per-line list to the clipboard. From there it can be pasted into a spreadsheet, a crawler checklist, a redirect audit, an analytics landing-page comparison, or any other pipeline that consumes plain URL text.
- Treat the list as evidence, not proof. Run separate live HTTP status, canonical, robots, and indexing checks on the URLs that matter, since extraction only confirms that each location appeared in the pasted structure and passed the tool's disclosed validation.
What the Parser Accepts and Rejects Per Entry
Because bulk extraction is only as trustworthy as its weakest loc, the parser applies a fixed set of rules to every entry. A consistent namespace prefix such as sm:urlset, sm:url, and sm:loc is accepted alongside the default-namespace form, XML declarations and comments are ignored, and optional children such as lastmod never alter the extracted location. Every decoded value then runs through the browser's WHATWG URL implementation, which lowercases the host, removes default ports, and percent-encodes non-ASCII path characters when required.
The table below summarizes what the parser accepts and what it rejects, using the same criteria the tool applies internally.
| Input shape | Result |
|---|---|
| <urlset><url><loc>https://example.com/page</loc></url></urlset> | Accepted: page URL added |
| <sitemapindex><sitemap><loc>https://example.com/sitemap-2.xml</loc></sitemap></sitemapindex> | Accepted: sitemap file URL added, not its pages |
| <urlset> with consistent sm: namespace prefix | Accepted as long as prefix is consistent |
| <urlset> containing no <url> children | |
| <loc> containing nested markup | Rejected — that numbered loc causes failure |
| Unknown XML entity such as © inside loc | Run fails — conservative decoding only |
| <loc>javascript:alert(1)</loc> | Rejected — only HTTP and HTTPS accepted |
| <loc>https://example.com/page#section</loc> | Rejected — fragments disallowed |
| <loc>https://user:[email protected]/</loc> | Rejected — credentials disallowed |
| <image:loc> used to replace a missing page loc | Rejected — extension locations describe a different resource |
According to the WHATWG URL Standard, browser-standard serialization is the only normalization applied, which keeps deduplication predictable. Two locs that serialize to the same string count as one — for example https://Example.com:443/page and https://example.com/page collapse together — and only the first occurrence is kept.
XML declarations and comments are skipped, but a DTD declaration or a custom entity declaration causes the whole run to fail. The parser does not repair malformed XML, does not guess where a missing closing tag belongs, and does not silently skip a problematic loc — every error message names the numbered loc or item so the source can be corrected in place. The Google Search Central sitemap guide treats entity expansion as something production sitemaps should avoid, and rejecting DTDs keeps the widget's behavior small and prevents that risk from leaking into the tool.
Bulk Limits: 50,000 URLs, 5 Million UTF-16 Code Units, and 2,048 Characters per URL
A bulk tool is only honest if its limits are explicit. The Sitemap URL Extractor accepts at most 50,000 unique URLs, at most five million UTF-16 code units of input, and individual serialized URLs shorter than 2,048 characters. Crossing any bound fails the entire operation without truncation — there is no partial output, no warning that hides behind a green checkmark, and no quiet rewrite of the unique count.
These numbers are chosen to match the Sitemaps protocol's documented envelope. A single sitemap file may list up to 50,000 URLs, and uncompressed sitemaps above 50 MB fall outside the protocol's stated ceiling. Five million UTF-16 code units corresponds to roughly 10 MB of UTF-16 input (5,000,000 code units × 2 bytes = 10,000,000 bytes), which gives meaningful headroom for indentation, namespace prefixes, and lastmod values without ever reaching the 50 MB protocol boundary. If a production sitemap is close to either bound, validating the actual uncompressed byte size on disk is the right next step; the tool can confirm only that the pasted text fits, not that the original file does.
For sites that exceed 50,000 page URLs, the standard practice described in the Sitemaps protocol is to split the inventory across multiple sitemap files and reference each one from a sitemap index. That index can itself be extracted by the same tool, producing a clean list of sitemap file URLs to process one at a time. From there, each child file can be obtained, decompressed if necessary, and pasted in separately — the cleanest way to keep an audit traceable when the inventory runs into the hundreds of thousands.
Using the Bulk URL List for Audits and Migrations
A clean one-URL-per-line list is the right shape for almost every downstream SEO workflow. Drop it into a spreadsheet to diff against canonical URLs from your database, paste it into a crawler configuration as the seed list, or feed it into a redirect-mapping table during a domain migration. Comparing the extracted list against analytics landing pages or a previous release is often the fastest way to spot unexpected duplicates, and unexpected duplicates usually point to default-port or host-case variants the browser-standard normalization surfaced rather than to bugs in your sitemap generator.
When the next step is generating a new list rather than auditing an existing one — for example, building a redirect map or staging a fresh URL inventory — a template-driven Bulk URL Generator produces up to 10,000 validated URLs from a single {n} pattern, which complements rather than replaces sitemap extraction. Extraction reads what is already declared; bulk generation writes what needs to be declared next.
It is worth repeating the boundary the tool draws. Extraction confirms that a location appeared in the pasted structure and passed validation. It does not mean the URL is crawlable, canonical, valuable, indexed, or ranked. Sitemaps are discovery hints rather than indexing guarantees, per both the Sitemaps protocol and Google's documentation. Treat the list as evidence in a larger audit, run the live checks that matter for your decision, and reserve any "indexed" claim for the tools and queries that actually prove it.
Related reading: Extract Structured Data in a JSON-LD Checker.
Related reading: Bulk QR Code Generator for Beginners: First Steps.