The HoopAI website strengthened its Sanity publishing path after a green static build produced empty CMS route families. The failure came from repeated uncached API reads that reached the plan limit, followed by an adapter behavior that returned empty collections instead of stopping the build. The correction moved public production reads to Sanity's CDN, memoized collection fetches, added a read-budget guard, and kept route auditing responsible for distinguishing expected empty collections from missing published content.
The silent-empty publishing risk
Static generation can succeed at the framework level while the resulting site is incomplete. In this case, the Sanity client used uncached authenticated reads for a large build. Once the API returned a plan-limit error, the content adapter converted the failed fetch into an empty result. Astro completed its work and emitted fewer pages without treating the missing collection as fatal.
This failure mode is dangerous because a green command can be mistaken for publishing proof. Route count and content presence need their own checks. The change record identified the gap by comparing the built site with known Sanity collection counts and observing that entire CMS families were absent even though other routes compiled normally.
Cached content reads
The production dataset is public, so website reads can use Sanity's CDN without an authentication token. Removing the token allowed useCdn to behave as intended instead of forcing uncached API requests. The updated adapter fetches each collection in bulk and memoizes the result for the duration of the build.
Individual document reads then use the memoized collection index. This reduces repeated network work and keeps page generation consistent within one build. A document rendered early and a related card rendered later read from the same collection snapshot, avoiding an unnecessary request for each route or reference.
The read-budget guard
A production guard now counts Sanity reads and fails when they exceed a configured budget. The default recorded in the changelog is intentionally higher than the normal collection-level total, leaving room for expected variation while catching a return to one-read-per-document behavior. The guard stops a caching regression before it consumes the available API quota.
The budget is an engineering constraint, not a publishing target. A low count does not prove that content is present or correct. It proves that the build followed the expected retrieval shape. Collection counts, generated routes, and representative rendered pages still need separate verification after the data has been fetched efficiently.
Verifying a complete build
Route auditing remains strict for established CMS families and carries a documented allowance only for collections known to have no published documents. At the time of the resilience fix, blog and news were verified empty in Sanity, so their absence produced a note while missing routes for other collections remained fatal. That allowance should be removed when those editorial collections receive published records.
The completed build was checked against content counts and representative production pages after deployment. A resilient publishing workflow therefore needs several independent signals: cached collection access, a bounded read count, route-family auditing, and inspection of real rendered content. Together they prevent a successful compiler exit from concealing an empty website.
