Saltar al contenido principal

Verifica las señales en tu storefront

Planes: Growth · Pro · Agency (Starter tiene acceso solo lectura a los resultados de verificaciones automáticas en segundo plano)

Tras Clione enriquecer una entidad y propagar las señales a tu tienda, querrás confirmar que las señales realmente aterrizaron donde deberían. La página Verification es la herramienta dentro del dashboard para eso.

Verification responde preguntas como:

  • ¿La nueva meta description llegó a la página de producto en vivo?
  • ¿El JSON-LD que veo en el dashboard es el mismo que está en el código fuente de la página?
  • ¿Aceptó Shopify el cambio de URL canónica, o lo descartó silenciosamente?

Dónde vive​

Para cada tienda, abre la tienda desde el sidebar y luego pulsa Verification (plan-gated; disponible en Growth y superiores).

La página muestra:

  • Una barra de filtro — elige tipos de entidad (products / categories / collections / pages), una banda de score (Pass / Warn / Fail), y qué tiendas incluir (si eres tenant multi-tienda).
  • Una tabla de ejecuciones de verificación recientes con una fila por entidad.
  • Pulsar una fila abre el modal de detalle: qué señales se comprobaron, cuáles pasaron, cuáles dieron mismatch, y los valores crudos tanto de la BD como del storefront.

También hay un URL Verifier global (sidebar → URL Verifier) para checks puntuales de URL sin un entity ID — cubierto por separado en URL Verifier.

Qué comprueba "verification" realmente​

Para cada entidad, Clione obtiene el HTML en vivo del storefront y lo compara contra los valores enriquecidos guardados en la base de datos:

SeñalQué comprueba
Meta titleEl tag <title> coincide con el meta_title enriquecido.
Meta description<meta name="description"> coincide con la description enriquecida (consciente de truncado en Shopify — consulta Connect Shopify).
Canonical URL<link rel="canonical"> coincide con la canónica que la plataforma debería devolver.
JSON-LDExiste un bloque <script type="application/ld+json"> con el @type esperado (Product, FAQPage, etc.) y las keywords + ID coinciden.
OG tagsog:title, og:description, og:image están presentes y coinciden (solo productos — categorías/pages no obtienen OG en la mayoría de plataformas).
meta_keywords (solo BC)El <meta name="keywords"> existe con la lista esperada (BC mantiene esta señal viva aunque la mayoría de motores la ignoran).

Cada check se califica:

  • Pass — el valor de BD coincide con lo que está en la página.
  • Warn — el campo está presente pero parcialmente mismatch (p. ej. description truncada, o keywords extra añadidas).
  • Fail — el campo falta o es completamente distinto.

La nota global de la fila es la peor de las notas por señal.

Notas por plataforma​

BigCommerce​

  • Verification necesita obtener tu storefront en vivo. Si el storefront está protegido por contraseña (tiendas sandbox), pasa un preview code.
    1. Abre la entidad que falla en Verification.
    2. El modal de detalle muestra un banner: "Storefront unreachable — looks like a password-protected store".
    3. Pega el preview code desde el admin de BC (Settings → Storefront → Sandbox) y pulsa Retry verification.
    4. Clione pasa ?preview_code=... en el fetch y la página devuelve normal.
  • El JSON-LD solo verifica si el Schema Injector está instalado. Sin él, Clione marca JSON-LD como "Not installed" (no Fail) para que sepas que es un problema de configuración, no de datos.
  • Categories y Pages: Clione verifica title + description + meta_keywords + search_keywords. El JSON-LD aún no se renderiza en entidades que no son producto, así que no se comprueba.

Shopify​

  • Verification obtiene https://<your-shop>.myshopify.com/products/<handle> (o el dominio personalizado configurado si lo pusiste en Store → Settings).
  • Si usas un dominio personalizado (shop.example.com), asegúrate de que está puesto en Store → Settings → Storefront URL. De lo contrario verification usa la URL .myshopify.com y puede reportar mismatches si tu tema renderiza distinto en los dos.
  • El JSON-LD solo verifica si el theme app block está activado. De lo contrario el metafield tiene el JSON-LD pero el storefront nunca lo renderiza — Clione marca JSON-LD como "Not rendered" (theme app block off).
  • El truncado de meta description a 255 chars es un límite conocido de la plataforma. Si tu descripción enriquecida es de 320 chars y el storefront muestra 255, verification lo marca como Warn, no Fail, porque el truncado es esperable.

