No añadas schema para decorar la ficha
Tesis práctica
Los datos estructurados de producto sirven para que Google entienda con menos ambigüedad qué vendes, cómo se compra y qué promesa comercial acompaña a esa oferta. En ecommerce no deberían tratarse como una capa SEO separada de la operación, porque precio, disponibilidad, variantes, imágenes, envío y devoluciones cambian desde sistemas distintos y acaban siendo lo que Google compara.
La documentación de Google distingue entre Product snippets y merchant listings. En una página donde el usuario puede comprar, el objetivo principal suele ser la experiencia de merchant listing: precio, disponibilidad, información de envío, devoluciones y otros datos que pueden aparecer en Search, Google Images o resultados de compra. Si la página es una review, un ranking o un contenido editorial sobre productos, el marcado puede necesitar otro enfoque.
La regla editorial para una tienda es simple: solo se marca lo que también ve el comprador o lo que está respaldado por el feed y la política pública. Un JSON-LD perfecto que promete stock, precio rebajado o devolución gratuita cuando la ficha no lo demuestra no es una mejora técnica; es una fuente de errores, rechazos y pérdida de confianza.
- Empieza por una ficha canónica de producto comprable, no por todas las plantillas a la vez.
- Mapea cada propiedad del schema contra un campo real: PIM, ERP, Shopify, PrestaShop, feed o política pública.
- Evita marcar ratings, disponibilidad o descuentos si no tienes evidencia visible y actualizada.
Construye primero Product y Offer sin contradicciones
Base técnica
La base de una ficha comprable es un objeto Product que describe el artículo y un Offer anidado que explica la venta concreta. Product suele reunir nombre, imagen, descripción, marca, SKU, GTIN o MPN cuando existan. Offer cubre URL, precio, moneda, disponibilidad, condición y, cuando procede, fechas de validez o reglas de precio más complejas.
El error habitual es copiar el marcado que genera una app sin revisar si el precio activo, la moneda y el estado coinciden con el HTML inicial de la ficha. Merchant Center recuerda que los datos estructurados deben estar sincronizados con los elementos mostrados al usuario y recomienda que el marcado de producto esté en el HTML inicial para obtener mejores resultados.
Para tiendas con promociones frecuentes, conviene separar precio activo, precio tachado y precio de socio. Google documenta que el precio activo puede declararse en Offer o en UnitPriceSpecification, pero si ambos aparecen para el mismo precio activo, Google prioriza el valor de offers.price. Esa prioridad importa cuando una plantilla duplica importes desde distintas apps.
Campos que no deberían faltar
Nombre comercial claro, imagen principal rastreable, descripción visible, SKU interno estable, GTIN cuando el producto lo tenga, marca correcta, Offer con URL canónica, precio actual, moneda ISO y disponibilidad única.
Campos que conviene auditar a mano
AggregateRating y Review solo si proceden de reseñas reales visibles; sale price solo si la oferta está activa; itemCondition solo si la condición se comunica; shippingDetails y return policy solo si coinciden con la política publicada.
Usa ProductGroup cuando el problema sean variantes
Catálogo real
Moda, calzado, muebles, electrónica y accesorios suelen vender una misma familia en tallas, colores, materiales o configuraciones. Si cada variante vive en una URL distinta, o si un selector cambia la variante dentro de una misma ficha, Google necesita entender que no son productos independientes sin relación, sino opciones de un producto base.
Para ese caso, Google recomienda ProductGroup junto a Product. ProductGroup agrupa variantes mediante variesBy, hasVariant y productGroupID; Schema.org lo define como un grupo de productos que varían solo en formas bien descritas, por ejemplo talla, color o material. La ventaja práctica es reducir duplicación y conservar propiedades comunes como marca, familia y reseñas compartidas cuando aplican.
No todas las tiendas necesitan ProductGroup desde el primer día. Si solo hay un producto simple por URL, Product y Offer bien resueltos aportan más que una arquitectura de variantes mal montada. Pero si Search Console muestra avisos por variantes, Merchant Center recibe item_group_id o el catálogo crea canonicals confusos, ProductGroup se vuelve una pieza de higiene comercial.
- Define una URL canónica para cada variante solo si el comprador puede aterrizar y comprar esa variante concreta.
- Usa productGroupID de forma estable y alineada con item_group_id cuando el feed ya agrupa variantes.
- Marca las diferencias reales: talla, color, material, patrón, capacidad o configuración, no atributos irrelevantes.
Marca envío y devoluciones solo si la promesa existe
Confianza comercial
El schema de producto se vuelve más útil cuando no se queda en precio y stock. Las fichas de comerciantes pueden resaltar información de envío y devoluciones, y Google documenta hasMerchantReturnPolicy y shippingDetails dentro de Offer para casos concretos. Aun así, la recomendación práctica es no empezar por ahí si la tienda no tiene una política estable y visible.
Una tienda que cambia costes de envío por provincia, peso, campaña o proveedor necesita una matriz operativa antes que un bloque JSON-LD. Si el schema dice envío gratis, el checkout cobra suplemento y Merchant Center tiene otra regla, el comprador recibe tres promesas distintas. Esa incoherencia no se arregla validando sintaxis.
El orden sano es página de políticas clara, checkout coherente, Merchant Center configurado y, después, marcado de envío o devoluciones donde aporte precisión. Para excepciones por producto, OfferShippingDetails puede tener sentido; para políticas globales, puede ser más mantenible declarar reglas a nivel de organización o cuenta y usar la ficha solo cuando cambia algo por SKU.
Cuando sí merece la pena marcarlo
Productos con envío gratuito real, plazos diferenciados, recogida, productos voluminosos, devolución limitada, garantía comercial específica o condiciones que el comprador compara antes de decidir.
Cuando bloquearlo temporalmente
Si soporte no puede explicar la promesa, si el checkout calcula otra cosa, si Merchant Center marca errores o si la política pública usa frases vagas como envío rápido sin rangos ni zonas.
Haz que schema, feed y página cuenten la misma historia
Datos sincronizados
Google Merchant Center usa datos de producto para asociar artículos con consultas adecuadas y advierte que información incorrecta o incompleta puede provocar rechazos, limitaciones o visualizaciones incorrectas. Por eso el schema no debe medirse solo por si el Rich Results Test lo acepta, sino por si ayuda a reconciliar la ficha con el feed.
Las automatizaciones de Merchant Center pueden usar el marcado estructurado y otros extractores para actualizar precio, precio de oferta, disponibilidad y condición en anuncios de Shopping y fichas gratuitas. Es una red de seguridad para discrepancias temporales, no un sustituto de subir datos precisos con frecuencia. Si el catálogo cambia varias veces al día, feed, API y schema deben tener responsabilidades claras.
La auditoría debería comparar cinco superficies: HTML visible, JSON-LD, feed de Merchant Center, checkout y Search Console. Si una app de reviews, un módulo de promociones o una integración headless genera datos distintos, el equipo debe decidir una fuente de verdad. La mejora no es añadir más propiedades, sino eliminar contradicciones.
- Comprueba que title, description, image_link, GTIN, item_group_id, price, sale_price y availability coinciden con la ficha.
- Revisa productos con variación alta de precio o stock antes de activar automatizaciones como solución permanente.
- Documenta qué sistema escribe cada campo para poder reparar errores tras cambios de tema, app o feed.
Haz que descubran tu tienda
Si tienes una tienda online, publícala aquí en TienRank gratis para reforzar la autoridad de tu web y ayudar a que Google y las IAs entiendan mejor tu marca.
Valida, despliega en pequeño y monitoriza avisos
QA SEO
La validación correcta tiene tres momentos. Antes de publicar, prueba la plantilla con Rich Results Test y corrige errores críticos. Después, despliega unas pocas fichas representativas y usa inspección de URL para ver si Google puede acceder a la página sin robots, noindex, login ni render roto. Finalmente, revisa Search Console cuando Google haya recrawleado las URLs.
Google explica que hay dos informes relacionados con Product structured data: Merchant listings para páginas donde se puede comprar y Product snippets para otras páginas de producto, como reviews o agregadores. Esa separación evita interpretar mal avisos que pertenecen a otro tipo de experiencia.
También hay que aceptar una limitación importante: Google no garantiza que una página con structured data aparezca como rich result. El objetivo razonable es aumentar elegibilidad, claridad y consistencia de datos; el resultado visual depende de sistemas de Google, competencia, consulta, calidad de página y disponibilidad de información.
- Crea una lista de URLs de muestra por tipo: producto simple, variante, oferta, agotado, preventa y producto con envío especial.
- Guarda capturas o exports de errores antes y después para distinguir arreglos reales de cambios de rastreo.
- Repite QA cuando cambien tema, app de reviews, motor de precios, feed, política de envío o estructura de variantes.
Seguir investigando
Impulsa buenas noticias
¿Te ha sido útil este análisis?
Dale un upvote para que suba en Noticias, llegue a más owners y podamos priorizar los casos que de verdad ayudan a tomar mejores decisiones en e-commerce.
Preguntas frecuentes
¿Qué datos estructurados necesita una ficha de producto ecommerce?
Como base, Product con nombre, imagen, descripción, marca, SKU o GTIN cuando existan, y Offer con URL, precio, moneda, disponibilidad y condición si aplica. Después se pueden añadir envío, devoluciones, reviews o variantes si están respaldadas por datos visibles y actuales.
¿Product snippets y merchant listings son lo mismo?
No. Merchant listings está pensado para páginas donde el usuario puede comprar y puede incluir precio, disponibilidad, envío o devoluciones. Product snippets encaja mejor en otras páginas relacionadas con productos, como reviews o agregadores.
¿Conviene usar ProductGroup en Shopify, PrestaShop o WooCommerce?
Conviene cuando una familia tiene variantes reales de talla, color, material u otra propiedad comparable. Si cada variante tiene URL propia o el feed usa item_group_id, ProductGroup puede ayudar a Google a entender la relación. En productos simples no es prioritario.
¿El schema puede sustituir al feed de Merchant Center?
No. Google recomienda datos precisos y frecuentes en Merchant Center. El marcado estructurado ayuda a entender la página y puede servir para automatizaciones o comprobaciones, pero no debe convertirse en la única fuente de verdad del catálogo.
¿Por qué Rich Results Test pasa pero Search Console marca avisos?
El test valida una URL o código en un momento concreto. Search Console refleja lo que Google ha rastreado e indexado en el tiempo y separa informes por experiencia. También puede mostrar advertencias de calidad que no bloquean elegibilidad pero conviene revisar.
¿Qué errores de schema producto debería priorizar una tienda?
Primero errores críticos de precio, moneda, disponibilidad, URL, imagen o identificadores. Después contradicciones con el feed, ratings sin evidencia, variantes mal agrupadas, políticas de envío inexistentes y datos generados por JavaScript que no aparecen en el HTML inicial.
Fuentes
Comunidad
La conversación se carga después del contenido principal para mantener rápida esta página.