Shopify Theme Sections I Rebuild on Every Store

I stopped building Shopify sections from scratch a long time ago. Four sections carry most stores I launch, and I copy them in on day one. Here is what they are, the schema patterns behind them, and why a non-dev can rearrange the blocks without ever calling me.

The Hero That Never Hardcodes Copy

The first section I drop into every theme is a hero. Nothing fancy on the surface, one background, one heading, one subheading, one button. The trick is that I never hardcode a single word of it. Every visible string lives in the schema so the store owner can edit it from the theme editor without touching Liquid.

The mistake I made on my first three stores was baking the headline into the template. Then a client wanted to change "Summer Drop" to "Autumn Drop" and I had to open the code editor for a two-word swap. Never again. Now the hero has a `text` setting for the heading, a `richtext` setting for the sub copy, an `image_picker` for the background, and a `url` plus `text` pair for the button.

Here is the pattern I use for the button so it degrades gracefully:

{% if section.settings.button_label != blank %}
  
    {{ section.settings.button_label }}
  
{% endif %}

If the label is empty, the button disappears. No broken empty pill floating on the page. That single `if blank` check saves me support messages, because a non-dev will absolutely clear a field to "remove" something and expect it to vanish.

I also expose an alignment select (left, center) and a `color_scheme` setting so the hero inherits the theme's palette instead of fighting it. That keeps the editor usable. Someone who has never seen Liquid can open the hero, type new copy, pick an image, and preview it live.

One number to justify the setup: this hero takes me about 20 minutes to paste and wire on a fresh store, versus roughly 90 minutes when I used to build heroes per-project. Across the last eight stores that is close to nine hours reclaimed. If you are building on Shopify and you launch more than one store a year, a reusable hero is the single highest-return file in your section folder. Build it once, treat it as an asset, copy it forward.

The Proof Band Built From Repeatable Blocks

The second section is a proof band, a horizontal strip of trust signals that sits just under the hero. Logos, star ratings, shipping promises, whatever the store leans on. The key design choice here is blocks, not fixed settings.

Blocks are the part of Shopify schema that non-devs love once they understand them. Each item in the proof band is a block. The owner can add a block, drag it up or down, or delete it, all from the editor, and the layout just re-flows. I define two block types: a `logo` block with an image picker, and a `stat` block with a big number field and a small label field.

{
  "type": "stat",
  "name": "Stat",
  "settings": [
    { "type": "text", "id": "value", "label": "Big number" },
    { "type": "text", "id": "label", "label": "Small label" }
  ]
}

I cap the band with a `max_blocks` of 6 in the schema. This is a small thing that matters more than it looks. Without a cap, a store owner will happily add eleven logos and shove the layout into an ugly wrapping mess on mobile. Six is the number where the row stays clean on a phone. Constraints keep the editor safe.

The band renders blocks in a flex row that wraps to two-up on mobile automatically. I write the CSS once inside the section's `{% stylesheet %}` tag so the styling travels with the file. When I copy the section into a new theme, the styling comes with it. No hunting through a separate CSS asset to remember which classes this thing needs.

The reason this section earns its place: proof does real work near the top of a page, and owners update it constantly. New review count, new press logo, a fresh shipping promise for the season. Because it is block-based, they never ask me to make the edit. I have not touched a proof band on a live store in over a year, and every one of them has been updated by the owner at least twice. That is the whole point. Build the thing so the person who owns the store can maintain it themselves.

The FAQ That Doubles As SEO

Third is the FAQ section, and it does two jobs. It answers buyer questions inline, and it feeds structured data to search engines. Both come from the same blocks.

The structure is simple: each FAQ is a block with a `question` text field and an `answer` richtext field. I render them as native HTML `details` and `summary` elements so I get accordion behavior with zero JavaScript. No library, no click handler, nothing to break on a slow phone.

{% for block in section.blocks %}
  

    
{{ block.settings.question }}
    
{{ block.settings.answer }}
  
{% endfor %}

That is the entire interaction layer. Native `details` gives you keyboard access and open/close state for free. I spent an embarrassing amount of time on my early stores wiring up custom accordion scripts before I realized the browser already does this perfectly.

The second job is the structured data. I loop the same blocks a second time to emit a FAQPage JSON-LD script. Search engines can then show the questions directly in results. I only emit the schema block if there is at least one FAQ, so an empty section does not push broken markup. Same discipline as the hero button: check for content before you render.

One caution I learned the hard way. Richtext answers can contain markup that breaks JSON if you drop it in raw. I run the answer through `strip_html` and `escape` before it goes into the JSON-LD script. Skip that and a single quote mark in an answer will silently invalidate your entire structured data block. I lost a week of eligibility on one store to exactly this before I found it in the search console.

The FAQ is also where I see the clearest content payoff. Owners tend to write FAQs as they get repeat customer emails, so the section grows organically and stays genuinely useful. Six to eight questions is the sweet spot. For the wider approach to structuring content that both humans and machines read cleanly, the Claude Blueprint walks through how I plan these blocks before writing any Liquid, so the schema matches the content instead of the other way around.

The CTA Section That Ships Everywhere

The fourth section is a closing CTA, the band you drop at the bottom of a page to push one clear next action. Newsletter signup, a link to a collection, a link to a hero product. It looks almost identical to the hero, and that is deliberate.

I keep the hero and the CTA as separate files even though they share most of their schema. The temptation is to make one flexible mega-section that does both. I tried that. It became a settings soup with fourteen toggles, and the non-dev owner froze the moment they opened it. Two focused sections beat one clever one every time. The editor stays readable, and each section has an obvious job.

The CTA has a heading, a supporting line, a button, and a `color_scheme`. The one extra setting is a boolean to switch between "link button" and "email capture". When email capture is on, I render the native form with a proper `contact` form type. When off, it renders the same styled button as the hero. One toggle, two clear behaviors, no confusion.

The reason a dedicated CTA matters across every store: repetition of the primary action. Someone scrolls a full page, and by the time they hit the bottom they need one obvious thing to do next. Because it is its own section, the owner can drag it onto any page template, homepage, collection, blog post, wherever they want a closing push.

Once these four sections exist, the next lever is what happens after someone acts. Scheduling the follow-up content that keeps them engaged is a separate discipline, and I lean on Buffer to queue the social posts that point back at these pages so the CTA is not the last touch, just the first.

Every one of these four sections travels as a single `.liquid` file with its own scoped styles and its own schema. I keep them in one folder and paste them into each new theme's sections directory. No dependencies, no shared assets to remember, no cross-file surprises. Copy, deploy, wire up the content in the editor, done. The whole set goes live in under an hour on a fresh store.

Bottom Line

Four sections cover the structural backbone of nearly every store I build: a hero that owns its copy through schema, a proof band made of capped blocks a non-dev can drag, an FAQ that renders native accordions and feeds structured data, and a CTA that repeats the primary action on any template. The pattern behind all four is the same. Never hardcode copy, always check for blank before rendering, cap block counts to protect mobile layout, and scope styles inside the section file so it travels clean.

The payoff is not the first store. It is the second, third, and eighth, where I paste four files instead of building four things, and where the owner maintains their own content without ever pinging me. That saves me roughly three hours per build and saves them the wait.

If you want to see how I plan the content that fills these blocks before writing any code, the Claude Blueprint is where I start. Build the sections once, treat them as assets, and copy them forward.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)