Ejecutar una verificación​

Las verificaciones son automáticas en segundo plano tras cada propagación, pero también puedes lanzarlas bajo demanda:

Una entidad​

  1. Abre la entidad (product / category / collection / page).
  2. Pulsa la pestaña Verification.
  3. Pulsa Run verification now.
  4. El resultado aparece en la pestaña unos segundos después.

Muchas entidades​

  1. Abre la página Verification de la tienda.
  2. Filtra a las filas que quieras re-comprobar (p. ej. por tienda, por banda de score, por tipo de entidad).
  3. Pulsa Verify selected en la barra bulk.
  4. Sigue el progreso vía el chip en la barra superior.

Leer el modal de detalle​

Pulsa cualquier fila para abrir el modal de detalle:

  • Summary panel — nota global + notas por señal.
  • Signal table — para cada señal: el valor en BD, el valor en el storefront, y el diff resaltado carácter por carácter si no coinciden.
  • Live URL — enlace para abrir la página del storefront en una pestaña nueva.
  • Last run — timestamp de la verificación más reciente.
  • Re-push from DB — re-propaga manualmente los valores de BD al storefront. Útil cuando verification marca un Fail causado por una propagación que falló silenciosamente (p. ej. un 5xx transitorio de la API de plataforma).

Cuando verification reporta "Fail" — orden de diagnóstico​

  1. ¿Se ha enriquecido la entidad? Abre la entidad → revisa la pestaña Enrichment. Si está vacía, enriquece primero.
  2. ¿Se ha propagado el enriquecimiento? Abre la pestaña Propagation. La última propagación debería mostrar un estado verde "Pushed". Si está en rojo, pulsa Re-push to storefront.
  3. ¿El storefront es alcanzable? Prueba la URL en vivo en incógnito. Si ves una página de contraseña, pon un preview code (BC) o quita la protección con contraseña (Shopify).
  4. ¿El Schema Injector (BC) / theme app block (Shopify) está instalado? Sin él, el JSON-LD dará Fail aunque la BD y la propagación estén sanas. Consulta Schema Injector.
  5. ¿Tu caché CDN está reteniendo la versión vieja? Espera 5 minutos y vuelve a ejecutar verification. Para Shopify, el TTL de CDN es corto (~60s). Para BC, depende de los headers de caché de tu tema.
  6. ¿La plataforma descartó silenciosamente el campo? Cada plataforma tiene rarezas de writability (Shopify rechaza descriptions > 255 chars en metafields, BC rechaza custom_url mal formada, etc.). La pestaña propagation muestra la respuesta cruda de la plataforma — si devolvió 200 OK pero el campo está vacío, el campo fue rechazado. Vuelve a enriquecer con una description más corta o arregla los datos fuente.

Checks por tipo de entidad​

No todos los tipos de entidad producen todas las señales. La tabla de abajo muestra qué se comprueba por tipo de entidad por plataforma.

Tipo de entidadTitleMeta descCanonicalJSON-LDOGmeta_keywords (BC)
Product (BC)✓✓✓✓✓✓
Product (Shopify)✓✓✓✓✓—
Category (BC)✓✓✓——✓
Collection (Shopify)✓✓✓———
Page (BC)✓✓✓——✓
Page (Shopify)✓✓✓———

El JSON-LD en categorías / collections / pages está en el roadmap pero aún no se genera.

Umbrales por tienda​

Verification califica cada fila de entidad, pero el rollup a nivel tienda aplica umbrales:

  • Badge verde del storefront — al menos el 90% de las entidades verificadas son Pass.
  • Ámbar — 70-89% son Pass.
  • Rojo — por debajo del 70% Pass.

El badge aparece en la tarjeta Store Overview para que veas de un vistazo qué tiendas están sanas. Pasa el ratón por el badge para ver el pass rate exacto y un enlace a las filas que fallaron.

Scheduling​

Las verificaciones en segundo plano corren automáticamente en los siguientes triggers:

  • 30 segundos tras cada ciclo de enriquecimiento + propagación (por entidad).
  • Una vez al día a las 03:00 UTC para cada tienda, como check baseline de drift.
  • Bajo demanda desde el botón Run verification now.

