How to Remove Leftover App Code From a Shopify Theme
A step-by-step audit for finding and safely removing ghost code that apps leave in Shopify themes after uninstalling, plus how to avoid the problem going forward.
Why uninstalling an app is not the end of the story
Most merchants assume that clicking “Delete” on an app removes everything the app put on the store. On Shopify, that depends entirely on how the app was built, and there are two very different generations of app architecture in the wild.
Modern apps integrate through theme app extensions. They ship their storefront pieces as app blocks and app embed blocks, which appear in the theme editor and never write anything into your theme files. Shopify’s developer documentation is explicit about why this architecture exists: the older approach, where apps pushed snippet files into the theme through the Asset API and injected JavaScript via script tags, “often leaves the code edits, or ghost code, behind in the theme” after uninstall. Theme app extensions were designed so that nothing is ever injected, so nothing can be left behind.
The catch is that plenty of apps — especially older ones, or quick script-style integrations — still fall into the first category. When you uninstall them, the files and include statements they added stay in the theme. The app’s dashboard is gone, but the code keeps rendering on every page load: orphaned <script> tags pointing at servers that no longer know about your store, dead CSS, empty <div> containers, and include statements referencing snippets that still exist.
This residue matters for three reasons. Dead JavaScript costs load time, which compounds any existing performance problems you might be tracking with the workflow in our Shopify theme performance guide. Ghost code can break layout in ways that are hard to trace because the editor shows nothing — the code lives in files, not in sections. And, as Shopify’s migration documentation notes, leftover edits from apps are a known blocker when merchants want to update or change their theme: the upgrade path carries old app code forward or forces manual reconciliation.
Step 1: Figure out what kind of app it was
Before touching any code, establish which integration method the app used. Shopify documents three:
App blocks. These appear as blocks inside sections, or as sections in templates, positioned in the theme editor. If the app worked this way, you can remove it visually: open the template in the editor, click the block, and delete it. Nothing remains in the theme files.
App embeds. These are the floating or invisible elements — chat bubbles, analytics, tracking pixels. They are toggled in the theme editor under the App embeds panel, and they can be configured per market if you sell internationally. If your app was an embed, the cleanest sequence is to disable the embed in the theme editor before uninstalling the app. That way the configuration is removed as part of the process.
Direct code injection. Some apps write Liquid snippets, scripts, and asset files directly into the theme. This is where uninstalling leaves residue — and where the rest of this guide applies.
If you no longer remember how the app was installed, check the theme editor first. Anything visible there is managed and clean. What is left over lives in the code editor.
Step 2: Duplicate the theme before editing anything
This step is not optional. Shopify’s own guidance for editing theme code starts with duplicating the theme so you have a copy to fall back on, and for good reason: the theme editor’s Timeline view restores one file at a time, cannot recover deleted files, and asset files — images, CSS, JavaScript, fonts — have no Timeline history at all. If you delete the wrong asset, there is no undo.
So: in your Shopify admin, go to Online Store → Themes, open the “…” menu on your live theme, and click Duplicate. Do your cleanup on the copy, preview it, then publish it when you are satisfied. This also gives you an instant rollback if something surfaces a week later.
One more reason to work on a copy: if a theme update arrives while you have incompatible code changes, Shopify’s documentation warns that your code changes are removed in the updated copy. Doing app-residue cleanup on a duplicate keeps your live theme stable while you work.
Step 3: Audit the theme systematically
Ghost code hides in predictable places. Open “…” → Edit code on the duplicate theme and work through this checklist. Search for the app’s name — most apps name their files and variables something recognizable — but also search for generic patterns, because not all apps are tidy about naming.
1. layout/theme.liquid. The single most common location. Old script-tag apps and manual integrations add <script> and <link> tags to the <head> or before </body>. Look for script src attributes pointing at external domains, especially ones matching the app vendor’s domain.
2. The snippets folder. Apps that used the Asset API typically dropped one or more snippet files here (often named after the app) and included them with {% render %} or {% include %} statements. Two things need removing: the snippet file itself, and every statement that references it. Search the whole theme for the snippet name to find the include sites — they are often in theme.liquid, product.liquid, cart.liquid, or section files.
3. The assets folder. Look for CSS and JavaScript files you cannot attribute to the theme or to a current app. Cross-reference carefully: free themes like Dawn have their own JS files, and removing one of those breaks the theme. If a file’s name matches the uninstalled app and nothing else references it, it is residue. Remember deleted assets are unrecoverable — this is the step where working on the duplicate earns its keep.
4. The templates and sections folders. Apps occasionally create their own template files (for example, a “wishlist” or “lookbook” page) or inject markup into existing sections. If the app created pages, check the Pages and Navigation areas of the admin too, so you don’t leave a published page pointing at a template you deleted.
5. config/settings_schema.json and locales/. Some apps add theme settings or translation keys so merchants can configure them from the theme editor. These are harmless-looking but contribute to clutter, and orphaned locale keys occasionally cause translation missing messages after cleanup.
6. config/settings_data.json. App embed toggles are stored here. If you uninstalled an app without disabling its embed first, an orphaned entry may remain. The safer route for anything still present in the theme editor is to toggle it off in the editor rather than hand-editing this file, since settings_data.json also holds all your legitimate theme settings.
A practical search strategy: in the code editor’s search bar, try the app name, the vendor name, and the domain from the app’s script URLs. Then search for <script src= and review every external domain you do not recognize.
Step 4: Verify, then publish the clean copy
Do not judge the cleanup from the editor alone. Preview the duplicate theme and check the pages where the app used to appear — typically the home page, product pages, and cart. Open your browser’s developer tools and look at the Console and Network tabs: the goal is zero requests to the uninstalled app’s domain and no JavaScript errors from missing elements it used to populate.
When the preview looks right, publish the duplicate theme and re-check the live storefront once more. Keep the previous version around for a few days before deleting it.
Step 5: Prevent the problem from coming back
The long-term fix is to prefer apps built on the modern architecture. When you are evaluating an app in the App Store, check whether it mentions app blocks or theme app extension support in its description or setup instructions — those apps never touch your theme files, so uninstalling them is genuinely clean.
The direction of travel is also enforced by Shopify itself: script tags, one of the legacy injection methods behind ghost code, stop running on storefronts on March 1, 2027. Apps that have not migrated to theme app extensions will lose that mechanism entirely, which makes “does this app use theme app extensions?” a fair question to ask any vendor whose app asks for theme access.
There is also a process habit worth adopting: before uninstalling any app, open the theme editor and disable its app embeds and remove its app blocks first, then uninstall the app. For apps built on extensions this removes everything; for older apps it at least removes the editor-managed portions, leaving less to hunt down in code.
When cleanup is part of something bigger
Residue cleanup is often not a standalone chore. It comes up during theme redesigns, version upgrades, and replatforming projects — precisely the moments when you do not want mystery code migrating forward. If you are weighing whether to clean, update, or migrate a storefront, the decision framework in our guide to choosing and migrating website platforms covers when each option makes sense. And if your store’s theme has accumulated years of app residue and you would rather have it audited and cleaned by someone who does this regularly, our Shopify development services cover theme cleanup and rebuilds; you can also read more about how we work with the Shopify platform.
The pattern to remember is simple: apps that show up in the theme editor are safe to remove there; apps that asked you to “paste this snippet into your theme” always leave something behind. Audit before you uninstall, edit only on a duplicate, and favor apps built on theme app extensions going forward.
Official sources.
Use these references to verify platform-specific behavior and version details.
Continue with the surrounding work.
How to Diagnose and Fix Shopify Theme Performance Issues
How to Fix WordPress Missed Schedules and WP-Cron Problems
Broader context from the YCTheme blog.
When to Migrate a Website to a New Platform
A decision framework for moving between WordPress, Joomla, TYPO3 and Shopify: the signals that justify a migration and how to plan one without losing search visibility.
Staging Environments: How Professional Teams Ship CMS Changes Without Breaking Production
Staging is where risky changes prove themselves before customers see them. A practical look at how WordPress, Joomla, TYPO3 and Shopify teams stage, test and promote changes.