URL Verifier

Planes: Growth · Pro · Agency (rollout — actualmente limitado a superadmins y tenants invitados)

El URL Verifier comprueba las señales enriquecidas de Clione contra el HTML en vivo de cualquier URL. Úsalo cuando:

• Quieres verificar una página específica sin abrir la entidad en Clione.
• Estás haciendo QA de una campaña recién lanzada y necesitas comprobar puntualmente un puñado de URLs.
• Estás investigando una discrepancia reportada por un cliente o por una herramienta de auditoría SEO.
• Una URL está fallando en la vista Verification por entidad y quieres saltarte el lookup por entidad y comprobar la página cruda directamente.

Ábrelo desde el sidebar → URL Verifier. (Actualmente disponible para superadmins y miembros del equipo durante el rollout — próximamente disponibilidad más amplia por plan.)

---

Qué puedes comprobar

Modo	Input	Output
Por tipo de entidad + tienda	Elige tipos de entidad (products / categories / collections / pages) + las tiendas a incluir. El verifier recorre el catálogo y ejecuta contra cada entidad matching.	Score agregado sobre el alcance elegido + una tabla ordenable.
URLs manuales	Pega una lista de URLs, una por línea.	Nota por URL + desglose a nivel señal.

La página tiene pestañas para ambos modos. Puedes ejecutarlos secuencialmente sin perder resultados previos.

---

Qué se comprueba en cada URL

Las mismas señales que la vista Verification por entidad:

• Meta title
• Meta description
• Canonical URL
• Presencia de JSON-LD + @type + match de contenido
• OG tags (og:title, og:description, og:image)
• Solo BC: meta_keywords, search_keywords

El verifier también detecta la plataforma (BC vs Shopify vs Other) desde los markers de la página, así que tiendas cross-platform reciben las reglas correctas por señal aplicadas.

---

Notas por plataforma

BigCommerce

• Mismo soporte de preview code que el verifier por entidad — pégalo en la URL si tu tienda está protegida por contraseña.
• El verifier obtiene la URL del storefront de cada entidad. La URL del storefront se resuelve desde el campo custom_url de la plataforma, con fallback al slug del nombre de la entidad si custom_url está vacío.

Shopify

• El verifier obtiene https://<your-shop>.myshopify.com/products/<handle> por defecto.
• Si has configurado un dominio personalizado en Store → Settings → Storefront URL, el verifier usa ese en su lugar. Esto importa porque algunos temas renderizan meta tags distintos en los dos dominios, y quieres verificar el canónico.

Cross-platform / URLs externas

Puedes pegar cualquier URL — incluso URLs de competidores. El verifier sigue ejecutando los mismos checks de señal, pero obviamente el diff BD-vs-storefront no aplica (Clione no tiene un registro de BD para el producto de otro). El verifier sigue calificando presencia + completitud de la señal, así que esto es útil como herramienta rápida "¿cómo está el schema de mi competidor?".

---

Leer la tabla de resultados

Cada fila muestra:

• URL — la página comprobada.
• Score — A / B / C / D / F basado en completitud de señal + exactitud del match.
• Platform — plataforma detectada.
• Mini-badges por señal — vista rápida de qué señales pasaron o fallaron.

Pulsa la fila para abrir el modal de detalle, igual que la vista Verification por entidad.

---

Filtros

• Entity types — products, categories, collections, pages.
• Score — mostrar solo A, solo Fail, etc.
• Stores — qué tiendas incluir (tenants multi-tienda).

Los filtros aplican a los resultados de modo catálogo. Los resultados de URL manual tienen un filtro más simple (solo banda de score).

---

Cómo el verifier obtiene una URL

