Build a page builder with a sections array

A sections array on a page document lets editors pick any defined section type, add sections in any order, and rearrange by drag-and-drop. AI generated your section schemas in the previous lesson. This lesson wires them into a page document.

This lesson covers the page builder for compositional pages: ones built from repeatable section blocks (buckets (a) and (b) from the classification step). If your site has custom-designed pages that don't decompose into sections, an About page with bespoke layout, a Pricing page with a unique structure, those become singleton document types with their own schemas, covered in the next lesson. Both appear together in the Studio under a single "Pages" section, so the distinction is invisible to editors.

A note on scale. With 50+ static pages, the value of the page builder isn't that you enumerate every page. It's that most pages share a small number of distinct section types. A 100-page marketing site probably has 12 to 18 unique section types. Focus the component inventory on section types, not page count.

During migration, you don't reconstruct pages manually. extract-static-pages.js reads each page's DOM from the HTML export, matches component instances to their section types using the component type map, and seeds the sections array for every static page automatically. Chapter 4 covers this in detail.

The long-term editorial benefit: once the section schemas and Next.js template are in place, adding a new page after launch is just creating a document in Studio and picking sections.

Before running this prompt, make sure you've completed the schema extraction step (Step 2) from the "Map collections to Sanity document types" lesson. That step may have already extracted a shared seo type. This prompt checks for it and references it rather than re-inlining the fields.

@webflow/api/components.json @webflow/api/pages.json @sanity/schemaTypes/objects/ @sanity/schemaTypes/documents/

Using the section types identified from the components file, write a page document type schema in TypeScript using defineType and defineField. The page should have:

- A title field (string)
- A slug field (no source)
- A sections array that accepts all the section types you identified
- An seo field — check /sanity/schemaTypes/objects/ first. If a shared seo type exists there, use type: 'seo' to reference it. If not, inline the object with metaTitle, metaDescription, ogImage, and noIndex fields.

For each section type, write it as a separate object schema file saved to /sanity/schemaTypes/sections/. Save the page document type to /sanity/schemaTypes/documents/page.ts. Then update index.ts to import and register both the page type and all new section types.

If a shared seo type already exists in objects/, the page schema references it by name. If not, the fields are inlined. Both are valid. Consistency across schemas is what matters:

// sanity/schemaTypes/documents/page.ts — with a shared seo type already extracted
import { defineType, defineField } from 'sanity'

export const page = defineType({
  name: 'page',
  title: 'Page',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
    defineField({
      name: 'sections',
      title: 'Page Sections',
      type: 'array',
      of: [
        { type: 'heroSection' },
        { type: 'featureGrid' },
        { type: 'testimonialBlock' },
        { type: 'ctaBanner' },
      ]
    }),
    defineField({ name: 'seo', type: 'seo' }),
  ]
})

The type names in the of array (heroSection, featureGrid, etc.) must exactly match the name values in your section schemas from the previous lesson. If they don't match, Studio will show a validation error. Each section type should be type: 'object'. Sections are embedded in the page, not standalone documents with their own URLs.

Confirm Studio compiles before moving on. The most common error here is a type name mismatch between the section type name in page.ts and the name value in the section's own schema file.

Next, you’ll create singleton document types for custom-template pages, then wire everything into a single Pages section in the Studio.