Begin with a publication inventory

A sitemap is a discovery aid, not a publishing queue. Google's sitemap guidance explains that submission does not guarantee crawling or indexing. Treat the file as your declaration of the public pages you want considered. Before generating XML, create a table containing each page's final URL, publication state, preferred canonical URL, and last substantive modification. This table gives editors and developers something they can inspect together. It also prevents a draft that happens to have a route from silently becoming part of the public submission.

Generate from the content source

My recommended implementation is to derive both article routes and sitemap entries from one filtered collection. The filter should admit published pages whose intended canonical URL is themselves. Include important landing pages and category pages deliberately, rather than assuming every generated route deserves inclusion. Exclude account screens, preview links, search results, and retired routes. This is an editorial decision as much as a technical one: a route existing in your application does not establish that it offers a useful standalone search result. Document any exceptions beside the filter.

A hypothetical publication example

Suppose a software company has 200 approved guides, 12 draft articles, a pricing page, and three public topic collections. Its expected inventory is 204 URLs if all those public pages are intended for indexing. The 12 drafts should not appear simply because their records exist. If one approved guide is merged into another, remove its old location and retain the destination once. Compare the generated count with the inventory after every release. This count is a consistency check for this example, not a recommended number of pages for SEO.

Inspect the deployed file

Download the public sitemap after deployment and parse it as XML. Check that its URLs use the production hostname, that ampersands and other special characters are escaped, and that a sample of entries returns the expected article rather than an application fallback. Test the first entry, a middle entry, the final entry, and any newly introduced page type. A file that opens in a browser may still contain incorrect destinations. Also inspect the response body when a CDN, security layer, or redirect sits in front of the site.

Make maintenance part of publishing

Add a release check comparing the sitemap URL set with the list of published canonical routes. Surface missing pages and unexpected entries separately so an editor can distinguish omissions from exclusions. Submit the sitemap in Search Console and investigate reported fetch or parsing errors. Do not repeatedly resubmit an unchanged file as a substitute for improving inaccessible or unhelpful pages. Once discovery is working, evaluate the pages themselves: their usefulness, internal links, and relevance to a real audience. A valid sitemap completes one part of the system; it does not validate the content.

Keep the inventory export available to editors, too. When an expected page is missing, they should be able to determine whether its publication state or its technical delivery caused the exclusion.

PUT IT TO WORK

Build the sitemap from the same published URL inventory that powers your website.

Sources & further reading

Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.

THE WORKSPACE WE'RE BUILDING

From search signals to a useful first draft.

SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.

Join early access ↗