Shopify theme updates: what breaks, what to test, and how to roll back

A merchant updates their Shopify theme on a Tuesday afternoon. Nothing looks wrong. The homepage loads, the logo is in the right place, the sale banner still says what it's supposed to say. Three days later they notice conversion is down 30 percent and the add-to-cart button on mobile has stopped responding on the product page template they customized last year. Nobody filed a support ticket. Customers just left. This is the normal shape of a broken Shopify theme update: it looks fine on the surface and fails somewhere specific enough that you don't stumble onto it by accident.

Why theme updates break things that used to work

Shopify theme updates aren't small patches most of the time. A major version bump on Dawn, or an update from your theme developer, can rewrite section schemas, rename Liquid variables, change how JavaScript is bundled, or restructure the cart drawer entirely. If you or a past developer added custom code (a countdown timer, a currency switcher, a custom size chart, a review widget snippet), that code was written against the old structure. The update doesn't know your custom code exists. It just overwrites the files it owns and leaves your custom snippets pointing at elements that no longer exist.

The most common breakage points, in order of how often they bite:

Cart and checkout flow. Custom cart drawers, quantity selectors, and "buy now" buttons are frequently theme-specific and get silently detached from their event listeners after an update.

Tracking and pixels. Meta Pixel, Google Ads conversion tracking, and TikTok Pixel snippets often live in theme.liquid or a custom section. An update can move or delete the injection point without warning, and you keep spending on ads while measuring nothing.

Custom sections and blocks. Anything built by a freelancer or a past version of your team, product bundles, upsell blocks, custom filtering, tends to reference specific CSS classes or JSON schema keys that new theme versions rename.

App embeds. Apps that inject widgets via theme app extensions can conflict with a new theme's block structure, especially around the cart and checkout.

Mobile-specific styling. Desktop looks perfect because that's what gets checked. Mobile breakage is disproportionately common and disproportionately expensive, since most Shopify traffic is mobile.

Test on a duplicate, not on the live theme

Shopify lets you duplicate your live theme before publishing an update, and that duplicate is where the update should happen first. Go to Online Store > Themes, duplicate your current published theme, and apply the update to the duplicate (or, if you're updating via a theme's GitHub repo or CLI, deploy to an unpublished theme). This gives you an exact copy of your store, on the new theme code, that customers never see, and that you can preview and test with Shopify's theme preview link.

The habit that matters most here isn't clicking around the preview. It's placing an actual test order. Add a product to cart, apply a discount code if you use them, go through checkout with a real (refundable) card or Shopify's Bogus Gateway in test mode, and confirm the order lands in your admin correctly. This single action catches the failures that a visual scan never will: a cart drawer that opens but won't let you change quantity, a checkout button that's visually present but unbound from its click handler, a discount field that no longer validates. If you sell in multiple currencies or ship internationally, run the test order in at least one non-default currency too, since currency conversion logic sometimes lives in theme code that updates touch.

While you're in the duplicate theme, check the things that don't show up on a homepage screenshot: tracking pixels firing on page view and purchase (use your browser's network tab or a tag-debugging extension), any custom section you've paid a developer for, mobile cart and checkout on an actual phone, and any app embeds tied to the cart or product page. If your store runs promotional Shopify Scripts, note that Shopify Scripts stopped running as of mid-2026, so if your checkout logic still depends on them, that's a separate and more urgent problem than the theme update; see Shopify Scripts stopped running on June 30, 2026. Would you have noticed? for what replaced them.

The rollback plan you should have before you need it

Shopify's theme editor keeps your previously published theme in your theme library automatically. When you publish a new theme, the old one doesn't disappear, it just becomes unpublished. That means rollback is almost always: go to Online Store > Themes, find the previous version sitting in your library, and click Publish. It typically takes effect within a minute or two.

The part people get wrong isn't the mechanics of rollback, it's the decision to do it. A theme broke store cart flow is rarely reported to you directly. Customers don't email to say the button didn't work, they just close the tab. That's why the plan needs a trigger, not just a button. Decide in advance: if the test order fails on the duplicate theme, don't publish. If you already published and orders drop sharply within a few hours of an update with no other explanation (no ad spend change, no site-wide sale ending), roll back first and investigate on the unpublished duplicate afterward. Don't spend two hours debugging a live checkout while customers are hitting it.

A few things that make rollback safer and faster when you actually need it: keep a named, dated copy of each theme version before you update it (Shopify lets you rename themes in your library), note what apps and custom code were active at each version, and if you use a custom domain and multiple sales channels, confirm the rollback doesn't affect anything channel-specific like a Shopify Markets currency setup. None of this is complicated. It just has to be decided before the update, not during it.

What continuous monitoring adds after you publish

Testing before you publish catches the failures you think to check for. It won't catch the ones that only appear under real traffic, real payment methods, or a specific browser combination you didn't test. This is where ongoing monitoring earns its keep rather than one-time QA. Cassian™ watches order flow after a theme goes live and flags it if orders stop coming in or drop sharply against your normal pattern, which is exactly the signal a broken cart or checkout produces. It also runs page-speed and broken-link checks that catch a theme update that quietly slowed down your product pages or introduced a 404 in a navigation link. None of this replaces the test order before you publish, but it catches what the test order missed, and it catches it in hours instead of days.

The same discipline applies whether you're on Shopify, WooCommerce, or BigCommerce, even though the mechanics differ. WooCommerce store owners face an analogous risk with plugin and core updates, covered in Plugin conflicts are the number one way WooCommerce stores break, and the broader pattern of updates silently breaking checkout is the subject of Checkout is where stores silently bleed. If you want a fuller picture of what to monitor day to day beyond theme updates specifically, How to monitor a Shopify store covers the full checklist.

The takeaway

Theme updates are routine, and most of them go fine. The ones that don't share a pattern: something looked correct at a glance and broke somewhere a quick visual check wouldn't reach, usually cart, checkout, tracking, or a custom section nobody thought to click. Test on a duplicate theme with a real order before you publish, know your rollback path before you need it, and keep something watching order flow after you do publish, so the gap between a silent failure and you noticing it is measured in hours rather than days.