Why your Shopify theme breaks on every update — and how to stop it

What's actually happening

A theme is a package of files — Liquid templates, JavaScript, CSS, settings. When you buy a theme and then pay someone to "customise" it, the cheap way to do that is to edit those files directly: hard-code a section into product.liquid, drop a script into theme.js, wedge a price rule into the cart template.

That works until the theme author ships an update — a fix, a new feature, a security patch. Now there are two versions of the same files: theirs and yours. Whoever installed the update either overwrites your work or has to merge two diverging codebases by hand. Either way, something breaks, and nobody can say exactly what changed.

The store isn't fragile because Shopify is fragile. It's fragile because the customisation was put somewhere updates can reach it.

Where the customisation should live instead

Shopify's Online Store 2.0 architecture exists precisely to keep your changes out of the theme's blast radius. There is a right home for almost everything people jam into theme files:

• Sections and blocks — layout and merchandising that a marketer can rearrange without touching code, and that survives a theme update because it lives in JSON templates, not the theme's Liquid.
• Metafields and metaobjects — structured, custom data (specs, badges, size guides, ingredient lists) attached to products and collections, rather than hard-coded into templates.
• App blocks and theme app extensions — third-party and custom functionality that installs into a section slot, so an app never edits your theme's files at all.
• A small, versioned theme layer — the genuinely bespoke code that remains, kept in Git, reviewed, and deployed deliberately — not hand-edited in the admin.

How to tell which kind of store you have

Ask for the store's theme in a Git repository. If it exists, is reviewed, and updates are applied as deliberate merges, you have a maintainable store. If "the theme" is a live copy in the Shopify admin that no one dares duplicate, every update is going to be an adventure — and that's the thing to fix first, before it costs you a launch.

The fix, in order

• Audit what's actually customised, and sort it into: belongs in a section, belongs in a metafield, belongs in an app block, or is genuinely bespoke theme code.
• Move each item to its right home. Most of it isn't bespoke — it just ended up in the theme because that was the fastest place to put it.
• Put the remaining theme code under version control, so updates are reviewed diffs, not surprises.
• Re-test the update path once. After that, updating is boring — which is the goal.

None of this requires rebuilding the store. It requires moving customisation out of the one place a theme update can overwrite it. That's the whole difference between a store that breaks every update and one that doesn't.