Start from the release inventory
Before opening Search Console, write down which public pages the release is supposed to introduce. Include the final address, language and owner of each page. Use this inventory to compare the sitemap with the release instead of assuming a larger URL count means the file is correct.
Google recommends fully qualified URLs and the preferred canonical versions. A sitemap should describe the pages you want discovered, not every address your application can generate. Keep draft routes and account-specific URLs outside this public release inventory.
Validate the actual downloaded file
Fetch the public sitemap address without an administrator session. Save the status, response type and a dated copy. An XML parser should be able to read the body; a login page or an error template saved with an .xml filename is not a valid substitute.
Google requires UTF-8 encoding and XML values must be escaped. If you include lastmod, it should reflect a significant real page update, not the moment a scheduled script reran. Have your build process check the file before deployment and repeat the check against the public copy afterward.
Compare expected, missing and unexpected URLs
Make three lists: expected addresses present, expected addresses missing and unexpected additions. Inspect missing pages before adding them: a page may still be a draft or its final route may have changed. Investigate unexpected additions with the owner rather than automatically deleting them.
For a small release, open every new URL and compare its actual canonical with the inventory. Record redirects and exclusions as separate findings. For larger releases, automate the URL comparison and keep a deliberate review of exceptional cases; a clean XML parse alone says nothing about the listed pages.
Worked example: a bilingual five-topic release
Illustrative example: a team expects five English pages and their five Arabic counterparts. The inventory contains ten unique addresses, but the generated file contains nine because one Arabic route was omitted. The reviewer catches this by comparing URL sets, not by counting every URL in the full site map.
The developer corrects the generator, rebuilds the file and repeats the public check. The release record lists ten expected addresses found and links to the saved file. This is a successful release validation; it is not a report that ten pages are indexed.
Submit once the release matches
Submit the updated map through Search Console and retain its acceptance message and time. Google explicitly describes sitemap submission as a hint, not a guarantee of downloading, crawling or indexing. Keep those later observations in separate fields.
Give the next reviewer a compact handover: release identifier, sitemap URL, expected page list, validation results and submission evidence. If the submission fails, preserve the message and investigate delivery separately. Do not rewrite good page content merely because a sitemap request failed.