Free Sitemap Checker & Validator

What is a sitemap.xml and why does it matter?

A sitemap is a structured XML document that lists the URLs of a website you want search engines to know about. It is served from a stable path, almost always /sitemap.xml, and follows the Sitemap Protocol — a small specification originally published by Google in 2005 and adopted as a joint standard by Google, Yahoo, and Microsoft a year later. The format is simple: a <urlset> root element containing one <url> element per page, with optional metadata about when each URL was last modified, how often it changes, and how it relates in priority to others on the same site.

The point of a sitemap is discovery, not ranking. Search engines crawl the web by following links from page to page. On a small site with clean internal linking, every page is reachable from the homepage within a few clicks, and crawlers find everything without help. On a large site, on a site with deep pagination, on a site with isolated landing pages that no internal link points to, or on a site that has just published new content, crawlers can take days or weeks to discover URLs through links alone. The sitemap solves this by handing the crawler a complete list up front.

Sitemaps do not guarantee indexing. Google has stated this explicitly in its documentation since the protocol launched: a URL in your sitemap is a signal that you want it indexed, not a command that it will be. Pages with low quality, duplicate content, or thin information will be skipped regardless of sitemap inclusion. What the sitemap does change is crawl efficiency. With a sitemap, Google can crawl your new and updated pages first, prioritize them based on the lastmod field, and avoid wasting requests on stale or archived URLs.

Sitemaps also matter for the long tail. A site with 100,000 product pages, 5,000 blog posts, and 200 category landing pages has too much for any internal linking pattern to expose every URL within a few clicks. Without a sitemap, the site relies on Googlebot's exploratory crawling to find the deep URLs, which works but is slow. With a sitemap, every URL is known to Google immediately, and the crawler can spend its budget on freshness checks and content quality rather than discovery. For e-commerce, news publishers, marketplaces, and content-heavy sites, the sitemap is not optional.

How to use this checker

The checker takes a sitemap URL or a domain root and returns a structured report on validity, completeness, and reachability.

Step 1 — Enter the sitemap URL. Paste the full URL to your sitemap, or just the domain — the checker will autodiscover via robots.txt and try common paths like /sitemap.xml, /sitemap_index.xml, and /sitemap.xml.gz. It also follows sitemap-index files automatically and walks every child sitemap inside.

Step 2 — Review the validity report. The checker validates the XML against the Sitemap Protocol schema, flags malformed lastmod values, checks for URLs over the 2048-character path limit, and verifies that the file is under the 50MB uncompressed and 50,000-URL hard limits. Each issue is shown with the exact URL or line number that triggered it.

Step 3 — Check reachability. For a sample of URLs in the sitemap, the checker performs a HEAD request and reports the response code. URLs that return 404, 301, 302, or 5xx in your sitemap are noise that wastes crawl budget; the report shows them grouped so you can fix or remove them.

The sitemap protocol in depth

A minimal valid sitemap looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Only <loc> is required. The other three optional fields are <lastmod>, <changefreq>, and <priority>, and modern best practice treats each one differently.

Hard limits and the sitemap-index pattern

A single sitemap file may contain at most 50,000 URLs and must be under 50MB uncompressed. These limits have been in the protocol since launch and are enforced by every major crawler. Files over the limit are not just truncated — they are rejected entirely by Googlebot, which then reports an error in Search Console. For a site with more URLs than fit in a single file, the protocol defines a sitemap-index format that lists multiple child sitemaps:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

The index can list up to 50,000 child sitemaps, each containing 50,000 URLs, for a theoretical limit of 2.5 billion URLs across the site. In practice, organizing by content type — pages, products, blog posts, tags, categories — produces a maintainable structure that also lets you re-generate only the changed sub-sitemap on each deploy. The convention is to name the index sitemap.xml or sitemap_index.xml and the children with descriptive paths.

lastmod precision and when Google trusts it

Google has stated repeatedly that it uses lastmod when the value is accurate, and discounts it across the entire sitemap when it appears unreliable. A site that always reports today's date for every URL is reporting freshness that does not exist; Google detects the pattern and stops weighting the field. The same applies to lastmod values that never update even when content changes — the lack of signal is itself a signal.

Use the full ISO 8601 datetime format, including the timezone offset: 2026-04-27T12:00:00+00:00. The date-only form 2026-04-27 is valid and accepted, but the datetime form is preferred for high-frequency sites where the time of day matters. Set lastmod to the actual modification time of the page content, not the deploy time of your application. Pages that have not changed should keep their old lastmod value, even when the rest of the sitemap is regenerated.

changefreq and priority: mostly ignored

