Site builder overview

The Build Me Web site builder is how marketing and content teams compose pages without waiting on a release train for every headline change. Pages inherit a template shell, sections stack into layouts, global styles keep brand consistent, and publishing moves work from draft to preview to production with a full release history.

This guide explains how those pieces fit together so you design maintainable sites instead of one-off canvases that become fragile after the third campaign.

Pages & templates

Every site is a collection of pages that inherit a template shell: header, footer, SEO defaults, and shared scripts. Marketing pages are composed of sections. Blog posts, docs, and other structured types use dedicated content models with their own fields and listing templates.

Templates define the chrome; pages define the story. When you create a page, you choose a template (or the site default) and then assemble sections inside the content area. Changing the template later remaps chrome without deleting section content, but always preview — navigation density and footer columns can shift layout assumptions.

1. Create pages from Site Pages with a clear internal title and public slug.
2. Keep slugs stable after publish; redirects are available when URLs must change.
3. Use folders or prefixes for large sites (/services/..., /resources/...) so navigation stays scannable.
4. Mark utility pages (legal, preferences) with appropriate noindex only when they should not compete in search.

Site
├── Template shell (header, footer, SEO defaults)
├── Pages (Home, About, …)
│   └── Sections (hero, features, FAQ, CTA)
└── Content types (blog, docs, case studies)

Localization: each locale can override copy and media while sharing structure. Prefer shared section schemas so translators are not inventing new layouts.

Sections

Sections are reusable blocks — hero, features, logos, testimonials, FAQ, pricing, CTA, and custom blocks on Growth and Managed engagements. Reorder them in the canvas or as a structured list for accessibility and keyboard users who prefer list editing.

Prefer composing from the section library over bespoke HTML. Library sections already follow spacing tokens, heading hierarchy, and responsive rules. Custom sections should still consume brand tokens so a theme refresh does not leave orphans.

• Hero: one headline, one supporting sentence, one CTA group — avoid stuffing stats into the first viewport unless the page is explicitly a dashboard.
• Features: three to six items with consistent iconography and parallel grammar.
• FAQ: real questions from sales and support; wire FAQ schema only when content is visible on the page.
• CTA: restates the offer and links to a form, calendar, or commerce path.

Nesting: most sites stay flat (sections in a column). Multi-column sections exist for comparisons and pricing; avoid nesting interactive cards inside other interactive cards — focus order and mobile stacking become unpredictable.

Visibility rules can hide sections by audience or locale. Use sparingly; too many forks make QA expensive. Document every rule in the page notes.

Global styles

Brand tokens — color, type, radius, spacing, elevation — cascade to every section. Prefer tokens over one-off hex values so themes stay consistent across locales and future rebrands.

Typography scales should map to semantic roles (display, title, body, label) rather than arbitrary pixel sizes per section. If a designer delivers a one-off size, ask whether it belongs in the scale.

Tokens
├── color.brand / color.accent / color.surface
├── font.display / font.body
├── space.xs → space.xl
└── radius.sm / radius.md

Dark surfaces and high-contrast modes, when enabled, should derive from tokens. Test forms and CTAs in both modes. Imagery: define default crop ratios for cards and heroes so editors cannot accidentally introduce CLS with oddly sized uploads.

Publishing model

Content moves Draft Preview Publish. Drafts are editor-only. Previews are shareable URLs that stay non-indexable. Publish pushes to the live hostname and records a release.

Scheduled publishes support campaigns: set the time in the workspace timezone, confirm dependent assets are already approved, and avoid scheduling during known DNS or payment provider maintenance windows.

Roll back to any prior publish from release history when a launch misfires. Rollback restores the prior artifact; it does not magically undo third-party side effects (emails already sent, ads already live).

• Draft reviewed on mobile and desktop previews
• SEO title and description set before first publish
• Schedule owner named for timed launches
• Rollback owner identified for the first hour after publish

Best practices

One job per page. Reuse sections instead of duplicating near-copies. Keep the section list short enough that a new editor can understand the page in under a minute. Pair this guide with Launch your first website for the end-to-end go-live path and SEO fundamentals for metadata discipline.

Prerequisites & preparation

Before changing production settings for the site builder, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.

Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.

Inventory templates in use, list custom sections, and decide who may publish vs who may only draft. Align on brand tokens before a redesign sprint.

Detailed walkthrough

Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.

1. Audit pages for duplicate near-copy sections that should become shared modules.
2. Normalize heroes to one headline, one supporting sentence, and one CTA group.
3. Move one-off colors to tokens; preview a theme tweak across key templates.
4. Practice draft preview publish on a low-risk page including rollback.
5. Document section visibility rules so QA knows what each audience sees.

Edge cases & failure modes

Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.

• Editors inventing one-off spacing that breaks mobile rhythm.
• Scheduled publishes without owners during the go-live minute.
• Locale clones drifting structurally from the primary locale.

QA checklist before you announce

• Happy path verified on mobile and desktop
• Failure path messaging reviewed
• Owners named for the first hour after launch
• Rollback or freeze path documented

Operating the change

After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.

Review the section library quarterly; deprecate unused custom blocks.

Composition beats novelty. Reusing library sections keeps accessibility and spacing correct when campaigns move fast.

Treat Home as a versioned product. Major layout changes belong on a draft swap with rollback, not live mid-campaign edits.

Structured content types (blog, docs) should not be forced into freeform marketing sections — use the right model.

Visibility rules are powerful and dangerous; every rule needs a named owner and an end date when it is campaign-specific.

Teach editors the publishing model once with a short internal loom or doc; most content incidents are process gaps, not tool gaps.

Keep the page section list scannable. If a new editor cannot understand the page in a minute, simplify.