Sitemap audit: the eight checks, and why a lastmod stamped with the build time gets ignored

An XML sitemap audit is eight checks: the file exists and robots.txt points to it; it returns 200 and parses; every URL in it is a canonical page that returns 200; no noindexed, redirecting or blocked URL is listed; no indexable page is missing; each URL carries a lastmod that moves when the page really changes; it stays under 50,000 URLs and 50 MB; and it is submitted in both Search Console properties. Six of the eight take a minute each. The lastmod check is the one that catches most sites, including ours until we rewrote our generators.

We run this audit on every site we take on and on our own thirteen sites after each deploy. What follows is the list in the order we run it, what each check is for, and what Google says it does with the result. None of it needs a paid tool.

What a sitemap is for, and what it is not for

A sitemap tells Google which URLs you consider canonical and, through lastmod, which ones changed since it last came. That is the whole job. It does not make a page rank, it does not make a page indexed, and a page that Google has fetched and declined is not rescued by being listed again. Discovered, currently not indexed is a quality verdict on the page, not a sitemap fault.

Two fields in the file do nothing. Google has said for years that it ignores priority and changefreq, so a generator that fills them is harmless and a consultant who reports on them is padding the invoice.

The eight checks, in the order we run them

1. Does robots.txt carry a Sitemap: line with the full URL? Open yourdomain/robots.txt. Without the line Google still finds a submitted sitemap, but Bing and the AI crawlers that read robots.txt lean on it.
2. Does the sitemap URL return 200 and valid XML? Open it in a browser; a redirect, a 404 or a blank page fails the check. A sitemap index that points to child sitemaps is fine, as long as every child also returns 200.
3. Is every listed URL the canonical version? Pick ten URLs and compare each with the rel=canonical in its own HTML. A sitemap that lists the http version, the trailing-slash version or a parameter version of a page that canonicalises elsewhere teaches Google the file is unreliable.
4. Does every listed URL return 200? Fetch each one. Redirects and 404s in the sitemap are the most common fault we see on sites that have been rebuilt: the old URLs stay in a hand-maintained list.
5. Is anything listed that says noindex, or that robots.txt blocks? A URL that is in the sitemap and noindexed at the same time is a contradiction, and Search Console reports it as one.
6. Is anything missing? Compare the sitemap against a crawl of the site and against the pages you know exist. Pages that only a generator knows about, such as case studies in a hand-written list, go missing first. We found exactly this on seven of our own sites this month: the sitemap listed the one case study the generator was written for and not the four added later.
7. Does lastmod move per page? Fetch the file twice a week apart. If every URL carries the same timestamp, or every timestamp changed on a day only one page changed, the field is the build time, and Google learns to ignore it.
8. Is it submitted in Search Console, in both properties if you have both? A domain property and a URL-prefix property track submissions and validations separately. Submit in each and read the Pages report in each.

The lastmod trap, and why it matters more than it looks

Google's documentation says it uses lastmod when the value is consistently accurate, and that it is the signal that tells the crawler which pages to come back for. Most site generators stamp every URL with the moment the site was built. Every deploy then says that every page changed, which is false, and a field that is always wrong is discounted. The site loses its only automatic recrawl signal and is back to waiting for Google to find changes on its own schedule.

Our own generators did this until we noticed. The fix was to take the date from the last commit that touched each page's file or its content entry, so a guide edited today carries today and a page untouched since August carries August. The sitemap on this site reads that map now, and the checks above would have caught it on day one if we had run them on ourselves as carefully as on clients.

The quickest test: open the sitemap and look for a timestamp that repeats on every line. If it does, the field is the build clock, whatever the generator calls it.

What to do with each failure

A twenty-minute version for an owner

Open robots.txt and find the Sitemap line. Open the sitemap. Count the URLs and compare with the number of pages you think you have. Click five at random and check they load without redirecting. Look at the lastmod column for a date that repeats on every line. Then open Search Console, Sitemaps, and read the discovered count and the last read date. That is six of the eight checks in the time it takes to make a coffee, and it finds the faults that matter.

The two you cannot do by eye, canonical matching and the noindex contradiction, are in the technical pass we run first on every audit. If you want it done once properly, the quote form is the place to ask, and the checklist linked beside this guide covers the other twenty-two checks that sit around the sitemap.