How to Build a CMS-Powered Sitemap That Updates Automatically

A sitemap is one of the most important SEO assets on your site — yet it is also one of the most commonly neglected. Most teams generate a sitemap once at build time and forget about it. The result is a sitemap that drifts out of sync with the actual content: new pages are missing, deleted pages linger, and search engines are left guessing.

A CMS-powered sitemap solves this by treating the sitemap as a live query against your content store. Every time the sitemap is requested — or revalidated — it fetches the current set of published documents and renders fresh XML. This guide walks through building exactly that with Sanity and Next.js App Router.

Why Static Sitemaps Fall Short

Static sitemaps are generated at build time, which means they only know about content that existed when the build ran. In a CMS-driven site, content changes constantly: editors publish new articles, update slugs, unpublish old pages, and create new categories. A static sitemap cannot reflect any of these changes until the next full build.

The consequences are real. Google may not discover new pages for days or weeks. Deleted pages may continue to be crawled, wasting crawl budget. Slug changes result in 404s that persist in the sitemap long after the redirect is in place.

Architecture Overview

The architecture has three components working together:

1. A Next.js sitemap route that fetches slugs from Sanity via GROQ and returns XML.
2. On-demand revalidation triggered by a Sanity webhook whenever a document is published or unpublished.
3. Incremental Static Regeneration (ISR) as a fallback, so the sitemap is never served stale for more than a configurable window.

Step 1 — Write the GROQ Query

The first step is writing a GROQ query that returns every published document that should appear in the sitemap. You typically want to include all document types that have a public URL — posts, pages, product pages, category pages, and so on.

The query below fetches posts and pages, projecting only the fields needed for the sitemap: the slug and the last-updated timestamp.

// queries/sitemap.ts
export const sitemapQuery = `{
  "posts": *[_type == "post" && defined(slug.current) && !(_id in path("drafts.**"))] {
    "slug": slug.current,
    "lastmod": _updatedAt
  },
  "pages": *[_type == "page" && defined(slug.current) && !(_id in path("drafts.**"))] {
    "slug": slug.current,
    "lastmod": _updatedAt
  }
}`

The filter !(_id in path("drafts.**")) is critical — it excludes draft documents so only published content appears in the sitemap. The defined(slug.current) filter ensures documents without a slug are also excluded.

Step 2 — Create the Sitemap Route in Next.js App Router

Next.js App Router supports a special sitemap.ts file convention that automatically generates a sitemap.xml response. Place this file at app/sitemap.ts and export a default async function that returns an array of sitemap entries.

// app/sitemap.ts
import { MetadataRoute } from 'next'
import { client } from '@/sanity/client'
import { sitemapQuery } from '@/queries/sitemap'

const BASE_URL = process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com'

export const revalidate = 3600 // ISR fallback: revalidate every hour

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const data = await client.fetch(
    sitemapQuery,
    {},
    { next: { tags: ['sitemap'] } } // tag for on-demand revalidation
  )

  const postEntries: MetadataRoute.Sitemap = (data.posts ?? []).map(
    (post: { slug: string; lastmod: string }) => ({
      url: `${BASE_URL}/blog/${post.slug}`,
      lastModified: new Date(post.lastmod),
      changeFrequency: 'weekly',
      priority: 0.8,
    })
  )

  const pageEntries: MetadataRoute.Sitemap = (data.pages ?? []).map(
    (page: { slug: string; lastmod: string }) => ({
      url: `${BASE_URL}/${page.slug}`,
      lastModified: new Date(page.lastmod),
      changeFrequency: 'monthly',
      priority: 0.6,
    })
  )

  return [
    {
      url: BASE_URL,
      lastModified: new Date(),
      changeFrequency: 'daily',
      priority: 1.0,
    },
    ...postEntries,
    ...pageEntries,
  ]
}

The { next: { tags: ['sitemap'] } } option tags the fetch request so it can be invalidated on demand. The revalidate = 3600 export ensures the sitemap is refreshed at least once per hour even if no webhook fires.

