Saltar al contenido principal

Propagación de señales

Esta página explica qué pasa entre "pulsas Enrich" y "el storefront en vivo muestra las nuevas señales". Es la parte que más a menudo sorprende a la gente, especialmente sobre qué es automático vs manual, qué se empuja dónde y por qué a veces parece que el JSON-LD desaparece.

El loop principal​

SYNC → ENRICH → PROPAGATE → VERIFY
  • Sync trae el catálogo desde la plataforma (BC, Shopify) a Clione.
  • Enrich genera las señales impulsadas por IA — meta title, meta description, JSON-LD, keywords bilingües.
  • Propagate escribe esas señales de vuelta a la plataforma.
  • Verify descarga el HTML del storefront en vivo y confirma que las señales aterrizaron.

Esta página se centra en el tercer paso.

Qué señales se propagan​

Para cada tipo de entidad, Clione tiene un SignalPropagationAdapter que sabe cómo escribir cada señal al campo específico de la plataforma:

SeñalBC ProductsBC CategoriesBC PagesShopify ProductsShopify CollectionsShopify Pages
Meta titleSíSíSíSíSíSí
Meta descriptionSíSíSíSíSíSí
meta_keywordsSí (array)Sí (array)Sí (string!)N/AN/AN/A
search_keywords (interno BC)SíSíSíN/AN/AN/A
URL canónicaSíSolo lecturaSíSíSíSí
JSON-LDSí (Schema Injector)PlaneadoPlaneadoSí (theme app block)PlaneadoPlaneado
OG tagsSíPlaneadoPlaneadoSí (vía metafield)PlaneadoPlaneado

Nota que meta_keywords en BigCommerce es un array para productos + categorías pero un string separado por comas para páginas. Es una rareza de la API de BC y una fuente frecuente de bugs en integraciones custom.

Propagación automática​

Tras un enriquecimiento exitoso, Clione propaga automáticamente las nuevas señales. No necesitas un paso "push" aparte. Esto aplica a:

  • Enrich de entidad única (un clic) — auto-propaga de inmediato al completarse.
  • Enrich bulk async — cada entidad auto-propaga a medida que se completa dentro del job masivo.

La auto-propagación pasa vía autoPropagateEntity() (o autoPropagateProduct() para productos), cableada en todas las rutas de enriquecimiento. Si la auto-propagación falla (5xx transitorio de la plataforma, etc.), el enriquecimiento sigue guardado y puedes re-pushear manualmente desde la pestaña Propagation de la entidad.

Por qué el JSON-LD es distinto​

Meta title, meta description, URL canónica y campos nativos de plataforma se escriben vía la API de catálogo de la plataforma. La plataforma los guarda y los renderiza en cada petición de página del storefront.

El JSON-LD es más enrevesado — ni BC ni Shopify renderizan JSON-LD arbitrario por defecto. Necesita un mecanismo de entrega:

BigCommerce — el Schema Injector​

Clione registra una etiqueta script pequeña vía la Scripts API de BC. En cada página del storefront, el script:

  1. Detecta la entidad actual desde URL + OG tags.
  2. Descarga el JSON-LD enriquecido de api.clione.ai.
  3. Lo inyecta en <head> como <script type="application/ld+json">.

Esto significa que el JSON-LD se renderiza por JS (Googlebot ejecuta JS, pero los crawlers viejos no — mira Stencil sin crawlers JS para la alternativa).

Shopify — el theme app block​

La Theme App Extension de Clione provee un bloque Liquid llamado clione-jsonld. Hace:

  1. Lee el metafield clione.jsonld en el producto / collection / page.
  2. Lo renderiza inline en <head> como <script type="application/ld+json">.

Esto es Liquid server-rendered, así que funciona para cada crawler de inmediato. Pero solo renderiza si el comerciante ha activado el block en su editor de tema.

Si el block no está activado, el metafield existe pero es invisible. Esta es la razón más común de "JSON-LD missing en Shopify" — mira Schema Injector.

Orden de operaciones durante auto-propagate​

  1. El enriquecimiento se completa; los nuevos campos se guardan en la BBDD de Clione.
  2. Se crea un snapshot en el histórico de versiones de enriquecimiento de la entidad (retención de 3 versiones).
  3. La caché se invalida (este fix aterrizó el 2026-04-19 — versiones anteriores tenían bug de UI vieja).
  4. autoPropagateEntity() resuelve las credenciales de la tienda desde la BBDD (o variables de entorno en modo single-tenant legacy).
  5. Para cada señal, el adapter de propagación escribe a la plataforma vía su API. Los errores se capturan por señal para que un fallo parcial no bloquee el resto.
  6. Un PropagationRecord se escribe en la BBDD de Clione capturando qué se empujó, cuándo y la respuesta de la plataforma.
  7. El subsistema de verificación programa un chequeo de descarga-en-vivo de seguimiento (visible en la página Verification minutos después).

Re-push manual​

Desde la pestaña Propagation de cualquier entidad:

  • Pulsa Re-push to storefront para reenviar cada señal a la plataforma.
  • Los toggles por señal te permiten empujar solo la meta description, por ejemplo, dejando el JSON-LD en paz.
  • El panel de historial muestra cada push pasado, con el código de respuesta de la plataforma y cualquier error devuelto.

Úsalo cuando:

  • La auto-propagación falló en silencio y verification marca un Fail.
  • Editaste manualmente un campo en Clione y quieres empujarlo.
  • La CDN del storefront está mostrando una versión vieja y quieres forzar una escritura para invalidar la caché.

Override manual (propagación solo de keywords para no-productos)​

Categorías, colecciones y páginas tienen un endpoint de propagación solo de keywords que escribe solo meta_keywords + search_keywords, dejando title y description intactos. Útil para equipos SEO que gestionan títulos en el admin de la plataforma manualmente y solo quieren empujar las keywords de Clione.

Busca Push keywords only en la pestaña Propagation de la entidad.

Rollback​

Restaurar una versión más vieja desde la pestaña History de la entidad dispara una re-propagación de los campos DE ESA versión. Así que hacer rollback también hace rollback del storefront en vivo, no solo de la vista del dashboard.

Por qué una propagación puede fallar en silencio​

Aun cuando la plataforma devuelve 200 OK, el campo puede ser descartado si:

  • Los metafields de Shopify de tipo single_line_text_field rechazan valores > 255 chars. La descripción enriquecida puede ser de hasta 320 chars; Clione trunca en un límite de frase y marca un Warn en Verification.
  • El custom_url de BC requiere la forma de objeto canónica { url, is_customized }; un string malformado se rechaza.
  • El custom_url de las categorías de BC es solo lectura vía la API pública. Clione no intenta reescribir URLs de categoría.
  • El webhook de la plataforma dispara product.updated de inmediato y nuestro auto-sync va detrás; si el updated_at de tu plataforma es más viejo que el timestamp del último enriquecimiento de Clione, el siguiente sync puede no traer nada de vuelta, y hace falta un re-chequeo de verification.

En todos estos casos, la página Verification es el sitio canónico para detectar la discrepancia. Mira Verification.