Create a siteSettings singleton

Set up a singleton document for global site configuration and pin it in Structure Builder so editors always know where to find it.

Global configuration, site name, default OG image, and footer copy belong in a single document with a fixed _id. This prevents multiple conflicting documents from being created. Your HTML export contains all of this: the <title>, default meta tags, footer text, and any global branding are already in the rendered markup. Use it as the source.

Keep siteSettings narrow: site name, default meta description, default OG image, footer copyright, social links. These are things a layout component reads once on every render, and that editors almost never touch.

Shared content blocks, a CTA section, a newsletter signup, a promotional banner, are a different problem. Putting them in siteSettings breaks down quickly: where does the second CTA go? Editors will also expect siteSettings to hold configuration, not content. The right model depends on how the content behaves:

Always in the layout, never in the page body (e.g. a footer newsletter form). Give it its own singleton document type and query it alongside siteSettings
Appears on multiple pages but could vary. Model it as a normal section type; editors add it per page
Must stay in sync everywhere (change once, updates everywhere). Model it as a standalone document with a reference; page section arrays hold a _ref to it rather than the content itself

@webflow/export/index.html @webflow/export/[your-most-content-rich-page].html Looking at the <head>, header, and footer of these pages, identify global site configuration that belongs in a siteSettings singleton: site name, default meta description, default OG image, footer copyright text, and social links. Do not include content sections or marketing blocks — only configuration a layout component would read on every page. Write a siteSettings document type schema in TypeScript using defineType and defineField. Save it to /sanity/schemaTypes/documents/siteSettings.ts.

The AI should identify fields grounded in what's actually in your site, not a generic template. One thing to verify: analytics IDs, API keys, and third-party tokens should NOT be fields in this schema. If the AI includes them, remove them. Those belong in environment variables — storing them in the CMS means a content publish is in the critical path for a configuration change.

A typical output looks like:

// sanity/schemaTypes/documents/siteSettings.ts
import { defineType, defineField } from 'sanity'

export const siteSettings = defineType({
  name: 'siteSettings',
  title: 'Site Settings',
  type: 'document',
  fields: [
    defineField({ name: 'siteName', type: 'string' }),
    defineField({ name: 'defaultMetaDescription', type: 'text', rows: 3 }),
    defineField({ name: 'defaultOgImage', type: 'image' }),
    // Your site may have additional global fields — footer copy, social links, etc.
  ]
})

The fixed documentId ensures only one instance ever exists. Ask AI to wire it up:

@sanity/sanity.config.ts @sanity/schemaTypes/documents/siteSettings.ts Update sanity.config.ts to add a custom Structure Builder entry that pins siteSettings as a singleton. It should appear as a top-level item in the Studio sidebar, open the single document with documentId: 'settings.global', and not be creatable as a new document from the list view. Use the structureTool plugin with a custom structure callback.

Editors will always find it in the same place in the sidebar, and the fixed documentId prevents duplicates from being created.

Next you’ll decide how internal links work in your rich text before extraction begins.

Mark lesson as complete

You have 1 uncompleted task in this lesson

0 of 1

Ask AI to generate the schema

What to look for when reviewing the output

Pin it in Structure Builder