There is a list of third-party scripts running on your storefront, and you have probably never seen it

Thirty seconds, before anything else

Open your storefront in a browser. View the page source — Ctrl+U on Windows, Option+⌘+U on a Mac. Search the page for asyncLoad.

If you find it, you are looking at a block like this one:

var urls = ["https://cdn.example-app.com/app/example.myshopify.com/widget.js?shop=example.myshopify.com", …];
for (var i = 0; i < urls.length; i++) {
  var s = document.createElement('script');
  s.async = true;
  s.src = urls[i];
  …
}

Every URL in that array is a script tag: a piece of JavaScript that an installed app asked Shopify to load on your site. On 1 March 2027, Shopify stops putting that block on the page. (In the real page source the slashes are escaped — you will see https:\/\/ — because the block is delivered as JSON.)

That array is the whole subject of this article. It is worth reading yours before you read the rest, because the general version of this news — "Shopify is deprecating script tags" — has been circulating in developer channels since August and sounds like somebody else's problem.

What is actually in there

I checked seven well-known Shopify storefronts on 8 September 2026. Three carried the block, and what was in it is below. Of the other four, three do not render a Liquid storefront at all — they are headless builds, where this check does not apply because the block it looks for is injected by Liquid — and one was behind a bot challenge that never served the page. So: three confirmed lists, and four stores this method cannot answer for.

That is a sample, not a statistic, and Shopify publishes no figure for how many stores are affected. But look at what those are. Not advertising pixels. Subscriptions. Loyalty points. The chat widget. The reviews under your products. Upsells in the cart. Returns.

Roughly half of that list is directly load-bearing for revenue, and almost none of it is the advertising analytics that dominates the conversation about this change — which matters later, because the replacement Shopify recommends most loudly is for analytics and cannot do any of these things.

What happens, and when

Three dates, two of which have already passed by the time you read this.

The wording of the last one, from Shopify's own documentation:

Shopify will stop injecting script tags into storefront pages. Your script will no longer load, and any feature that depends on it will stop working for that store.

• Storefront script tags, Shopify developer documentation

At publication that is 140 days away — four months and a bit over a fortnight. Long enough to be nobody's priority this week, short enough that a vendor who has not started yet may not finish.

One clarification on wording, because it changes what you should expect to see. Shopify does not describe this as failing silently, and I am not quoting them as saying so. The silence follows from the mechanism: the script is simply not written into the page, so there is no request to fail, nothing in the browser console, no error anywhere. The feature is present one day and absent the next, and the site looks completely normal.

A script tag is not a <script> tag

This is where most summaries of this change go wrong, and getting it right will save some people a panic and cost others their complacency.

In Shopify's vocabulary a script tag is a resource in the Admin API that an app creates. Shopify then injects it into your storefront on that app's behalf. As the documentation puts it, a script tag "loads JavaScript on a storefront without any changes to theme code", and script tags "are scoped to the app that created them".

Which means:

• Code your developer pasted into theme.liquid, or into a Custom Liquid block, is not a script tag and is not affected. It keeps working on 1 March 2027. Shopify actually recommends moving into theme code as the escape hatch for apps with no other option.
• Additional Scripts in checkout is a third, different thing — that was checkout.liquid, and it died in August 2026 for non-Plus stores.
• The people affected are store owners with installed apps whose developers do not migrate in time. You cannot fix this yourself; you can only find out and apply pressure or replace the app.

So the question is not "did we ever add custom code" — it is "which of our installed apps still work this way".

Where the list lives, and where it does not

The obvious move is to ask Shopify for the list. It does not work, and the way it fails is a trap worth naming.

There is an API for querying script tags. It returns only the script tags belonging to the app doing the asking — they are "scoped to the app that created them". So if you make your own app and query it, you get an empty list and conclude, reasonably and wrongly, that you have none.

That path is also closing from the other end: new admin-created custom apps can no longer be created at all, so "I will just make a custom app and check" is closed off from that side too — and even if you built one through the developer tooling, it would still only see its own script tags, which is none.

Nor does Shopify's developer documentation or its merchant help centre describe any admin screen that lists the script tags on a store. That is not proof one does not exist — it is what searching for it produces. Which leaves the page source, and that is why this article starts there rather than ending there.

This time, staying on an old API version does not help

