Los datos estructurados ayudan a Google a interpretar una página y pueden habilitar presentaciones enriquecidas. No garantizan que esas presentaciones aparezcan ni permiten adjudicar un aumento de CTR sin datos comparables.
La página anterior mostraba miles de URLs y mejoras porcentuales sin exportaciones, fechas o muestra. Esta versión sustituye esas cifras por un protocolo comprobable.
Elegir el tipo desde la página real
El punto de partida no es una lista de tipos de Schema.org. Se revisa la función de cada plantilla y el contenido que ve el usuario.
| Plantilla | Candidato habitual | Prueba antes de marcar |
|---|---|---|
| Producto vendible | Product y Offer |
Precio, disponibilidad y vendedor visibles y actuales |
| Navegación jerárquica | BreadcrumbList |
Migas visibles o jerarquía coherente |
| Negocio con ubicación | LocalBusiness específico |
Nombre, dirección y contacto reales |
| Artículo editorial | Article o subtipo |
Titular, fechas, imagen y autor presentes |
| Organización | Organization |
Identidad y datos corporativos aprobados |
No se añaden reseñas, ratings, autoría o precios que no existan en la página. La política general de datos estructurados de Google exige que el marcado represente el contenido principal y aclara que una prueba válida no garantiza rich results.
Contrato de implementación
Cada plantilla necesita una fuente de verdad. El precio puede venir del catálogo, el autor del CMS y la disponibilidad del inventario. El JSON-LD no debería mantener copias manuales que envejecen por separado.
La especificación interna registra:
- tipo y propiedades usadas
- campo visible que respalda cada valor
- sistema de origen
- comportamiento cuando el valor falta
- ejemplo válido y ejemplo límite
- responsable de la plantilla.
Para productos, la documentación oficial explica las diferencias entre Product en Search y las experiencias de merchant listings. Feed, HTML y marcado deben coincidir.
Validación por capas
Primero se valida el JSON. Después se comprueba el tipo con Rich Results Test. A continuación se inspecciona el HTML renderizado, porque una herramienta no sabe si el dato es verdadero o visible. Finalmente se toma una muestra en Search Console y se revisan errores tras el despliegue.
La muestra incluye estados que suelen romper plantillas: producto agotado, precio promocional, contenido sin imagen, varios autores, cambio de idioma y páginas paginadas.
“Válido” significa que la sintaxis y ciertos requisitos pasan una prueba. No significa que Google mostrará la función ni que el cambio causará más clics.
Diseño de una medición de CTR
Una evaluación seria fija antes del cambio:
- Plantillas y URLs incluidas.
- Fecha de despliegue y validación.
- Consultas, países y dispositivos comparables.
- Posición, impresiones y apariencia de búsqueda.
- Cambios simultáneos en títulos, precios, inventario o campañas.
El CTR se analiza junto con posición e impresiones. Si la mezcla de consultas cambia, comparar un promedio global puede atribuir al schema lo que proviene de otra demanda. Un grupo de control o un rollout escalonado mejora la interpretación.
Mantenimiento
Los tipos y políticas de Search cambian. La revisión mensual debe comprobar errores nuevos, diferencias con el contenido visible, plantillas sin marcado y funciones retiradas. El inventario conserva la última fecha de prueba y un enlace al ejemplo público.
Evidencia que permitiría publicar resultados
Para convertir esta guía en un caso harían falta la lista o muestra definida, exportaciones antes y después, registro del despliegue, validaciones, cambios concurrentes y permiso del cliente. Sin eso no se publica un porcentaje de CTR ni un número de páginas como logro.