Datos estructurados para productos: cómo implementarlos sin dañar la confianza
Los datos estructurados ayudan a Google y otros sistemas a entender mejor una ficha de producto: nombre, imagen, precio, disponibilidad, marca, variantes, reseñas reales y breadcrumbs. En ecommerce pueden mejorar la claridad del resultado, pero solo funcionan bien si reflejan contenido visible y verificable.
Si quieres bajar esta capa técnica a una auditoría real de catálogo, revisa nuestro servicio de SEO ecommerce. Para tiendas en Shopify, consulta también SEO Shopify.
Qué son los datos estructurados de producto
Los datos estructurados son una forma de etiquetar información de una página para que los motores de búsqueda la interpreten mejor. En una ficha de producto, el marcado más habitual usa Product, Offer, Brand, AggregateRating, Review y BreadcrumbList.
La regla principal: el schema debe coincidir con lo que el usuario ve. Si una página no muestra precio, stock o reseñas, no conviene inventarlos en JSON-LD.
Qué datos necesita una ficha de producto
Como mínimo, revisa que cada producto tenga:
- nombre del producto;
- descripción visible;
- imagen principal;
- marca o fabricante cuando aplique;
- URL canónica;
- precio;
- moneda;
- disponibilidad;
- estado del producto;
- breadcrumbs;
- variantes si cambian atributos relevantes.
En tiendas con catálogo complejo, también puede aplicar ProductGroup para familias con variantes, pero solo si la implementación representa bien la estructura real del producto.
Qué schema usar según el tipo de URL ecommerce
Uno de los errores más habituales es marcar todas las URLs como si fueran productos. Cada plantilla tiene un rol distinto.
| Tipo de URL | Schema recomendado | Qué evitar |
|---|---|---|
| Ficha de producto | Product, Offer, BreadcrumbList | Ratings, stock o precios que no estén visibles. |
| Producto con variantes | Product o ProductGroup si la implementación lo sostiene | Duplicar el mismo JSON-LD para variantes distintas. |
| Categoría o colección | BreadcrumbList y schema de página según implementación | Marcar la categoría completa como un único Product. |
| Blog o guía | BlogPosting o Article, BreadcrumbList, FAQPage si hay FAQs visibles | Añadir Product solo porque se mencionan productos. |
| Página de servicio | Service, FAQPage, Organization, BreadcrumbList | Reviews o ratings sin prueba visible y real. |
| Página de política | Schema básico de página si procede | Forzar marcado comercial sin sentido. |
Esta separación ayuda a que Google y motores de IA entiendan la función de cada URL sin mezclar señales.
Ejemplo básico de Product schema
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Zapatillas de running ejemplo",
"image": "https://example.com/zapatillas-running.jpg",
"description": "Zapatillas de running ligeras para entrenamientos diarios.",
"brand": {
"@type": "Brand",
"name": "Marca Ejemplo"
},
"offers": {
"@type": "Offer",
"url": "https://example.com/zapatillas-running",
"priceCurrency": "EUR",
"price": "79.95",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
Este ejemplo es deliberadamente simple. En producción, los valores deben salir del catálogo real y mantenerse sincronizados con precio, stock y URL visible.
Cuándo añadir reviews y ratings
Añade Review o aggregateRating solo cuando existan reseñas reales, visibles y asociadas al producto correcto.
No marques:
- ratings inventados;
- reviewCount sin reseñas visibles;
- valoraciones agregadas de otra fuente no mostrada;
- testimonios de marca como si fueran reviews de producto;
- reseñas duplicadas en productos distintos.
Un snippet más atractivo no compensa el riesgo de incoherencia entre datos estructurados y contenido visible.
BreadcrumbList para productos y categorías
El breadcrumb ayuda a explicar la jerarquía:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "Running",
"item": "https://example.com/running"
},
{
"@type": "ListItem",
"position": 3,
"name": "Zapatillas de running",
"item": "https://example.com/zapatillas-running"
}
]
}
El breadcrumb visible y el marcado deberían contar la misma historia. Si el usuario ve una ruta y Google otra, hay una señal confusa.
Errores frecuentes en ecommerce
- Usar el mismo schema para todos los productos.
- No actualizar disponibilidad cuando cambia el stock.
- Mantener precios antiguos en JSON-LD.
- Añadir ratings sin reseñas visibles.
- Marcar páginas de categoría como
Product. - Usar schema generado por apps sin revisar.
- Tener varios bloques JSON-LD contradictorios.
- Incluir productos descatalogados en sitemap sin criterio.
Estos errores son habituales cuando varias apps modifican el theme o cuando el catálogo se importa desde ERP, PIM o feeds sin una capa de validación.
Cómo validarlo
La validación debe combinar herramientas y revisión manual.
- Revisa el HTML renderizado de una ficha real.
- Valida con Rich Results Test o Schema Markup Validator.
- Comprueba Merchant listings y Product snippets en Search Console si aplica.
- Compara schema con contenido visible.
- Verifica productos con variantes, agotados y rebajados.
- Repite después de cambios de theme, apps o feed.
Si una herramienta marca warnings, no todos son críticos. Lo importante es separar advertencias asumibles de errores que impiden interpretar el producto.
Criterio de aceptación para publicar schema de producto
Antes de dar por buena una implementación, valida:
- una ficha con stock;
- una ficha agotada;
- una ficha con descuento;
- una ficha con variantes;
- una ficha sin reviews;
- una ficha con reviews reales visibles si existen;
- una categoría que no debe llevar
Product; - una URL antigua redirigida o retirada.
El criterio mínimo: el JSON-LD debe coincidir con el contenido visible, no debe duplicarse por apps y no debe declarar datos comerciales que el usuario no pueda comprobar.
Datos estructurados y GEO
Los datos estructurados también ayudan a que motores de IA entiendan mejor entidades, productos, marca y relaciones. No garantizan aparecer en AI Overviews ni en ChatGPT, pero reducen ambigüedad cuando el contenido ya es rastreable y útil.
Para GEO, combina schema con:
- descripciones claras;
- FAQs visibles;
- comparativas honestas;
- datos de producto actualizados;
- contenido de soporte;
- enlaces internos coherentes.
Esta capa conecta con SEO GEO cuando la tienda quiere ser citada o entendida mejor en respuestas generativas.
Preguntas frecuentes sobre datos estructurados de producto
¿Puedo añadir AggregateRating si tengo reseñas en otra plataforma?
Solo debería añadirse si las reseñas son reales, están asociadas al producto correcto y son visibles para el usuario en la página. Si el usuario no puede verificar esa valoración, el marcado crea una señal incoherente.
¿Una colección ecommerce debe llevar schema Product?
Normalmente no como si fuera un único producto. Las colecciones cumplen otra función: agrupar productos, explicar una categoría y enlazar fichas. El marcado debe representar esa función sin inventar un producto agregado.
¿Las apps de Shopify resuelven el schema automáticamente?
Pueden ayudar, pero no sustituyen revisión. Varias apps pueden inyectar JSON-LD duplicado o contradictorio. En Shopify conviene validar el HTML final de plantillas de producto, colección, blog y página.
Conclusión
Los datos estructurados para productos no son una decoración técnica. Son una forma de declarar, con precisión, qué vende una página y bajo qué condiciones. Si el marcado no coincide con el contenido visible, pierde valor y puede generar problemas.
Empieza por productos estratégicos, valida el marcado y evita automatizar ratings, reviews o stock sin control. Cuando el catálogo crece, esta revisión debe formar parte del plan de SEO técnico ecommerce.
Fuentes oficiales revisadas
Referencias usadas para contrastar recomendaciones técnicas, documentación de plataforma y criterios de búsqueda.
