Назад до блогу

Shopify блокує ScriptTag з 1 жовтня: як перевірити й перенести скрипти магазину

·14 хв читання·Rendframe·Shopify, Розробка ecommerce, Міграція застосунків, Аналітика

1 жовтня 2026 року Shopify заблокує створення й оновлення storefront ScriptTag. Уже встановлені теги ще працюватимуть п’ять місяців, але 1 березня 2027 року платформа взагалі припинить додавати їх на сторінки магазину.

Схема міграції ScriptTag у Shopify: віджети переходять у app embed, аналітика — у вебпіксель до двох дат вимкнення
Знайдіть кожну функцію, оберіть підтримуваний механізм, доведіть роботу заміни й лише тоді видаліть старий тег.

Найнебезпечніша дата — перша. Після 1 жовтня старий чат, бейдж або трекер може виглядати справним, хоча нова інсталяція, зміна URL чи перевстановлення вже не спрацює. Власнику магазину час з’ясувати, які функції вітрини залежать від застосунків; розробнику — випустити заміну та контролювати її активацію в кожній опублікованій темі.

Коротка відповідь: дві дати й контрольована міграція

ДатаЗміна ShopifyРизик для бізнесу
1 жовтня 2026scriptTagCreate і scriptTagUpdate повертають помилку дозволу в усіх версіях API; REST POST і PUT теж не працюютьНова інсталяція, нова адреса скрипту або відновлення конфігурації не можуть спиратися на старий механізм
1 березня 2027Shopify більше не додає на storefront жоден наявний ScriptTagЗникає віджет, персоналізація або збір подій, що залежать від тега

Читання й видалення залишаться доступними, тож застосунок зможе перевірити та прибрати власні записи. Стара версія Admin API не відкладе зміну. Від 1 жовтня Shopify також може показувати попередження під час установлення застосунку, якщо той використовує ScriptTag, але не містить theme app extension або вебпікселя.

Не плутайте ScriptTag із Shopify Scripts. ScriptTag — ресурс Admin API для завантаження віддаленого JavaScript на вітрині чи старій сторінці статусу замовлення. Shopify Scripts був окремим Plus-інструментом на Ruby для знижок, доставки й платежів; він припинив виконання 30 червня 2026 року. Поле Additional scripts і checkout.liquid також мали окремі строки переходу на Checkout Extensibility.

Спершу визначте роботу коду, а не шукайте слово “script”

Березневе вимкнення стосується JavaScript, який ScriptTag додає на сторінки online store. Воно не видаляє звичайний код теми, підтримуване розширення теми, вебпіксель, Shopify Functions або серверні webhooks. Але один магазин може одночасно мати всі ці способи, тому назва файла ще не доводить його походження.

Опишіть кожну залежність через її видиму функцію:

  • інтерфейс: чат, popup, бейдж, відгуки, таблиця розмірів або блок рекомендацій;
  • поведінка без фіксованого місця: персоналізація, accessibility-віджет, валюта чи A/B-тест;
  • вимірювання: перегляд сторінки й товару, додавання в кошик, checkout і покупка;
  • зміни сторінки оформлення або статусу замовлення;
  • серверна логіка: знижки, antifraud, fulfilment, синхронізація каталогу або webhooks.

Так ви не перенесете код у неправильний механізм. Аналітичний тег не треба відтворювати як віджет, що читає DOM. Знижка не належить app embed. А візуальний компонент не запрацює у вебпікселі: пісочниця пікселя не є повноцінним доступом до сторінки.

Зведіть докази продавця й розробника в один реєстр

У Shopify немає одного екрана з усіма залежностями. Створіть таблицю: застосунок або постачальник, домен скрипту, бізнес-функція, сторінки, відповідальний, новий механізм, стан у published theme і результат тесту. Дані зберіть із чотирьох джерел.

  1. Застосунки та договори. Запитайте кожного постачальника, чи використовує поточна версія ScriptTag і чи вже має app embed, app block або web pixel. Потрібні дата релізу та сценарій тесту, а не фраза “сумісно з Shopify”.
  2. Опублікована вітрина. Запишіть Network-запити й вихідний код на головній, у категорії, картці, кошику та кабінеті. Зіставте невідомі JS-домени з постачальниками. Повторіть без авторизації та з різними рішеннями щодо cookies.
  3. Тема й Customer events. Перевірте Theme settings → App embeds, app blocks у потрібних шаблонах, ручні зміни коду й Settings → Customer events. Одна аналітична система не повинна непомітно працювати з кількох місць.
  4. API застосунку. Команда, що підтримує інтеграцію, має отримати власні ScriptTags, зберегти id, src, displayScope і налаштування кешу та вказати заміну для кожного запису. Перед видаленням збережіть датований експорт.

