Vutral
How to use this tool

XML Sitemap Finder & URL Extractor

How to use the XML sitemap finder

Back to the tool

A domain goes in; what comes back is every sitemap file the site declares, and the URLs inside any file you open.

  1. 01

    Enter a domain or a sitemap address

    A domain is the usual way in: we read robots.txt, then the standard locations on the host root. Paste an address ending in .xml or .xml.gz instead and that exact file becomes the root of the tree, useful when the sitemap sits somewhere robots.txt never mentions. The path of an ordinary page is ignored; only its host is used.

  2. 02

    Read the tree of files

    The scan reads robots.txt, then fetches the files it names: the top level, and only that. Files a sitemap index declares are listed straight from the index body, address and Last modified included, but nothing is fetched for them yet; that is what the Check button on their row is for. Ten requests answer the question most people came with.

  3. 03

    Check a file to read its contents

    Check fetches that one file: one click, one request. A URL set opens its page URLs and their Last modified dates. An index adds its children to the tree as new rows. An unreadable file says why, and its button becomes Retry. Check all runs the same check down every waiting row and stops the moment the rate limit answers.

  4. 04

    Export the list

    Copy table and Export CSV take the table as it stands: every file row, plus the page URLs of any file you have opened. Five columns carry the tree into a spreadsheet: Level says whether a row is a sitemap or a page URL; then the address; then Parent sitemap, the file that declared it; then Last modified; then Result, how the file itself answered — blank on page rows, which this tool never fetches.

How to read the sitemap tree report

Every row is one sitemap file, or one page URL inside one. A row stays silent while nothing is wrong, so anything written beside an address is worth reading. Ceilings are announced in the table, never applied quietly: a hundred files per scan, three hundred rows, 5,000 URLs shown per file, 10 MB per file.

Row status notes

No note, next to Check
Not fetched yet. An index declared this file, but the scan stops at the top level on purpose: fetching every child of every index costs a request each and answers a question you may not have asked.
No note, next to View
The file was read and nothing was wrong with it. Press View to see what is inside: page URLs for a URL set, or new child rows if it turns out to be another index.
404, 503, Timeout
The file could not be read. A file an index declares but does not serve is a real finding: search engines get the same answer you did. The button becomes Retry, which asks again.
Not a sitemap (html)
The server answered 200 but sent a web page. Usually a soft 404, sometimes a block page. Worth fixing either way; from a browser it looks fine.
Over 10 MB — not parsed
Past our size ceiling, measured after decompression. We do not parse what we could only read half of: a truncated XML file is a broken XML file, and a partial URL list that looks complete is worse than none.

Tree columns

Index Lv1, Sitemap Lv2, URL
The Level column holds the tree: indent, the ↳ arrow for a file declared by a row above, and the level. Index lists other sitemaps; Sitemap is a file not yet read; URL is a page in the file above.
A date in Last modified
The lastmod the parent index declares for this file. It costs nothing to read and is often the reason to be here: it says which branch of the site changed recently. It is the site’s own claim, not a measurement.
A dash in Last modified
Nothing declared a date for this file. Top-level files usually sit here, since nothing above them declares anything about them. It says nothing about whether the file is stale.
A row with no button
An index whose children are already in the tree. There is nothing left to fetch for it; read its children instead.