A lot of the Shopify work that reaches us starts the same way: the store works, mostly, but nobody wants to touch it. A freelancer built it and moved on. A previous agency stopped halfway. A theme was bought, then edited by three different people until changing a banner risks breaking the product page.
This is rarely anyone's villainy. Most badly built themes were built quickly, on a tight budget, by someone solving the problem in front of them. But the result is the same: a store that costs more to run every month, ranks worse than it should, and makes your team afraid of their own website.
TL;DR: Audit before you decide. Fix the theme when the problems are few, specific and sitting on a modern Online Store 2.0 base. Rebuild when the theme cannot take updates, the problems live in the templates that every page uses, or your team cannot make routine changes without a developer. Increasingly the best middle path is to rebuild your current design on a maintained Shopify theme such as Horizon, rather than starting from a blank page.
How You End Up Here
Across the takeover requests we get, three stories repeat:
- The freelancer store. Built by an individual developer, often through a marketplace, with an app for every feature. The owner's question to us is usually some version of "was this built properly?", because they have no way to tell.
- The unfinished agency build. A previous agency started a custom theme and the relationship ended before launch. What you inherit is a preview theme with features nobody can explain. On one handover the list of open questions included what a particular button on the collection page was even meant to do.
- The purchased theme, edited to death. A third-party theme, customized directly in the code over several years. Our brief for one of these said: the client has had issues making changes in the past, so don't assume any task is easy.
The Symptoms
These are the signs we look for, roughly in order of how much they cost you:
- Routine changes need a developer. Changing homepage content, adding a section to a product page or reordering a menu should be theme editor work. If it needs code, content is hardcoded into templates instead of being exposed as settings.
- SEO basics broken in the templates. On one purchased theme we were asked to fix, the client's SEO specialist had found meta tags rendering outside the page's
<head>, every product page had duplicate H1 headings, and the homepage H1 was present but empty. A template bug is not one error. It is one error multiplied by every page that uses the template. - Layout shift and slow loading. The same store's layout jumped as content loaded, including around the Add to Cart button, and it failed Google's PageSpeed test on both mobile and desktop. A common cause is lazy-loading applied to content that is visible immediately, which delays exactly what the shopper is waiting for.
- The theme cannot be updated. Shopify can carry your code edits into a theme update only when they do not conflict with it. When they do, Shopify's own documentation says all your code changes are removed from the updated copy. So heavily edited themes quietly stop being updated, and fall further behind every year.
- Ghost code from old apps. Apps built on theme app extensions remove themselves cleanly when uninstalled. Older apps that edited theme files directly often leave their code behind, still loading scripts for services you stopped paying for.
- Features nobody can explain. Buttons, sections and settings whose purpose died with the previous developer's notes. Every one is a small risk when changing anything nearby.
- It only works on one store. Themes quietly depend on a particular store's data, apps or plan. In one case a theme built and tested on a Basic Shopify store was imported into a Shopify Plus store, and colour swatches and variant products simply did not appear.
How to Audit It in a Day
You do not need to read every line of code to know what you have. These checks get you most of the way:
- Identify the base theme and version. The theme's
config/settings_schema.jsonfile usually names the theme and version it started from. Knowing it was, say, a specific version of a Theme Store theme tells you what "clean" looks like. - Compare it against a clean copy. Install a fresh copy of the same theme and version as an unpublished theme and compare the files. The differences are exactly what was edited. Few, tidy differences mean fixable. Hundreds of changed files mean you are no longer running that theme.
- Check whether it is Online Store 2.0. If the
templatesfolder is mostly.jsonfiles, pages are built from sections your team can rearrange. If it is mostly.liquidfiles, it is an older architecture that limits what can be edited without code. - Try three routine edits in the theme editor. Change a homepage banner, add a section to a product template, and edit a collection page's content. Note anything that cannot be done without code.
- View the source of a product page. Count the
<h1>tags (there should be one), confirm the title and meta description sit inside<head>, and check for structured data. - Run PageSpeed Insights on the homepage, a collection page and a product page, on mobile. Look at the real-user data if Google has enough traffic to show it.
- List the apps, past and present. Then search the theme code for the names of apps you no longer have installed. Anything you find is ghost code.
Fix or Rebuild: How to Decide
| Fix the existing theme when... | Rebuild when... |
|---|---|
| It is Online Store 2.0, with JSON templates and sections | It is an older Liquid-template theme |
| Differences from the base theme are few and understood | The code has drifted so far that it cannot take updates |
| Problems are specific: a slow section, one broken template | Problems sit in the templates every page uses |
| Your team can make routine changes in the editor | Routine content changes need a developer |
| The design still works for the business | You were planning a redesign anyway |
If most of your answers land in the right-hand column, fixing is usually a false economy. You pay to repair a foundation that will keep generating the same class of problem.
The middle path: same design, maintained foundation
Rebuilding no longer has to mean a redesign. Shopify's Horizon themes, launched in 2025, are free, built on theme blocks your team can arrange in the editor, and maintained by Shopify. Two of the takeovers above were quoted exactly this way: rebuild the current design on Horizon, keep what customers recognise, and drop the accumulated code underneath.
The advantage is that you stop owning the foundation. Shopify keeps the base theme current, your custom work is limited to what genuinely makes your store different, and the next person to work on it starts from a theme they already know. Our custom Shopify theme development page covers when a fully custom theme is still the right call.
What a Rebuild Must Carry Over
Changing theme on Shopify does not change your URLs, because product and collection URLs belong to the platform, not the theme. Your products, customers, orders and redirects are untouched. What does live in the theme, and must be deliberately rebuilt, is:
- Structured data. Product, breadcrumb and organisation markup is usually output by the theme. Check the new theme outputs it before launch.
- Page titles and meta handling. Confirm titles, descriptions and canonical tags render correctly on every template type.
- Metafield-driven content. Size charts, specifications and badges that the old theme read from metafields need wiring into the new one.
- App blocks and embeds. Re-add them in the new theme, and use the move as the moment to drop apps you no longer need.
- Tracking. Any analytics or ad pixels pasted into the old theme's code. Move them to Shopify's customer events where possible, so they survive the next theme change.
Build it as an unpublished theme, test it against the live one template by template, and publish only when both match. Our migration SEO guide covers the ranking checks in more detail, and our ADA compliance guide is worth reading before launch, because a new theme is the cheapest moment to fix accessibility.
Handing Over From the Previous Developer
However the relationship ended, get these before it goes quiet:
- Access. Remove their collaborator or staff access once you have what you need, and confirm nobody else has access you do not know about.
- Custom apps. A custom app built for your store may live in the developer's own Shopify Partner account. If they close it or stop paying for hosting, the app stops working. Ask where each one lives and who owns it.
- Code history. If the theme was managed in a Git repository, ask for it. It explains why things were done, which the theme files alone never will.
- Any documentation, however rough. A half-page of notes can save days of reverse-engineering.
Questions to Ask Whoever Quotes the Fix
- Which theme is this based on, and how far has it drifted from it?
- Can it still take theme updates? If not, what would it take?
- Which of the problems are template-level, and which are one-offs?
- What will my team be able to edit without a developer afterwards?
- Which apps can be removed, and is any ghost code left from old ones?
Anyone who quotes a fix without being able to answer the first two has not looked at the code yet.
Inherited a Store You Are Nervous to Touch?
Give us collaborator access and we will tell you, plainly, what you have: which problems are real, which are cosmetic, and whether fixing or rebuilding makes more sense. Talk to us directly.
Frequently Asked Questions
How do I know if my Shopify theme is badly built?
The clearest signs are routine content changes that need a developer, SEO basics broken in the templates such as duplicate or empty H1 headings, layout shift and slow loading, a theme that can no longer take updates, leftover code from uninstalled apps, and features nobody can explain. Comparing the theme against a clean copy of the same version shows how far it has drifted.
Should I fix my Shopify theme or rebuild it?
Fix it when it is an Online Store 2.0 theme, the edits are few and understood, and the problems are specific. Rebuild when it is an older Liquid-template theme, it can no longer take updates, the problems sit in templates every page uses, or your team cannot make routine changes without a developer. Rebuilding your current design on a maintained theme such as Horizon is often the best middle path.
Will changing my Shopify theme hurt SEO?
Not if it is done carefully. Product and collection URLs belong to Shopify, not the theme, so they do not change. What the theme controls, and what must be checked before launch, is structured data, page titles, meta descriptions, canonical tags and heading structure. Build the new theme unpublished and compare it with the live one template by template.
Can a customized Shopify theme still be updated?
Only partly. Shopify carries code edits into a theme update when they do not conflict with it. When they do conflict, Shopify removes all code changes from the updated copy, so heavily edited themes often stop being updated. Changes made in the theme editor, rather than in code, are carried over.
What happens to my apps when I change Shopify theme?
Your apps stay installed, but anything they added to the old theme has to be set up in the new one. Apps that use app blocks and app embeds are re-added in the theme editor. Older apps that edited theme code directly may need reinstalling in the new theme, and may have left code behind in the old one.
Who owns the custom apps a previous developer built for my store?
It depends where they were created. A custom app built in the developer's own Shopify Partner account belongs to that account, and can stop working if they close it or stop paying for its hosting. Ask the previous developer where each custom app lives and who controls it before the relationship ends.