Add a Sitemap Diff to Your Website Release Check

A deployment can pass its homepage health check while quietly dropping new articles from the sitemap. It can also add preview URLs or stamp every page with the deployment date. None of those failures necessarily breaks the site's visible navigation, so a normal uptime check may miss them.

Add one small artifact to the release record: a before-and-after comparison of the URLs in the public sitemap, with an explanation for each intended change. Use it to verify discovery data, not to claim that Google has indexed the release.

Capture the public file, not only the build output

Before deployment, save the sitemap response, retrieval time and final URL. If the entry point is a sitemap index, follow its child sitemap locations and collect their page URLs. An index lists sitemap files; counting those entries as pages produces the wrong baseline.

Repeat the fetch after deployment from the public hostname. A correct file in a build directory does not prove the CDN or reverse proxy is serving it. Record the response status and whether the content actually parses as XML: an HTML error or login page can arrive with a successful HTTP status.

For a quick explanation of the format and its role, Guangsuan's XML sitemap basics distinguishes page locations from optional metadata. That distinction is useful when a release review starts drifting into changes that have no effect on which URLs are listed.

Compare sets of URLs before comparing dates

Extract each page's loc value with an XML parser, then compare the before and after sets. Do not use line counts: a serializer can reformat an unchanged sitemap into one line or thousands. Preserve the actual URL text, including its host, path and query, so unintended changes remain visible.

• Added URLs: do they correspond to newly published pages, and are they the intended production versions?
• Removed URLs: were those pages deliberately retired, redirected or made non-indexable, or did a query filter accidentally omit them?
• Unexpected hosts or paths: did an environment variable introduce staging addresses, preview routes or an obsolete domain?
• Duplicate entries: did two child sitemaps start exporting the same records?

Open the changed URLs and check their responses, content and canonical values. If the change set is large, automate those checks rather than assuming a sample proves every URL works. A sitemap URL that leads to a redirect or a page declaring a different canonical deserves review against the site's intended URL policy.

Ask why lastmod changed

The sitemap file's generation time and a page's last significant modification are different facts. Rebuilding a website does not necessarily change the content of every page. A generator that fills every lastmod field with the current time can obscure which pages actually changed.

Google's sitemap documentation says it uses lastmod when consistently and verifiably accurate, and ignores priority and changefreq. The documentation lists changes to main content, structured data or links as examples of significant updates; changing the copyright date is not one.

If your system cannot track meaningful per-page modification dates, leaving the optional field out is more honest than inventing dates. If a release intentionally changes important content across many pages, a broad date change may be justified. Keep the reason in the release note rather than treating every large diff as an error.

Classify a mismatch before rolling back

If the origin serves the new sitemap but the public URL serves the old one, investigate the cache and its actual expiry or invalidation process. If both are wrong, inspect the generator's source query, publication filters and hostname configuration. These are different faults and should not trigger the same blind redeployment.

A missing newly published URL may call for a sitemap correction. A sitemap that exposes private preview addresses needs a broader access review: removing a URL from a sitemap does not make the page private. Judge the release by what changed and who can reach it.

When rolling back, verify the resulting sitemap again. Reverting application code does not guarantee that a cached sitemap or a separately generated file reverted with it.

Keep the outcome precise

A compact release record can contain the release identifier, before/after sitemap hashes, added and removed URL lists, checks on those URLs, the reason for date changes and any cache action. Record who will investigate an unexplained difference.

“Public sitemap serves the expected URL set and the changed pages are reachable” is an engineering result. “Google fetched the sitemap” needs evidence from Search Console or appropriate logs. “The new page is indexed” is another result again. Keeping those statements separate makes later troubleshooting much faster.