Make Shopify Liquid Sections Reusable for Your Store Team

By Milan Dhameliya · · 8 min read

Understand Shopify Liquid sections, brief an editable component, and test independent settings, empty content, and editor behavior before accepting the work.

Shopify Liquid sections are reusable theme components that give your team editable controls for content and layout. Add existing sections through Online Store > Themes > Edit theme > Add section; commission a custom section when the theme's controls cannot express the content you need.

The useful deliverable is something your merchandising team can operate next month: add it twice, change each copy independently, leave optional content empty, and rearrange it without breaking the page. This guide explains the moving parts, provides a small implementation example, and gives you a practical acceptance test to send with a development brief.

What you are buying when you commission a section

A section usually lives in a sections/name.liquid file. Its Liquid and HTML produce the visible content; its schema defines the controls staff see in the editor. Shopify's sections documentation describes these as customizable, reusable modules. Blocks can provide smaller pieces inside a section, such as individual questions in an FAQ.

Three similar-sounding requests produce different handoffs:

For a temporary piece of developer-maintained markup, a Custom Liquid field may be sufficient. For a notice your operations team updates every week, ask for labeled fields. If the current theme already has a suitable rich-text section, try it first: custom development should solve a requirement you can name.

Ask the person who will maintain the notice to demonstrate an ordinary edit during the handoff. If changing its wording requires finding a sentence between HTML tags, you have received editable code, but perhaps not the editing experience you intended to commission.

Reusable code does not mean synchronized content

Imagine a homewares store wanting a notice above its collection grid and another below its product details. Both can use one section file while holding different text. Shopify's JSON template documentation separates the section's type from each placement's settings and order. Section data is not shared across JSON templates.

That distinction should appear in your brief. “Reuse the same design” means one component can serve several placements. “Update this message everywhere from one place” is an additional content requirement. Do not approve the first and assume you received the second.

There is another boundary: editing a template affects all pages assigned to it, as Shopify's template guide confirms. A notice typed into the default product template can therefore appear across many products. Choosing a different preview product does not create a separate notice for that product.

For product-specific information, use a compatible dynamic source rather than creating dozens of manually maintained copies. Shopify documents how to connect metafields to supported settings. Our reusable size-guide tutorial covers structured content shared by several products. Establish the content owner and source before deciding how many section placements you need.

A small section with a clear editing contract

Here is an illustrative store-notice section for a developer to adapt. Its contract is deliberately modest: staff can edit a heading and message, adjust padding, and add more than one instance to a JSON template. With no message, it emits no notice content. It has no countdown, dismissal state, or JavaScript dependency.

Start with a duplicate theme using Online Store > Themes > actions menu > Duplicate, following Shopify's backup instructions. Open the copy's actions menu > Edit code, right-click the sections folder, and select New file. Name it store-note.liquid and add the following contents, following Shopify's code-editor instructions. This belongs in a section file, not inside an existing Custom Liquid field. If you do not maintain theme code, pass the example and acceptance criteria to your developer.

{% if section.settings.message != blank %}
  <div id="StoreNote-{{ section.id }}">
    {% if section.settings.heading != blank %}
      <h2>{{ section.settings.heading | escape }}</h2>
    {% endif %}
    <div>{{ section.settings.message }}</div>
  </div>
  <style>
    #StoreNote-{{ section.id }} {
      max-width: 70rem;
      margin-inline: auto;
      padding: {{ section.settings.padding }}px;
    }
  </style>
{% endif %}

{% schema %}
{
  "name": "Store note",
  "settings": [
    { "type": "text", "id": "heading", "label": "Heading" },
    { "type": "richtext", "id": "message", "label": "Message" },
    {
      "type": "range", "id": "padding", "label": "Padding",
      "min": 0, "max": 48, "step": 4, "unit": "px", "default": 16
    }
  ],
  "presets": [{ "name": "Store note" }]
}
{% endschema %}

The presets entry makes the component available for addition through the editor. Shopify's schema reference also documents restrictions such as enabled_on and disabled_on. A production version can restrict placement to the templates where the notice makes sense.

The heading uses a text setting; the message uses rich text so staff can maintain paragraphs and links. Shopify's input-setting reference explains these control types. It also distinguishes their translation support: text-bearing settings can be translated through Translate & Adapt, while a Liquid setting's stored value is not available there. That matters when a quick pasted notice later becomes multilingual content.

The CSS selector includes section.id, which Shopify generates for sections in JSON templates, as documented in the section object reference. Each instance's padding rule therefore targets its own notice. A single global .store-note rule containing the last instance's padding would defeat the independent controls.

This example intentionally leaves typography and colors to the surrounding theme. Have the developer align it with your theme's spacing and heading conventions. Shopify still supplies a section wrapper even when the message is empty; inspect whether your theme adds spacing to that wrapper before promising that an empty notice occupies no space.

Accept the section with two copies on one page

In the draft theme editor, select a suitable template and add Store note twice. Fill both Message fields so they render. Use different headings, then give the first instance zero padding and the second 48 pixels. These are test settings, not a recommended storefront design.

My acceptance test is two notices with different padding on the same page: changing the second must not restyle the first, because one successful instance cannot expose a selector that accidentally controls both. This tests the promise of reuse more directly than a polished screenshot of one placement.

Use deliberately distinguishable content during review, such as “Collection notice” and “Product notice,” then replace it with approved copy. Identical sample text makes accidental sharing harder to spot. Capture both settings panels and the rendered result so the next editor knows what was tested.

If your section should allow only one instance, specify that instead and verify the restriction. The two-copy test is appropriate for components sold as independently reusable, not every component in a theme. Likewise, test in the intended page area: Shopify's section-group guidance notes that header and footer content is shared across storefront pages.

Interactive sections need an extra editor test

A static notice has a smaller acceptance surface than a carousel, tabs, or a dismissible promotion. Shopify's editor integration documentation explains why: editing can replace a section's HTML without reloading the page, so JavaScript that ran only on initial page load does not automatically run again.

For an interactive component, change a setting and immediately try its controls without refreshing the editor. Then remove and re-add it. Ask the developer to verify initialization on shopify:section:load and cleanup on shopify:section:unload, or to explain the equivalent lifecycle handling in their implementation.

My recommended evidence is a short recording showing the interaction before and after an edit, followed by the same interaction in storefront preview. A component that works after a manual refresh but stops when staff change its settings is not ready for ordinary merchandising work.

Do not add JavaScript just to make a plain notice seem more sophisticated. Decide whether the shopper needs the interaction. If dismissal is required, specify whether it should last for a page visit, a browser session, or longer, and what happens when the message changes. Those are separate acceptance criteria; the example above implements none of them.

Hand over the component your team will maintain

Ask for the filename, supported templates, field descriptions, empty-state behavior, and a note identifying any shared assets. Keep the test results with that handoff. When another developer changes the design later, they should be able to find every placement using the section before altering its output.

Before publishing, have a staff member perform the expected weekly edit in the draft. Then review the intended pages on desktop and mobile. Our theme editor and publishing guide covers template assignment and the distinction between previewing a page and changing the live storefront.

Skip this custom-section approach when an existing theme component already meets the brief, when you only need a shared data entry, or when the requested behavior belongs to an app's service rather than page presentation. For a headless storefront, this Liquid implementation is also the wrong starting point.

If you commission the work, send the developer the desired shopper outcome and the acceptance cases together. Our Shopify theme development services can help build the section and its editing controls. The handoff should leave your team able to make the next content change themselves and recognize when a change needs development.