An XML sitemap is a discovery file containing preferred page URLs. This guide walks through a small service-site example, the exclusions to check and a practical release handoff. A submitted file is not evidence that its pages are indexed.
01Start with a canonical page inventory
For an example service site, list the homepage, an audit service and a useful guide. Record each final HTTPS URL beside its purpose, response status, canonical and indexability. Keep this inventory as the input to the generator, rather than copying every URL found in a crawl.
- Check the final response after redirects
- Distinguish public pages from previews
- Keep the inventory with the release
02Understand the minimal XML shape
A simple document uses a urlset element in the sitemap namespace, containing one url element per entry and a loc element with the absolute preferred URL. For example, the audit entry might identify https://example.com/services/audit/. Replace this illustration with your own verified URL; do not publish the example domain.
- Use absolute URLs
- Escape XML characters in URL values
- Validate the generated XML before deployment
03Exclude URLs that contradict your intended index
A practical exclusion review checks redirecting aliases, broken URLs, private areas, test pages and pages intentionally marked noindex. A sitemap should describe your intended canonical inventory. If an excluded URL is an important page, investigate its configuration instead of silently removing it to make the report look clean.
- Compare sitemap and canonical destinations
- Check both slash and hostname variants
- Record why an entry is excluded
04Treat lastmod as a content fact
If your generator emits lastmod, derive it from a meaningful change to the page, not from every build or visit. A deployment that only rebuilds unchanged HTML is not automatically a substantive content update. Omit an unreliable optional date rather than manufacture a fresh one.
- Choose a documented date source
- Avoid resetting all dates on each build
- Test one changed and one unchanged page
05Publish and hand over the actual file
Make the file available at its declared public URL and check the body as well as the status code. A 200 response containing a login screen or an HTML fallback is not a usable XML file. Provide the sitemap URL to the person responsible for Search Console submission.
- Save the public URL and checked date
- Verify XML content type and parseability
- Identify the submission owner
06Validate the pages separately
After release, sample the URLs in the file and retain the results with the commit or deployment. Discovery, crawl response and index inclusion are separate observations. A clean sitemap can coexist with a page-level problem, so include unresolved redirects, canonical disagreements and indexing questions in the handoff.
- Compare generated entries with the approved inventory
- Recheck affected templates after changes
- Review Search Console evidence where access is available