November 5, 2026 by Alex Massaad · 14 min read

Shopify Script Tags Stop Working March 1, 2027: What Breaks and How to Migrate

Shopify announced in August that script tags stop loading on storefronts on March 1, 2027. Most merchants have never heard the term, and the apps that rely on it do not show up anywhere obvious in the admin. This post is the merchant version of the answer, with a section at the end for developers.

What Happens to Your Shopify Store on March 1, 2027?

On March 1, 2027, Shopify stops injecting script tags into your online store pages. Your store keeps working and keeps taking orders. Any app feature that still loads through a script tag stops appearing, with no error and no warning to you or your customers.

The store does not break. Pieces of it go missing.

The first deadline has already passed. Since October 1, 2026, apps cannot create or update script tags at all, on any API version, so an app that has not moved by now cannot even patch its old setup. Here is the full timeline from Shopify’s changelog and its order status migration guide:

Is this the same as the Shopify Scripts deadline? No, and the names do not help. Shopify Scripts were Ruby code that changed checkout logic on Plus stores, and they stopped running after June 30, 2026. We covered that one in what happened to Plus stores on July 1. Script tags are a different, older mechanism that any app on any plan could use to load JavaScript on your storefront. Plus merchants who just finished the Scripts migration are not done, because their apps may still use script tags.

What Is a Script Tag, and Does My Store Use One?

A script tag is a record an app creates through Shopify’s API that says “load this JavaScript file on every storefront page.” Shopify then adds the file to your pages for you. It never appears in your theme code or in the theme editor. Shopify’s changelog gives that as the reason for retiring them: script tags run “without appearing in the theme editor, which makes them difficult for merchants to find and control.” You cannot see one, and you cannot turn it off without uninstalling the app. It also keeps running long after anyone remembers why.

If you have installed apps that add something visible to your storefront, or that track what customers do there, some of them may have used script tags at some point. Many popular apps moved to theme app extensions years ago. Some did not. The only way to know for your store is to check, because Shopify does not give you a list.

Shopify is not warning merchants directly. Shopify’s storefront migration doc says an earlier version of its plan included a banner warning merchants who install an app that uses script tags, and that it has decided not to show that banner “for now.” You may see blog posts saying a warning appears in your admin. Do not wait for one.

What Will Actually Break

It depends on what each app was doing on your storefront. The common patterns:

Widgets disappear. Review stars, size charts, wishlists, “frequently bought together” bars, countdown timers. If the widget was drawn by a script tag, it stops rendering. The space it occupied usually collapses, so the page looks fine at a glance. Nobody notices until someone asks where the reviews went.

Popups and chat stop opening. Email capture popups, spin-to-win wheels and chat bubbles commonly load as a single script. When the script stops loading, the popup never fires. Your email list growth slows and nothing in the admin tells you why.

Tracking goes quiet, and this is the dangerous one. Analytics and conversion scripts that load through script tags stop reporting. Revenue in Shopify stays where it was, but the conversions your ad platforms see drop. If you run paid campaigns, automated bidding reads that as campaigns failing and adjusts accordingly. A team that does not know about this change can spend weeks optimizing ads against a measurement gap.

Order status page scripts already stopped. If an app added code to your Order status page through a script tag, that ended on August 28, 2025 for Plus stores and August 26, 2026 for everyone else. If a post-purchase survey or tracking pixel on that page went quiet in late August 2026 (or back in August 2025 on Plus), this is a likely reason.

How to Find Out Which Apps Are Affected

Shopify does not offer merchants a report of which apps use script tags. Only the app that created a script tag can list it through the API, so the full picture lives with your vendors, not in your admin. That leaves a mix of asking and looking.

Start with your app list. Go through Settings, Apps and sales channels, and write down every installed app that touches the storefront. Skip the ones that only work in the admin (inventory, accounting, shipping labels). For a quick outside view of what your storefront actually loads, our free Shopify store inspector fingerprints the apps it can recognize from the public page. It tells you which apps are present, not how each one loads, so treat it as the inventory step.

Ask each vendor in writing. This is the most reliable check, and the next section has the exact questions.