The <changefreq> and <priority> fields were defined in the original protocol to give site owners a way to express how often a page changes (always, hourly, daily, weekly, monthly, yearly, never) and a relative priority within the site (a decimal between 0.0 and 1.0). Modern Google ignores both. The crawler decides crawl frequency from observed change patterns and decides priority from content quality and link equity, not from sitemap declarations.

The practical recommendation is to omit both fields. They make the sitemap larger and more complex without changing crawler behavior. Bing's documentation suggests it still considers changefreq weakly, but the impact is small enough that maintaining accurate values is rarely worth the engineering cost. A clean sitemap with just <loc> and <lastmod> is the modern default.

Autodiscovery via robots.txt vs Search Console submission

Two ways to tell Google about a sitemap: declare it in robots.txt or submit it via Search Console. Both work, both are recommended, and both together is the modern best practice.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

The robots.txt declaration is read by every well-behaved crawler — Googlebot, Bingbot, DuckDuckBot, Yandex, and most SEO tools — without any per-platform setup. Search Console submission is Google-specific but unlocks the indexing reports that show how many URLs in the sitemap are indexed, how many are excluded, and why. For a site that takes SEO seriously, submit through Search Console for visibility and declare in robots.txt for portability.

Image, video, and news sitemap extensions

The base protocol has extensions for image, video, and news content. Image sitemaps add an <image:image> element listing the images on each page, which helps Google discover images on JavaScript-rendered pages where the image URLs are not in the initial HTML. Video sitemaps add a <video:video> element with title, description, thumbnail, and runtime, and remain the canonical way to surface video to Google Video. News sitemaps use a separate <news:news> element with publication date and required namespace, and are mandatory for inclusion in Google News.

For a typical marketing or content site, a plain URL sitemap covers the use case completely. The extensions are worth the complexity only when image discoverability, video, or news inclusion is a meaningful traffic source.

Common mistakes that hurt SEO

404s and redirects in the sitemap. Listing URLs that return 404 or redirect to a different URL pollutes the sitemap with noise. Google flags these in Search Console as sitemap errors and may discount the rest of the sitemap. Audit the sitemap on every deploy and remove non-200 URLs. Redirects should be replaced with the destination URL.

Including non-canonical URLs. Pages with rel="canonical" pointing to a different URL should not appear in the sitemap. The sitemap is a list of pages you want indexed; pages canonicalized away are pages you have explicitly told search engines to ignore. Including them creates conflicting signals.

Always-current lastmod. Setting lastmod to today's date for every URL on every regeneration tells Google that the field is unreliable, and the crawler stops weighting it. Set lastmod from the real modification time of the page content, not the deploy time. Pages that did not change should keep their previous lastmod.

Sitemap blocked by robots.txt. A Disallow: /sitemap.xml line, or a broader Disallow: /sitemap that matches the file, prevents crawlers from fetching the sitemap at all. Always test with curl or a sitemap checker after modifying robots.txt to confirm the sitemap URL is reachable.

Sub-sitemaps inside a sitemap-index returning 404. A sitemap-index that lists ten child sitemaps but only nine of them resolve causes the missing one to be flagged as an error. Worse, if the path pattern changes between deploys, every old sub-sitemap URL becomes a 404 until the index is regenerated. Generate the index from the same source of truth as the children to keep them synchronized.

Mixing protocols inside a sitemap. A sitemap served at https://example.com/sitemap.xml should contain only https:// URLs. Mixed http:// URLs are treated as a different host and ignored by the canonical host's sitemap processor. The same applies to www vs non-www inconsistency: pick one and use it throughout the sitemap.

Forgetting to escape special characters in URLs. XML requires &, <, >, ", and ' to be escaped inside attribute and element values. URLs with raw ampersands break the XML parser, and the entire sitemap fails validation. Generate URLs through a library that handles escaping rather than concatenating strings manually.

Edge cases nobody mentions

A sitemap.xml served with the wrong content type breaks some crawlers. The correct content type is application/xml or text/xml. Some servers return text/plain or text/html for .xml files when the MIME type is not configured, and Bingbot in particular has been known to refuse such responses. The checker tests the content type and flags it as a warning when it does not match.

Compressed sitemaps served as .xml.gz save bandwidth dramatically — sitemaps compress to 5-10% of their original size because of the heavy URL prefix repetition. Both Google and Bing accept gzipped sitemaps without any extra configuration, and the file size limit is measured against the uncompressed size. The only catch is that some hosting platforms serve .gz files with the wrong content encoding, causing the crawler to receive raw gzip bytes that fail to parse. Test the gzipped version in a browser; if you see binary garbage instead of XML, the response is missing the Content-Encoding: gzip header.