A website sitemap XML is a standards-shaped XML document that lists the page URLs a site owner wants crawlers to know about — or, in its index form, the locations of other sitemap files — and getting one usually means either locating the file at a well-known path or copying the XML text from a URL you already trust. The actual file is plain text in either case, which is what makes it easy to handle on a laptop without a server, a deployment pipeline, or a live crawl.
Once the XML is in hand, the next step is to do something useful with it. A raw sitemap.xml file is rarely the deliverable on its own. Most workflows want a clean, deduplicated, one-URL-per-line list of pages that can be pasted into a spreadsheet, a crawler checklist, a redirect audit, a log comparison, or a release review. Converting the markup into that list is the job of a small browser-based tool, not a server call, and that is exactly what the Sitemap URL Extractor is built for.
The whole conversion runs locally. You paste the complete XML text from one urlset or sitemapindex document into the editor, run the extraction, and the tool returns the direct loc values as a deduplicated, ordered list — without uploading the file or following any link it discovers. From there you can hand the list off to a status checker, a canonical reviewer, a robots auditor, or a search-console pull.
Inside the XML: urlset and sitemapindex
Two structures are defined by the sitemaps protocol, and the choice between them shapes everything downstream. The urlset form is a flat list of page entries; each <url> element contains a direct <loc> child holding an absolute HTTP or HTTPS URL. The sitemapindex form is a directory of sitemap files rather than a recursive bundle of pages, where each <sitemap> entry contains a direct <loc> pointing at another sitemap XML document. Both forms may use the default namespace or a consistent prefix such as sm:urlset, sm:url, and sm:loc.
XML declarations such as <?xml version="1.0" encoding="UTF-8"?> and any comments are ignored. Optional children like <lastmod>, <changefreq>, and <priority> do not alter the extracted location. Extension locations such as <image:loc> are not substituted for a missing page loc, because they describe a different resource role. Knowing which root you are dealing with is the first piece of evidence the extractor reports, and it usually answers the question "what is this file supposed to contain".
Common places the sitemap XML lives on a site
Most sites place their sitemap at a small set of well-known paths. The protocol does not mandate a name, but /sitemap.xml is the de facto default and the first place to check. Larger sites split content into multiple files and expose a master index at /sitemap_index.xml or /sitemap-index.xml. Common CMS conventions add a platform prefix: WordPress commonly publishes /wp-sitemap.xml after version 5.5, Shopware exposes /sitemap/shop_index.xml, and many static-site generators default to /sitemap.xml at the site root.
If the obvious paths return a 404, the second place to look is /robots.txt. The Sitemaps protocol allows a site to declare one or more sitemap locations there with a line such as Sitemap: https://example.com/sitemap.xml. Search engines also look for an HTTP Link response header with rel="sitemap", though this is less common than the robots.txt reference. Cloudflare-fronted sites often rewrite one of these paths through a worker or a page rule, so the file may live on a slightly different URL than the one implied by the CMS.
When the file is not reachable, the next-best source is the CMS export, the build artifact, or the staging deployment that produced the public file. Compression makes a difference: the protocol admits .gz sitemaps, and many tools serve only the compressed form. Decompressing sitemap.xml.gz outside the extractor is part of the work of converting the sitemap XML into plain text. Anyone running the workflow the other way around — turning a reviewed URL list back into XML — can use the XML Sitemap Generator to produce a standards-shaped document without crawling the live site.
Paste a sitemap XML into the Sitemap URL Extractor
- Paste the complete XML text from one urlset or sitemapindex document into the editor. XML declarations and comments are ignored, and only the direct <loc> values found under each <url> or <sitemap> entry are considered.
- Run the extraction. The result reports which root type was detected, how many unique URLs were accepted after normalization, how many duplicates were removed, and the complete deduplicated list preserved in first-seen order.
- Copy the one-URL-per-line list to the clipboard using the built-in copy control, then route that list to separate live-status, canonical, robots, and indexing checks.
What the extraction result tells you
Three pieces of evidence appear at the top of every successful run. The detected root type confirms whether the paste was a urlset page list or a sitemapindex directory; surfacing this up front prevents the common surprise of treating sitemap-file URLs as page URLs. The unique count is the number of serialized URLs that survived deduplication, and the duplicate count is how many loc values were removed because they normalized to a value already seen earlier in the document.
Duplicates are usually a clue rather than a failure. Default-port or host-case variants such as https://Example.com:443/page and https://example.com/page collapse to the same value because the extractor uses the browser's WHATWG URL implementation to normalize each loc. Tracking those duplicates in a separate column during a spreadsheet review often reveals canonicalization gaps that show up again in the crawler report. The WHATWG URL standard is the underlying reference for how hosts are lowercased, default ports are stripped, and non-ASCII path characters are percent-encoded.
A single-source failure case matters here: when the input crosses the 50,000 unique-URL bound or the five-million UTF-16 code-unit input bound, the entire run fails instead of returning a truncated list. This is intentional, because a partial list mistaken for a complete one is a worse outcome than a clear "run again with a smaller file" message. Google Search Central — Build and submit a sitemap describes the file-size and split-via-index conventions that sit behind that limit.
What the extractor checks vs. what still needs a live verification
The extractor is strict about parsing and lenient about assumptions. It guarantees the XML shape and the loc values are sane, but it does not draw conclusions about how the live site behaves. The split is worth memorizing before the list goes into an audit spreadsheet.
| Concern | Handled by the extractor | Needs a live-site check |
|---|---|---|
| Valid urlset / sitemapindex structure | Yes | — |
| Five predefined XML entities and valid numeric references decoded | Yes | — |
| Absolute HTTP/HTTPS loc values only, under 2,048 characters | Yes | — |
| Deduplication on normalized href values | Yes — first occurrence kept | — |
| 50,000 unique URLs / 5M UTF-16 code units cap | Yes — fails the whole run | — |
| Decompression of .gz sitemaps | No | Yes — decode outside the tool |
| Recursive fetch of sitemapindex children | No | Yes — fetch each child file separately |
| HTTP status, redirects, canonical tags | No | Yes |
| robots.txt and meta robots directives | No | Yes |
| Actual search-engine indexation | No | Yes |
Reading this table is the fastest way to set expectations inside a team. The extractor answers "is the XML valid and what does it list" while everything in the right-hand column answers "does the live URL behave the way the sitemap implies".
Limits worth knowing before you paste
The protocol caps each sitemap at 50,000 URLs and 50 MB uncompressed; large sites split content well below those numbers and reference child files from a sitemapindex. Crossing the extractor's 50,000 unique-URL bound fails the run, so splitting a large file into an index with smaller children is the usual workaround. Anything over the bound should be packaged as an index before re-running.
The parser is deliberately strict about a small set of edge cases. DTD declarations, custom entity declarations, nested markup inside <loc>, unknown XML entities, and incomplete items cause the extraction to fail with a numbered reference to the offending location. Rejection is intentional: presenting a partial list as complete would be worse than asking the user to fix the source. Malformed XML or a missing closing tag is not repaired — the tool refuses to guess where a tag belongs. Credentials, URL fragments, relative paths, non-HTTP schemes, and backslashes are all rejected on the loc side as well, and any decoded loc longer than 2,048 characters fails.
A parse error usually points at one of two places. Either the file starts with the wrong root — someone pasted an RSS feed, a tracking pixel list, or a search-results page — or it mixes namespace prefixes inconsistently (using sm:url for most entries and <url> for one of them, for example). Fixing those before re-running is faster than toggling tool options, and the location hint is precise enough to drive a search-and-replace pass in the source document.
Putting the list to use
Once the deduplicated list is on the clipboard, the work shifts to live-site evidence. The four checks the extractor does not run — status codes, canonical tags, robots directives, and indexing status — each need their own tool, and each answers a different audit question.
- Status codes catch accidental 404s, soft 404s, and redirect chains that add a hop the sitemap did not mention. Run them against the extracted list rather than against an internal database to surface whatever users actually see.
- Canonical tags confirm whether the URL the sitemap points at is the URL the page declares as itself. A mismatch between the two is one of the more common indexation bugs in mid-sized sites.
- robots.txt and meta robots directives can quietly block a URL even when it is present in the sitemap. Pairing the list with a separate robots check reveals those blocked entries without ambiguity.
- Index coverage from the search console names the URLs the search engine actually has in its index. Comparing this against the sitemap list finds both orphan pages and over-promised files.
A sitemap XML proves only that a URL appeared in the structure and passed the extractor's disclosed validations; it does not prove indexation, ranking, canonicalization, or crawlability. Treat the extracted list as one column in a broader audit spreadsheet, anchor it to evidence from a live crawler where the decision matters, and revisit it whenever the staging inventory changes — prelaunch URL inventories stay on the device unless they are copied out, because the entire workflow is client-only.