Search your page source for asyncLoad. Open your home page in a desktop browser, view the page source, and search for asyncLoad. That is a small loader Shopify adds to your pages. The line just below it that starts with var urls = [ lists the JavaScript files Shopify is injecting through script tags right now. Each entry is a full URL, shown with escaped slashes (https:\/\/) and usually ending in ?shop=yourstore.myshopify.com. The domain in each URL usually tells you which app it belongs to. We checked this on live storefronts in November 2026, and the third-party app scripts showed up in that list exactly as described. Anything still in that list is something that stops loading on March 1.

Check App embeds in the theme editor. Open Online Store, Themes, Customize, then the App embeds panel. Every app that has moved to an embed should be listed there. An app you know adds something to your storefront that has no embed listed, no app block placed in a section, and no entry in the asyncLoad list deserves a question.

Check Customer events, as a hint. Settings, Customer events is where Shopify has you manage pixels, and tracking apps that moved off script tags often show up there. Do not treat it as a complete list. A missing entry is a question for the vendor, not proof of anything.

Look in your theme code. Some “script tag” problems are not script tags at all. Older app installs, or a developer in a hurry, often pasted a <script> straight into theme.liquid. That code is not affected by this deprecation and will keep running, but it is worth finding now, because it often belongs to an app you uninstalled years ago.

What to Ask Your App Vendors

Send this to every app that touches your storefront. Get the answer in writing, because you will want it again in February.

1. “Does your app load anything on our storefront through a script tag today?” You want a yes or no, not a link to their help center.

2. “If yes, what is replacing it: an app embed, an app block or a web pixel?” Each one means something different for you. An embed you switch on once per theme. An app block you place in a specific section. A pixel needs no theme step from you, though you may be asked to approve the app’s updated permissions.

3. “When will the replacement be live, and what do we need to do?” Pin down a date before March 1, 2027 and whether you need to switch anything on.

4. “Does it work on our theme?” App blocks only work on Online Store 2.0 themes. App embeds work on older themes too. If you are on a vintage theme, ask this one specifically.

5. “Once the replacement is running, will you delete the old script tag?” If they switch on the new version and forget to remove the old one, the code loads twice until March. That means duplicate widgets and double-counted analytics.

A vendor who cannot answer the first question clearly by now is telling you something. Since October 1, 2026, they cannot update their old setup even if they want to.

What Your Developer Needs to Do

If you have a developer or an agency, or you run a custom app, here is the work in the order Shopify recommends in its storefront migration doc.

Pick the right replacement. There are three, and they are not interchangeable:

• App embed block. Part of a theme app extension, targeted at the page head or body. It loads your JavaScript or injects content on every page, works on both vintage and Online Store 2.0 themes, and the merchant switches it on in the theme editor. This is the closest thing to a script tag.
• App block. Also part of a theme app extension, but the merchant places it in a specific section, and it only works on Online Store 2.0 themes. Use it when the feature belongs in one spot on one template, such as a widget on the product page.
• Web pixel. For code that only collects analytics or conversion data. It runs in a sandbox, respects customer privacy settings, and needs no theme at all. The app creates it with webPixelCreate, which needs the write_pixels and read_customer_events scopes.

Audit what the app has. The scriptTags query and scriptTagDelete mutation still work, so start by listing what your app actually created, store by store:

query ScriptTagAudit {
  scriptTags(first: 50) {
    nodes {
      id
      src
      displayScope
      createdAt
    }
  }
}

A displayScope of ALL means the tag was also running on the Order status page, which already stopped, so that part of the feature needs its own replacement. The storefront half of an ALL tag keeps running until March 1, 2027.

Ship the replacement, then get merchants to turn it on. Shopify’s theme app extension docs describe no programmatic way to switch on an embed for existing merchants. The best you can do is a deep link into the theme editor with your embed ready to activate (https://{shop}.myshopify.com/admin/themes/current/editor?context=apps&activateAppId={api_key}/{embed_handle}), plus a check in your app that tells the merchant when it is off. The same docs say an embed appears in the theme’s settings_data.json only after it has been switched on once, and stays there with disabled set to true if the merchant later turns it off.

Delete the script tag only after the replacement runs. Shopify’s doc is blunt about the order. Delete the tag first and nothing runs. Leave both and the code loads twice. Confirm the embed is active on the merchant’s published theme, then call scriptTagDelete for that store.

Remember the theme switch. Embeds are switched on per theme. When a merchant installs and publishes a new theme, your embed is off there until they switch it on again. Build for that from day one.

Custom apps created in the admin are a special case. They cannot use app extensions, which rules out both theme app extensions and web pixels. If a past developer set up storefront code that way, the choices are to move the code into the theme, to rebuild it as a proper app, or, if a third-party service set it up, to ask them to publish a real app. Moving code into the theme is fastest. Shopify suggests a custom Liquid block where possible, which you add in the theme editor without editing theme files. Pasting the code into the code editor also works, but that is a code edit, which makes future theme updates a manual job. Either way, the code stays put if you ever stop using the service, which is exactly the kind of thing to write down for whoever runs the store next.

What We Learned Building on the Replacement

To be clear about where our experience comes from: none of the apps we have built ever used script tags. We started on theme app extensions, so we have not migrated an app off script tags. What we can tell you is what the replacement is like to build on.

JourneyGlow is an app block. Our product journey app puts an interactive map of where a product comes from on the product page, as an app block the merchant places in a section of the product template. It renders content in one spot that the merchant chooses, so a block fits, and it has never used script tags. Its thank-you page block is a checkout UI extension, the same family of extension Shopify now points to for anything that used to run on post-purchase pages.

Merchants have to find your embed. Expect most of the support friction with embeds to come from merchants not knowing an embed exists. If your app checks whether its embed is on, name it in the warning exactly as the theme editor lists it, because that is the name a merchant will look for. On themes built from nested theme blocks, such as Horizon, an app block can sit inside another block in the template, so a check for whether your block is placed has to look there too.

CrowdShop, a client app we built, uses two app blocks. One shows the cashback offer on the product page and one shows the customer’s wallet. Both are placed by the merchant in the theme editor, so the merchant has to add each one where they want it to appear.

What to Do Before March 1

This month: inventory and ask. List your storefront apps and send every vendor the questions above. Note who answers clearly and who does not.

December and January: switch on and test. As vendors ship their replacements, switch embeds on in a duplicate of your live theme first, check the pages they touch on desktop and mobile, then switch them on in the published theme. Watch for anything loading twice.

February: chase the stragglers. Any app still on script tags in February needs a decision: wait, replace it, or remove it. If it drives revenue or tracking, do not wait.

After any theme change: re-check embeds. A newly installed theme starts with every app embed switched off. Put “re-enable app embeds” on your theme launch checklist permanently.

How long the developer work takes depends on what you are migrating:

A simple storefront widget moving to an app embed. A few hours. Switching it on is a separate step, because the merchant still has to activate the embed, and again on any new theme.

An analytics or tracking script moving to a web pixel. A day or two, including testing in the pixel sandbox, which behaves differently from a normal page.

An app with several scripts. About a week, once you include testing across themes.

Code from a custom app created in the admin. Moving it into a custom Liquid block is usually the quick route. Rebuilding it as a proper app with a theme app extension is a bigger job and lands in the “about a week” range.

The vendor chasing usually takes longer than the code. Start that part now.

Common Mistakes We Expect to See

Deleting the app to “fix” it. Uninstalling an app removes its script tag, its embed and its blocks. That is fine if you no longer need it. It is not a migration.

Forgetting the embed on a new theme. A store launches a redesign in February, every embed is off, and reviews and tracking vanish on the same day. It looks like the deprecation hit early. It did not.

Running old and new together. A vendor ships an embed, the merchant switches it on, and the old script tag is never deleted. Analytics double-counts until March 1, then drops by half, and someone decides marketing stopped working.

Assuming Plus means you are covered. Plus merchants who finished the Scripts to Functions migration sometimes assume their apps are handled too. They are separate deadlines with separate fixes.

Leaving pasted theme code alone because it “still works.” Code pasted into theme.liquid survives March 1, but it is often from an app you no longer pay for, and it still loads on every page. Clean it up while you are in there.

Need a Hand?

If you want someone to check which of your apps still load through script tags and chase the vendors who have not answered, that fits naturally into ongoing maintenance and support. If you run a custom or private app that still uses script tags, we build theme app extensions and web pixels as part of our Shopify app development work.

Send us a note with your store URL and we can check which of your apps still load through script tags. We will tell you honestly what is at risk and what can wait.

The worst version of March 1 is the one where you find out from your ad dashboard three weeks later.