Page Builder
How operators turn content records into rendered pages.
Page Builder in SG-Modules is the visual composition surface — the place operators drag, drop, configure, and preview the layout that surrounds and renders their content. Where SG-Builder is the editor itself (the canvas, the toolbars, the component library), and SG-Core is the engine that resolves templates and renders, SG-Modules positions Page Builder as a platform module: what kinds of work belong on it, what kinds don't, and how it connects to the records and templates around it.
What is this for?
Read this page when you need to understand Page Builder as a platform module — what work goes through it, what doesn't, who in an operator team owns the surface, and where it fits between content authoring and final rendering.
Good use cases
- You are scoping which work belongs on Page Builder versus elsewhere (templates, custom code, content records).
- You are explaining to a stakeholder why Page Builder is the visual layer rather than the content layer.
- You are evaluating component coverage for a planned site build.
- You hit a question like "Should this section be a Page Builder block or a Template?"
What NOT to use this for
- Component-by-component reference (what each block does, what traits each carries) — that lives in SG-Builder Component Library.
- Editor mechanics (toolbars, keyboard shortcuts, panels) — that lives in SG-Builder Builder Workspace.
- Template-resolution rules (which template renders a record) — that lives in SG-Core Templates.
How this connects to other features
- SG-Builder Overview — the editor surface Page Builder is delivered through.
- SG-Builder Component Library — the inventory of blocks Page Builder offers.
- SG-Core Templates — the layouts Page Builder authors and the resolver consumes.
- SG-Admin Pages — the operator surface that lists Pages and routes them into the Page Builder editor.
Module role
Page Builder occupies a specific layer of the platform: it is the visual composition module, sitting between content records (Pages, Posts, Custom Object records) and the rendered site. Records carry data; templates declare layout shape; Page Builder is where operators assemble the layout shape for a specific record or template.
That layered role is deliberate. Content stays clean — a Page record carries title, body, fields. Layout stays separable — the same Page can render under different templates, and the template's Page Builder body decides the rendered shape. Visual changes don't churn content; content changes don't churn layout.
The SG-Modules positioning treats Page Builder as one module among several (alongside Forms, SEO, Phone Taps, Tracking Consent, Templates, Popups, Redirects, Custom Fields, Locations, Events, Analytics, Blacklist). Each module is a self-contained operator surface; the platform-level promise is that they compose without leaking into one another.
Composition boundary
Page Builder handles visual composition. That includes: laying out sections, columns, and components; binding content into placeholder anchors; configuring spacing, color, typography at the design-token level; setting responsive behavior at supported breakpoints; previewing the result.
Page Builder does not handle content authoring (the record's title, body, fields go through the record's edit surface, not the builder), template resolution (the engine picks which template a record renders against, not the builder), data-source configuration (the builder consumes content but does not define the record class), or low-level styling primitives (color, font, spacing tokens are configured at site level, not per-page).
When to leave Page Builder
Three signals tell operators to step out of Page Builder for a piece of work:
- It needs to apply site-wide. Page-level edits in Page Builder affect one page or one template. Site-wide changes belong in design tokens or in the master template.
- It is content, not layout. A piece of copy, a published date, a related-record link — those live on the record, not in the page body.
- It needs custom code beyond the configuration surface. Page Builder offers a Custom Code component for cases where the configuration surface doesn't reach; for anything beyond that, the operator works through the admin Custom Code, not through the builder.
Authoring surfaces
Page Builder is reached through three operator paths:
Per-record authoring — opening a Page, Post, or Custom Object record and clicking the "Edit in Page Builder" affordance. The builder loads the record's body and any template-bound layout, lets the operator compose, and saves the result back to the record on publish.
Template authoring — opening a Template record from the Templates module. The builder loads the template body. Saving updates the template; on next render, every record bound to the template picks up the new layout.
Component-library authoring — opening a saved component from the SG-Builder component library. The builder loads the component body in isolation. Saving updates the component; on next render, every template that uses the component picks up the new shape.
Each path uses the same editor, the same component palette, the same trait system. The difference is what the save target is — record body, template body, or component body — and what the propagation surface is — one record, every record bound to the template, or every template using the component.
Composition primitives
Page Builder exposes a fixed vocabulary of composition primitives operators combine to build layouts.
Sections are the top-level horizontal bands of a layout — a hero section, a feature section, a footer band. Each section sets its own background, padding, and width. Sections stack vertically; they do not overlap.
Columns divide a section horizontally. A section can contain one column (full-bleed content), two columns, three columns, or any layout the column primitive supports. Each column carries its own width contribution; columns within a section sum to the section's width.
Components are the leaf-level building blocks — headings, body text, images, buttons, forms, navigation, cards, galleries, custom code blocks, and the rest of the component library. Components nest inside columns.
Containers group components for shared traits — a card container that holds an image, heading, and button as a single hover unit; a section container that applies background and padding once to a stack of inner sections.
Saved components are operator-saved compositions — a hero block used across the site, a CTA pattern reused per landing page. Saved components carry their own definition; updating the definition propagates to every place that uses it.
Responsive controls
Each primitive carries per-breakpoint configuration. Operators set the desktop layout first, then adjust at tablet, mobile-large, and mobile-small as needed. The builder previews at each breakpoint; the preview matches what the rendered site shows on the corresponding device.
The breakpoints are platform-defined and consistent across the site. Per-page custom breakpoints are not supported; the platform-default breakpoint set is what every layout works against.
Output discipline
Page Builder output quality has direct downstream consequences. A Page Builder layout that bloats the rendered HTML costs visitors load time. A layout that nests components excessively increases maintenance friction. A layout that breaks at narrow viewports loses mobile visitors.
The platform's design tokens, default breakpoints, and component traits are tuned for output discipline — most layouts compose into clean rendered HTML by default. The cases that produce poor output are usually the ones where operators reach outside the configuration surface (custom CSS overrides, deep nesting beyond what the components were designed for).
Maintenance cost
Page Builder layouts that follow component-based composition are cheap to maintain — content updates land via record edits, layout updates land via template edits, design-token updates apply site-wide. Layouts that override at the page level (per-page custom CSS, per-page hardcoded content) cost operators each time site-wide design changes.
The platform documentation generally recommends operators keep layout work inside Page Builder's configuration surface and reach for custom code only when the configuration surface genuinely doesn't cover the case.
Constraints and boundaries
Page Builder is the visual composition module. The editor itself lives in SG-Builder; the engine that renders the result lives in SG-Core; the content records the layouts apply to live across SG-Core (Pages, Posts) and operator-defined in the admin (Custom Objects).
What this module does
- Provides the visual canvas for composing layouts.
- Offers the platform-default component library.
- Manages per-breakpoint responsive configuration.
- Authors content for record bodies, template bodies, and saved component bodies.
- Produces rendered output the SG-Core template resolver consumes.
What this module does not do
- Author content (record fields, titles, bodies) — that is the record's edit surface.
- Resolve which template a record renders against — that is SG-Core.
- Define the platform's design tokens — those live in site settings.
- Persist record data — records persist through SG-Core's standard storage.
Public boundary
The module is publicly documented at this depth (its role, its composition primitives, its authoring surfaces). Lower-level details (component internal IDs, trait schemas, output HTML structure) are not published.
Examples
Example 1 — Marketing page composed from saved components
A marketing team uses Page Builder to compose a campaign landing page. The body is built from saved components (hero block, feature grid, testimonials carousel, CTA section). The team edits content through the record's title and body fields; visual treatment comes from the saved components. Any future site-wide saved-component update propagates without per-page re-authoring.
Example 2 — Per-record override of a templated layout
A site uses a default Post template for blog posts. One launch post needs a heroic hero treatment. The operator opens that post in Page Builder, adds a hero section above the templated body, and publishes. Other posts continue rendering through the default template; the launch post carries the override.
Example 3 — Authoring a Template body
The site's design lead opens the Page template and rebuilds the body — new section structure, different component palette, refined design-token usage. Saving updates the template. On next render, every Page bound to the template picks up the new layout. Per-record overrides on individual Pages persist where present.
Example 4 — Component-library evolution
The site's design system maintainer adds a new card variant to the saved component library. Templates that reference card components by saved-component ID immediately render the new variant; templates that hardcoded the prior layout don't, by design.
Internationalization
Page Builder layouts compose against per-language record content when sites are configured for multiple languages. The same template body renders for every language version of a record; the binding anchors fill from each language's content.
Layout choices that depend on text length — fixed-height heroes, tight column proportions, columns that wrap text into limited space — show stress when a language version of the content is significantly longer or shorter than the language the template was originally designed against.
The platform documentation generally recommends operators design templates against the language with the longest expected expansion (often German for English-source sites), then verify the layout holds across other languages. Per-language template overrides are supported but rarely needed when the original layout is generous about text-length variance.
For right-to-left languages, the platform's design tokens carry directional values; component layout flips automatically when the language is RTL. Operators verifying RTL behavior should preview at the RTL language to catch any custom-code components that don't honor the directional tokens.
Editorial workflows for translated pages — who translates, who reviews, when each language version goes live — are operator-side concerns.
Page Builder treats each language version as its own record body for save and revision purposes.
Accessibility
Page Builder layouts inherit the platform's accessibility defaults. Components ship with accessibility built in — semantic markup, keyboard interaction, focus management, ARIA labels where they are needed.
Operators do not configure accessibility behavior at the component level for most cases. The platform-default treatment is intentionally non-optional for the behaviors that matter most (focus order, semantic heading structure when components are used as documented, keyboard reachability of interactive elements).
Where operator choice does affect accessibility, the configuration surface guides the right choice — for example, image alt text is requested at upload time rather than left silently empty, and color choices flag insufficient contrast against the chosen design tokens.
Custom Code blocks are the exception. Custom HTML or CSS in a Custom Code block does not pass through the platform's accessibility checks. Operators using Custom Code carry the responsibility for the accessibility of what they author there.
Performance considerations
Page Builder output is what visitors download. Operators composing layouts have direct influence over rendered page weight, render time, and visible-paint speed.
The platform's component library is built with these costs in mind — components ship lean, defer non-critical loading where possible, and follow modern responsive image patterns. Operators who stay within the configuration surface generally produce performant pages by default.
Two patterns most often introduce performance cost: deeply nested compositions (many sections inside many containers inside many columns) and unoptimized media (large images uploaded without compression). The configuration surface offers natural ceilings for nesting depth; the Media Library applies optimization automatically when operators upload through it.
Operators tuning page performance should treat Page Builder as the layout dial and the Media Library as the asset dial; both surfaces compose into the rendered output. Custom Code blocks are the third dial — and the one most often responsible for unexpected weight, since custom HTML and CSS bypass the platform's optimization defaults.
Versioning and history
Every Page Builder save creates a revision on whatever record is being edited — the page record, the template record, or the saved-component record. Revision history is the same revision system every other SGEN record gets; the editor surfaces it through a revision panel that lets operators compare versions and roll back.
For per-record edits, rollback affects only that record. For template-body edits, rollback shifts every record bound to the template on next render — the template body returns to its earlier state and resolution picks up the rolled-back version. For saved-component edits, rollback affects every template that references the component.
Operators planning a major template or saved-component change should treat the change as having site-wide effect from the moment it publishes. Staging — duplicating the template, editing the duplicate, swapping bindings when ready — is the path that lets operators preview without committing the change site-wide.
Preview semantics
The Page Builder preview pane shows the current edit state rendered through the platform's standard render pipeline. The preview is faithful — what the operator sees in preview is what visitors will see when the page publishes. There are no "preview-only" components or render shortcuts.
The preview switches between configured breakpoints. The operator picks a breakpoint; the preview shows the layout at that breakpoint with the configuration that breakpoint carries. Switching breakpoints does not regenerate the layout; it shifts which configured state the preview shows.
Cross-record context (related-record links, dynamic content, search-index integrations) renders in preview using the same data the live site would. The preview is connected to the same backing store the rendered site reads from.
Operator team roles
Page Builder is used by different operator roles for different kinds of work, and how a team divides the surface up shapes the discipline they get from it.
Design system maintainer — owns saved components and the design tokens. Updates to the saved component library propagate site-wide; design-token tuning shifts every component at once. This role spends most of its Page Builder time in the saved-component library and in template bodies, rarely in per-record bodies.
Template author — owns the template bodies for each post-type. Builds layouts that compose saved components, configures responsive behavior, sets per-template content anchors. This role works at the template level; per-record overrides are not the template author's concern.
Content editor — works inside the record edit surface, occasionally drops into Page Builder for per-record overrides. Most content edits don't reach the builder; the role spends most time in the record's title and body fields.
Marketing operator — uses Page Builder per-record to build campaign pages, landing pages, launch posts. This role does the most per-record composition work; the discipline that supports it is a strong saved-component library and clean template defaults.
Cross-role discipline
The roles divide cleanly when the platform's propagation surfaces (templates, saved components, design tokens) carry the design vocabulary and per-record overrides stay rare. They blur when one role reaches into another's surface — for example, a content editor doing per-record visual tweaks that should have been a saved-component update.
The platform doesn't enforce role separation; teams set their own discipline. The propagation surfaces are designed to make the disciplined path the cheap path: templates and saved components are easier to update than per-record bodies, so a team that uses them well pays less cost over time.
Common patterns
Templates-first composition — most layout work lives in templates; record-level Page Builder use is rare. Suitable for sites with strong design discipline; produces consistent rendering.
Hub-and-spoke composition — templates carry the spine, record-level overrides handle exceptional pages (homepage, marketing campaigns, launch posts). The most common pattern at scale.
Library-first composition — saved components carry the bulk of design vocabulary; templates are mostly composition of saved components. Useful for sites with frequent design-system updates; the library is the propagation surface.
Per-record composition — every page authored independently. Suitable only for very small sites; loses the propagation benefits of templates and saved components.
Edge behaviors
What happens if a saved component used in many templates is deleted? Templates that referenced the saved component fall back to nothing for that block. Operators see the missing block in the editor and replace or remove it; the site continues rendering.
What happens if a record-level override conflicts with a template change? The override wins for that record. Other records continue picking up the template change.
What happens if breakpoint configuration is set at one breakpoint but missing at another? The unconfigured breakpoints inherit from the next-larger configured breakpoint. The platform default is desktop; mobile breakpoints inherit unless explicitly configured.
What happens if Custom Code components reference site-level CSS that gets refactored? The custom code keeps rendering with whatever it directly contains; site-level CSS changes affect components that read from the platform's design tokens, not custom code.
Documentation guidance
This page is the SG-Modules-level positioning. For editor mechanics open SG-Builder Builder Workspace. For component-by-component reference open SG-Builder Component Library. For template resolution open SG-Core Templates.
Reading order
Read this page when you need a platform-level frame for Page Builder — what kinds of work belong on it, what kinds don't, where it fits between content and rendering. Pair with the SG-Builder editor docs for authoring mechanics and the SG-Core Templates page for resolution behavior.
Related reading
- SG-Builder Overview — editor surface.
- SG-Builder Builder Workspace — editor mechanics.
- SG-Builder Component Library — component reference.
- SG-Core Templates — template resolution at the engine layer.
- SG-Admin Pages — the records Page Builder works against.
Vocabulary cross-reference
- Visual composition — the act of arranging components in a Page Builder layout to produce the rendered site.
- Layout authoring — Page Builder work that targets template bodies (site-wide effect) versus record bodies (single-record effect).
- Component-based pages — pages assembled from the component palette rather than authored as raw markup or code.
- Responsive layout — per-breakpoint configuration that the rendered site honors at the matching viewport.
- Composition primitive — Section, Column, Component, Container, Saved component — the vocabulary Page Builder offers.
- Output discipline — the practice of keeping rendered output clean by composing within the configuration surface rather than overriding around it.
Maintenance discipline
Update this Reference when:
- Page Builder gains a new authoring surface beyond per-record / per-template / per-component.
- The composition primitive set changes (new section type, new container behavior).
- The breakpoint set changes platform-wide.
- The output-discipline guidance shifts (e.g. the platform officially deprecates per-page custom CSS overrides).
- The SG-Modules positioning changes — for example if Page Builder ever absorbs responsibilities currently in the admin or SG-Core.
Scope
This Reference covers the platform-level shape of page builder: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.
Where to find it
Open SGEN' SG-Admin and navigate via the sidebar group that owns this surface. For platform-level reference (this page), the entry point is the SGEN documentation index at docs.sgen.com. For the operator-facing configuration screen, the entry point is the corresponding SG-Admin module page linked in Related features above.