Shopify script tags are being switched off: the two dates that matter

Shopify has put an end date on script tags. This one is worth acting on early, for a reason that is easy to miss in the announcement: the first deadline does not break anything visible. It breaks your ability to fix things. By the time the second deadline arrives and stores start losing functionality, the tool you would have used to repair it has been gone for five months.

Why the October date is the one to plan around

Read the two dates again and the sequencing is unusual. Normally a deprecation removes the feature and you notice immediately. Here, write access dies first and the feature keeps working, which means nothing in your monitoring will tell you anything is wrong until March.

Concretely, after October 1 an app cannot install a script tag on a newly installed store. If your app's install flow creates a script tag, every merchant who installs from October onwards gets an app that silently does nothing on their storefront. Your existing merchants are fine, your new ones are broken, and the failure is invisible unless you happen to test a fresh install.

Step 1: find out whether this affects you

Do not assume. Plenty of apps created a script tag years ago in an install hook that nobody has read since. Query it:

1query AuditScriptTags {2  scriptTags(first: 50) {3    nodes {4      id5      src6      displayScope7      createdAt8    }9  }10}

Run it against a store the app is installed on. If it returns nodes, you have work to do. Also grep your own codebase for scriptTagCreate, ScriptTag, and script_tags, because the call is often buried in an app/uninstalled or post-install handler rather than anywhere obvious.

Step 2: pick the replacement

There are two, and the choice is genuinely determined by what your script does rather than being a preference.

The second row is the happier path and it is worth checking honestly whether you qualify. A web pixel runs in a sandbox, is designed for exactly this job, and requires nothing from the merchant. If your script is a tracking beacon, this migration is close to painless.

The first row has a consequence people underestimate: app embeds require the merchant to switch them on. A script tag installed itself silently; an app embed does not. So the migration is not only an engineering task, it is a communication task. Every existing merchant needs to be told to open the theme editor and enable the embed, and some percentage of them will not. Plan the emails now, not in February.

1{% comment %}2  An app embed block with "target": "head" in its schema loads on every3  storefront page, which is what your script tag used to do. The4  difference is that the merchant activates it in the theme editor.5{% endcomment %}6 7<script8  src="{{ 'your-script.js' | asset_url }}"9  data-shop="{{ shop.permanent_domain }}"10  defer11></script>

That is the whole shape of it. The script itself usually needs little change; what changes is how it gets onto the page and who decides. If you have never built one, the theme layer explainer covers where an app embed sits in the request and what it can and cannot reach from there.

The exception worth knowing about

Script tags with a display_scope of order_status are on a separate and earlier timeline. If your audit query returns anything with that scope, treat it as more urgent than the dates in this post and check the order status page deprecation notices directly. Checkout and post-purchase surfaces have been moving to checkout UI extensions for a while, and this is the tail end of that.

The bigger pattern

This is not an isolated cleanup. Script tags were the last widely used way for an app to inject arbitrary JavaScript into a storefront without the merchant knowing, and Shopify has spent years replacing that model with declared, scoped, merchant-visible surfaces: theme app extensions for storefront UI, web pixels for tracking, checkout UI extensions for checkout, Functions for backend logic.

The through-line is that the platform keeps trading implicit power for explicit contracts. You lose the ability to silently run anything anywhere; you gain a storefront where a merchant can see what is on their store and Shopify can reason about performance. The same instinct produced Events replacing webhook topic subscriptions and the Liquid block and partial tags, where composition moved back into files you can read.

Practically, it also means "does this app use script tags?" is now a reasonable question to ask before installing anything. An app built on a theme app extension is on the right side of this deprecation and needs nothing from you in March. Cordon, for instance, loads through an app embed rather than a script tag, which is the pattern to look for when you audit the apps on a store you maintain.

What to do this week

1. Run the scriptTags query on every store you own or maintain. Delete anything orphaned while deleting is still easy.
2. Grep your app for scriptTagCreate and ScriptTag. Check install hooks specifically, since that is where it usually hides.
3. Classify each remaining script: storefront behaviour goes to an app embed, analytics goes to a web pixel.
4. If any have display_scope: order_status, handle those first. They are on an earlier clock.
5. Write the merchant communication plan. App embeds need activating, and that is the part of this migration that does not happen in code.

October 1 is the date to work backwards from. Not because anything breaks that day, but because after it the cheap fix is gone.