Get help on Discord

Sanity schemas in Next.js frontend: necessary with headless CMS or redundant?

10 replies
Last updated: Nov 29, 2025
Hi everyone! I’m starting a job next week using Sanity + Next.js, so I’ve started spiking ahead of time and teaching myself about Sanity as a headless CMS. I followed User’s tutorial here , which was great at showing the basics of building and deploying a Sanity Studio schema, the Presence API, the content lake, etc. Then for the frontend, User selected a Next.js blog template and deployed it on Vercel. She didn’t go into too much detail about tailoring and customization, as this was in the final 2 minutes of the video, just encouraged us to select a blog based template and play around with it.
I selected
this template, and tweaked some of the interface and content type definitions for Post and Author to match the naming conventions we had in the tutorial (or vice versa in some cases), so when it was connected to my headless Sanity Studio and deployed, everything would be apples to apples. Everything showed up correctly after this. Now I see there is also a 
/schemas
folder inside the Next.js template with it’s own content type definitions for Post and Author, and a couple of presentational components that pull from this schema’s content types instead of the deployed Sanity schema that the project links to. Aside from redirecting those content type definitions to ones that come in from the Sanity Studio repo, is this 
/schemas
folder with the duplicate schema definitions necessary to keep on the frontend? It looks like it’s packaged in as an embedded studio for Sanity Studio functionality out of the box without a corresponding sanity.io deployment.

My question is this: where I already have the second repo with my headless CMS deployed, is this necessary to keep 
/schemas
on the frontend, or can I rip it out? I’m leaning towards ripping it out, as another tutorial mentions creating a 
client.ts
file which will fetch from the content lake, and does not have a 
/schemas
folder in the front end. I’m pretty certain it’s not needed but am I missing something? I can’t seem to find a straight answer online as to whether or not this is redundant in a headless deployed CMS scenario.
AI Update

You're absolutely right to be leaning towards removing that /schemas folder from your Next.js frontend! Let me clarify what's happening here.

The /schemas folder in that Next.js template exists because it's set up as an embedded studio - meaning the Sanity Studio runs directly within your Next.js application rather than as a separate deployment. This is a valid approach, but it's not what you need since you already have a separate, deployed Sanity Studio at *.sanity.studio.

In a headless CMS setup (which is what you're doing):

  • Your Sanity Studio is deployed separately and manages your content schema
  • Your Next.js frontend only needs to fetch data from Sanity's Content Lake using a client
  • The frontend doesn't need to know about or define the schema at all

You can safely remove the /schemas folder from your Next.js project. Your frontend only needs:

  1. A Sanity client (usually in a client.ts or similar file) configured with your project ID and dataset
  2. GROQ queries to fetch the data you need
  3. TypeScript types (optional but recommended) - these can be auto-generated from your deployed schema using Sanity TypeGen

The tutorial you mentioned with just a client.ts file is the more common pattern for headless setups. Your Next.js app queries the Content Lake at runtime, and all schema management happens in your separate Studio deployment.

The only time you'd keep schemas in your Next.js project is if you're intentionally running an embedded studio (like for a monorepo setup where Studio and frontend live together), but that doesn't sound like your architecture.

So yes - rip it out! Your Next.js app will be cleaner and you'll avoid the confusion of maintaining duplicate schema definitions. Good instincts on this one, and congrats on the new job!

Show original thread
10 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?