Step 3 — Set Up On-Demand Revalidation with a Sanity Webhook

On-demand revalidation lets you purge the cached sitemap the moment a document is published in Sanity, rather than waiting for the ISR window to expire. You need two things: a Next.js API route that accepts the revalidation request, and a Sanity webhook that calls it.

The Revalidation API Route

// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache'
import { type NextRequest, NextResponse } from 'next/server'
import { parseBody } from 'next-sanity/webhook'

export async function POST(req: NextRequest) {
  try {
    const { isValidSignature, body } = await parseBody<{ _type: string }>(
      req,
      process.env.SANITY_WEBHOOK_SECRET
    )

    if (!isValidSignature) {
      return NextResponse.json(
        { message: 'Invalid signature' },
        { status: 401 }
      )
    }

    // Revalidate the sitemap tag on every publish event
    revalidateTag('sitemap')

    return NextResponse.json({
      status: 200,
      revalidated: true,
      now: Date.now(),
    })
  } catch (err: unknown) {
    console.error(err)
    return NextResponse.json(
      { message: 'Error revalidating' },
      { status: 500 }
    )
  }
}

Configuring the Sanity Webhook

In your Sanity project dashboard, navigate to API → Webhooks and create a new webhook with the following settings:

• URL: https://your-site.com/api/revalidate
• Trigger on: Create, Update, Delete
• Filter: _type in ["post", "page"] (adjust to your document types)
• HTTP method: POST
• Secret: a random string stored in SANITY_WEBHOOK_SECRET environment variable

The webhook filter ensures only relevant document types trigger a revalidation, avoiding unnecessary cache purges for unrelated changes.

Step 4 — Handle Multiple Document Types with a Sitemap Index

If your site has tens of thousands of URLs, a single sitemap file will exceed the 50,000 URL limit imposed by the Sitemaps protocol. The solution is a sitemap index — a parent XML file that references multiple child sitemaps, each covering a subset of your content.

Next.js App Router supports this natively through the generateSitemaps export. You export a function that returns an array of IDs, and Next.js generates a separate sitemap file for each ID.

// app/sitemap/[id]/route.ts  (for large sites)
import { MetadataRoute } from 'next'
import { client } from '@/sanity/client'

const PAGE_SIZE = 5000

export async function generateSitemaps() {
  const total = await client.fetch<number>(
    `count(*[_type == "post" && defined(slug.current) && !(_id in path("drafts.**"))])`
  )
  const pages = Math.ceil(total / PAGE_SIZE)
  return Array.from({ length: pages }, (_, i) => ({ id: i }))
}

export default async function sitemap({
  params,
}: {
  params: { id: string }
}): Promise<MetadataRoute.Sitemap> {
  const id = Number(params.id)
  const posts = await client.fetch<Array<{ slug: string; lastmod: string }>>(
    `*[_type == "post" && defined(slug.current) && !(_id in path("drafts.**"))] | order(_updatedAt desc) [$start...$end] {
      "slug": slug.current,
      "lastmod": _updatedAt
    }`,
    { start: id * PAGE_SIZE, end: (id + 1) * PAGE_SIZE },
    { next: { tags: ['sitemap'] } }
  )

  return posts.map((post) => ({
    url: `${process.env.NEXT_PUBLIC_SITE_URL}/blog/${post.slug}`,
    lastModified: new Date(post.lastmod),
    changeFrequency: 'weekly',
    priority: 0.8,
  }))
}

Step 5 — Verify the Sitemap

Once deployed, verify the sitemap is working correctly by visiting https://your-site.com/sitemap.xml in a browser. You should see well-formed XML with all your published URLs. Then publish a new document in Sanity and confirm the sitemap updates within seconds (if the webhook is configured) or within the ISR window.

Submit the sitemap URL to Google Search Console under Sitemaps. Google will begin crawling it and report any errors. You can also use the URL Inspection tool to check whether specific pages are indexed.