Rebuild a sitemap from the verified restored-page inventory, not from every address found in an archive download. Include the approved public destinations you want discovered, then check them against actual responses and canonical decisions. Submission is a discovery hint, not proof that every page is indexed.
Define the eligible page set
Separate published public content from drafts, test copies, private endpoints and utility pages. Identify the canonical destination for each eligible page in the approved URL map. Avoid exporting archive replay addresses or staging URLs into the live sitemap.
Do not use this exercise as automatic permission to exclude pages from search. If an existing page’s indexability needs changing, make that a separate owner decision supported by evidence. A missing sitemap entry and a noindex directive are different things.
Check for pages that were approved and reconstructed but never connected to the current inventory. The sitemap audit should surface that discrepancy instead of silently omit them.
Compare inventory and output in both directions
Collect the actual sitemap or sitemap index and the URLs in its child files. Compare them with the eligible-page list. There are two questions: which approved pages are absent, and which sitemap addresses do not belong to the approved set?
A raw count cannot answer either question. Two lists can have equal lengths and different destinations. Compare exact addresses first, then investigate variants with the URL map rather than remove slashes or parameters indiscriminately.
For each mismatch, record the address, expected page, observed sitemap state and proposed resolution. Keep unresolved entries visible until the owner or responsible developer makes the necessary decision.
A small reconciliation example
This is a synthetic example, not a current site finding. An approved inventory contains a restored article at /guides/recovery/. The sitemap instead contains /guides/recovery.html, while both lists contain the same total number of URLs.
The count appears correct, but the address does not agree. Check which path serves the approved content and which one owns the canonical role. Correct the sitemap generation or inventory only after establishing that evidence. Do not rename the article just to match the generated output.
A second mismatch might be a stale sitemap entry for a missing download page. That needs a content or URL decision, not simply another sitemap submission.
Verify response and canonical consistency
Open priority sitemap URLs while logged out. Confirm the expected page content and inspect redirects, canonical references and unintended robots restrictions. Where a sitemap names a redirecting variant, reconcile it with the intended final public destination.
Google advises consistent canonical preferences across the signals supplied by the site. The sitemap should support the approved canonical map, not contradict it.
An unavailable page or a successful-status error message does not pass simply because the XML is valid. Validate the destinations as well as the file format.
Use modification dates honestly
Keep capture dates in the recovery provenance record. Do not automatically copy them into lastmod or set every page to today’s date to appear fresh. Establish the actual significant update represented by the sitemap field.
Google’s sitemap guidance says it uses lastmod when consistently accurate and reflective of significant page updates. It also says it ignores priority and changefreq. Those fields are not substitutes for useful content or measured crawl evidence.
If the system cannot provide a reliable modification date, ask the responsible developer for an accurate approach rather than invent one. A new restoration and a historical publication date can be documented separately.
Inspect existing generation before replacing it
Many content systems already generate a sitemap. Review that output and its page-selection behavior before adding a second generator or resetting SEO settings. A single omitted article may have a page-specific explanation.
When a correction is approved, preserve the prior output and settings reference. Make the smallest necessary change, check the generated files and rerun the inventory comparison. Do not make global plugin changes solely because a historical audit suggested them.
Record submission, processing and indexing separately
After authorized submission, retain the submitted address and date. Check the search dashboard’s reported access or processing results where available. Google describes sitemap submission as a hint and does not guarantee that it will download or use the file.
Indexing requires separate page-level evidence. A sitemap marked processed does not mean all listed pages are indexed, and an indexed page is not proof of strong rankings. Monitor important URLs and unresolved discrepancies rather than repeatedly submit the same file without a reason.
Repeat the comparison after later content batches or changes to sitemap generation. The URL acceptance checklist provides the underlying preservation checks; sitemap QA ensures the site’s discovery output reflects those verified destinations.
Does a sitemap replace internal links?
No. Visitors still need meaningful navigation and contextual routes. Use the sitemap as complementary discovery information, not a reason to leave restored pages disconnected.