Si quieres polling continuo (p. ej. cada hora), actualmente no es configurable — abre una feature request vía soporte.

Resolución de problemas​

"Storefront unreachable" en una tienda pública — DNS, firewall o bloqueo geo. Prueba la URL en vivo en incógnito. Si carga para ti, comprueba si tu storefront bloquea la IP de nuestro datacenter — contacta a soporte para whitelist si hace falta.

Verification marca Pass pero el storefront sigue mostrando la description vieja — Caché CDN del storefront. Force-refresh (Ctrl/Cmd + Shift + R) o espera a que la caché expire. Verification obtiene con cache-busting, así que lo que Clione ve es la respuesta canónica del origen.

La misma entidad verifica Pass en una URL y Fail en la URL de variante — Algunos temas varían meta tags por variante. Clione verifica solo la URL canónica del producto. Si necesitas verificación a nivel variante, hoy no está soportado.

Categorías de BigCommerce marcadas Fail en URL canónica — Las categorías de BC no siempre emiten un canonical link en la sección head por defecto. El tema Stencil controla esto. Edita templates/pages/category.html y añade {{> components/common/canonical}} al bloque head. Si no puedes editar el tema, esta señal se quedará en Warn (no Fail) — no bloquea el resto.

La URL del storefront de Shopify apunta a sitio incorrecto tras activar Markets — Cuando activas Shopify Markets con dominios específicos de país (p. ej. de.example.com para Alemania), la URL canónica emitida en cada Market puede diferir. Pon el Storefront URL en Store → Settings a la URL del Market principal, y Clione verificará contra esa. Los otros Markets no se verifican hoy.

El estado "Not installed" persiste tras instalar el Schema Injector — El estado se cachea durante 5 minutos. Espera o pulsa Refresh en la tarjeta del Schema Injector. Si persiste pasados 10 minutos, abre la página del storefront y mira el código fuente — busca <!-- clione:jsonld -->. Si el comentario está presente, vuelve a ejecutar verification en una entidad para forzar un re-check.

Verification API​

Para acceso programático:

  • GET /api/v1/verifications?store=:storeId&entityType=:type — lista verificaciones para una tienda.
  • POST /api/v1/verifications/run — lanza un batch de verificación (devuelve un job ID).
  • GET /api/v1/verifications/:id — resultado de una verificación con desglose completo por señal.

Consulta la sección developers para auth.

Exportar​

La tabla de verification tiene un botón Export CSV. Columnas:

  • Entity ID + name
  • Entity type
  • Platform
  • Storefront URL
  • Pass/fail por señal
  • Valor de BD vs valor de storefront (truncado a 200 chars)
  • Nota global
  • Timestamp de la última verificación

Usa esto para auditorías offline o para entregar a un consultor SEO.

Lo que el verifier no comprueba​

Para fijar expectativas:

  • Alt text de imagen — presente en la entidad pero fuera del scope de Verification. Pulse sí lo comprueba.
  • Métricas de page-speed (LCP, FID, CLS) — fuera de scope. Usa Google PageSpeed Insights.
  • Estructura de enlaces internos — fuera de scope.
  • Mismatch de hreflang entre locales — fuera de scope para v1.
  • Presencia de sitemap.xml — fuera de scope.
  • Corrección de robots.txt — parcial: el verifier marca si la propia página está bloqueada por robots pero no audita la política completa de robots.
  • Validez de schema según las reglas de Google — Verification confirma que el bloque JSON-LD existe y coincide con la BD; no pasa el JSON-LD por el validador de Google. Usa el Google Rich Results test para eso.

Estos son gaps que conocemos. Algunos se añadirán (Pulse ya cubre la mayoría), otros se quedan fuera de scope por diseño.

Buenas prácticas​

  • Ejecuta Verification tras cada cambio importante de catálogo (nueva línea de productos, actualización de tema, cambio de locale).
  • Trata un pico súbito de Fails como una regresión — normalmente una actualización de tema cambió cómo se renderizan los meta tags.
  • No ignores los Warns — a menudo degeneran silenciosamente en Fails en el siguiente sync.
  • Re-verifica tras instalar el Schema Injector — la primera ronda de verificaciones corre antes de que el script se propague a la caché de la Scripts API de BC.