Shopify elimina los script tags: fechas, qué se rompe y cómo migrar
Desde el 1 de octubre de 2026 las apps ya no pueden crear ni actualizar script tags, y el 1 de marzo de 2027 Shopify dejará de cargarlos en las tiendas. Te explico qué hacer si tienes una app, cómo revisar tus script tags y con qué reemplazarlos.
- Javi Mata
- 9 min de lectura
Tabla de contenido
- Las fechas
- Lo que ya se rompió: la página de estado del pedido
- Primero, revisa qué script tags tienes
- Con qué reemplazarlos
- App embed block: el reemplazo directo
- Web pixel: si solo mides
- Cómo migrar sin dejar un hueco
- El caso que nadie ve venir: apps personalizadas creadas en el administrador
- Mi recomendación
- Conclusión
- Fuentes
Durante años, la forma más rápida de que una app de Shopify cargara JavaScript en una tienda fue un script tag: la app registraba la URL de un archivo .js con la API y Shopify lo inyectaba en las páginas. Eso se acaba. Shopify está quitando los script tags de las tiendas, con fechas concretas, y lo incluyó entre las novedades para desarrolladores de la Fall ‘26 Edition: “Apps can no longer create or update script tags and must migrate to theme app extensions or web pixels”.
Este artículo resume la guía oficial de shopify.dev consultada el 30 de octubre de 2026. Si tienes una app (pública o personalizada para un cliente) que usa script tags, esto te afecta.
Las fechas
| Fecha | Qué pasa |
|---|---|
| 1 de octubre de 2026 | Ya no puedes crear ni actualizar script tags. Los que existen siguen funcionando. |
| 1 de marzo de 2027 | Shopify deja de inyectar script tags en las tiendas. |
Desde el 1 de octubre, las mutaciones scriptTagCreate y scriptTagUpdate devuelven un error de permisos en todas las versiones de la API, y lo mismo pasa con las peticiones POST y PUT al recurso ScriptTag de la REST Admin API. Las operaciones de lectura y borrado siguen funcionando, así que todavía puedes revisar y limpiar.
El 1 de marzo de 2027 tu script dejará de cargarse y cualquier función que dependa de él dejará de funcionar en esa tienda. Los registros que queden no tendrán efecto, así que después de esa fecha no hace falta borrarlos.
Lo que ya se rompió: la página de estado del pedido
La página de estado del pedido (Order status) va por delante, con un calendario propio. Solo aplica a script tags con display_scope igual a order_status o all:
| Fecha | Qué pasó |
|---|---|
| 1 de febrero de 2025 | Las apps ya no pueden crear script tags con ese display_scope. |
| 28 de agosto de 2025 | Dejan de ejecutarse en la página de estado del pedido en tiendas Plus. |
| 26 de agosto de 2026 | Dejan de ejecutarse en la página de estado del pedido en el resto de tiendas. |
Es decir: si tu app personalizaba la página de estado del pedido con un script tag, eso ya no funciona en ninguna tienda. Ahí los reemplazos son las extensiones de UI de cuentas de cliente (para mostrar contenido) o un web pixel (para medir). Ojo: un script tag con display_scope all sigue ejecutándose en la tienda hasta el 1 de marzo de 2027.
Primero, revisa qué script tags tienes
La consulta scriptTags de la Admin GraphQL API devuelve los script tags de tu app. Este es el ejemplo de la referencia, con paginación y los campos útiles para revisar:
query GetScriptTags($first: Int!, $cursor: String) {
scriptTags(first: $first, after: $cursor) {
nodes {
id
cache
createdAt
displayScope
src
updatedAt
}
pageInfo {
startCursor
endCursor
}
}
}
Si mantienes muchas apps, por ejemplo una app personalizada para cada cliente (el caso típico de una agencia), la guía indica revisarlas una por una: ejecuta la consulta con un token que la app ya tenga para una tienda donde esté instalada y repite en cada tienda. Lo que encuentres lo borras con scriptTagDelete, pero no antes de tener el reemplazo funcionando (más abajo explico por qué).
Con qué reemplazarlos
La guía lo resume en dos casos:
| Si tu app usa un script tag para… | Usa |
|---|---|
| Cargar JavaScript en las páginas de la tienda | Un app embed block |
| Medir analítica, conversiones o comportamiento del cliente | Un web pixel |
App embed block: el reemplazo directo
Un app embed block es parte de una extensión de tema de app (theme app extension), que construyes y despliegas con tu app. Sus ventajas, según la documentación:
- Funciona en temas vintage y en temas Online Store 2.0, porque no depende de secciones ni de plantillas JSON.
- Aparece en el editor de temas, en Theme Settings > App embeds, donde el comerciante ve que tu app está activa y puede desactivarla.
- Shopify lo inyecta antes del cierre de
</head>o de</body>, según eltargetque pongas en su esquema:head,bodyocompliance_head(este último solo cuando hace falta, por ejemplo para banners de consentimiento de cookies). - Puedes cargar el script solo en algunas plantillas con
enabled_onodisabled_on, algo que el script tag no permitía.
Si tu script inyecta contenido en la página, un app embed block también te sirve, porque tu JavaScript hace el mismo trabajo que hoy.
Este es el ejemplo mínimo de la documentación (un archivo Liquid en la carpeta blocks de la extensión):
<div style={{position: 'fixed', bottom: '0', right: '0'}}>
{{ "kitten.jpg" | asset_url | img_tag }}
</div>
{% schema %}
{
"name": "App Embed",
"target": "body",
"settings": []
}
{% endschema %}
En el esquema también puedes usar javascript y stylesheet para cargar un archivo de la carpeta assets de la extensión; si varios bloques usan el mismo archivo, se incluye una sola vez.
Una limitación: los app embed blocks solo tienen acceso al ámbito global de Liquid de la página y no pueden usar fuentes dinámicas. Si necesitas contenido que el comerciante coloque dentro de una sección, eso es un app block (target content), pero solo funciona en temas con plantillas JSON.
Web pixel: si solo mides
Si tu script solo recolecta datos, la guía dice que un web pixel es el reemplazo más sencillo: no hay que activarlo en el editor de temas. Tu app lo crea con la mutación webPixelCreate, y el comerciante aprueba los permisos write_pixels y read_customer_events al instalar o actualizar la app.
Los web pixels corren en un sandbox y respetan las señales de consentimiento del cliente. Esto implica que lo que dependa de leer o modificar el DOM no funcionará igual o no funcionará; para eso está la API de web pixels, que pasa los datos de los eventos al sandbox.
Cómo migrar sin dejar un hueco
El detalle que más importa: un app embed block está desactivado hasta que el comerciante lo activa, y tu app no puede activarlo por él. Si borras el script tag antes, la función desaparece hasta que alguien active el bloque. El orden que propone la guía:
-
Construye la extensión de tema con tu app embed block.
-
Manda al comerciante al editor de temas con el bloque ya activado mediante un deep link:
https://<myshopifyDomain>/admin/themes/current/editor?context=apps&template=${template}&activateAppId={api_key}/{handle}Donde
{api_key}es elclient_idde tu app y{handle}es el nombre del archivo Liquid del bloque (por ejemplo,app-embedparablocks/app-embed.liquid). El comerciante ve la vista previa y guarda. -
Confirma que el bloque está activo en el tema publicado. Desde tu app en el administrador puedes usar
shopify.app.extensions()de la App API: unstatusigual aactiveindica que está activado, yavailable, que tu app lo incluye pero el comerciante no lo ha activado. Desde tu backend, puedes leerconfig/settings_data.jsondel tema publicado (requiere el permisoread_themes). -
Borra el script tag con
scriptTagDelete.
¿Por qué no dejar los dos? Porque mientras convivan, tu script se cargará dos veces, y eso puede duplicar eventos de analítica o mostrar dos veces la interfaz de tu app.
Un detalle más: el app embed block solo está activo en el tema donde se activó. Si la tienda publica otro tema, hay que volver a comprobarlo.
El caso que nadie ve venir: apps personalizadas creadas en el administrador
Las apps personalizadas creadas directamente en el administrador de Shopify (no con Shopify CLI ni con el Dev Dashboard) no pueden usar extensiones de app, así que tampoco extensiones de tema ni web pixels. No tienen un reemplazo basado en extensiones. La guía distingue tres situaciones:
- Si tú la mantienes: mueve el script al tema, con un bloque de Liquid personalizado si es posible, o desde el editor de código si hace falta. La documentación advierte que un script en el código del tema se queda ahí aunque la app desaparezca, y que editar el código saca al tema de su ruta de actualizaciones automáticas, así que solo conviene cuando la app no puede usar extensiones.
- Si la mantiene una agencia u otro desarrollador: tienen que mover el script al tema o construir un reemplazo.
- Si un servicio externo te pidió crear la app y pegar un token de acceso en su panel: ese servicio tiene que publicar una app real que use una extensión de tema o un web pixel.
Si eres comerciante y tienes una app de este tipo instalada por un proveedor, mi recomendación es preguntarle ya qué plan tiene antes del 1 de marzo de 2027.
Mi recomendación
- Haz el inventario esta semana. Ejecuta
scriptTagsen cada app y cada tienda, y anotasrcydisplayScope. - Separa lo que pinta de lo que mide. Lo que solo mide va a un web pixel; lo demás, a un app embed block.
- Prepara el deep link y la comprobación de activación antes de borrar nada.
- Revisa las apps creadas en el administrador. Son las que no tienen reemplazo directo y las que más fácil se olvidan.
- No esperes a marzo. Desde el 1 de octubre de 2026 una instalación nueva ya no puede crear el script tag, así que cualquier tienda que instale hoy tu app sin el reemplazo listo se queda sin esa función.
Conclusión
Los script tags fueron cómodos, pero cargaban JavaScript en toda la tienda sin que el comerciante lo viera. Los app embed blocks y los web pixels hacen lo mismo, pero visibles, controlables y mejor integrados con el tema y el consentimiento. Tienes hasta el 1 de marzo de 2027, pero el cambio ya está en marcha: desde octubre no se pueden crear script tags nuevos.
Fuentes
Etiquetas:
Compartir: