From reading to action
A practical path through this guide.
Select a step to explore what to do and why it matters.
List expected canonical pages
Use all public content sources, including any bundled articles.
When a sitemap is missing pages, trace the content collection used to generate it. A common problem is that detail routes support more content than the sitemap query returns. A successful XML response does not prove the URL inventory is complete.
Establish the expected set
List canonical public routes from the same content sources used by the site. Include managed CMS documents and any bundled articles that remain live. Exclude drafts, deliberately noindex pages, invalid slugs, and URLs that redirect to another canonical route.
Compare identifiers and slugs rather than only counts. Two collections can contain the same number of items while one misses a new article and includes a retired one. Save the difference as a small report you can review.
Inspect query and merge behavior
Check pagination limits, publication filters, dataset configuration, and empty-response fallback logic. If the site merges CMS and local posts by slug but the sitemap chooses only one source, valid pages can disappear from discovery.
Use the same canonicalization policy throughout. A CMS override should replace the local article with the same slug rather than create a duplicate sitemap entry. If a document is deliberately excluded from indexing, its fallback copy should not silently reintroduce the route into the sitemap.
Validate the URL output
- Each entry uses the public production origin.
- Slugs are valid and uniquely identify the intended page.
- URLs return the expected page rather than a redirect chain.
- Modification dates reflect meaningful content changes where known.
- XML escaping and response headers are valid.
Do not update every article's modification date to the current request time just to make it appear fresh. Prefer actual content dates. For static navigation pages, choose a defensible update policy rather than implying an editorial change on every generation.
Check publication and caching
Publish one test article and verify its detail page, listing entry, and sitemap inclusion. Remove or noindex a test document and check the opposite path. Test with a nonempty CMS dataset because “works with fallback data” does not prove merge behavior.
Inspect the public sitemap after the configured revalidation cycle. Local success does not establish that the deployed environment has the same CMS project or cache state. Keep the reconciliation check repeatable so future content batches cannot quietly regress coverage.
Further reading
Google's sitemap guidance covers the format and discovery role. Related: Next.js technical SEO.
A few practical answers
Frequently asked questions
Why can a live article be absent from the sitemap?
The sitemap may use a limited query, different publication filters or a different CMS/local merge policy. Compare its expected URL set with the source used by listings.
Should every route be added to a sitemap?
No. Build the set from intended canonical public pages. Exclude drafts and deliberately non-indexable alternatives, then verify the listed URLs resolve to their intended content.