Статус “installed” не означає, що компонент працює. Після інсталяції app embed за замовчуванням вимкнений і активується окремо в кожній темі. Публікація сезонної або оновленої теми здатна знову вимкнути вже перевірену заміну.

Оберіть правильну поверхню Shopify

Стара функціяОсновна замінаКритичне обмеження
Плаваючий віджет або код на більшості сторінокTheme app extension з app embed blockПродавець має зберегти активацію; стан прив’язаний до опублікованої теми
Відгуки, бейдж або UI всередині секціїApp blockПотрібні JSON-шаблон і секція з підтримкою app blocks
Аналітика, реклама, поведінкові подіїWeb pixel app extension; custom pixel лише за потребиПісочниця, Shopify customer events і сигнали згоди
Інтерфейс статусу замовленняCustomer account UI extensionМіграція storefront ScriptTag не повертає доступ до checkout
Знижки, доставка, платежіShopify Functions або підтримувана серверна логікаЦіну не можна визначати авторитетно в браузері

App embed працює і у vintage themes, і в Online Store 2.0. Його можна додати в head або body та обмежити певними шаблонами. App block доречніший, коли продавець має розташувати видимий компонент у секції сторінки. Після інсталяції дайте deep link, який відкриває редактор поточної теми з підготовленою активацією, і чітко попросіть переглянути та зберегти зміни.

Окремий випадок — custom apps, створені безпосередньо в Shopify Admin. За документацією Shopify вони не підтримують app extensions. Для такого ScriptTag може знадобитися повноцінно розповсюджуваний застосунок або, якщо іншого шляху немає, контрольована зміна теми. Код у темі може лишитися після деінсталяції та завадити оновленню, тому це виняток із власником і планом видалення.

Не замініть майбутній збій подвійним виконанням

Безпечна послідовність Shopify: створити theme app extension, відкрити продавцю deep link, підтвердити active-стан у published theme і лише після цього видалити ScriptTag. Якщо видалити раніше — виникне пауза. Якщо надовго залишити обидва варіанти — віджет з’явиться двічі, обробники подій продублюються, а конверсії можуть подвоїтися.

Розробник може використати app.extensions() у Shopify Admin і відрізнити статус active від available. Для фонової перевірки опублікованої теми можна прочитати config/settings_data.json із дозволом read_themes. Перевірку слід повторювати після кожної публікації теми.

Зберігайте стан міграції для кожного магазину: legacy_only, replacement_available, replacement_active, dual_run, legacy_removed, verified. Обмежте dual run у часі й явно налаштуйте дедуплікацію подій. Після 1 жовтня старий ScriptTag уже не є надійним rollback-механізмом.

Перебудуйте аналітику навколо подій, згоди й звірки

Web pixels отримують customer events через контрольований API Shopify. App pixel працює в strict sandbox, custom pixel — у lax sandbox. Старий код, який читає або змінює DOM верхньої сторінки, може не запрацювати; навіть URL усередині sandbox може відрізнятися від адреси вітрини. Для кожного поля знайдіть документовану стандартну чи власну подію.

Web pixel app extensions враховують сигнали Customer Privacy API. У регіонах, де потрібна згода, callbacks запускаються після неї, а зареєстровані раніше події відтворюються. Це корисний механізм, але не автоматична юридична чи аналітична коректність. Перевірте синхронізацію стороннього cookie-банера з Shopify та узгодьте модель даних із фахівцем з privacy.

  • Одна дія має породжувати одну потрібну подію: page view, product view, add to cart, checkout start і purchase.
  • Звірте event ID, order ID, валюту, суму, знижку, податок і доставку.
  • Протестуйте згоду, відмову, частковий вибір і зміну рішення.
  • Порівняйте конверсії рекламної платформи із замовленнями Shopify за узгоджене вікно.

