Extracting a URL from a sitemap means parsing the XML document that search engines treat as a discovery hint, reading each loc element inside a urlset or sitemapindex structure, and producing a clean one-URL-per-line list you can paste into a crawler checklist, spreadsheet, or redirect audit. The output is the direct location values declared in the source file, normalized through a browser-standard URL parser so duplicates caused by capitalization, default ports, or stray whitespace collapse into a single line. A correctly built Sitemap URL Extractor runs entirely in the browser: nothing is uploaded, the XML never leaves the device, and the result reflects whatever the pasted document actually contained. Extraction is a structural operation, not a search-engine signal. A line in the output means a valid absolute HTTP or HTTPS address appeared inside the XML and passed the parser's validation rules; it does not mean the page is crawled, canonical, indexed, or ranked.
What "extracting a URL" from a sitemap actually returns
A sitemap file is one of two shapes defined by the Sitemaps XML protocol. A urlset wraps individual url entries, and each url must contain a direct loc child carrying an absolute web address. A sitemapindex does not list pages at all; it wraps sitemap entries, each of which carries a direct loc pointing to another sitemap file. When you ask a parser to extract URLs from either shape, you are asking it to read those direct loc values, decode the standard XML entities, ignore the optional children like lastmod, and emit each address as its own line.
That distinction matters when comparing results. Paste a urlset and the output is a list of page URLs. Paste a sitemapindex and the output is a list of sitemap file URLs, which the parser does not fetch or expand. The protocol treats a sitemap index as a directory, not a recursive bundle, so the page URLs sitting inside each child file require a separate extraction pass per file. Readers who need to walk through every level of a nested index can follow the workflow outlined in the guide on extracting every URL from a website sitemap.
A reliable extractor also reports what it found: which root type it recognized, how many unique URLs were accepted, and how many normalized duplicates were removed. That metadata is more useful than a raw count, because duplicate removal is a side effect of normalization rather than a sign that the source had intentional duplicates.
Why extraction alone is not an indexation check
The Sitemaps protocol describes sitemap files as discovery hints, not indexing guarantees. The page only enters a search engine's queue after a separate crawl, and the search engine may still skip it if the URL returns a non-success status, is blocked by robots, carries a conflicting canonical, or is filtered for low quality. Pulling a URL out of a sitemap proves that the location was declared in the source file; it does not prove that the page can be reached, that the page is the canonical version, or that any search engine has accepted it.
According to Google Search Central documentation on building a sitemap, a URL appearing in a valid sitemap is a request for crawling, not a confirmation of indexation. Live checks — an HTTP HEAD request for status, a page-source inspection for canonical tags, a robots lookup, a Search Console URL Inspection, or a site: search — are what actually answer those questions.
Treat the extracted list as evidence in a larger audit. Cross-reference it against canonical URLs from the database, against crawl results, against analytics landing pages, or against a previous release. Unexpected duplicates often reveal host-case variants, default-port entries, or trailing-slash inconsistencies; unexpected gaps often reveal pages that the sitemap author forgot to include or that have been removed from the site since the file was generated.
How to extract URLs from a sitemap XML
- Open the sitemap source in a plain text editor. Copy the complete contents, including the XML declaration if it is present. If the file is distributed as .gz, decompress it first — the editor only reads XML text and does not handle compressed input.
- Paste the XML into the editor of the Sitemap URL Extractor. The widget makes no network request, so pasting a remote URL into the box does not download anything.
- Run the extraction. Review the reported root type (urlset or sitemapindex), the unique URL count, the duplicate count removed, and the full output preview.
- Copy the one-URL-per-line list with the copy button. First-seen order is preserved, so the output stays easy to compare with the original source.
- Run separate live status, canonical, robots, and indexing checks on the URLs that matter for the audit. The extractor stops at the structural layer; it does not test crawlability.
Rules the extractor enforces on each loc
Every accepted loc must be an absolute HTTP or HTTPS URL. The WHATWG URL Standard governs how the parser serializes each value: the host is lowercased and validated, default ports are stripped, non-ASCII path characters are percent-encoded when required, and raw whitespace, malformed percent escapes, and backslashes cause rejection. URLs that serialize to the same value collapse to a single output line; only the first occurrence is kept.
Several forms that look like URLs are intentionally rejected:
- Fragments (anything after #) — they identify a sub-resource, not the page.
- Userinfo (user:pass@host) — credentials inside a sitemap are almost always a leak or a mistake.
- ftp://, mailto:, javascript:, tel: and other schemes — a sitemap only describes HTTP/HTTPS resources.
- Relative paths (/page or page.html) — the protocol requires absolute locations.
- Strings over 2,048 characters — matching the protocol's loc constraint, anything longer fails the whole run.
The parser also rejects DTD declarations and custom entity declarations to keep the widget's behavior small and predictable. Unknown XML entities, nested markup inside a loc, invalid Unicode scalar values, and missing closing tags cause the extraction to fail rather than producing a partial list. Optional children such as lastmod or priority do not alter the extracted location; extension tags such as image:loc are not substituted for a missing page loc, because they describe a different resource role.
Limits on sitemap size and URL count
The widget accepts at most 50,000 unique URLs and five million UTF-16 input code units per run. Crossing either bound fails without truncation. That mirrors the Sitemaps protocol's own caps: a single sitemap file is allowed up to 50,000 URLs and, after uncompressing, 50 MB. If a production sitemap sits close to those limits, validate the actual uncompressed byte size and consider splitting it into smaller files referenced by a sitemap index.
Large sitemaps also have a habit of containing normalized duplicates: the same page listed once with HTTPS and again with HTTP, once with a trailing slash and once without, or once with an explicit :443 port and once without. A well-built extractor removes those silently and reports the duplicate count, which is often the first signal that the source file needs cleaning rather than the tool needing adjustment.
Compressed input, by design, is handled outside the widget. Gunzip the .gz sitemap on disk first, paste the resulting XML, and keep the original archive as evidence for the audit.
Using the extracted list for downstream audits
Once you have a clean list, the next move depends on what you are auditing. For a redirect review, paste the list into a status checker and compare HTTP 200 rows against a previous crawl. For a migration, diff the old list against the new list and chase every URL that disappeared into a 301 or a 410. For a crawl-budget review, compare the list against the URLs that Googlebot actually requested in server logs and look for the gap.
| Question | Answered by URL extraction? |
|---|---|
| Did the source XML contain a valid loc for this URL? | Yes |
| Did two entries normalize to the same address? | Yes (reported as duplicate) |
| Is the URL reachable today (HTTP status, redirects)? | No — separate live check |
| Is this the canonical version of the page? | No — page-source inspection |
| Is the URL blocked by robots.txt? | No — robots rule lookup |
| Has a search engine indexed the page? | No — Search Console or site: query |
| Does the page rank for anything? | No — ranking report |
Because the widget is client-only, private staging locations and prelaunch URL inventories stay on the device unless the user copies them elsewhere. That makes the extraction step safe to run against internal sitemaps, but the downstream checks still need to happen against the live site or against a controlled environment that can resolve those hosts.