El fetcher usa un GET headless con un user-agent string estable Clione-URLVerifier/1.0 (+https://clione.ai). No ejecuta JavaScript por defecto — lo que ves es cómo se ve el HTML server-rendered a un crawler típico. Si tu storefront solo renderiza contenido crítico tras JS, el verifier lo marcará como ausente, que es exactamente lo que un crawler LLM también vería.

Para tiendas BigCommerce Stencil (donde el script Schema Injector de Clione corre en cliente), el verifier sigue recorriendo el texto de la página buscando el marcador de comentario JSON-LD que Clione inyecta pre-script. Así el verifier sabe que el script está presente incluso si no se ha ejecutado.

Para tiendas Shopify, el verifier busca el comentario HTML <!-- clione:jsonld --> que la Theme App Extension emite antes del tag <script> JSON-LD. Si el comentario está presente pero el script está vacío, la extension está activada pero el metafield falta — normalmente un problema de propagación.

Timeouts y retries

• Timeout por URL: 10 segundos.
• Reintentos: 1 reintento con backoff exponencial (1 seg, luego 3 seg) en 5xx o errores de red.
• Errores 4xx se devuelven tal cual — sin reintento. Un 404 significa que la URL no existe en el storefront.

Rate limits

• 100 URLs por minuto en modo manual.
• 1000 URLs por recorrido de catálogo (cap es por tienda, por día) para proteger tanto tu storefront como la infraestructura del verifier.

Si necesitas verificar más, ejecuta varios batches más pequeños a lo largo del día o contacta a soporte para subir el cap.

Exportar

La tabla de resultados tiene un botón Export CSV. El CSV incluye:

• URL
• Score
• Plataforma
• Pass/fail por señal (una columna por señal)
• HTTP status
• Timestamp de fetched-at
• Mensaje de error (si lo hay)

Usa esto para audit trails o para alimentar tu propio dashboard.

Resolución de problemas

Todas las URLs fallan con "Storefront unreachable" — DNS o firewall. Prueba una de las URLs en incógnito; si carga, escríbenos con la URL para que diagnostiquemos. Si tu storefront está detrás de Cloudflare con el WAF puesto en challenge a user agents desconocidos, allowlistea el user-agent Clione-URLVerifier/1.0.

Una URL falla con "Storefront unreachable" pero carga en el navegador — A menudo una regla de bot-protection de Cloudflare. Abre Cloudflare → Security → Bot Fight Mode → permite nuestro user-agent. O pasa un preview code si es BC sandbox.

JSON-LD reportado como ausente en una página que lo tiene — Algunos temas renderizan JSON-LD tras el evento DOMContentLoaded vía JS. El verifier obtiene el HTML crudo, así que solo ve JSON-LD server-rendered. Para BC, esto es por diseño (el Schema Injector corre JS). Para Shopify, el JSON-LD se renderiza server-side por el theme app block, así que si falta, el bloque no está activado — consulta Schema Injector.

El verifier reporta score F pero la página en vivo se ve bien para mí — La causa más habitual es un meta robots tag noindex o una URL canónica ausente. Pulsa la fila → modal de detalle → mira la lista Failed signals. Cada fallo enlaza de vuelta a qué señal y el HTML real que el verifier vio.

El storefront BigCommerce devuelve 200 OK pero el verifier dice 404 — BC Stencil a veces devuelve 200 con un soft-404 (el template "page not found"). El verifier trata un 200 sin Product schema o sin Article schema como un soft-404 probable y lo marca. Usa el admin de BC para confirmar que la entidad está publicada y visible.

La página de contraseña de Shopify interfiere — Si tu shop está en modo desarrollo con contraseña, la página de contraseña redirige cada URL. Añade la contraseña como parámetro de query string en el input del URL Verifier: https://shop.myshopify.com/products/foo?password=YOUR_PASSWORD.

Comparación vs Verification por entidad

	Verification (por entidad)	URL Verifier
Input	ID de entidad de la BD de Clione	Cualquier URL
Sabe qué debería ser	Sí (registro de BD)	No (trata la URL como caja negra)
Cross-platform	Una sola plataforma por entidad	Cualquier plataforma
URLs de competidores	No	Sí
Tendencia en el tiempo	Sí (historial por entidad)	No (cada scan es puntual)
Dónde encontrarlo	Pestaña Verification por entidad + página Verification	Sidebar → URL Verifier
Auto-ejecución	Sí (tras cada propagación)	No (manual)

Usa la Verification por entidad para tu propio catálogo. Usa el URL Verifier para checks ad-hoc (tus propias URLs aún no en Clione, URLs de competidores, URLs de partners).

Compartir resultados

El URL Verifier no tiene una función nativa de compartir hoy — los resultados de cada sesión son locales a tu dashboard. Workaround:

• Exporta el CSV y comparte el archivo.
• Añade la URL a un Pulse scan (vía la extensión de Chrome) — los Pulse scans tienen Site URLs públicas que puedes compartir. Caveat: Pulse usa pesos de scoring distintos al URL Verifier.

Los resultados compartibles del URL Verifier están en el roadmap.

Casos de uso que merece la pena conocer

• Spot-check de competidor — pega 5 URLs de producto de tu top competidor. La nota te dice cómo de bien posicionados están para crawlers de IA. Si están en A+ en todo, trátalos como benchmark; si están fallando, tienes una oportunidad de superarlos.
• QA pre-launch — antes de un push de landing page de Black Friday, pega las URLs de las nuevas collection pages. Pilla meta descriptions ausentes o canonical tags rotos antes de que llegue tráfico.
• Regresión post-deploy — tras una actualización de tema, pega 10 URLs de tu catálogo. Confirma que nada regresó.
• Handoff a consultor SEO — exporta el CSV y entrégaselo al consultor como baseline de auditoría.
• Resultado de verification en disputa — cuando la verification por entidad marca un Fail y juras que la página está correcta, mete la URL en el URL Verifier. Hace los mismos checks pero no se apoya en el registro de BD de Clione, así que puedes confirmar si el problema es real.

Caveats de storefront headless

Si tu storefront es headless (Hydrogen, Catalyst, Next.js SSR), el verifier escanea la respuesta HTML renderizada. Caveats:

• CSR-only headless — páginas que renderizan meta + JSON-LD solo tras ejecución de JS puntuarán bajo. Pulse obtiene solo HTML.
• Edge runtime — páginas servidas desde edge functions (Cloudflare Workers, Vercel Edge) pueden devolver markup distinto para la IP del datacenter del verifier que para tráfico normal. Si lo sospechas, confirma haciendo curl server-side a tu URL y comparando.
• Authentication walls — si tu storefront requiere login (p. ej. B2B con gate de wholesale), el verifier no puede pasarlo. Usa una ruta pública temporal o pasa una cookie de sesión vía el campo Advanced → Request headers en el URL Verifier.

Formatos de input para batch

La pestaña Manual URLs acepta:

• Una URL por línea.
• Valores separados por coma en una sola línea.
• Separados por tab.
• Una URL de sitemap.xml — pega la URL del sitemap en su propia línea y el verifier recorre el sitemap, extrayendo URLs para verificar (capped a los rate limits de arriba).

Si tienes un CSV de una herramienta como Screaming Frog, copia la columna URL y pega — el verifier ignora whitespace al principio/final y cualquier línea de cabecera.

Comparar dos runs

Tras ejecutar dos scans (p. ej. antes y después de una actualización de tema), selecciona ambos en la tabla de resultados y pulsa Compare. La vista compare muestra un diff side-by-side por señal por URL con verde para mejoras y rojo para regresiones.

La vista compare es solo lectura y no exportable hoy — copia/pega o haz screenshot si necesitas un registro.

Referencia de pesos por señal

Por transparencia, los pesos por señal en la calificación del URL Verifier:

Señal	Peso	Notas
Title presente + 30-65 chars	15	El title es la superficie más clicable — el peso más alto.
Meta description presente + 100-180 chars	15	Segunda más clicable.
URL canónica presente + coincide con la esperada	10	Evita penalizaciones por contenido duplicado.
JSON-LD presente	20	El mayor factor único de AI-readiness.
@type del JSON-LD coincide con el tipo de entidad	10	Una página con @type=WebPage en lugar de @type=Product puntúa peor que sin JSON-LD.
OG og:title, og:description, og:image	10	Previews de LinkedIn / WhatsApp / iMessage.
og:url coincide con canonical	5	Detecta bugs de cross-canonicalization.
Solo BC: meta_keywords	5	La búsqueda nativa de BC lo usa; inocuo en otras plataformas.
Solo BC: search_keywords	5	Igual.
Robots no bloquea	5	Si la página es noindex, el resto es irrelevante.

100 en total. La nota viene de la suma, mapeada a A/B/C/D/F.