Maintain a sitemap that reflects your public site

Define which pages belong in the sitemap

Use the public page inventory to identify product pages, documentation, articles, and other routes intended for search. Exclude private workflows and routes that are not meant to be indexed. Include the preferred versions of substantially duplicate pages rather than every available variant.

For a registration product, public setup guides may belong in the sitemap while customer attendee lists do not. The sitemap is not an access-control mechanism; private data still needs proper protection. Document the inclusion rule so future content templates and automated generators do not accidentally publish utility, preview, or account-specific URLs.

Generate from the actual publication inventory

Connect sitemap generation to the pages the site genuinely publishes. A static article collection can supply route entries from its stable slugs, while product routes may come from a separate maintained inventory. Avoid a manually copied list that silently falls behind as content grows.

Verify that every generated entry resolves to the expected public page after deployment. Static exports and host configuration can produce differences between source routes and live behavior. Check representative paths and any newly introduced page type. Generation is a useful convenience only when its inputs reflect real published content and the output is tested.

Keep URLs and modification dates accurate

Use the intended host, protocol, and route convention consistently. Align entries with canonical choices and internal links. If you provide modification information, make it reflect meaningful page changes rather than the date of every build or deployment.

A rebuild that leaves an article unchanged should not automatically imply substantive content revision. Conversely, a major correction should be reflected in the publication metadata and sitemap where applicable. Accurate dates help keep the content system understandable and prevent the team from using superficial freshness signals in place of genuine editorial maintenance.

Submit and inspect without promising inclusion

Make the sitemap available at its intended public location and use supported submission methods where appropriate. Inspect whether the file can be retrieved and whether the relevant tool reports processing errors. Keep this evidence separate from whether individual pages are indexed.

If a page is not indexed, review its accessibility, content, canonical signals, and reported status rather than assuming resubmission is the universal fix. A sitemap is one discovery aid among other signals, including internal links. It does not override access problems or compel systems to include every listed URL.

Review the sitemap during release and cleanup

After adding, merging, redirecting, or removing pages, inspect the resulting entries. Retire outdated URLs where appropriate and confirm that the preferred destination is listed. Check for accidental host changes, duplicate entries, and unavailable routes when deployment configuration changes.

Keep a small release check that compares the sitemap with the expected page inventory. This is especially helpful when editorial content and product pages are generated by different parts of the application. Assign an owner to unresolved discrepancies. A useful sitemap remains a truthful map of the current public site, not a historical collection of every route ever created.

• Use preferred URLs from a maintained inventory.
• Verify entries resolve on the public host.
• Keep modification dates tied to meaningful changes.
• Inspect processing and page indexing separately.

Discovery aids do not describe every page fact. Where a supported structured-data type fits, represent the visible content accurately and validate the deployed output.Use structured data that matches the page