A healthy XML sitemap is a current list of preferred, indexable URLs that can be fetched successfully. Validate the file, compare it with the site's canonical page inventory, check the live response for every listed URL, and review search-engine processing reports after each material publishing or migration change.
Confirm that the sitemap can be fetched
Request the sitemap from its public HTTPS URL without authentication. Confirm a successful response, an XML content type, valid UTF-8 encoding, and no HTML error page. If the site uses a sitemap index, fetch every referenced child sitemap. Check that robots.txt points to the intended sitemap location and that the submitted URL in each search-engine console matches the production host.
The Sitemaps protocol defines the required sitemap and URL elements, URL escaping rules, location scope, and size limits. The protocol limits a single sitemap to 50,000 URLs or 50 MB uncompressed, so larger inventories require multiple files and a sitemap index.
Compare listed URLs with the intended inventory
Extract every location and remove exact duplicates. Verify that each URL is absolute, uses the preferred scheme and hostname, and belongs within the sitemap's permitted path scope. Include canonical pages that the site wants search engines to discover. Exclude admin pages, internal search results, test content, duplicate parameter variants, redirected URLs, missing pages, and pages intentionally marked against indexing.
Google's sitemap guidance recommends fully qualified absolute URLs and preferred canonical URLs. It explains that sitemap submission is a hint, not a guarantee that a URL will be crawled or indexed.
Check every live response
Request a representative sample or the full list when the sitemap is manageable. Record the final status, redirect chain, canonical tag, indexability directives, and page identity. A listed URL should normally resolve directly to its intended canonical page. Investigate redirecting, missing, blocked, unauthorized, or server-error results rather than leaving them in the file.
Compare the sitemap against the site's published content database or crawl. Find intended pages that are absent, as well as sitemap entries that no longer have a published page. Review language, image, video, or news extensions separately if the site uses them.
Verify freshness fields
Treat the optional modification date as a content signal, not a build timestamp. Sitemaps.org specifies that the value reflects the linked page's last modification date rather than the time the sitemap was generated. Google says it uses the value when it is consistently and verifiably accurate and that the date should represent a significant page change. Do not update every date on every deployment when page content did not change.
Use an accepted date or date-time format and keep time zones explicit when including times. If the publishing system cannot produce trustworthy modification dates, omitting the optional field is better than manufacturing freshness.
Submit and monitor
Submit the sitemap or index in the appropriate verified search-engine property and retain the submission date. Review the reported fetch time, discovered URL count, parsing errors, and processing status. Recheck after domain changes, URL migrations, canonical changes, publishing-system changes, or a sudden difference between sitemap and index coverage.
Keep an audit record with the sitemap hash, URL count, status summary, excluded categories, modification-date check, and search-console result. A successful XML fetch proves only that the file is reachable; the URL-level checks prove whether it describes the current public site accurately.
Sources
- Build and submit a sitemap — Google Search Central
- Sitemaps XML format — Sitemaps.org