Skip to main content

Builder Overview

The builder is where your storefront is designed: open it from the dashboard and you're looking at your store as shoppers see it, with every part editable in place. This page explains the model behind it — what a page is, what sections and blocks are, and which parts of the store live outside any single page.

The one rule that explains the rest

Nothing you do in the builder reaches shoppers until you publish. Editing happens on a draft; the live store keeps serving what was last published. See Drafts & Publishing.

Pages and page types

Every store starts with its core pages: home, product, collection, cart, checkout, and thank-you. These are provisioned automatically, can't be deleted, and each carries required sections — a product page always has its product details section, a checkout always has its form. Required sections show a lock icon in the panel: you can restyle and configure them, but not remove them.

Beyond the core set you can create as many custom pages as you like — landing pages, about pages, campaign pages. Custom pages are fully yours: any sections, any order, deletable, and they can override the theme's colors and fonts per page (useful for a campaign that shouldn't look like the rest of the store).

Each page also carries its own SEO fields and visibility toggle — a page can be hidden from shoppers while you work on it, independently of publishing.

Sections and blocks

A page's body is a stack of sections — hero, featured collection, FAQ, rich text, and a few hundred more, all in the Add section panel. Most sections are composable: they contain blocks you can add, remove, reorder, and configure independently.

The clearest example is the featured collection: the section owns the layout and picks the collection; inside it, a header block holds the title and "View all" button, and a product-card block defines what every product card shows — image, title, price, add-to-cart, badges. Edit the card block once and every product in the grid follows.

Selecting anything — section or block — opens its settings in the panel: content, layout, style, and (for most sections) spacing and a color scheme.

The navbar and footer are not sections of a page. They're global wrappers, composed around every page, edited once for the whole store. That's why they appear pinned at the top and bottom of the layers panel rather than inside the page tree.

Per page, you can override this three ways:

ChoiceEffect
Use global (default)The store-wide navbar/footer renders
HiddenThis page renders without it — typical for focused landing pages
CustomThis page gets its own copy, seeded from the global one, edited independently

Inside the navbar and footer, individual blocks (logo, menu, copyright…) have their own eye toggles, so you can hide a piece without hiding the whole bar.

Menus are authored in the dashboard (Menus page) as nested trees, then referenced from the builder — the navbar's menu block has a menu picker. Edit the menu in one place; every surface that references it updates.

Where the look and feel lives

Colors, fonts, buttons, spacing and the rest of the store-wide design live in Theme settings, not on individual sections — see Themes & Theme Settings. The rule of thumb: if a change should apply everywhere, it belongs in theme settings; if it belongs to one section, it's in that section's panel.

For developers and AI assistants

Everything above is also reachable programmatically: the MCP server exposes the same pages, sections, themes, and drafts to AI assistants, with the same safety model — writes land on a draft and a human publishes. Designs the built-in sections can't express can be built as Custom Liquid components.