Every time I open a new Liquid file on a Shopify build, I have to make the same small decision: should this thing be a section, or a block inside another section? The default most themes fall into is wrong often enough that getting the choice right early saves days of refactoring later.
This is the rubric I use, the three most recent theme builds where I had to make the call, and the evidence that would make me revisit it.
The fork: sections vs blocks
Shopify's theme model has two granularities for merchant-editable content.
A section is a self-contained Liquid file with its own schema, settings, and render logic. It's a unit of layout the merchant can add, remove, or reorder on a template. Sections have hard limits (20 per template, 25 blocks each on legacy themes; larger on Online Store 2.0 but still finite).
A block is a sub-unit inside a section's schema. It gets its own settings and renders inside the parent section's loop. Blocks are good for variable-length lists (slides in a slideshow, items in a features grid) where the merchant needs to add or remove N of something without creating a new section each time.
The default most developers fall into is "make everything a block." It feels cleaner because it keeps the section count low and groups related content. It also works, at first. The schema stays compact, the theme editor looks tidy, merchandisers can add items without a developer.
The place it breaks is when a block needs to carry content that's really product-owned, not page-owned. Or when a block's settings start to echo fields that already exist as metafields on the resource the section is rendering. Or when a block's layout needs variant logic the schema can't express.
That's when the fork matters.
Option A: put it in a section
When to use this:
- The content is a layout the merchant will reuse on multiple templates (home, collection, landing page)
- The content owns its own presentation (hero banner, testimonial row, marquee)
- The merchant needs to control placement relative to other sections, not relative to other blocks
What you get: clean separation of concerns, a file you can read end-to-end, a section that the theme editor treats as a first-class unit. Sections show up in the "Add section" menu at the template level, so merchandisers can add them anywhere.
What it costs: more files. A theme with 40 bespoke sections is a theme with 40 Liquid files to maintain, 40 schema definitions, 40 places to check when a site-wide token changes. There's also a soft ceiling on how many sections a template can carry before the editor gets sluggish.
Option B: put it in a block
When to use this:
- The content is a repeatable sub-unit inside a larger layout (a testimonial inside a testimonials row, a logo inside a logo bar)
- The merchant needs to add or remove N of these without thinking about layout
- The block's settings are truly presentation-local, not content that should live on the product or collection
What you get: compact schema, easy merchandiser UX (add/remove/reorder within one section), one Liquid file per compound layout rather than one per child item.
What it costs: blocks inherit the parent section's lifecycle. If the parent section is removed from a template, all its blocks go with it. Blocks also can't host their own sub-blocks on legacy themes (Online Store 2.0 theme blocks changed this, but only for app-driven blocks, and the ergonomics are still awkward). Block settings are stored per-instance in the template's JSON, which means a block pattern repeated across ten templates duplicates its data ten times.
Option C: section bound to a metaobject or metafield
When to use this:
- The content is fundamentally product-owned, collection-owned, or entity-owned (a "key benefits" list per product, a "featured review" per collection)
- You want the merchant to edit the content once, on the resource, and have it render everywhere
- You want agents or scripts to write to the content via the Admin API (blocks can't be written to programmatically; metafields and metaobjects can)
What you get: one source of truth per resource. The section reads the metaobject or metafield at render time and loops over its entries. The merchandiser edits the resource in Shopify Admin, not inside the theme editor, which matches how most merch teams actually work.
What it costs: more moving parts. You need a metafield definition or metaobject definition set up first, a namespace convention, and a migration path for any existing in-section content. The theme editor stops being the single place the merchant controls the page; they also have to know to edit the product.
For mid-market and above, this usually wins. For a store at $50-500K where the merchandiser is the owner and is fine editing in one place, blocks are often the right call.
What I chose on the last three theme builds
Build 1: a DTC apparel rebuild with four hero layouts. The question was whether the four layouts (columns, scroll, collapsible, slider) should be four sections or one section with a block-level variant picker. This is the four-variant Shopify theme engagement. I chose four sections. The layouts differ enough internally that a single section's schema would have needed conditional blocks, which the theme editor handles poorly. Four discrete sections with shared snippets for common pieces (heading, CTA, video embed) kept each file readable and let the merchandiser pick the layout by adding a section, not by toggling a setting.
Build 2: a DTC consumables brand with a product-benefits section. The initial instinct was to put benefits in blocks inside the product template (one block per benefit). I moved this to Option C: a "product_benefits" metaobject, with a section that loops over whatever benefits the product references. This meant the merchandiser edited benefits on the product page, not on the template, and the same benefits rendered on collection-level preview cards without duplicating data.
Build 3: a homepage with a rotating promo bar. Three promo slides, each with a headline, a color, and a link. I started with blocks, five minutes later switched to a metaobject. The reason: the marketing team wanted the same promos to appear on the homepage, on category landing pages, and optionally inside email templates via API. A block couldn't be read programmatically; a metaobject could. Two hours of upfront work saved a week of "can we also put this in the email."
“If a block's settings are asking the merchandiser to fill in content that should live on the product or collection, the block is doing metafield work.
”
What I would revisit (and with what evidence)
The thing I'd watch in 2026 is Shopify's expansion of theme blocks (the new Online Store 2.0 block variant that can host its own sub-blocks and can be defined by apps). If theme blocks become stable enough that merchants can treat them like mini-sections inside a section, the case for turning repeatable patterns into blocks gets stronger than it is today.
The evidence that would make me change the rubric: a theme blocks engagement where the schema duplication cost disappears, the theme editor handles nested blocks gracefully, and merchants don't trip over the UX of "a block that contains blocks." Until I've shipped that on a real store, I'm still defaulting to metaobjects for anything that looks like it should live on a resource.
The other thing I'd revisit is the section count soft-limit. Online Store 2.0 raised the hard cap significantly, but the theme editor's performance at 30+ sections per template is still uneven on older Admin client builds. If you're using metafields and metaobjects aggressively, your section count stays low anyway; you have fewer sections doing more work each, rather than many sections each doing a narrow job.
The rubric compresses to three questions. Is the content page-owned or resource-owned? If resource-owned, use metaobjects or metafields. Is the content a unit of layout or a repeatable sub-unit inside a layout? If a unit, make a section; if a sub-unit, use a block. Do you need to write to this content from an API or agent? If yes, use a metafield or metaobject, period.
All of this ties back to the DTC Shopify theme architecture for brands past 2M, where the three-layer model (section skeleton, data contract, runtime bindings) formalizes this thinking as the theme grows. The PDP is where the decision shows up most often; the six-block PDP conversion framework goes deeper on how each block tends to map to one of the three options above.
When you're sizing whether the chosen shape is actually fast enough for the merchandiser to edit without waiting, the performance budget methodology gives you the ceiling numbers. And if one of the sections you're writing needs cross-browser video, the hand-rolled video section pattern walks through the exact Liquid and JavaScript that ship it.
The decision rubric lives alongside, not inside, the schema defaults in the Shopify Theme Starter - the starter ships a default that sits in the middle of this rubric (thin sections, metafields for most product-owned content, blocks only for true repeatables). Most stores I hand it to want to shift in one direction or the other; the rubric is how we decide which.
FAQ
Can I migrate blocks to metaobjects later without breaking the theme?
Yes, but it's not free. You need a data migration (read block settings out of the template JSON, write them to a metaobject), a Liquid change (swap the block loop for a metaobject loop), and a schema update to remove the block definition. I've done this three times; each time it was a day of work per section, plus a testing pass. Moving in the other direction (metaobject to blocks) is rare and usually a mistake.
What about apps that inject blocks via theme app extensions?
Theme app extensions add blocks through their own scope. They're useful for app-driven content (a reviews widget, a subscription picker) where the app owns the rendering. Don't use them for content the merchandiser authors; that content belongs to your theme or to the resource, not to the app.
Should I use block groups?
Block groups (introduced in Online Store 2.0) are useful when a compound layout needs a nested hierarchy (a testimonials section with multiple testimonial categories, each containing testimonials). Treat them the same way you treat sections: use them when the grouping represents a unit of layout, not when it represents a taxonomy that should live on a resource.
What's the maximum number of sections I should have per template?
There's no single answer; the hard cap in Online Store 2.0 is generous. The practical ceiling I use is "the merchandiser's attention span in the theme editor," which is somewhere between 12 and 20 before the sidebar becomes unmanageable. If I'm past 20 sections on a template, I look for opportunities to consolidate into metaobject-driven sections.
Does this rubric apply to Hydrogen or headless themes?
Partially. Hydrogen doesn't have a theme editor or the section/block distinction; content comes from Storefront API queries, metafields, and metaobjects. The resource-owned content question still applies (metafields and metaobjects are still the right shape for product-owned data), but the section/block fork collapses into "what does my React component hierarchy look like." I wrote about the tradeoffs of going that direction in the Hydrogen vs Liquid breakdown for 2026.
Sources and specifics
- The three build decisions are anonymized composites of DTC Shopify engagements in 2024-2026, all on Online Store 2.0 themes.
- Block and section limits are current as of Shopify's 2026 theme documentation. Theme blocks (the app-driven nested variant) are still evolving and were not used on the three builds above.
- "Mid-market" here is approximately $2M-50M in annual DTC revenue; smaller stores often benefit from simpler schemas and can skip the metaobject step.
- All three builds used Liquid sections, not Hydrogen, and all three shipped on Online Store 2.0.
- The rubric deliberately ignores third-party page-builder apps; those come with their own schemas and conflicts that are outside the sections/blocks decision.