If you have dealt with a Shopify deprecation before, you may know the usual escape: version pinning buys time, because each stable version is supported for at least twelve months and requests to a retired version get served by the oldest one still available.

That rule is explicitly cancelled here:

The deprecation applies to all API versions, including older ones, so pinning won't defer it.

• Online store script tags deprecation, Shopify changelog, 24 August 2026

That sentence is written about the October date — the block on creating and updating script tags — and Shopify repeats it in the documentation as "treat the failure as permanent". It applies with more force to March, for a reason worth stating plainly: what is being removed then is not a field or a behaviour inside an API version. It is the delivery mechanism itself, and no version of the API brings it back.

Which makes this the exact inverse of the situation in a metafield filter that quietly stopped filtering, where pinning a version does postpone the problem and the danger is forgetting that the postponement runs out. Here there is nothing to postpone at all.

One diagnostic while we are on versions, since it is one line of work: the API version that actually served a request comes back in the X-Shopify-API-Version response header. Compare it with the version in the URL you called, and if they differ, you are already being served by a different version than the one you think you are pinned to.

The replacement is worse for you in one specific way

Shopify's migration path is a fork, and it is documented plainly:

If your app uses a script tag to…	Then use
Load JavaScript on storefront pages	An app embed block
Track analytics, conversions, or customer behavior	A web pixel

• Storefront script tags

For the things in your asyncLoad list — chat, loyalty, reviews, upsells — the answer is almost always the left-hand row, and that is the one with a cost attached for you rather than for the developer.

A script tag was installed silently by the app. An app embed block is not:

App embed blocks are inactive until an app user turns them on in the theme editor, and your app can't activate them on the app user's behalf.

• Migrate to theme app extensions, Shopify developer documentation

And it lives in the theme rather than in the store:

An app embed block is only active on the theme it was enabled on. If a store publishes a different theme, then your block isn't active on it, so check activation again.

• Storefront script tags, Shopify developer documentation

Read that as an ongoing operational change, not a one-off migration. Change your theme, publish a redesign, roll back to a backup theme — and the apps go quiet again, with no error, exactly as they will on 1 March. This already happens today. One developer described running into it on the Shopify forum in April 2025, before any of these dates:

Brands like the app and they install it, but whenever they change themes or redesign their site my app switches off (becomes disabled) and they need to manually switch it on again. I thought that theme extension app blocks were not supposed to do this (I thought they were supposed to persist).

• a merchant, Shopify community, April 2025

The other branch, web pixels, is genuinely simpler — no action needed from you — but it is strictly for collecting data. Pixels run in a sandbox built to control what data reaches the app developer, and Shopify's own list of what that costs starts with any features that rely on "scraping the DOM for information or attempting to write to the DOM". For app pixels the sandbox is a web worker, where, in Shopify's words, "traditional JavaScript pixels that use browser APIs such as window.document won't work". So a widget cannot become a pixel. If a vendor tells you their migration is done because they shipped a pixel, and their product draws something on your page, those two facts do not fit together.

The last click belongs to the merchant

The question everybody asks was asked publicly, by an app developer, the day after the announcement:

Will there be a way to programmatically enable an app embed block for existing users? We have thousands of merchants using ScriptTags, and relying on each one to click a deep link from an email or return to the app dashboard feels daunting.

• a developer, Shopify developer community, 25 August 2026

A Shopify staff member answered the same day:

[…] there's no programmatic way to enable them for existing users. Let me go back to the team, see what's possible here.

• a Shopify staff member, same thread, 25 August 2026

Six weeks later the thread was still sitting at four posts, and that promise to go back to the team had produced nothing public. So the position, as it stands, is that the decision to re-enable each widget is a manual action taken by the store owner — you — in the theme editor, for every affected app, on every theme you publish.

An app vendor can do everything right and still end up switched off on your store, and the only person who can complete their migration is you. That is worth knowing now rather than in March, because it means "our vendor says they're on it" is not the end of your involvement.

And if your "app" is one somebody had you create

There is a category with no replacement at all, and it describes a lot of small businesses:

Admin-created custom apps can't use app extensions, so they can't use theme app extensions or web pixels either. These are apps created directly in the Shopify admin, rather than with Shopify CLI or the Dev Dashboard, and they have no extension-based replacement for script tags.

• Storefront script tags

Shopify then sets out three cases, and the third is the one to recognise: a third-party service had you create the app in your own admin and paste an access token into their dashboard. If that describes any of your tools, that service has to release a real app. There is no configuration change that saves it.

