That matters more for a small site than a large one. A 40 page service business site does not get crawled constantly. If you fix a price on a service page or rewrite a post, you want Google to come back for that page soon, not for the homepage it already has. An honest lastmod is the cheapest signal you can send, and most Next.js sites throw it away.

What Google does with lastmod

Google has said plainly that it uses lastmod when it is consistently accurate, and ignores it on sites where it is not. The other sitemap fields, changefreq and priority, are ignored outright. So the entire value of the file comes down to two things: a complete list of canonical URLs, and a date per URL that actually reflects when the content changed.

"Actually reflects" is the hard part. A build timestamp is not a content change. A git commit that touched a layout component is not a content change for every page that uses it. The only source that knows when the content changed is the CMS.

Pull the date from the CMS, not the build

On a Sanity and Next.js stack this is a small query. Every Sanity document carries _updatedAt, which moves when the document is edited and published. That is the date you want. Here is a sitemap route for the App Router that reads it directly.

// app/sitemap.ts
import type { MetadataRoute } from "next";
import { client } from "@/sanity/client";

const BASE = "https://www.example.com";

const query = `{
  "posts": *[_type == "post" && defined(slug.current) && !(_id in path("drafts.**"))]{
    "slug": slug.current, _updatedAt
  },
  "services": *[_type == "service" && defined(slug.current) && !(_id in path("drafts.**"))]{
    "slug": slug.current, _updatedAt
  },
  "home": *[_type == "homePage"][0]{ _updatedAt }
}`;

export const revalidate = 3600;

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const { posts, services, home } = await client.fetch(query);

  return [
    { url: `${BASE}/`, lastModified: home?._updatedAt ?? new Date() },
    ...services.map((s: any) => ({
      url: `${BASE}/services/${s.slug}`,
      lastModified: s._updatedAt,
    })),
    ...posts.map((p: any) => ({
      url: `${BASE}/journal/${p.slug}`,
      lastModified: p._updatedAt,
    })),
  ];
}

Three details in that file do the real work. The draft filter keeps unpublished documents out, which also keeps their URLs from leaking before they exist. The revalidate export caches the sitemap for an hour so the route is not hitting Sanity on every crawler request. And nothing in the file uses new Date() except the one fallback, because a date you make up is worse than no date.

Do not let a layout change bump every page

The trap on the other side is being too clever. Some teams compute lastmod from the git history of the page file, or from the deployment time, so that a change to the global header makes every URL look fresh. Google notices within a few crawls that the dates do not correspond to visible changes and stops trusting the file. You are back to zero, with extra code.

If a layout change really does alter the content of every page, say you added a new section to every service page, that is a content change, and the right move is to touch the documents in Sanity so _updatedAt moves. A single migration script does it.

// scripts/touch-services.ts
import { createClient } from "@sanity/client";

const client = createClient({
  projectId: process.env.SANITY_PROJECT_ID!,
  dataset: "production",
  token: process.env.SANITY_WRITE_TOKEN!,
  apiVersion: "2025-01-01",
  useCdn: false,
});

const ids: string[] = await client.fetch(`*[_type == "service"]._id`);
const tx = ids.reduce((t, id) => t.patch(id, { set: { touched: new Date().toISOString() } }), client.transaction());
await tx.commit();

Setting any field, even one the frontend never reads, moves _updatedAt. It is deliberate, it is reviewable, and it only happens when you decide the content changed.

Keep the sitemap complete and canonical

The second half of the job is the URL list itself. A few checks worth running once:

Every URL should be the canonical form. If the site serves www, the sitemap uses www. No trailing slash mismatches, no http. If a page has a canonical tag pointing somewhere else, it does not belong in the sitemap at all.

Paginated listing pages, tag pages, and search result pages usually should not be in there. They dilute the signal and most of them are noindex anyway. The sitemap is for pages you want ranked, which on a service site means the homepage, the service pages, the location pages, and the posts. That is also the set of pages your internal links should concentrate on, and if you have never audited that, the internal link graph Google actually uses is the place to start, because a sitemap can list a page but it cannot make it matter.

Above about 50,000 URLs you need a sitemap index. Almost no service business is near that, but if you run a large catalog or city by service matrix, the App Router supports it through generateSitemaps, which splits the file by id and serves /sitemap/0.xml, /sitemap/1.xml, and so on. The same _updatedAt approach applies to each chunk.

Make it update itself

The last piece is not letting the sitemap go stale between deploys. With revalidate set, the route refreshes on its own schedule. For a tighter loop, point a Sanity webhook at a revalidation route that calls revalidatePath("/sitemap.xml") whenever a document publishes. Then the sitemap updates within seconds of an editor hitting Publish, with the right date, and nobody touched a deploy.

This is the same pattern we use when we build a content system that publishes and revalidates on its own for a client: the CMS is the source of truth for what changed and when, the frontend reads that truth, and the sitemap is one more consumer of it rather than a file someone remembers to regenerate.

A five minute check for your own site

Open /sitemap.xml. If every lastmod matches, or is missing, the file is not helping you. Open Search Console, go to Sitemaps, and confirm the submitted file is the one you think it is and that the discovered URL count matches what you expect. Then pick one page you edited last week and confirm its date in the sitemap matches the edit. If all three pass, you have a sitemap Google can use. If not, the fix above is about thirty lines.

Level Up Digital Marketing Group builds Next.js and Sanity sites for service businesses in San Diego and runs the SEO behind them. More at levelupdigitalmarketinggroup.com.