A sitemap URL extraction is the process of pulling every <loc> value out of a standard sitemap.xml or sitemapindex XML document and turning it into a plain, deduplicated list of URLs you can sort, paste into a spreadsheet, or hand to a crawler. The XML itself is a hint file in a machine-readable format, not a human-readable index — so converting it into one URL per line is usually the first step before any analysis, audit, or migration work. The Sitemap URL Extractor does exactly this: paste the XML text, get back a clean list with the duplicates already removed. The tool does not connect to the website, does not crawl it, and does not download the file. You copy or save the XML text yourself, then paste it into the editor. Everything happens in the browser, which keeps private staging sitemaps, prelaunch URL inventories, and unreleased redirects off any third-party server while you work.
What the tool actually parses
The Sitemap URL Extractor recognizes two structures from the Sitemaps XML protocol: a urlset (a list of page locations) and a sitemapindex (a list of sitemap file locations). For a urlset, each <url> entry is expected to contain a direct <loc> child whose text is the page URL. For a sitemapindex, each <sitemap> entry is expected to contain a direct <loc> child whose text is the URL of another sitemap file.
The parser is intentionally strict. It ignores XML declarations and comments, accepts a consistent namespace prefix such as sm:urlset, sm:url, and sm:loc as well as the default namespace form, and decodes only the five built-in XML entities plus valid decimal or hexadecimal numeric character references. Unknown entities, DTD declarations, custom entity declarations, nested markup inside <loc>, and malformed roots cause the extraction to fail rather than silently return a partial list. This is by design: rejecting DTDs keeps the parsing behavior small and predictable and prevents entity expansion from turning into hidden product logic.
What the tool does not do
This is the part most readers get wrong, so it is worth spelling out. The Sitemap URL Extractor does not fetch the sitemap from a URL. It does not download anything, decompress .gz files, or follow redirects. If you want to read a sitemap index, the tool returns only the direct sitemap file locations it lists — each child file has to be obtained and processed separately.
It also does not check whether a page is crawled, canonical, indexed, or ranked. Per the Sitemaps protocol and Google's own documentation, a sitemap is a discovery hint, not an indexing guarantee. Extraction only proves that a valid <loc> appeared in the pasted XML and passed the tool's validation. Crawl status, canonical selection, noindex directives, robots rules, and search-engine acceptance are separate live-site checks that you run after the list is in hand.
Extract a sitemap URL list in your browser
The full workflow fits into three repeatable steps. Treat each one as a deliberate handoff so the result is verifiable rather than magical.
- Paste the complete XML text from one urlset or sitemapindex document into the editor. Open the source file in any text editor, select everything from the opening root tag to the closing root tag, and copy. If the source is a .gz archive, decompress it first; compressed bytes cannot be read as XML text.
- Extract the direct loc values and review the root type, unique count, duplicate count, and complete output. The reported root type tells you which structure was detected; the counts tell you whether normalization removed anything; the complete output is the canonical answer.
- Copy the one-URL-per-line list, then perform separate live status, canonical, robots, and indexing checks as needed. Use the list as evidence in a larger audit rather than as proof of indexation.
Why two different sitemap structures exist
The distinction between urlset and sitemapindex is one of the most common sources of confusion when working with real-world sitemaps. The table below summarizes what each one contains and what the extractor returns for it.
| Root type | What the document contains | What the tool returns | Limit applied |
|---|---|---|---|
| urlset | A flat list of <url> entries, each with a <loc> and optional metadata like lastmod, changefreq, priority | The direct page URL from each <loc> | Up to 50,000 unique URLs |
| sitemapindex | A directory of <sitemap> entries, each with a <loc> pointing to another sitemap file | The direct sitemap file URL from each <loc> | Up to 50,000 unique entries; child files are not fetched |
Both forms go through the same URL normalization: hosts are lowercased and validated, default ports are removed, non-ASCII path characters are percent-encoded when required, and credentials, fragments, raw whitespace, malformed percent escapes, backslashes, and relative paths are rejected. Serialized duplicates are deduplicated in first-seen order. Anything that fails validation stops the whole run instead of producing a partial answer — partial answers are worse than no answer when the result is feeding an audit.
Why the parser fails fast instead of guessing
A sitemap parser that guesses is a sitemap parser that hides bugs. If a <loc> is missing inside an item, if the root is incomplete, if a numeric character reference points outside the valid Unicode range, or if the input exceeds the 50,000 unique URL cap or the five-million UTF-16 code-unit input cap, the entire operation fails. The browser URL standard, which is what the parser uses to normalize each <loc>, expects absolute HTTP or HTTPS URLs shorter than 2,048 characters — that length matches the protocol's own loc constraint.
The parser is specific about which <loc> or item caused the failure so the source can be corrected instead of silently skipped. This is the practical difference between a verifier and a converter: a converter would happily return the entries it could read; a verifier tells you that the document is broken and where. For large or production sitemaps, that distinction is the difference between an audit you can trust and an audit built on assumptions.
What to do with the extracted list
Once the URLs are in one-URL-per-line form, they are ready for the operations that originally motivated the search. The most common uses include:
- A crawler checklist during a migration: paste the list into your crawler or staging validator and compare it against the URLs the new environment actually serves.
- A redirect audit: cross-check the list against the redirect map, looking for missing 301s, chains, or stale destinations.
- A spreadsheet import: each row becomes a record you can annotate with status code, canonical, indexability, and lastmod.
- A log-file comparison: load the list into a log analysis tool to see how often crawlers actually request each URL.
- A canonical review: compare the list against canonical URLs from your database, your analytics landing pages, and the previous release to spot duplicates and host-case variants.
For each of these, the extracted list is the source of truth for what the sitemap claims, and the live check is the source of truth for what the website does. Mixing those two roles is how audit reports quietly become wrong. The Sitemaps protocol and the Google documentation both describe sitemaps as discovery hints — extraction confirms only that a location appeared in the pasted structure and passed the tool's disclosed validation. It does not mean the URL is crawlable, canonical, valuable, indexed, or ranked.
Limits worth knowing before you paste
A few operational boundaries shape what kind of input the tool will accept. The parser accepts at most 50,000 unique URLs and five million UTF-16 input code units. Crossing either bound fails without truncation. Every decoded <loc> must be an absolute HTTP or HTTPS URL with fewer than 2,048 characters. Credentials, malformed escapes, raw whitespace, fragments, and non-HTTP schemes are rejected. Compressed .gz data must be decompressed outside the tool before use. And pasting a remote URL into the editor does not download anything; the widget only reads text you paste.
If a production sitemap is close to the protocol limits, validate the actual uncompressed byte size on disk and consider splitting it into smaller files referenced by a sitemap index. The Sitemaps protocol caps sitemap files at 50,000 URLs and 50 MB uncompressed for a reason. Splitting also reduces the blast radius if a single file becomes invalid — only that file's entries fail the parser, not the rest of the site's coverage.