For the first case — you maintain it — the fix is to move the script into the theme, using a Custom Liquid block where possible. Shopify's own caveat is worth repeating: editing theme code takes the theme off its automatic upgrade path, so it is a last resort rather than a shortcut.

What this looks like when it actually happens

You do not have to imagine the experience, because the same mechanism ran in August on the checkout pages, and the merchant forum filled up afterwards — with people who did not know that was what had happened to them.

The reports arrive as a measurement problem:

Shopify order counts look normal, but Meta reports fewer purchases across the same days. The gap is small enough that you would miss it unless you put the two numbers side by side […]

• a merchant, Shopify community, 26 August 2026

A merchant in the same thread named the cause:

Aug 26 killed Additional Scripts on Thank You / Order status for non-Plus. Pixels that still lived there went quiet with no dramatic error. Shopify admin orders look fine. Meta (and sometimes Google) under-report.

• another merchant, same thread

And another participant named the real cost, which is not the missing data:

during a gap like this your measured ROAS drops but your actual profit doesn't move at all. The orders are still happening, Shopify sees them, Meta just stopped counting. The risk is that someone looks at the dashboard, sees ROAS fall below what they think their threshold is, and pauses a campaign that was making money the whole time.

• another merchant, same thread, 3 September 2026

Note that nobody in those threads arrived saying "script tags" — the words they arrived with were "Meta is reporting fewer purchases". In that thread the connection was made the same day, by people who work on stores professionally. Elsewhere on the merchant forum it went differently: a store owner posting about flat-lined conversion data after the same kind of migration reported that "The WebDev doesnt have an answer for me". March will produce the same shape, except the missing thing will be a chat widget or a subscription flow rather than a number in somebody else's dashboard.

Worth adding: the announcement went into the developer changelog and the developer forum. Searching the merchant community for the 2027 date turns up nothing at all. Shopify's documentation describes exactly one merchant-facing warning — a dismissible banner shown from October 2026 when somebody installs an app that still uses script tags — which by definition does not reach a store that installed the app two years ago. Whether Shopify emails existing merchants closer to the date, I could not establish either way.

Your list, and what to do with it

1. Get the list. Page source, search asyncLoad, read the URLs. The domain tells you the vendor — smile.io, gorgias.com, attn.tv and so on.
2. Check which of them have already migrated. In Online Store → Themes → Customize, open the App embeds panel. An app that appears there has a theme app extension. An app whose script is still in your asyncLoad array and is not in that panel has not finished, or has finished and nobody switched it on.
3. For a more reliable version of step 2, look at the published theme's config/settings_data.json under Edit code and read the blocks section — the same file Shopify tells app developers to read when they want to confirm a block is active.
4. Check Settings → Customer events for what has moved to web pixels. Anything analytics-shaped should end up here.
5. Email every vendor you could not account for, and ask one specific question: do you have a theme app extension or web pixel replacement, and what do I need to switch on before 1 March 2027? A vague yes is not an answer — the action is yours, so you need to know what it is.
6. Redo step 2 after any theme change, permanently. This is the part that does not end in March.
7. If a vendor had you create a custom app in your admin and paste a token to them, raise it now. That one needs them to ship real software, and four months is not long for that.

When this is a job to hand over

The audit is genuinely yours. It is one keyboard shortcut, one search, and a list of domains. If your storefront is a standard Shopify theme and the search comes back empty, that is the end of it for you. If your store is headless — a custom front end that talks to Shopify only through the API — this check tells you nothing either way, because the block it looks for is injected by Liquid.

What is not yours is the middle of the list. Nobody who runs a shop can tell, from a domain name, whether that vendor has shipped a theme app extension, whether the block is active on the published theme, or whether the thing it renders can even survive the move to a pixel. That is vendor-by-vendor chasing, and its size is exactly the length of your list — which makes it one of the rare pieces of work you can price before starting, because you produced the count yourself in step one.

The part worth paying for, though, is not the chasing. It is the day after: a theme change switches these off, permanently and quietly, and no alert exists anywhere for "the loyalty widget stopped rendering". Whoever handles this should be leaving behind a check that runs after every theme publish, not just a completed migration. Most of the storefront work we take arrives as something that used to be on the page and is not any more, and nobody can say when it went.