Мета — не ідентичні цифри в усіх системах, а пояснювана різниця, відсутність дубльованих маршрутів і сигнал, коли відхилення виходить за погоджений поріг.

Релізні умови для кожної залежності

ПеревіркаУмова проходження
ПовнотаКожен тег має власника, функцію та рішення: заміна або видалення
АктиваціяЗаміна active саме в published theme, а не лише встановлена чи активна в чернетці
ШляхиГоловна, колекція, товар, кошик, пошук, кабінет і локалі працюють на mobile і desktop
ДубліОдин екземпляр віджета й одна потрібна аналітична подія
PrivacyЗгода, відмова, частковий і змінений вибір відповідають політиці
ШвидкодіяNetwork, LCP, INP і JavaScript cost не виходять за релізний бюджет
Нова темаПублікація теми запускає перевірку активації та інструкцію продавцю
ВидаленняLegacy-запит зник, заміна спостережувана, rollback задокументований

Для UI перевірте клавіатуру, focus, reduced motion, різну ширину й переклади. Shopify радить мінімізувати стартовий JavaScript і завантажувати некритичний код після взаємодії. Міграція — слушний момент прибрати покинуті сервіси й зайвий глобальний код, а не відтворювати старе навантаження.

План на сім днів до 1 жовтня

  1. День 1: перелічіть застосунки, ScriptTag-записи, запити вітрини, Customer events і зміни теми.
  2. День 2: класифікуйте функції та оберіть app embed, app block, web pixel, UI extension, Function або видалення.
  3. День 3: отримайте строки від постачальників; призначте власників custom та покинутих інтеграцій.
  4. Дні 4–5: випустіть extension або pixel, deep link, перевірку status, consent mapping і telemetry.
  5. День 6: увімкніть заміну на контрольному магазині, усуньте дублювання та видаліть відповідний тег після доказу.
  6. День 7: перевірте шляхи, конверсії, privacy й performance; увімкніть alerts на legacy-виклики та inactive embeds.

Якщо постачальник не дає відповіді до 1 жовтня, зафіксуйте ризик і fallback. Старий тег може працювати до березня, але не додавайте нову бізнес-залежність до механізму, який уже неможливо нормально перевстановити чи виправити.

Поширені запитання

Чи зламаються всі Shopify-застосунки 1 жовтня 2026 року?

Ні. Уже встановлені storefront ScriptTags можуть працювати до 1 березня 2027 року. 1 жовтня припиняються створення й оновлення. Застосунки на підтримуваних extensions, pixels або server-side механізмах ця зміна не вимикає.

Чи допоможе стара версія Shopify API?

Ні. Shopify прямо вказує, що заборона create та update діє для всіх версій API.

Чи треба переносити аналітичний ScriptTag в app embed?

Зазвичай Shopify спрямовує аналітику, рекламу та поведінкові події у web pixel. App embed призначений для коду й UI на вітрині. Спершу перевірте потрібні події та обмеження sandbox.

Коли видаляти старий ScriptTag?

Після того, як заміна active в опублікованій темі та пройшла критичні сценарії. Одночасна робота може подвоїти UI чи аналітику; передчасне видалення створить збій.

Що станеться після публікації нової теми?

App embed активується окремо для кожної теми. Перевірте нову published theme і, якщо потрібно, проведіть продавця через збереження в theme editor.

Джерела й дата перевірки

Перевірено 23 вересня 2026 року за офіційними матеріалами Shopify: огляд припинення ScriptTag, графік для storefront, міграція на theme app extensions, активація та конфігурація, web pixels і consent, інструкція з перенесення пікселів, окремий графік Shopify Scripts та вимоги до швидкодії застосунків.

Rendframe може інвентаризувати залежності вітрини, створити потрібне extension або event pipeline, провести заміну з постачальниками й протестувати аналітику, privacy та швидкодію. Почніть з аудиту сторонніх скриптів, додайте перевірку Core Web Vitals або надішліть домен Shopify-магазину та знеособлений список застосунків.