The short answer
Build a sitemap from the public URLs you actually want discovered, with accurate modification information. Keep drafts, private account pages and utility endpoints out of the list. A sitemap is a discovery aid, not proof that an article has been crawled, indexed or ranked.
A worked example
A fictional rebuild has an active catalog, a private cart and an unfinished policy page. The launch team should not include all three merely because their routes exist. The sitemap decision follows the approved public indexing plan, while a human-readable page directory can still help visitors navigate useful preview pages.
A practical checklist
- Separate route existence from indexing approval. Create an explicit inventory of public pages, their canonical destinations and their launch readiness.
- Generate entries from that inventory or published content records. Record real substantive modification dates rather than stamping every URL with the current date on each request.
- Check sample URLs and the submitted file on the final host. Monitor discovery and indexing through appropriate tools instead of interpreting submission as completion.
What to avoid
Avoid listing every filter combination or copying private route names into the sitemap. Do not enable production discovery for a preview simply because more articles were added. This project's migration settings remain separate from its new content and tool implementation.
A useful follow-up
Is a page directory the same as an XML sitemap?
No. A page directory serves visitors; an XML sitemap supplies discovery information to crawlers.