The wider lesson is about where responsibility lands when a platform retires a mechanism. Shopify gave the notice, in the right place, to the right technical audience. App vendors will mostly do their part. And the last step in the chain — the one that decides whether your reviews still appear — is a toggle in a theme editor that only the store owner can press, on a page they have no reason to open. The migration can be complete on every side and still not have happened on your storefront.

Sources

• Online store script tags deprecation - Shopify changelog, 24 August 2026, read 8 September 2026. The 1 March 2027 date for Shopify ceasing to inject script tags into storefronts, the 1 October 2026 block on creating and updating them, the statement that pinning to an older API version does not defer it, the description of a script tag as loading JavaScript without theme code changes, and the note that the script tags query returns only the calling app's own records.
• Storefront script tags - Shopify developer documentation, read 8 September 2026. What stops working on 1 March 2027 and the fact that leftover records become inert; the replacement table pairing app embed blocks with storefront JavaScript and web pixels with analytics; app embed blocks being per-theme and requiring the store owner to enable them; the banner shown from October 2026 when installing an app that still uses script tags; and the three ownership scenarios including admin-created custom apps having no extension-based replacement.
• Order status page script tags - Shopify developer documentation, read 8 September 2026. The earlier phases of the same deprecation, including August 2025 for Plus stores and 26 August 2026 for all others. Shopify's own wording covers the Order status page and script tags; the wider description including the Thank you page and Additional Scripts comes from merchants in the community thread cited below.
• Migrate to theme app extensions - Shopify developer documentation, read 8 September 2026. App embed blocks being inactive until enabled by the store owner with no way for the app to enable them, and the documented method of checking the published theme's settings file for active blocks.
• About web pixels - Shopify developer documentation, read 8 September 2026. The sandbox restrictions, including that features relying on reading from or writing to the page will not work, the limited set of available globals, and that callbacks run only after customer consent where consent is required.
• API versioning - Shopify developer documentation, read 8 September 2026 from the raw page. The accessibility dates for current stable versions, the fall-forward behaviour, the X-Shopify-API-Version response header, and the list of unversioned APIs which includes web pixels.
• ScriptTag resource - Shopify Admin API reference, read 8 September 2026. Script tags being scoped to the app that created them and removed when that app is uninstalled.
• Generate access tokens for admin-created custom apps - Shopify developer documentation, read 8 September 2026. That new admin-created custom apps can no longer be created while existing ones continue to work.
• content_for_header - Shopify Liquid reference, read 8 September 2026. The warning against parsing or modifying the header object, which is why the page-source check in this article is described as a manual audit rather than something to automate.
• Deprecation: script tags will stop running on March 1, 2027 - Shopify developer community, August 2026, read 8 September 2026. A Shopify staff member noting that script tags have been deprecated since 2021, a developer with thousands of merchants asking for a programmatic way to enable app embed blocks, and the staff answer that there is none. The thread had received no further reply six weeks later.
• App extension theme block regularly disabled unintentionally - Shopify community, April 2025, read 8 September 2026. A developer reporting that app embed blocks switch off when merchants change themes or redesign, which is the failure mode the replacement introduces.
• Meta reporting fewer purchases than Shopify after the Aug 26 checkout upgrade - Shopify community, August to September 2026, read 8 September 2026. The symptom as merchants experience it, the identification of the 26 August change as the cause on the same day by people who work on stores professionally, and the observation that the real risk is pausing a profitable campaign because the measured return fell while actual profit did not.
• Transitioning to the new Checkout Extensibility Thank you and Order status pages and Google Ads conversions not showing in dashboard - Shopify community, 2024 to 2026, read 8 September 2026. Store owners describing flat-lined analytics after the same kind of migration, including one whose developer had no answer for them — the version of this experience that arrives without a diagnosis attached.
• Storefront HTML of seven Shopify stores - read 8 September 2026. Three carried the injected script block, and the named vendors are those identifiable from the script URLs. Of the remaining four, three serve a headless front end with no Liquid layer for the block to appear in, and one returned a bot challenge instead of the page — so they are not evidence of migration in either direction. This is an illustration of what these scripts typically are, not a measure of how many stores are affected, and Shopify publishes no such figure.
• Extend your theme with apps - Shopify merchant help centre, read 8 September 2026 through a fetching tool because the site refuses direct requests. Used only for the description of where app embeds appear in the theme editor.