Shopify merchants keep saying the same thing in different words: design got harder, features moved, and simple edits take more clicks. A header change that used to be one setting now needs a developer, and when the storefront misbehaves, Support replies that the theme is too customised to touch.
That complaint is real, and the usual explanation is incomplete. Shopify moved settings while it added surfaces, so the theme editor, section groups, and dynamic sources now expose more of the storefront than Vintage themes ever did. A large share of live catalogues have already stepped off that path with custom Liquid, leftover static section tags, and metafield workarounds.
Once you leave the supportable path, the editor and Support stop being useful in the way the marketing site promised. The store still sells, yet every change costs more, and nobody can say which file is allowed to own the header.
Introduction
Online Store 2.0 was sold as merchant control: JSON templates, sections on every page, and layout edits without a developer on Slack. That model still holds when the theme uses section groups for chrome, JSON templates for page structure, and dynamic sources for product data. Online Store 2.0: What Changed and Why It Matters is the architectural baseline.
The friction showing up in merchant and developer communities this month sits one layer further on. Teams rebuild a mega menu in Liquid, then see three Header entries in the theme editor. They try to connect product.description to a Studio collapsible row and the picker offers Title, Content, and Add metafield. They stack homepage sections until the page feels busy, then ask whether the section counter itself is killing conversion.
The shared pattern on those storefronts is customisation that no longer matches the model Shopify will support. Adjacent operational drag (exports, app hops, inventory clicks) belongs in operational friction when simple tasks still take too long. This article stays on the storefront: how to tell you have left the supportable path, and how to get back without a cosmetic redesign.
The common assumption
The assumption is that Shopify redesigned the admin and the theme editor for someone else, and that everyday store design is now supposed to feel like a developer product.
That story is easy to believe. Product and inventory screens have gained steps, variant options take more clicks than they did a few years ago, and Sidekick and other admin AI tools fail to find settings that used to live in one obvious menu, so merchants conclude the interface got worse on purpose.
On the storefront side, the same assumption shows up as a support ticket: the layout file calls the header once, the rendered HTML contains three copies, and the theme editor lists three linked Header rows. Support confirms the theme is heavily customised and closes the case, which the merchant reads as Shopify walking away from its own theme system.
Ownership is the missing piece. Shopify will stand behind documented Online Store 2.0 behaviour: section groups, declared schemas, and dynamic sources whose types match. A header rewritten outside header-group.json is an engineering surface, and treating it as an editor bug wastes a week.
Where Shopify theme customisation leaves the supportable path
Section groups and leftover static tags
Modern themes render sitewide chrome with a section group, using {% sections 'header-group' %} (plural) in the layout. The group file lists the announcement bar, header, and anything else that should appear on every template, up to 25 sections per group.
Older or heavily edited themes still use a static {% section 'header' %} tag. Shopify documents that you should avoid mixing static sections and section groups in the same layout. After a custom mega-menu rebuild, we often find both: a leftover static tag, a group file that still references header, and sometimes a third copy of the markup sitting inside Custom CSS comments. View-source then looks like three headers. Shoppers may only see one, because two copies are commented or disabled. The editor still shows three linked rows, and the HTML weight is real.
Support is right to step back. There is no settings toggle for "undo the last few header experiments."
Dynamic sources that cannot see native fields
Connect Dynamic Source is type-aware. A collapsible row setting that expects a metafield, or a text type that does not match product description HTML, will show No compatible fields under Template → Product. Merchants follow the official click path, see Title and Content, and assume Studio is broken.
What usually happened is more specific. A metafield named something like description already occupies the slot. The native product.description stays hidden because the setting is already bound, or because the section schema never listed description as a compatible source. Preserving paragraph spacing and bold text then requires either a metafield that stores the same HTML, or Liquid that outputs {{ product.description }} inside the row. That small Liquid change is exactly the moment the block leaves the no-code path.
Liquid Explained for Store Owners is the right primer before anyone pastes a snippet they cannot later find.
Section sprawl without a job per section
Homepage anxiety is the third signal. Merchants add a banner, featured products, collections, a brand story, reviews, and two promotional modules, then ask whether "too many sections" hurt conversions. Shopify's ceiling is 25 sections per JSON template. Conversion trouble starts earlier, when several sections sell the same idea and mobile stacking turns a balanced desktop into a long scroll.
That is a merchandising and performance problem, covered in common theme mistakes that kill conversion. It is also a customisation-limits problem: the editor makes adding a section cheap, and nothing in the UI asks whether the new block has a job the previous block already does.
What we see on real builds
On audits at oContis Studio, the storefronts that feel "too complicated to design" share a file-level pattern. The published theme still looks like Dawn, Studio, or a premium OS 2.0 theme in the admin. The layout and section JSON tell a different story.
We find custom mega menus wired through snippets that the header section no longer owns. We find theme.liquid carrying logic that should live in a section. We find metafields created so the editor has something to connect, while the live product description sits unused. We find Custom CSS used as a junk drawer for markup people were afraid to delete.
None of that is visible in a theme demo: it appears after a year of campaign work, a marketplace feed, and successive header changes that never replaced the last version.
Our beauty & skincare work with Medik8 is the pattern we prefer: a Shopify 2.0 migration that keeps multi-store architecture on a section model the merchant team can still edit. Kem Collection needed a custom OS 2.0 theme for lookbook merchandising in fashion & apparel, which only stays maintainable if the custom work is named, limited, and kept out of the layout file. Craft belongs in the theme you chose to own, named in a section or snippet the merchant team can still find.
For the structural standard we hold those builds to, see The Anatomy of a High-Performance Shopify Theme.
A better framing
The useful question is whether the storefront is still on the supportable path, or whether custom work has created a private theme that happens to run on Shopify.
| Signal | Still on the supportable path | Left the supportable path |
|---|---|---|
| Header and footer | One section group each, rendered with {% sections %} | Static tags, leftover group files, or markup in Custom CSS |
| Theme editor sidebar | One Header row, one Footer row, template sections below | Linked duplicate Header rows, sections you cannot delete |
| Product content | Native fields or documented metafields via dynamic sources | Support-created metafields shadowing product.description |
| Homepage | Each section has one job; mobile order checked | Repeated promises, campaign leftovers, no owner for the stack |
| Who can change it | Merchandising in the editor; developers for schema and Liquid | Every campaign is a developer ticket; Support declines the theme |
The supportable path is narrower than "anything the theme editor can open." It is the combination of JSON templates, section groups, declared schemas, and dynamic sources whose types match. Custom Liquid is allowed when it is an explicit exception with an owner, documented in a named snippet or section.
If you need faster page updates without reloading chrome, that is a separate, documented technique: Shopify Liquid Partials. Partials still assume a clean header group, so a layout that renders the header three times stays broken.
What to do differently
1. Map chrome before you edit it. Open layout/theme.liquid and list every {% section %} and {% sections %} tag. Confirm matching header-group.json / footer-group.json files. If you see both a static header tag and a header group, stop adding mega-menu Liquid until one owner remains.
2. Treat duplicate editor rows as an extra render in the layout. Hiding a second header with CSS leaves duplicate IDs and HTML weight in place. Find the extra render: commented markup, a disabled section in the group, or a static tag that should have been removed during an OS 2.0 migration.
3. Match dynamic sources to setting types. If Connect Dynamic Source hides description, check the block setting type and any existing metafield binding before you file a Studio bug. Decide whether native product.description should win, then disconnect the shadow field.
4. Give every homepage section a job. On mobile, walk the first screen and the next two scrolls, then remove or merge sections that repeat the same promise so proof and products sit close to the first decision. The 25-section ceiling is a platform cap, so aim for one job per section well below that number.
5. Write down the exceptions. Any Liquid that Support would refuse should live in a named snippet or section, with a one-line comment that says why the editor could not do it. Undocumented exceptions are how the next partner rebuilds the header again.
6. Choose rebuild versus recover. Recover when the theme is still an OS 2.0 theme with a few dirty files. Rebuild when the layout is a collage of static tags, app embeds, and Custom CSS, and merchandising has already lost the editor. Recovery is cheaper. Rebuild is cleaner when you are already paying for every campaign twice.
Conclusion
Shopify theme customisation limits are easy to misread as a redesign complaint. The practical limit is the gap between what the theme editor can own and what your files actually do. Section groups, dynamic sources, and JSON templates still give merchandising real control. Custom Liquid still has a place. The expensive storefront is the one that pretends to be both: a native theme in the sidebar, a private fork in the layout.
If your header shows up more than once in the editor, if Support has already declined the theme, or if connecting a product description now requires a metafield invented last week, you have left the supportable path. A Shopify theme development engagement at oContis Studio starts by mapping that path, then restoring a section model your team can edit without opening a ticket for every campaign.
