Retrieve the sitemap as a crawler would
Request the sitemap without a signed-in browser session. Confirm a successful response, the final URL, and XML content. Some error pages return status 200, so inspect the body rather than relying on the code alone. For a sitemap index, repeat the check for every child file.
Look for a sitemap declaration in robots.txt and verify that all referenced hosts and protocols are intentional. A robots.txt declaration helps discovery, but the sitemap still needs to work independently.
Validate protocol rules before page quality
Check XML parsing, the root element, namespace, absolute URL format, escaping, and file limits. Large implementations should use a sitemap index and predictable file boundaries. Compression must still produce a file crawlers can retrieve and parse.
Keep protocol errors separate from URL findings. Invalid XML may need a platform fix; a redirecting product URL may come from catalog logic. Combining them into one vague “sitemap error” makes ownership and retesting harder.
Test whether listed URLs are truly preferred
Sample every sitemap type and test all URLs when the set is manageable. A listed page should return successfully, be crawlable, avoid a noindex directive, and agree with its canonical target. Redirects, soft errors, tracking parameters, and duplicate variants usually do not belong in the primary sitemap.
Compare the file with internal navigation and known site sections. A missing page may be harder to discover, but adding it to the sitemap does not repair poor internal linking or make a low-value page worth indexing.
• Successful final response• Preferred canonical URL• No blocking noindex directive• Correct host and protocol• Useful page linked within the site
Treat lastmod as a claim that needs evidence
Update lastmod when the page changes meaningfully, not every time the sitemap job runs. A fresh date on thousands of untouched pages makes the field less useful and can conceal whether the publishing system knows what changed.
Test known examples against their actual update history. If the platform cannot produce a trustworthy date, omitting the field can be more honest than publishing false precision.
Worked example: a migration left two URL generations
Imagine a software documentation site that moved from numbered article URLs to descriptive slugs. The sitemap includes both versions; the old URLs redirect, while several new articles are absent. XML validation alone reports no problem.
The useful fix is to publish only the preferred new URLs, add the missing articles, and verify internal links. The follow-up report records when the sitemap changed and checks later crawl or index evidence. It does not promise that every submitted URL will be indexed.
Create an issue log that can be retested
Prioritize retrieval failures, malformed files, wrong hosts, and large groups of non-canonical URLs. Then address missing sections, unreliable dates, and maintainability. Include an example URL, affected sitemap, estimated scope, owner, and retest method for each finding.
A useful audit ends with a small number of reproducible problems. A single pass/fail score cannot explain whether the sitemap reflects the site, which team needs to act, or what should be checked after release.