Composition at build time, not runtime
Next.js sitemap.ts reads the slug manifest and the spine route table, then emits a single XML document at /sitemap.xml. Priorities are assigned by category: spine pieces get 0.8, leaves get 0.6, the audit endpoint gets 0.7. The lastModified field uses the build timestamp, so every deploy freshens the sitemap whether or not content changed. Build-time composition means the served document is byte-identical from CDN cache hits and is never recomputed under request load. This matters for surfaces that scale past a thousand URLs, where runtime composition can dominate the cold-start budget.
IndexNow on deploy, not on a schedule
A post-deploy hook POSTs the new and changed URLs to api.indexnow.org. Bing and Yandex participate; Google reads its own signals. The leverage on Google specifically comes from sitemap freshness plus internal-link density rather than the IndexNow ping itself, but the Bing leverage is real: on our agents.alkenacode.dev surface, Bing indexed the first eight URLs within three calendar days of the IndexNow ping, versus eleven days for the equivalent slug set on a project without IndexNow. The protocol spec at indexnow.org defines the key file pattern; the implementation cost is roughly thirty lines of code.
What this layer does not do
It does not handle removals cleanly. If a slug is deleted from the manifest, the sitemap stops listing it; the search engine drops it on its own schedule, which has been twenty to thirty days in our observed cases. For aggressive removal, the URL would need to return 410 Gone, which is outside the sitemap layer's scope. The robots layer is also a separate concern; if you need to block specific paths from indexing, the noindex meta tag or a robots.txt rule does the work, and the sitemap is not the right place to express that intent.