Locate and validate your XML sitemap: discovery, structure, URL count, HTTPS consistency and the live status of every URL it lists.
Everything else is optional or ignored.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">1
<url>
<loc>https://site.com/shoes/</loc>2
<lastmod>2026-09-28</lastmod>3
<priority>0.8</priority>4
</url>
</urlset>
Anything that redirects, errors, is noindexed or isn't canonical sends a mixed signal. The checker flags each one. Illustrative counts:
Big sites use a sitemap index that lists child sitemaps. The checker follows the index and validates every child. Illustrative structure:
List it in robots.txt so every crawler can find it, and submit it in Search Console to see processing errors.
Kalenux User-agent: *Disallow: /cart/Sitemap: https://site.com/sitemap_index.xmlAn absolute URL on its own line. Read by every major crawler.Publishing the file does nothing on its own. There are two ways that still work and one that no longer does, and the difference matters most when a tutorial tells you to use the third.
Indexing › Sitemaps
https://site.com/sitemap.xml
→ Success · 1,284 discovered
The only method that tells you what Google made of it: how many URLs it read, when it last fetched the file, and which entries it could not parse. Submit once; Google rechecks on its own schedule.
User-agent: *
Sitemap: https://site.com/sitemap.xml
An absolute URL on its own line, anywhere in the file. Bing and the others read this too, so it is the one line worth adding even if you have already submitted in Search Console.
GET /ping?sitemap=…
→ deprecated by Google in 2023
Google removed the unauthenticated ping, so scripts that still call it achieve nothing. If a tutorial tells you to hit this URL after every deploy, the tutorial is out of date.
Submitting does not make Google index anything. A sitemap is a hint about which URLs exist and are worth crawling, not a request to index them, and a URL listed there can still be skipped on its own merits.
What the search engines document about each check this tool runs, with every claim linked to its source.
A single file may hold up to 50,000 URLs or 50 MB uncompressed [1][2]. Google ignores <priority> and <changefreq> entirely, so time spent tuning them is wasted [2].
<loc> always, <lastmod> when you genuinely track it. Drop priority and changefreq rather than maintaining values nothing reads.<?xml version="1.0" encoding="UTF-8"?>Only
<urlset xmlns="http://www.sitemaps.org
/schemas/sitemap/0.9">
<url>
<loc>https://site.com/page</loc>
</url>
</urlset>
<loc> is required, and it must be a fully qualified absolute URL [1].<priority>0.8</priority> → ignoredTwo of the four optional tags do nothing at Google. The third only helps when it is accurate.
<changefreq>daily</changefreq> → ignored
<lastmod>2026-10-01</lastmod> → used
Google generally shows canonical URLs in results, and the sitemap is one of the signals it uses to choose one [2]. Listing a URL that redirects, 404s or carries a noindex sends the opposite message.
noindex or a redirect can never appear in it. A generator that crawls and lists whatever it finds will not do this.<loc>https://site.com/old</loc>Each one spends crawl budget proving the file wrong.
→ 301 to /new
<loc>https://site.com/tag/x</loc>
→ carries noindex
<loc>https://site.com/gone</loc>
→ 404
• returns 200A file listing only indexable URLs is a far stronger signal than one listing everything [2].
• self-referencing canonical
• no noindex, not disallowed
• a page you would link to yourself
Google uses <lastmod> when it is consistently accurate and ignores the field entirely when it is not [4]. A nightly build that stamps today on all 10,000 URLs trains it to disregard yours.
<lastmod>2026-10-26</lastmod>Identical dates across the whole file say nothing about which page changed.
<lastmod>2026-10-26</lastmod>
<lastmod>2026-10-26</lastmod>
→ every URL, every night
<lastmod>2026-10-24T09:12:00+03:00</lastmod>W3C datetime format, and spread across real editing history [1].
<lastmod>2026-03-02</lastmod>
<lastmod>2025-11-18</lastmod>
A Sitemap: line in robots.txt is read by every crawler that reads robots.txt [5], and Search Console submission tells you what Google made of the file [3]. The unauthenticated ping endpoint was retired and now returns 404 [4].
User-agent: *Anywhere in the file, on its own line, with the full URL including the scheme [5].
Disallow: /admin/
Sitemap: https://site.com/sitemap.xml
/sitemap.xml → covers the whole siteA sitemap affects only URLs at or below its own directory, which is why the root is the place to put it [2].
/shop/sitemap.xml → covers /shop/ only
Past 50,000 URLs or 50 MB you split the file and list the parts in an index [1]. Nesting an index inside another index is not allowed, and gzip compression counts against the 50 MB uncompressed, not the transferred size [6].
<sitemapindex xmlns="…/0.9">A different root element and a different child:
<sitemap>
<loc>https://site.com/sm-1.xml</loc>
<lastmod>2026-10-24</lastmod>
</sitemap>
</sitemapindex>
<sitemap>, not <url>./sitemap-products.xmlSplitting by section rather than by number means the coverage report tells you which part of the site has the problem [3].
/sitemap-categories.xml
/sitemap-blog.xml
→ Search Console reports each separately
Image and video extensions live inside the ordinary <url> entry under their own namespace [7][8]. Google News sitemaps are the exception: a separate file, limited to 1,000 URLs and to articles from the last two days [9].
<urlset xmlns:image="…/image/1.1">The namespace goes on
<url>
<loc>https://site.com/shoes</loc>
<image:image>
<image:loc>…/shoe.jpg</image:loc>
</image:image>
</url>
<urlset>; the image sits inside the page that shows it [7].news → separate file, ≤1,000 URLsOnly news is genuinely a different file [9].
→ last 2 days only
image → same file, extra tags
video → same file, extra tags
Google states plainly that submitting a sitemap does not guarantee it will download the file or crawl the URLs in it [2]. The Search Console report says how many URLs it read, which is a different number from how many it indexed [3].
Discovered URLs 1,284The gap is not an error. It is Google declining, which no change to the sitemap will fix.
Indexed 941
→ 343 read, considered, skipped
• pages that duplicate each otherAll of them live on the pages, not in the file listing them.
• thin or templated content
• no internal links pointing in
• slow responses limiting the crawl
Blocking wins, because the crawler never gets far enough to act on the listing [5]. The sitemap then describes pages nothing can reach, which is one of the quieter ways a file becomes misleading.
# robots.txtListed as worth crawling, forbidden to crawl. The block is what happens.
Disallow: /private/
<!-- sitemap.xml -->
<loc>https://site.com/private/a</loc>
Disallow: /sitemap.xmlA broad disallow rule can cover the sitemap, after which nothing reads it at all [5].
→ the file itself unreachable
Validation proves the XML parses and the file is within its limits. It cannot tell you that 300 of the URLs inside redirect, that 40 carry a noindex, or that the canonical on each one names a different address. Those are contradictions between the file and the pages it lists, so they only surface when something fetches both. The full audit runs 19 sitemap checks across every URL you have listed.
URLs listed as crawlable that answer with a redirect, a 404 or a 5xx, carry a noindex, or are disallowed in the robots.txt file sitting beside them.
Indexable pages missing from the file entirely, which is the quieter half of the problem: Google never learns they exist unless something links to them.
The sitemap naming one URL while the canonical on that page names another, the same page listed in several sitemaps, and lastmod dates in the future or missing.