The sitemap toolkit checks that your XML sitemaps list the right URLs, that every URL in them is one a search engine should actually index, and that nothing important is missing. Where a site doesn’t produce a usable sitemap, it generates one.
Built in-house. It is my own tooling rather than a reseller’s dashboard, which is why it checks the things I act on rather than everything a generic tool can measure.
What it does
A sitemap is a list of the URLs you want indexed. That sounds simple, and on most sites it isn’t true of the file being submitted. Sitemaps accumulate redirected URLs, noindexed pages, 404s and old parameter versions, and once a meaningful share of the list is wrong it stops being a useful signal.
The toolkit compares the sitemap against what’s actually on the site, and reports the gap in both directions.
What it checks
| Check | What it looks at |
|---|---|
| Format | Valid XML, correct namespace, within the size and URL limits |
| Status | Whether every listed URL returns 200 rather than a redirect or an error |
| Indexability | Whether any listed URL is noindexed, canonicalised elsewhere or blocked |
| Coverage | Pages that should be listed and aren’t, including new sections |
| Index files | Whether a sitemap index is used properly and every child file is reachable |
| Declaration | Whether the sitemap is referenced in robots.txt and submitted in Search Console |
| Freshness | Whether lastmod dates are real rather than rewritten on every build |
The two findings that come up most
Redirected URLs left in the file. After a migration or a URL change, the sitemap often still lists the old addresses. Every one is a URL you’re asking a search engine to index and then redirecting away from, which is a contradiction and a waste of the crawl.
Pages missing entirely. Usually a section a content system doesn’t include by default, or a template added later. This is the more expensive of the two, because those pages are relying on internal links alone to be found.
Lastmod is worth a mention too. A date that updates on every deployment, whether or not the page changed, tells a search engine nothing. Either make it real or leave it out.
Headless and custom builds
A headless build doesn’t hand you a sitemap by default. That caught me out once on a project where the redirects had been planned carefully and the sitemap hadn’t been thought about at all, because on a normal build the platform produces one.
On any custom or headless site, the sitemap has to be specified as a deliverable before launch rather than assumed.
Example output
SITEMAP: /sitemap_index.xml, 4 child files, 2,140 URLs STATUS: 186 URLs 301 redirect. 12 return 404. INDEXABILITY: 31 listed URLs carry a canonical pointing elsewhere. MISSING: The entire /guides/ section, 48 pages, is absent from every child file. LASTMOD: All 2,140 URLs share the same date, which is the last deployment. ACTION: Regenerate from live indexable URLs, add the guides template, make lastmod real.
What I review
The sitemap is compared against a live crawl rather than against a previous sitemap, and anything reported as an error is rechecked, since a crawler under rate limiting produces errors a browser never sees.
Limitations
- A sitemap doesn’t guarantee indexing. It helps search engines find pages. It doesn’t oblige them to keep any.
- It won’t fix a discovery problem caused by internal linking. A page reachable only from the sitemap is a page with a different problem.
- Platform control varies. Some systems give little control over what goes in.
Services it powers
The sitemap toolkit powers XML sitemaps and indexing, runs across every site migration, and supports web development builds. See the rest of the tools on the tech stack page.
FAQ
Does my site need an XML sitemap?
Most sites benefit from one, and larger or frequently updated sites benefit most. On a very small, well-linked site it makes little difference. It matters more when pages are hard to reach through internal links, or when a section has just been added.
What shouldn’t go in a sitemap?
Anything you don’t want indexed: redirected URLs, noindexed pages, 404s, pages canonicalised somewhere else, and parameter versions of pages that are already listed. Once a meaningful share of the file contradicts itself, the sitemap stops being a useful signal to a search engine at all.
Why does a headless site need a sitemap built specially?
Because a headless build doesn’t produce one automatically the way a standard content system does. It has to be specified and built as a deliverable before launch, which is easy to miss when everyone is concentrating on redirects and rendering.
See the whole toolkit
The tech stack page lists every tool, and the free assessment includes a sitemap check.