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. The marketing team often grew while the editing surface stayed a one-person Liquid job, so campaign volume hits files that never declared the work as settings. 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, how to separate recovery from a visual redesign, and when Horizon or checkout catch-up is a later project.
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." Those extra header copies also create accessibility failures: duplicate landmarks, broken skip links, and keyboard traps in custom mega menus. How to Fix Shopify Accessibility Bugs That Block WCAG AA is the fix path once the markup is no longer a single documented section group.
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.
The team grew, then the platform moved
Campaign volume goes up as the marketing team grows, while the number of people allowed to edit Liquid stays at one, or at zero once the last freelancer rotates off. Sequential developers make the same congestion in the files: one person rebuilt the mega menu, the next injected an app snippet into theme.liquid, and a third added Custom CSS because the section setting was already doing something else. Nobody removed the previous layer.
Shoppers still see one header. The editor may list two. View-source still carries commented blocks and script tags for apps you no longer pay for. App sprawl adds a second owner on a different axis, which is the pattern in app costs and audit steps. Marketing then buys a landing-page app because the theme editor is already a maze.
Checkout customisation now lives in UI extensions, Functions, branding APIs, and web pixels. Stores that still think in checkout.liquid or Shopify Scripts cannot pick up the current editor. Horizon nested blocks and AI-assisted section generation assume a theme-block tree, not a collage of static tags and app embeds. You can keep a converting Dawn (or other OS 2.0) theme while you recover merchant control. Dropping Horizon onto those files still leaves marketing without nested blocks they can actually use. There is no automatic Dawn-to-Horizon migration, because the architectures do not translate.
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.
Wrong-variant carts are the sharp version of the same congestion. Visible swatches that are not wired to the product form's variant id look fine in a screenshot and sell the wrong SKU. An unpublished Dawn or Horizon copy is the isolation test. If the default theme adds the right variant, the live theme’s customisation is the fault, and painting a new look on those swatches will ship the same bug.
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.
Treat three jobs as three jobs. Teams collapse them into one word, redesign, and then wonder why the tickets never shrink.
| Job | What the team asked for | What actually changes | When it is the right spend |
|---|---|---|---|
| Visual redesign | A newer look | Type, colour, photography, component styling | Brand identity must change, and the section model underneath is already something marketing can edit |
| Recover merchant control | Fewer developer tickets | JSON templates, honest schemas, metafields and metaobjects, leftover snippets removed | The store converts, the theme is already OS 2.0-shaped, and campaigns still require Liquid |
| Architecture catch-up | Horizon, checkout extensions, Functions | A new theme-block or checkout model, with content migrated on purpose | Vintage templates, unsupported checkout customisation, or recovery still leaves merchandising in tickets |
Recovery is the default on established catalogues. Catch-up is a project with a cutover plan. Redesign is optional cosmetics once one of the other two has restored an editing surface. Spending the cosmetics budget first is how a congested theme gets a new coat of paint and the same Slack thread in November.
What to do differently
Start with four questions you can answer in a working session, before anyone opens Figma.
- Who can change the next campaign without a developer? If the answer is nobody, merchandising has already left the supportable path regardless of how the homepage looks.
- Can marketing add a section on the product template, or only on the homepage? Homepage-only flexibility is a Vintage leftover, even when the theme picker shows a modern name.
- Does checkout customisation still assume a single Liquid file or Scripts? If yes, that work has to move to extensions and Functions before you restyle the storefront.
- What would break if you installed an unpublished copy of Dawn or Horizon and clicked Add to cart on one product? Use that as an isolation test, not as a live cutover.
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 recover, rebuild, or catch-up. Recover when the theme is still an OS 2.0 theme with a few dirty files. Rebuild the architecture when the layout is a collage of static tags, app embeds, and Custom CSS, and merchandising has already lost the editor. Decide Horizon and checkout catch-up as a second phase: recover the current OS 2.0 theme so marketing can operate through peak, then rebuild onto nested blocks when you already need a new architecture and you can migrate content on purpose.
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.
Horizon, checkout UI extensions, and admin AI become useful after that work, once the files can receive them. A new look on the same files leaves the ticket queue in place.
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.
