Why does my \"Proceed to checkout\" button do nothing after switching themes?
A theme switch shouldn't be able to break the most important button in your store, but cart JavaScript conflicts make it happen more often than you'd think.
What's going on
A merchant switches themes — or restores a theme to a fresh, unedited state — and suddenly the "Proceed to checkout" (or just "Checkout") button on the cart page or cart drawer does absolutely nothing when clicked. No error banner, no page navigation, nothing. Refreshing doesn't help, and the behavior sticks around even after making unrelated edits to the theme, which rules out a one-off glitch.
This is a recognizable pattern: the button itself is still there and still styled correctly, so it looks like everything should work. But somewhere between the click and the redirect to Shopify's checkout, something is silently failing. Because it survives across further edits, the cause usually isn't the specific change that was just made — it's something baked into the cart template, a snippet, or an app that got carried forward (or reactivated) during the theme switch and is now quietly breaking the handoff to checkout.
Why it happens
On most Shopify themes, the checkout button is either a submit button inside the cart form (which posts to /cart and then redirects to /checkout) or, in cart-drawer setups, a link intercepted by JavaScript that reads the cart's current state before sending the customer forward. Either way, that handoff depends on a chain of JavaScript running cleanly — an event listener has to be attached to the right element, and no earlier script on the page can throw an uncaught error that stops the rest of the page's scripts from initializing.
A theme change disrupts that chain in a few predictable ways: custom code that lived in the old theme.liquid or cart snippets gets copy-pasted into the new theme without being adapted to its structure, producing duplicate element IDs or references to elements that no longer exist; an app's cart-drawer script and the theme's own cart script both try to manage the same button and conflict; or an app embed that was toggled on for the new theme injects a script that errors out before the checkout redirect logic even runs. Because the failure is silent (no error shown to the customer), it's easy to mistake for a settings problem when it's really a script execution problem.
5 ways to fix it
Open the browser console and read the actual error first
Before touching any code, load the cart page, open dev tools (F12 or right-click → Inspect), click Console, and click the checkout button again. A JavaScript error thrown anywhere on the page — even in a completely unrelated script, like an app's tracking pixel or a leftover snippet from the old theme — can stop the browser from running the click handler that was supposed to fire next. The error message and file name it points to (usually something like theme.js, cart.js, or an app's asset file) tells you exactly which script to start with, which saves hours of guessing.
Duplicate your theme and test with a fresh, unedited cart template
In Shopify admin under Online Store > Themes, duplicate your current live theme, then in the duplicate, replace the cart/cart-drawer section with the same section from a fresh copy of Dawn (Shopify's free reference theme) or from your theme's own unedited default. If checkout works again on the clean version, the problem is confirmed to live in custom cart markup or JS carried over from the old theme, and you can restore the original section piece by piece to find the exact line that breaks it — this is the diff-and-isolate approach that consistently finds these bugs.
Check for duplicate IDs and leftover script tags in theme.liquid
A very common cause after a theme switch is that two elements on the page end up sharing the same id (for example, two "checkout" or "CartDrawer" IDs), which means the JavaScript that's supposed to attach a click listener attaches it to the wrong element, or to none at all. This usually happens when old custom code was pasted into theme.liquid or a cart snippet and never removed during the switch. Search theme.liquid and any cart-related sections/snippets for hardcoded IDs, inline <script> blocks, or old app snippets that reference elements from the previous theme's structure, and remove anything that isn't part of the current theme.
Temporarily disable apps and theme app embeds one at a time
Any app that touches the cart — upsell/cross-sell widgets, cart drawers, currency converters, free-shipping bars, sticky add-to-cart bars — can intercept the checkout button's click event and fail to hand off to Shopify's checkout, especially if it calls preventDefault() and then errors before redirecting. In the theme editor, go to App embeds in the left-hand panel and toggle each one off individually, retesting the checkout button after each toggle, and separately check Settings > Apps to see which apps are actually still active versus leftover from before the theme change.
Rule out ad blockers and browser extensions as the last check
Because Shopify's checkout button (or the AJAX call that leads to it) often depends on scripts being able to load and run without interference, an ad blocker, privacy extension, or corporate network filter can silently block a script the button depends on, making it look like a theme bug when it only reproduces in one browser. Test in an incognito window with all extensions disabled, and ask a customer or colleague on a different device to confirm before assuming the fix has to be code-level.
Bottom line
Most of the time this is a JavaScript conflict, not a Shopify platform bug — the theme change either carried over stale custom code, exposed a duplicate ID, or an app's cart script started throwing an error that blocks the checkout click handler from firing. Work through the browser console first, then isolate with a clean duplicate theme; that combination finds the cause in the vast majority of cases without needing to touch checkout settings at all. If your store leans heavily on customer-facing popups or announcements layered onto the cart (free-shipping bars, upsell modals, etc.), it's worth having someone audit how those scripts interact with the cart drawer specifically, since that's the most frequent source of this exact symptom.
Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.