Back to blog

Shopify Development

Nested Sections Are Here: Landing Pages Without a Page Builder

June 8, 2026 · 10 min read

Every Editions release has a headline act, and this summer it was AI merchandising. Most of the coverage followed it. But the change that will save merchants the most actual money sat further down the announcement page, written up almost as a footnote: sections can now nest inside other sections. We covered the subscription side of Summer Editions 2026 separately. This post is about the theme change alone, because it deserves it.

For five years the Online Store 2.0 section model has been strictly flat. A template is a vertical stack of sections, each section holds blocks, and that is the entire grammar. Anything more ambitious — a two-column row where each column has its own stack, an offer grid built from reusable cards — meant a developer hard-coding it as a one-off, or a page-builder app. Most brands chose the builder.

PageFly, GemPages and Shogun built genuinely good businesses on that gap. Summer Editions 2026 closes most of it. The question for any brand paying a builder subscription is no longer whether to rebuild natively, but which pages to rebuild first, and whether the builder still earns its fee for whatever remains.

Composite figures from the theme audits we run. Individual stores vary; the direction rarely does.

---

What flat sections could never do

Shopify has been inching toward this for a while. Section groups arrived in 2023, but only for the header and footer areas. Theme blocks landed in the Winter '25 release and let blocks nest inside blocks via the @theme type. Useful, but the nesting stayed trapped inside a single section's scope, and adoption across the theme store was patchy. The fundamental unit of layout, the section, remained a full-width slice of page that could never contain another section.

That single constraint is why page builders exist at the scale they do. Merchants did not buy PageFly for its colour pickers. They bought it because it was the only way a marketer could place two independent content stacks side by side without filing a ticket.

"The page builder's core feature was never design. It was nesting."

Nested sections change three things at once. First, layout composition: a row section can hold columns, and each column can hold any section the theme provides, to a sensible depth. Second, reusable composed units: a group of nested sections can be saved as a preset, so a "testimonial wall" or an "offer stack" is built once and inserted anywhere as a single object. Third, the theme editor now renders the page as a tree, so marketing can rearrange content at every depth rather than only at the top level.

None of these is exotic. They are simply the things builders charged for.

The flat section model versus the nested tree. The right-hand structure is what brands have been paying page builders to simulate.

---

What a page builder actually costs

The subscription is the cheapest part. In the theme performance audits we run, a page builder reliably shows up in three other places on the invoice, none of them itemised.

The first is the injected runtime. Most builders register app embeds that load their JavaScript on every page of the store, including pages the builder has never touched. We have audited stores where the builder's runtime was the third-largest script on the product page despite zero builder-built PDPs. It is the same pattern of ambient cost we describe in our piece on how apps degrade storefront performance.

The second is duplication. Builders ship their own grid system, typography scale and spacing utilities on top of the ones your theme already provides. The customer downloads two design systems to render one page. On builder-heavy landers we commonly see north of 200KB of CSS and runtime JavaScript that a native rebuild simply would not need, and the late-mounting hero patterns most builders use are a direct tax on Core Web Vitals: in our experience, somewhere between half a second and a second and a half of LCP.

The third is lock-in. Builder pages live in the builder's data model, not in your theme. Uninstall the app and you are left with orphaned static exports at best, dead URLs at worst. Migrating means rebuilding every page anyway, so brands defer, and the fee quietly compounds for another year.

Uninstalling is the part nobody prices in.

A composite of typical results from rebuilds we have audited. Exact numbers depend on the builder and the theme; the gap rarely closes on its own.

---

Three rebuild patterns for the pages builders usually own

Across the stores we work with, builder usage concentrates on three page types: offer landers for paid traffic, plan comparison pages, and editorial-style content bolted under a product page. Each has a clean nested-section equivalent.

Three nested-section blueprints covering the page types that account for most builder usage. The shell owns layout and brand decisions; the leaves own words and images.

Offer landers

