How to Find a Website’s XML Sitemap

Find advertised and common sitemap locations, verify the response is real XML, and understand what sitemap discovery can and cannot prove.

SharePost on XShare on LinkedIn
Watercolor illustration of cobalt paths converging on a small coral document marker in a cream paper landscape

The short answer

Read the website’s root robots.txt file first and follow each Sitemap declaration. If none is advertised, check a short list of common locations such as /sitemap.xml and /sitemap_index.xml. Verify the final response and XML root instead of trusting the filename or HTTP status alone.

Sitemap Finder showing the Overhyped website URL and live evidence for its advertised working XML sitemap
The focused Sitemap Finder workspace using live Overhyped evidence, captured 30 August 2026. Re-run the check after a deployment to verify the current public response.

An XML sitemap can be published at almost any public URL. /sitemap.xml is common, not mandatory.

That is why sitemap discovery should begin with declared evidence and use common paths only as a bounded fallback.

Start with robots.txt

Request the site’s root /robots.txt file and look for lines beginning with Sitemap:. A declaration should contain a complete public sitemap URL.

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

Google documents robots.txt declarations as one way to make a sitemap available, alongside Search Console submission. A file may contain more than one declaration. See Google’s sitemap submission guidance.

Check a short list of common locations

When robots.txt contains no declaration, a few conventional paths are reasonable to inspect:

  • /sitemap.xml
  • /sitemap_index.xml
  • /sitemap-index.xml

Do not turn this into unlimited path probing. Failing to find a file at these locations does not prove that no sitemap exists.

Verify the response, not the filename

A URL ending in .xml can return a branded HTML error page with HTTP 200. A useful discovery result should record:

  1. The entered website URL.
  2. The location checked.
  3. Whether it came from robots.txt or a common-path fallback.
  4. Redirects and final URL.
  5. Final HTTP status and content type.
  6. Whether the response contains a sitemap root such as <urlset> or <sitemapindex>.

This evidence separates a real XML resource from a soft 404 or an unrelated response.

Finding is not validating

Discovery answers where a sitemap is publicly available. It does not establish that the XML is well formed, that every location is canonical, or that search engines have accepted the file.

Use a separate validator for those questions. Then use Search Console on a verified property when you need Google’s private submission and processing evidence.

A sitemap is a hint, not an indexing result

Google describes sitemap submission as a hint. A discovered or submitted sitemap does not guarantee that it will be fetched or that its URLs will be crawled, indexed, ranked, or displayed.

Small, well-linked sites may not need a sitemap. Larger, newer, media-heavy, or frequently changing sites often benefit more from one. See Google’s sitemap overview.

A safe discovery workflow

  1. Normalize the website to its public origin.
  2. Fetch root robots.txt through guarded public-only networking.
  3. Record every valid Sitemap declaration.
  4. Check those declarations first.
  5. Check only a bounded fallback list when useful.
  6. Confirm final response and XML evidence.
  7. Validate the discovered file separately.
  8. Record the limits of the discovery method.

Use the free Sitemap Finder to inspect declared and common locations with visible response evidence.

Method note: the tool checks root robots.txt and three bounded common locations. It does not brute-force paths or inspect private Search Console data. Last reviewed 30 August 2026.

Continue learning

Keep moving with a closely related topic and a free tool you can use immediately.

Watercolor illustration of a cobalt link path meeting one coral break while other paths fade behind cream mist

Broken Link Versus Unavailable Response

Distinguish confirmed HTTP errors from redirects, timeouts, bot blocks, and temporary failures before removing or changing useful page links.

Watercolor illustration of cobalt content cards connected by clear coral paths across textured cream paper

What a Useful Internal Link Tells People and Search Engines

Review crawlable internal links, descriptive anchor text, destination intent, and page-level evidence without pretending one page reveals a whole site architecture.

Watercolor illustration of nested cobalt paper steps forming a clear hierarchy with one coral focal mark

Headings Are Document Structure, Not a Keyword Checklist

Review H1–H6 headings as an ordered document outline for people and assistive technology without inventing rigid SEO penalties or keyword rules.