A sample Sanity CMS audit report

Evidence

62,670 live API GET requests came from the site’s server user agent. The navigation query ran 15,719 times against the production dataset, once per server render, and every render sent its page queries to the live API as well. Page renders account for 47,157 live API requests, 64.0% of the total; with the related route (finding 4), published reads are 57,932, or 78.6% (computed from the sample).

Cause

The site has one Sanity client, created with useCdn: false, and uses it for every server render. Sanity’s request spike guide describes exactly this: a client with useCdn: false that fetches published content on every render sends a live API request for every query on every page view, so usage grows with traffic instead of being absorbed by the cache. Sanity meters API requests and API CDN requests as separate quotas.

Fix

Two clients: a published client with useCdn: true for every page view, and a preview client for draft mode only.

// lib/sanity.ts
const config = {
  projectId: 'sq4t9wzk',
  dataset: 'production',
  apiVersion: '2025-02-19',
  requestTagPrefix: 'web',
}

// Every page view: cached on the API CDN
export const client = createClient({ ...config, useCdn: true })

// Draft mode only, server only
export const previewClient = createClient({
  ...config,
  useCdn: false,
  perspective: 'drafts',
  token: process.env.SANITY_API_READ_TOKEN,
})

Then cache each query’s result in Next.js and revalidate it when the content changes:

Evidence

The navigation query ran 15,729 times with a median response of 187.4 KB: 2.81 GB, 17.4% of the live API’s response bytes, to draw a menu of titles and links. The home page’s “latest” query ran 2,436 times with a median response of 4.17 MB: 9.91 GB, 61.3%. Together, 78.7% of live API response bytes (computed from the sample).

Cause

The menu is a list of references to articles, and items[]-> with no projection returns each whole article, body included. The home query has no slice and no projection, so it returns every article ever published.

Fix

Project only what each page draws, and slice the list:

// Navigation: before
*[_type == "navigation"][0]{..., items[]->}

// Navigation: after
*[_type == "navigation"][0]{
  "items": items[]->{ title, "slug": slug.current }
}

// Home "latest": before
*[_type == "article"] | order(publishedAt desc)

// Home "latest": after
*[_type == "article"] | order(publishedAt desc)[0...12]{
  title, "slug": slug.current, publishedAt, excerpt, hero
}

Both change only when an editor publishes, so cache them (finding 1’s table). The section query already follows this pattern.

Effort: Two hours.

Evidence

All 73,710 live API requests were untagged. Insanity Logs’ insights flag it too: “100.0% of queries are untagged”. The 960 POST search queries had no groqQueryIdentifier, so they can’t be grouped at all.

Cause

Neither the client nor the queries set a tag. Sanity’s log reference says the identifier is empty for POST requests and points to request tags as the way to group them; the client sends a query as POST once it is long enough.

Fix

Set requestTagPrefix on each client (finding 1’s snippet does) and a tag on each query. The client joins them with a dot, so this appears in the logs as web.nav:

const nav = await client.fetch(NAV_QUERY, {}, { tag: 'nav' })

Use one tag per part of the site: nav, settings, article, latest, section, search, related, revalidate.

Effort: An hour.

Evidence

Filtering the log for perspective=drafts finds 10,775 requests, all to the live API, all one query, *[_type == "article" && references($id)], all from the site’s server. That is the same count as the browser’s “most read” requests, which run once per article view: the related route runs on every article page for every reader.

Cause

The related-articles route, /api/related, imports the preview client: drafts perspective, read token, no CDN. Anyone who calls it with an article ID gets that article’s related drafts, unpublished titles and slugs included. Every call is also a live API request: Sanity’s docs say a client with the drafts perspective queries the live API even when useCdn is true.

Fix

This week: switch the route to the published client. Then check that every import of the preview client sits behind draft mode, and add a lint rule so it can’t be imported anywhere else. The token never reached the browser, so it doesn’t need rotating, but rotate it if there’s any doubt.

Effort: An hour.

Evidence

One IP address, 203.0.113.47, sent 10,110 requests: one every 60 seconds (the median gap), around the clock, from the first minute of the window to the last. User agent python-requests/2.28.1, no referer, no tag, and API version 2021-10-21, the only pre-2023 version in the log, which Insanity Logs marks as outdated. 30 requests got a 503 and were retried a second later, so 10,080 were billable. Each returned the 20 latest articles in full, 307.4 KB at the median: 2.95 GB, 18.3% of live API response bytes. Insanity Logs’ “suspicious IP activity” insight lists this address first.

Cause

The query and the API version match the newsletter integration Sedgeway used in 2024. Callum thinks it was replaced and never switched off. The project’s API settings still list a read token named for it.

Fix

Find and switch off the integration, then revoke its token from the project’s API settings. If the newsletter still needs a feed, point it at the site’s RSS feed instead.

Effort: An hour, once found.

Evidence

8,751 image requests, 18.3% of image requests, asked for an original file with no parameters. The median was 3.23 MB, and together they came to 27.58 GB, 91.5% of image bandwidth. The site’s other 38,998 image requests were sized, with a median of 32.2 KB.

Cause

The article template builds the hero image URL by hand, without the image URL builder the rest of the site uses. Sanity’s image transformation docs say a URL with no parameters serves the original asset, which can use a lot of bandwidth.

Fix

Use the URL builder with a width per breakpoint and auto=format, which returns the best format the browser supports, or Next.js’s image component with a Sanity loader:

urlFor(article.hero).width(1200).auto('format').url()
// https://cdn.sanity.io/images/sq4t9wzk/production/...jpg?w=1200&auto=format

Effort: Half a day.

Evidence

Webhook deliveries don’t appear in request logs, but the handler’s query does. The Studio sent 5,068 draft commits in the week and 43 publishes. A query listing every article, section and page path ran 5,068 times, 95.2% of them within 60 seconds of a commit: about 118 runs per publish. It follows the editors’ week: 180 and 222 commits on the Saturday and Sunday, between 828 and 1,063 on each weekday. It is 6.9% of live API requests.

Cause

The revalidation webhook has its drafts setting switched on and no filter, so every draft change in any document is a delivery. Sanity’s webhook docs warn about exactly this: webhooks ignore drafts by default, and with drafts on, almost every keystroke in the Studio is an update. The handler then lists every path and revalidates them all, which clears the cache finding 1 sets up.

Fix

Switch the drafts setting off, so only published changes trigger it. Filter it to the types the site renders, project just what the handler needs, and revalidate by tag for the document that changed:

// Filter
_type in ["article", "section", "page", "navigation", "siteSettings"]

// Projection
{ _type, "slug": slug.current }

Effort: Half a day.