XML Sitemap Checker: Find what's broken.

What our XML sitemap checker actually checks

A working sitemap isn’t just a valid XML file. Google reads it as a hint about which URLs you want crawled and when each last changed. Listing a URL is also one of the signals Google uses to pick the canonical version of a page, though Google’s documentation ranks it as a weak signal next to redirects and canonical tags. A sitemap that parses fine but lists redirects, dead pages or the wrong URL versions sends mixed signals and spends crawls on URLs you don’t want.

Our checker first confirms the file is a real sitemap (it must contain a <urlset> or <sitemapindex> element), then looks at the parts that matter for SEO outcomes:

• URL pattern consistency — flags mixed trailing slashes, mixed upper- and lower-case paths, and paths that mix hyphens with underscores.
• Stale and missing lastmod — URLs whose lastmod is more than a year old, plus a count of URLs that carry no lastmod at all.
• Lone URLs and depth — URLs that sit alone in their own top-level section, and how deep the site’s URLs go. This is a URL-pattern signal; we don’t crawl your internal links.
• Sitemap index handling — we read the URLs in up to five sitemap files: the first five child sitemaps of an index, or five shared between the sitemaps your robots.txt lists. Some Jetpack sites put an index inside an index. We open the inner one too and read the sitemaps it lists, within the same five.
• 30 live URL checks — 404s, redirects, server errors, noindex tags, canonical tags pointing elsewhere, robots.txt blocks and slow responses, on 30 URLs sampled evenly across the sitemap.

Why a sitemap audit is worth doing every quarter

Most teams ship the sitemap once and forget it exists. Three quarters later, you’ve added a new content section, deprecated some pages, restructured the URL scheme, or pushed a CMS upgrade — and the sitemap still reflects the site as it was at launch. Every URL in the sitemap that doesn’t belong there is a wasted request, and a lastmoddate that never changes gives Google no reason to recrawl an updated page. Google only uses lastmodwhen it’s consistently accurate.

You get a fix list, not a score: an AI action plan built from the structure analysis and the live checks. Your first check needs no signup. A free account unlocks the full action plan, and paid plans add more checks per month.

Common sitemap mistakes

The same issues come up again and again, and most of them are invisible without a structured look. Read about each: missing lastmod, changefreq misuse, trailing-slash inconsistency, and the self-defeating case where a sitemap lists URLs that robots.txt blocks.

Checker, validator or generator?

The three names get mixed up, and search results for them overlap, but they answer different questions:

• Generator — creates a sitemap file when you don’t have one. Our generator crawls your site and keeps only pages that answer 200, aren’t noindexed and point their canonical to themselves, but it doesn’t check a sitemap you already have. Most sites don’t need one, because the CMS or framework already builds the sitemap (see how to create a sitemap).
• Validator — confirms the XML follows the sitemap format: the right namespace, well-formed tags, escaped characters, UTF-8. A file can pass validation and still be full of redirects and dead pages.
• Checker — tests what the sitemap says against the live site: whether the URLs load, redirect, carry noindex, or declare a different canonical. That’s the job this tool does, on a sample of 30 URLs, after confirming the file is a real sitemap.

Rule of thumb: generator when the file doesn’t exist, validator when Search Console reports a parsing error, checker when the sitemap “works” but pages still aren’t being indexed.

How to check a sitemap by hand

You can do a quick check without any tool. These are manual steps, not part of our scan:

• Open it in a browser. You should see XML (or a styled list), not a 404, a login page or your home page. If the address is unknown, look for a Sitemap: line in /robots.txt.
• Check the response. curl -sI https://example.com/sitemap.xml should return 200. A redirect or 5xx here means Google may not get the file at all.
• Read the Sitemaps report. In Search Console (Indexing > Sitemaps), the status should be Success. “Discovered pages” is how many URLs Google parsed, not how many are indexed; to see indexing, open the Page indexing report and filter it by the sitemap.
• Spot-check URLs. Open a few entries from different sections and make sure each loads directly, without a redirect, and names itself as canonical.

What a healthy sitemap looks like

The file returns 200 and is UTF-8 encoded XML with the sitemaps.org namespace. It stays within 50,000 URLs and 50MB uncompressed (bigger sites split it and use a sitemap index). Every entry is an absolute URL on your preferred host and protocol, returns 200 without a redirect, isn’t blocked by robots.txt, has no noindex tag, and is the canonical version of its page. lastmod dates, if present, match real content changes. Our scan tests the URL-level items on 30 sampled URLs; the file-level items are a checklist for you.

When to test your sitemap

A sitemap breaks quietly: Search Console may still say Success while the URLs inside it redirect or return errors. Test it after every event that changes URLs: a redesign, a CMS or plugin upgrade, a new content section, a domain or HTTPS move, and any change to robots.txt. If you publish often, a monthly check catches drift before it piles up.

Teams with a build pipeline can automate the basic part. After each deploy, fetch the sitemap, confirm it returns 200 and parses as XML, then request each listed URL (or a sample) and fail the build on anything that is not a 200. A few lines are enough:

curl -s https://example.com/sitemap.xml   | grep -o '<loc>[^<]*' | sed 's/<loc>//' | head -50   | while read -r u; do
      echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"
    done | grep -v '^200 '

That catches status codes only. It won’t see noindex tags, canonicals or robots.txt blocks, which is what the scan above adds.

Check again after a migration

Right after a domain move, an HTTPS switch or a URL restructure is when sitemaps go wrong most: old URL patterns, http:// addresses, or entries that now redirect to their new locations. List only the new, final URLs, and submit the new sitemap in the Search Console property for the new address.