Model custom-template pages as singletons
Pages that don't decompose into sections. An About page with a bespoke layout, a Pricing page with a custom grid, and a Contact page with an embedded form don't belong in the page builder. Forcing them into a sections array creates a schema that technically compiles but is editorially meaningless: editors can't compose the layout through sections because the layout is the code.
The right model: one singleton document type per custom page. The document holds only the content fields the Next.js template actually reads. The layout is hardcoded. The document has a fixed _id so there's exactly one instance.
Pull up your classification output from the previous lesson and identify the pages in bucket (d). Then run one prompt per custom page, or batch them:
@webflow/export/about.html @webflow/export/pricing.html @sanity/schemaTypes/objects/seo.ts
Each of these pages has a unique, custom layout that can't be composed from reusable sections. For each page, identify all the editable content fields — headings, body text, images, CTAs — by reading the HTML. Write a singleton document type schema for each page in TypeScript using defineType and defineField. Each schema should:
- Have a descriptive name (e.g. aboutPage, pricingPage)- Contain only fields the template will query — no sections array- Include an seo field using the shared seo type from /sanity/schemaTypes/objects/seo.ts- Save to /sanity/schemaTypes/documents/ (e.g. aboutPage.ts, pricingPage.ts)
Update index.ts to import and register all new types.With page documents for the page builder and singleton documents for custom pages, editors need one place to find everything. Use Structure Builder to create a "Pages" section that aggregates all of them:
@sanity/sanity.config.ts @sanity/schemaTypes/index.ts
Update sanity.config.ts to add a "Pages" section to the Studio sidebar using structureTool. The Pages section should contain:
- A "Landing Pages" list showing all documents of type page (the page builder type)- One entry per custom-template singleton (e.g. "About", "Pricing", "Contact") — each opens its singleton document directly using documentId matching the type name (e.g. documentId: 'aboutPage')
Use S.listItem, S.documentTypeList, and S.document().schemaType().documentId() as appropriate. Singletons should not be creatable from the list view.The output looks roughly like this, with your actual type names substituted in:
// sanity.config.ts (structure excerpt)S.listItem() .title('Pages') .child( S.list() .title('Pages') .items([ S.listItem() .title('Landing Pages') .child(S.documentTypeList('page').title('Landing Pages')), S.listItem() .title('About') .child( S.document() .schemaType('aboutPage') .documentId('aboutPage') ), S.listItem() .title('Pricing') .child( S.document() .schemaType('pricingPage') .documentId('pricingPage') ), ]) )Editors see one "Pages" entry in the sidebar. Clicking in shows all page builder pages plus named entries for each custom page. The schema difference is invisible to them.
Confirm Studio compiles and each singleton opens correctly before moving on. If a singleton shows a "Create new document" button instead of opening the document directly, check that documentId matches the fixed _id you'll assign during import.
Next, you’ll model navigation as its own document type so editors can manage menus independently.