Shopify theme maintenance is the work that keeps a store editable by the people who run it, months after the agency that built it has moved on. Most themes do not break in one dramatic moment. They drift. A banner gets hardcoded for a sale and never comes out, an app leaves code behind after it is uninstalled, a product template is copied three times for three launches, and one day nobody on the team can change the homepage without asking a developer.
This guide is about preventing that drift: how to build a theme so editors can own it, how to use metafields without making a mess, how to keep apps from polluting the code, and the routine we run on the stores we maintain.
Why stores stop being editable
When a store owner tells us they “can’t change anything without a developer”, the cause is almost always one of four things. None of them are exotic, and all of them were easier to do than to avoid at the time.
- Content in code. Text, links and images written straight into Liquid files instead of section settings. It is faster on launch day and it means every copy change afterwards is a code change.
- Template sprawl. A new product template for every campaign or product family:
product.summer.json,product.summer-2.json,product.bundle-new.json. Nobody remembers which products use which, so nobody dares to delete any of them. - App residue. Older apps edited theme files directly to inject their widgets. Uninstalling the app does not always remove that code, so scripts keep loading and snippets keep rendering for an app you no longer pay for.
- Edits made in the live theme. Changes made through the code editor on the published theme, with no copy anywhere else. The theme becomes a one-off that cannot take the vendor’s updates and has no history.
Build for editors: sections, blocks and a small set of templates
Shopify’s current theme architecture (often called Online Store 2.0) is built around JSON templates made of sections and blocks that merchants arrange in the theme editor. Used well, it removes almost every reason to touch code for day-to-day changes. The rules we follow when we build or rebuild a theme:
Every piece of merchandising copy is a setting
Headlines, button labels, promo text, trust badges, shipping notes: if a marketer might want to change it, it is a section or block setting, not a string in a Liquid file. The test we use is simple. Could the store’s newest team member change it on a Friday afternoon without help? If not, it belongs in the editor.
Few templates, more sections
Instead of a new template for each campaign, we build flexible sections and let editors add, hide and reorder them on a handful of templates. A typical store we maintain has one default product template, one or two alternates for genuinely different product types, and a clear naming convention for anything else. Campaign-specific content goes into sections that can be switched off afterwards, not into a template that lives forever.
Name things for the person using the editor
Section names like “Image with text (left)” or “FAQ accordion” help. Names like “custom-section-v3” do not. Settings get labels and short help text. This costs minutes during the build and saves hours of confusion later.
Metafields and metaobjects: structure, not a junk drawer
Metafields let you store extra information on products, collections, customers and other objects: care instructions, size guides, ingredients, delivery estimates. Metaobjects let you define your own content types, such as a designer profile or a reusable FAQ entry, and reference them from products. Together they are what keeps product pages consistent without copying content into every product description.
What goes wrong is the same thing that goes wrong with any unmanaged database:
- Metafields created by apps and by past developers with no definition, so they cannot be edited in the admin and nobody knows what they do.
- The same concept stored three ways, for example a size guide as a rich text metafield on some products, a file reference on others and pasted into the description on the rest.
- Theme code that reads a metafield without a fallback, so a product missing that value shows an empty block or a broken layout.
Our rule: every metafield the theme reads has a definition with a clear name and description, the theme handles the “empty” case gracefully, and repeated content lives in a metaobject that products reference rather than in each product’s own fields.
App hygiene: the biggest source of slow, fragile themes
Apps are where most of the long-term damage comes from, because each one is added for a good reason and removed less carefully than it was installed.
Modern apps should integrate through theme app extensions: app blocks and app embeds that you place or switch on in the theme editor and that do not edit your theme’s files. When the app is removed, its blocks go with it. Older apps (and some current ones) still inject code into theme.liquid or add snippets, and that code can outlive the app.
Before installing an app, we ask three questions: does it use app blocks or embeds, what does it load on pages where it is not used, and how is it removed. After removing an app, we search the theme for its name, its snippet files and its script URLs. It is common for us to find leftovers from several apps on a store we take over. Each one loads something on every page view, which also shows up in your Core Web Vitals.
What breaks after six months
These are the problems we see most often when a store comes to us around six months to a year after launch.
| Symptom | Usual cause | Fix |
|---|---|---|
| Editors cannot change homepage copy | Text hardcoded in Liquid for launch | Move it into section settings; delete the hardcoded version |
| A product page shows an empty box | Metafield read without a fallback, or a missing definition | Add definitions; render nothing when the value is empty |
| Nobody knows which template a product uses | Template sprawl from campaigns | Audit templates, reassign products, delete unused ones |
| Theme update would wipe changes | Code edited directly in the vendor theme | Move custom code into clearly named sections/snippets and track them in Git |
| Pages got slower without new features | Uninstalled apps still loading scripts | Remove residue; review app embeds; re-measure |
| A change “broke something” and nobody knows what | No version history outside Shopify | Connect the theme to GitHub and work on branches |
A maintenance routine that actually gets done
Maintenance only works if it is boring and regular. This is the checklist we run for stores on a care plan; it fits into a few hours a month for most catalogs.
Every change
- Work on a copy of the theme, never the published one. Preview, then publish.
- Keep the theme under version control. Shopify’s GitHub integration syncs a theme with a branch, and the Shopify CLI lets developers pull, preview and push themes and run Theme Check to catch common Liquid problems.
- Write down why a change was made, not only what changed. Six months later the “why” is what you need.
Monthly
- Review installed apps against what the store actually uses. Uninstall what is not used and remove its residue.
- Check the templates list: anything with no products or pages assigned is a candidate for deletion.
- Look at the theme’s speed in Shopify’s web performance report and investigate any template that got worse.
Quarterly
- Review metafield definitions and remove ones nothing reads.
- If you use a Theme Store theme, check whether a new version is available and what it would take to move your customisations across.
- Walk through the store as an editor: can the team change every piece of content they should be able to?
Maintain or rebuild?
Not every theme is worth maintaining. We recommend a rebuild, usually onto a well-supported base theme, when most content is hardcoded, when custom code is so entangled with the vendor theme that no update can be applied, or when the theme predates sections everywhere and fighting it costs more than replacing it. If a full redesign is on the table, plan the URLs and redirects first; our guide to redesigning without losing rankings or revenue covers that part.
Otherwise, a structured cleanup (content into settings, templates consolidated, apps audited, the theme under version control) usually restores editability in a few weeks. That work is what our Shopify development team does on takeovers, and it is part of our maintenance and support plans. If speed is the pressing problem, start with speed optimization instead, since app residue is often the cause.