The fastest way to find every URL listed inside an XML sitemap is to paste the full sitemap text into a browser-based extractor, which reads the loc elements and returns a clean one-URL-per-line list. Sitemap files follow the XML protocol defined at sitemaps.org and contain either a urlset wrapper around repeated url/loc pairs (one entry per page) or a sitemapindex wrapper around repeated sitemap/loc pairs (one entry per child sitemap file). Loc is short for "location," and it is the single child element that holds the absolute URL of a page in a urlset or the absolute URL of a child sitemap file in an index. Everything else inside an entry — lastmod, changefreq, priority, image:loc — is optional metadata that never replaces the loc value. Knowing this structure up front turns "how to find sitemap URL" from a guess into a deliberate parsing job with a known input shape, a known output shape, and a clear line between what a tool can answer and what only a live fetch can.
Two Meanings of "Find Sitemap URL"
Most people searching this phrase want one of two things. The first meaning is "where is my sitemap file?" — that lives at a guessable path such as /sitemap.xml or /sitemap_index.xml, and it is a configuration question rather than a parsing question. The second meaning is "what URLs are listed inside the sitemap file I already have?" — that is a parsing question, and it is the job the Sitemap URL Extractor is built for.
If you only need the first answer, the extractor is overkill. Open your site's robots.txt and look for a Sitemap: line, or check the CMS settings for the path the platform generated. If you need the second answer, you already have the XML in front of you and want every loc turned into a plain, copyable list — without writing a regex, opening a spreadsheet, or uploading the file anywhere.
Why Hand-Parsing Sitemap XML Goes Wrong Quickly
A typical sitemap looks harmless at a glance: a wrapper tag, repeated url blocks, each with a single loc child. The trap is that XML has edge cases the casual reader skips. Sitemaps can carry a namespace prefix such as sm:urlset, sm:url, and sm:loc, and any parser must accept the prefixed form and the default-namespace form interchangeably. Comments and XML declarations need to be discarded without throwing off the loc counter. lastmod and changefreq can appear before or after loc inside a single url element, and the parser must not mistake them for the location.
Image extensions place an image:loc inside an image:image block that is nested inside url — that loc describes an image resource, not the page, and an extractor must ignore it when the page loc is also present. Unknown entities, malformed numeric character references, DTD declarations, and missing closing tags also break the file outright. Any of these trips up a naive regex, a grep one-liner, or a spreadsheet import that treats the file as plain text. A purpose-built extractor handles these cases by design, which is why it is the safer place to hand the work.
How to Get a Clean URL List From Any Sitemap
- Open the Sitemap URL Extractor in your browser and clear any sample text from the editor.
- Paste the complete XML contents of one urlset or one sitemapindex file into the editor. Do not paste a remote URL — the widget makes no network request and only reads what is on your clipboard.
- Run the extraction. The result panel reports which root type was found (urlset or sitemapindex), how many unique URLs were accepted, and how many duplicates were removed.
- Review the complete output: one absolute HTTP or HTTPS URL per line, in the order the URLs first appeared in the source.
- Copy the list with the copy button and paste it into a spreadsheet, crawl checklist, redirect audit sheet, or migration comparison document.
- For sitemapindex input, repeat the process for each child sitemap file the list names — the extractor returns the file locations, not the page URLs inside them.
| Aspect | urlset | sitemapindex |
|---|---|---|
| Wrapper element | <urlset> | <sitemapindex> |
| Repeated item | <url> | <sitemap> |
| Required child | <loc> (page URL) | <loc> (child sitemap file URL) |
| Common optional children | lastmod, changefreq, priority, image extensions | lastmod |
| What the extractor returns | Absolute page URLs | Absolute child sitemap file URLs |
| Need to fetch children? | No, the listing is final | Yes, each child file must be processed separately |
What the Output Tells You About Your Sitemap
Three numbers matter when you read the result panel. The root type confirms whether you pasted the right kind of file — a urlset holds page URLs, a sitemapindex holds child sitemap file URLs, and confusing the two is a common audit mistake. The unique count is the size of your working list and the number to compare against expectations: if your CMS reports 4,200 published pages and the extractor returns 4,200 URLs, the sitemap and the database agree; a wide gap is the starting point for an investigation.
The duplicate count is the normalized-duplicate tally. Hosts are lowercased, default ports are stripped, non-ASCII path characters are percent-encoded, and URLs that serialize to the same value count as one. Browser-level normalization follows the WHATWG URL Standard, so https://example.com:443/foo and https://Example.com/foo collapse into a single entry. A non-zero duplicate count is often the first evidence of a default-port variant or a host-case inconsistency in the generator, and fixing the generator is usually cheaper than re-uploading the file.
What the Tool Intentionally Does Not Do
The output is a list of locations that appeared in the XML and passed the extractor's validation. It is not proof that those pages are crawlable, canonical, indexed, or ranked. The sitemaps protocol describes sitemaps as discovery hints for crawlers, not as indexing guarantees — per Google's sitemap documentation, a submitted file is a request for crawl attention, not a promise of inclusion in search results.
Status codes, redirect chains, canonical-tag selection, robots directives, noindex meta tags, page content, ownership, and whether a search engine accepted the source file are all separate live-site checks the extractor does not perform. Use the list as evidence in a larger audit, then run those checks against the URLs themselves with a crawler, your analytics, or your search-console exports.
| Concern | Covered by extractor? | What to use instead |
|---|---|---|
| Count of locs in the sitemap | Yes | — |
| Detect duplicates after normalization | Yes | — |
| Validate absolute HTTP/HTTPS URL form | Yes | — |
| Check HTTP status or redirect chain | No | Crawler or live HTTP request |
| Verify canonical tag selection | No | Page-level inspection |
| Check robots or noindex directives | No | Robots check plus meta tag inspection |
| Confirm a search engine accepted the file | No | Search Console sitemap report |
Reading the Parser Error When a Run Fails
The extractor fails the whole run rather than returning a partial list, and the error message is numbered to point at the specific loc or item that caused the failure. Most failures come from a handful of structural problems. A DTD declaration at the top of the file is rejected because the widget refuses to expand custom entities — decompress and strip the DTD outside the tool if you control the source. A missing closing tag on the root or on any url or sitemap item fails the run instead of guessing where the tag belongs. An unknown entity, a nested tag inside loc, or an invalid numeric character reference fails the same way.
Credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and any scheme other than http or https are rejected at the URL step. Inputs above 5,000,000 UTF-16 code units or 50,000 unique URLs also fail by design rather than truncate. Correct the named item and re-run rather than relying on a partial result, because a partial result is the worst possible outcome for an audit.
Privacy, Limits, and Where the Output Goes
Parsing happens entirely in the browser, so a private staging sitemap or a prelaunch URL inventory stays on your device unless you copy it elsewhere. Pasting a remote URL into the editor does not download anything; only the XML text you paste is parsed. Compressed .gz data must be decompressed before pasting because the widget does not inflate archives.
URLs longer than 2,048 characters are rejected to match the protocol's loc constraint, and the maximum of 50,000 unique entries means a very large sitemap index needs to be split across multiple pastes — one for the index, one for each child file it names. Treat the output as the input to a comparison step: line it up against the canonical URLs in your CMS, your last crawl, or your previous release, and the differences become the audit list. Readers handling many child files at once may want a companion workflow for extracting every URL from a website sitemap end to end.