On 1 October 2026 Shopify stops letting apps create or update script tags. Nothing on your store breaks that day, which is exactly why this deadline will be ignored. The breakage comes later, on 1 March 2027, and in the meantime the October date sets a trap that is easy to walk into during the busiest eight weeks of your year.
From 1 October 2026, scriptTagCreate and scriptTagUpdate return an error and the REST ScriptTag resource stops accepting writes. Existing script tags keep running, and can still be read and deleted. On 1 March 2027 Shopify stops injecting script tags into storefronts entirely, on every API version, so pinning an older version does not defer it. Replacements are theme app extensions with app embed blocks, or web pixels for anything that only collects analytics.
The two dates, and what each one actually forbids
| Date | What stops | What still works | What a merchant sees |
|---|---|---|---|
| 1 October 2026 | Creating or updating script tags. scriptTagCreate and scriptTagUpdate return a user error; REST POST and PUT are refused | Every existing script tag keeps running. Reading and deleting still work | Nothing, unless an app tries to install or update one |
| 1 March 2027 | Shopify stops injecting script tags into storefronts | Nothing, for script tags. Whatever they powered is gone | Features silently stop working, all at once, on every affected store |
The second date applies across all API versions. There is no pinning your way out of it and no grandfather clause for older apps, which is the detail that separates this from most Shopify deprecations.
What a script tag even is, and why you probably have several
A script tag is a JavaScript file that Shopify injects into your storefront on an app's behalf. It is not part of your theme. It does not appear in your theme files, it survives a theme change, and nothing in your Shopify admin lists which apps are using one. That combination is why most merchants have no idea how many they are running.
Historically, script tags were the default way an app added anything to the front of your store without editing your theme. The categories that leaned on them hardest are the ones most stores have installed: review and ratings widgets, currency converters, popups and email capture, upsell and cross-sell widgets, wishlists, back-in-stock alerts, loyalty programmes, live chat, cookie-consent banners, and third-party analytics or pixel managers.
Two replacements exist, and which one applies determines who has to do the work:
| What the script does | Replacement | Who acts | Merchant effort |
|---|---|---|---|
| Collects analytics or conversion data only | Web pixel | App vendor | None. The migration needs no action from the app user |
| Renders or changes something on the storefront | App embed block in a theme app extension | App vendor builds it; you enable it | Enable the app embed in your theme editor, then verify it renders |
| Custom code an agency added via the API | App embed block, or move the code into the theme | You or your developer | Real work. Nobody else is tracking this one |
App embed blocks work on both Online Store 2.0 and vintage themes, so an old theme is not a reason a vendor cannot migrate. It is sometimes the reason they have not.
The October trap: reinstalling an app after the first
This is the part worth acting on, and it follows directly from what the October date forbids.
Uninstalling an app removes its script tags. Reinstalling it after 1 October 2026 cannot put them back, because creating a script tag is no longer permitted. If the vendor has not shipped an app embed block or web pixel replacement, the feature does not come back — not in a different form, not after a support ticket. It is simply gone until the vendor migrates.
The same logic covers updates. An app that needs to change the URL or contents of its injected script — a new CDN path, a new version, a bug fix — cannot update the tag after 1 October. Its old script keeps loading from wherever it pointed, indefinitely, which is a slower and more confusing failure than an outage.
Now put that against the calendar. October and November are when stores install countdown timers, swap review widgets, add upsell apps and uninstall the ones that slowed the site down. That is the precise window in which "uninstall it and reinstall it" stops being a safe piece of troubleshooting.
Treat 1 October as the start of a no-reinstall period on any app that touches the storefront, and put it in the same document as your Q4 code freeze plan. Before that date, do any app churn you were planning. After it, the standard "uninstall and reinstall" fix carries a risk it did not carry in September.
How to find out what your store is actually running
Nothing in the Shopify admin lists this for you, so you have to go and look. Three methods, in ascending order of effort and certainty. Do the first one today.
- Read your storefront source. Open your homepage and a product page, view source, and collect every
<script src=...>that points at a domain you do not recognise or at an app's CDN. Then search your theme files for each of those URLs. Anything present in the rendered page but absent from the theme is being injected — a script tag is the most likely reason. Twenty minutes, no tooling. - Ask your app vendors, in writing. Three questions, to each app that changes anything on your storefront: does your app currently use script tags on my store; if so, have you shipped an app embed block or web pixel replacement; and by what date will my store be migrated. Put it in one email and keep the replies. Vendors who cannot answer this in September 2026 are telling you something.
- Have a developer list them. The ScriptTag resource stays readable after 1 October, so a developer can query the Admin API and return a definitive list of every script tag on the store and which app owns it. This is the only method that is actually complete, and it is a thirty-minute job.
Run method one now, method two this week, and method three once you know roughly what you are dealing with. The output you want is a single list: app name, what it does on the storefront, whether it uses a script tag, and what the vendor says about migration.
Ranking the risk: what fails loudly and what fails silently
When 1 March 2027 arrives, not all of these failures cost the same, and the expensive ones are not the obvious ones.
| What it powered | How it fails | How long before you notice | Cost while unnoticed |
|---|---|---|---|
| Analytics, conversion tracking, ad pixels | Silently. Pages still render; data stops arriving or goes partial | Weeks, usually via a reporting anomaly | High. Blind optimisation and misattributed ad spend |
| Cookie-consent banner | Silently. The banner disappears and collection continues | Until someone complains or audits | High. This is a compliance exposure, not a UX bug |
| Upsell, cross-sell, bundles | Quietly. The widget just is not there | Days to weeks, via an AOV dip | Medium to high, and hard to attribute |
| Reviews, ratings, trust badges | Visibly. A blank space where social proof was | Fast, if anyone looks at a product page | Medium. Conversion drop on the pages that matter most |
| Popups, email capture | Visibly, to you. Invisibly, to customers | Fast, via list growth falling off | Medium |
| Live chat | Visibly. The bubble is gone | Same day, via support volume | Low to medium |
The pattern is the same one that made August's checkout tracking deadline expensive for the stores it caught: the things that break quietly cost more than the things that break loudly, because nobody is watching them. Sort your audit list by this table, not alphabetically.
Is this the same thing as the August checkout change?
No, and conflating them is common enough to be worth ten seconds. The 26 August 2026 deadline retired checkout.liquid and the additional scripts box, which affected code running inside the checkout. This deprecation covers script tags injected into the storefront by apps, on a different timetable, with different replacements.
A store can comfortably have passed the first and be fully exposed to the second. If you did the checkout tracking work in August, you have the habit but not the coverage — the audit above is a separate exercise.
What to do, in order, before the end of 2026
- Before 1 October: finish any app changes you were planning. Uninstall what you do not use, install what you need for Q4, and get it settled while script tags can still be created.
- Before 1 October: run method one above and get a rough list. You want to know now whether this is a two-app problem or a twelve-app problem.
- October: email your vendors and collect written answers. Chase the ones who do not reply — non-response is the strongest signal you will get.
- During Q4: no uninstall-and-reinstall troubleshooting on storefront apps. Fix forward or wait.
- January 2027: get the definitive developer-run list, and replace anything whose vendor has no migration date with an app that has one.
- February 2027: verify on a staging copy that every replacement actually renders and fires, and that the web pixel versions are recording. Do not verify on 1 March.
The wider point about app-heavy stores
Every platform deadline of the last two years has landed hardest on the same kind of store: one running fourteen apps, most of them installed for a reason nobody remembers, several of them injecting code nobody can see. The individual migration is not difficult. The difficulty is that no single person can say what is currently running on the storefront.
That inventory is the deliverable worth having, and it outlives this deadline. One page: every app, what it does for a customer, what it injects, what it costs, who owns the relationship. It makes each of these deprecations a scheduled task rather than an archaeology project, and it is usually the first thing that shows you which four apps you can remove — which is the cheapest speed improvement most stores have available. If you are picking apps for the first time, the same discipline applies at the point of choosing them: ask what the app injects and how, before you install it.
Frequently asked questions
What happens to Shopify script tags on 1 October 2026?
Apps can no longer create or update them. The scriptTagCreate and scriptTagUpdate mutations return a user error, and the REST ScriptTag resource stops accepting POST and PUT requests. Nothing on your store breaks that day: existing script tags keep running, and they can still be read and deleted. What is lost is the ability to add a new one or change an existing one.
Will my store break on 1 October 2026?
No. Everything already installed keeps working. The breakage date is 1 March 2027, when Shopify stops injecting script tags into storefronts altogether. That applies across all API versions, so pinning an older version does not defer it. The risk in the intervening months is that any app you uninstall, reinstall or that needs to update its injected script cannot restore it.
How do I find out which of my apps use script tags?
Nothing in the Shopify admin lists them, so there are three routes. Open your storefront source on a homepage and product page and collect every script whose URL does not appear anywhere in your theme files. Email each app vendor asking whether their app uses script tags on your store and when they will migrate. Then have a developer query the Admin API's ScriptTag resource, which stays readable after 1 October and is the only complete answer.
What replaces Shopify script tags?
Two things, depending on what the script does. If it only collects analytics or conversion data, the replacement is a web pixel, and that migration requires no action from you as the merchant. If it renders or changes something on the storefront, the replacement is an app embed block shipped in a theme app extension, which you enable in your theme editor. App embed blocks work on both Online Store 2.0 and vintage themes.
Is this the same as the August 2026 Shopify checkout change?
No. The 26 August 2026 deadline retired checkout.liquid and the additional scripts box, which covered code running inside the checkout. This deprecation covers script tags that apps inject into the storefront, on a different timetable and with different replacements. A store that handled the checkout change in August can still be fully exposed to this one.
What should I do before Black Friday 2026?
Finish any app installs, removals or swaps before 1 October, while script tags can still be created. After that date, treat uninstall-and-reinstall as an unsafe troubleshooting step on any app that touches the storefront, because the app may not be able to restore its script. Add that rule to your Q4 code freeze plan alongside the deploy freeze.
The takeaway
The date everyone will diarise is 1 March 2027, because that is when things break. The date that should change your behaviour is 1 October 2026, because from then on an uninstalled app cannot put its script back, and that lands in the eight weeks when stores churn apps hardest. Spend twenty minutes reading your storefront source this week, send one email to your app vendors, and do your app changes before the first of the month. The March work is then a scheduled task rather than a discovery exercise you run under pressure.