Build a lander shell section that owns the things campaigns share: width, background, vertical rhythm, whether the header shows. Inside it, nest a claim hero and a repeatable offer card section that carries its own product reference, price anchor and CTA. Save the whole composed stack as a preset. Launching the next campaign becomes: insert preset, swap copy, publish. No app, no duplicated CSS, and the hero renders server-side so paid traffic is not staring at a mounting spinner.

Comparison pages

Subscription brands lean on these heavily — monthly versus prepaid, starter versus full plan. The nested pattern is a comparison shell that accepts one plan column section per option, with each column holding a price block, a feature checklist and a CTA. Because the column is a single section type, every column is visually consistent by construction, and adding a fourth plan is a marketing task rather than a development ticket.

Editorial PDP supplements

The long-form story content under the buy box — founder note, sourcing story, ingredient breakdown, UGC wall — is where builders most often creep onto money pages, and where their payload does the most conversion damage. Rebuild it as a nested story group: one parent carrying the editorial styling, children carrying the content, the whole thing saved as a preset and reused across the product range. The buy box itself stays untouched theme code.

---

Schema rules that keep marketing self-sufficient

Nesting is power, and power is how theme editors become unusable. The point of rebuilding natively is that marketing ships pages without you; a careless schema gives them a tree so deep and so configurable that they go straight back to asking for a builder. These are the rules we apply when structuring nested schemas for clients.

• Cap nesting at three levels. Shell, row, leaf. Beyond that the editor tree reads like a file manager and nobody self-serves anything.

• Style at the top, copy at the leaves. The parent section carries colour scheme, spacing and width settings; children inherit them. Leaf sections expose words, images and product picks, nothing structural.

• Ship presets for whole patterns, not parts. Marketing should insert "Offer stack (three cards)", never assemble twelve raw sections from scratch. The preset is the product.

• Name by job, not implementation. "Plan column" and "Proof row", not "Flex child v2". The editor tree is documentation; write it for the person who did not build it.

• One CSS source. Nested units consume the theme's tokens. The moment a nested section carries its own font sizes, you have rebuilt the page-builder problem inside your own theme.

Constrained nesting is the whole game. The builder's failure mode was giving marketers infinite freedom and letting the brand drift one pixel-pushed lander at a time; a good nested schema gives them speed inside guardrails instead.

---

When a builder still earns its fee

We are not arguing every store should uninstall its builder tomorrow. There are two situations where the fee is still justified, and one where it is at least defensible.

The strongest case is heavy A/B iteration without developer support. If your growth team launches and kills landers weekly, the builders' duplication workflows, visual editing and built-in testing hooks deliver a velocity that a theme tree managed through the editor will not match. At that cadence the performance tax is real but the experiments pay for it — provided the winning variants eventually graduate into native sections rather than living in the builder forever.

The second is sheer template count. A brand running hundreds of audience-specific campaign pages, regenerated every season for paid social, will outgrow what a tidy nested theme can sensibly manage. Builders are databases with a design surface; at that volume, the database is the feature.

The defensible case is teams with no theme access at all — locked-down stores, franchise setups, agencies working without code deployment rights. Even then, the rule we give clients is simple: keep the builder off the money pages. Home, PDP and collection templates should be native regardless, because that is where the payload costs conversions you can actually count.

A builder is a velocity tool now, not a layout tool.

---

The flat-section era is over

Expect the next year to move quickly. Theme developers will start shipping composed pattern libraries (landers, comparison shells, editorial groups) as presets, the way component libraries matured in the wider frontend world. The builders will respond by repositioning around testing, personalisation and campaign workflow, because layout alone no longer clears the bar. Both outcomes are good for merchants.

In the meantime, the exercise worth doing is blunt. List the pages your builder actually maintains. Price what a native rebuild of each would cost against the subscription, the duplicated payload and the LCP you are giving away on every visit. Then check what the builder's runtime is costing on all the pages it does not even touch.

In most of the audits we run, that maths points the same way: the builder is doing layout work the platform now does for nothing, and charging you twice for it — once in dollars, once in conversion rate. Nested sections did not make page builders obsolete. They made them optional, and optional tools have to earn their keep.