Los datos estructurados de producto industrial son el marcado Schema.org que permite a Google mostrar precio, disponibilidad o valoración junto al resultado de búsqueda, en vez de un enlace sin más información. En catálogos industriales con cientos de referencias técnicas, ese marcado decide si la ficha compite en el buscador o queda por debajo del distribuidor genérico. El fallo no suele ser desconocerlo, sino aplicarlo a medias: un precio inventado, una valoración que Google nunca va a mostrar o un dato caducado que tira la ficha entera de los resultados enriquecidos. El marcado no trabaja solo: la velocidad de carga de la ficha pesa tanto como el JSON-LD a la hora de decidir si esa página compite o se queda fuera de los resultados enriquecidos.
Google exige tres propiedades dentro del Offer para activar el rich result de producto: price, priceCurrency y availability. Sin las tres juntas no aparecen precio ni disponibilidad en el buscador, y forzar un valor falso, como poner precio 0 en un artículo bajo presupuesto, puede descalificar toda la ficha.
Datos estructurados de producto industrial, las tres propiedades clave
La documentación de Google exige name y al menos uno de review, aggregateRating u offers para que la ficha entre en la conversación de los resultados enriquecidos. Pero lo que activa precio y disponibilidad es el Offer, con tres propiedades sin excepción: price, priceCurrency y availability, según la documentación de marcado de producto de Google.
- price: número plano, sin símbolo de moneda ni separador de miles.
- priceCurrency: código ISO 4217, nunca el símbolo.
- availability: uno de los valores que acepta Schema.org, nunca texto libre.
Un rich result de producto es el fragmento que añade precio, disponibilidad o valoración bajo el título en Google. Sin las tres propiedades obligatorias del Offer, la ficha se muestra como un enlace normal, sin ninguna de esas señales.
Los valores válidos de availability
Availability no admite un texto cualquiera: solo los valores que define el vocabulario ItemAvailability de Schema.org, de donde sale buena parte de los errores en catálogos gestionados con hojas de cálculo o un PIM. Los que de verdad se usan en una ficha industrial son InStock, para envío inmediato; OutOfStock, agotado; PreOrder, reserva sobre fabricación; BackOrder, pedido con plazo de fabricación; y LimitedAvailability, series con pocas unidades. Un ERP que exporta «disponible» o «consultar stock» tal cual rompe la validación: Search Console marca el valor como no reconocido y descarta esa propiedad. La corrección es un mapeo, no una redacción: cada estado interno tiene que traducirse a uno de esos valores antes de llegar al JSON-LD.
Precio bajo consulta en catálogo industrial
El catálogo industrial tiene un problema que el textil o la electrónica de consumo no arrastran: media referencia no tiene un precio fijo, porque depende de volumen, acabado o plazo de fabricación. Ahí es donde más ficha se rompe: alguien pone price a 0 para que valide, o directamente omite el Offer entero. Las dos salidas son peores que el problema original, porque Google no distingue «sin precio» de «precio cero»: entiende que el producto se regala.
Cómo declarar un rango con AggregateOffer
Cuando la referencia tiene variantes con precios distintos, tres acabados o cinco capacidades, Schema.org resuelve el caso con AggregateOffer en lugar de un Offer suelto: lowPrice y highPrice marcan el rango real, y offerCount indica cuántas variantes lo componen. Para el caso más incómodo, el producto que de verdad exige presupuesto a medida, la práctica que sostiene la propia especificación es usar el precio de la referencia más básica de la familia como lowPrice orientativo, nunca un cero, y reforzar en el texto visible de la ficha que el importe final depende de la configuración elegida. Es el mismo ajuste que aplicamos en clientes del sector industrial que exportan su catálogo desde un ERP: la ficha entra en el rich result con un precio real y verificable, aunque no sea el que pague cada comprador.
AggregateRating en fichas de producto industrial
El marcado de reseñas es donde más confusión hay desde que Google restringió las estrellas de autoevaluación. Desde 2019 dejó de mostrar el rich result de valoración cuando es la propia organización quien puntúa su negocio en general, el marcado sobre LocalBusiness u Organization, y en agosto de 2023 endureció además la política contra reseñas falsas o incentivadas sin declarar en cualquier AggregateRating. Ninguna de las dos restricciones prohíbe valorar un producto concreto: prohíben fabricar estrellas para el negocio genérico.
Por qué el self-serving no aplica al Product
La restricción de 2019 habla de Organization y LocalBusiness, no de Product: una ficha de válvula industrial con reseñas reales de compradores, cada una con nombre de persona o de empresa verificable, sigue siendo elegible para estrellas en el buscador. Lo que descalifica la ficha es lo de siempre disfrazado de marcado: pedir al equipo comercial que puntúe cinco estrellas sin haber comprado, o heredar la valoración media de todo el catálogo en cada producto nuevo que aún no tiene una sola compra. Si no hay reseñas reales todavía, la propiedad correcta es omitir aggregateRating, no inventarlo con una cifra redonda.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Envío y devolución en el marcado de producto
shippingDetails y hasMerchantReturnPolicy llevaban años siendo terreno casi exclusivo de quien tenía cuenta en Google Merchant Center, pero la ampliación de noviembre de 2025 dejó declarar plazos de envío y condiciones de devolución con MerchantReturnPolicy directamente en la página de producto, sin depender de ese feed. Para un fabricante o distribuidor industrial el dato que de verdad importa no es el plazo de un paquete de mensajería, sino el de transporte paletizado o la instalación in situ, y ahí conviene declarar deliveryTime con el rango real, aunque sean semanas y no días. hasMerchantReturnPolicy tiene una casilla que muchos catálogos B2B olvidan marcar aparte: returnPolicyCategory admite MerchantReturnNotPermitted para piezas fabricadas a medida o cortadas por encargo, que legítimamente no admiten devolución. Dejarlo en blanco no es más seguro: Google lo trata como ausencia de política, algo que Search Console señala como incidencia no crítica pero visible, y frente a un competidor que sí la declara, la ficha completa gana el hueco del rich result.
Checklist de datos estructurados antes de publicar
Antes de dar una ficha por lista para producción conviene repasarla contra lo que Google trata como obligatorio y lo que solo suma. La tabla siguiente resume las propiedades que más fallan en catálogos industriales gestionados desde un PIM o exportados de un ERP, con la consecuencia real de dejarlas fuera, no la genérica de «no es óptimo». Conviene meter este repaso dentro de una auditoría SEO técnica periódica, no revisarlo ficha a ficha cada vez que cambia el catálogo, y decidir también si el JSON-LD lo genera el plugin de WordPress o se inyecta a mano en la plantilla de producto. Conviene repetir el repaso también cuando cambia la plataforma del catálogo: un salto como migrar de PrestaShop a Shopify reescribe la plantilla de producto entera, y con ella el JSON-LD que la acompaña.
| Propiedad | Tipo | Qué exige Google | Si falta |
|---|---|---|---|
| price + priceCurrency | Obligatoria | Número plano y código ISO 4217, nunca símbolo | Sin rich result de precio |
| availability | Obligatoria | Uno de los 7 valores de ItemAvailability | Google descarta el Offer completo |
| priceValidUntil | Recomendada | Fecha ISO 8601 futura | Deja de mostrarse pasada esa fecha |
| aggregateRating | Opcional | Reseñas reales, con autor identificable | Sin estrellas, sin sanción |
| hasMerchantReturnPolicy | Recomendada | returnPolicyCategory declarado, aunque sea sin devolución | Incidencia no crítica en Search Console |
| shippingDetails | Recomendada | deliveryTime realista para carga industrial | Sin estimación de entrega en el resultado |
Preguntas frecuentes sobre datos estructurados de producto industrial
¿Qué precio se declara si el producto es bajo presupuesto?
El de la variante o configuración más básica de la familia, nunca un cero. Se usa como lowPrice dentro de un AggregateOffer y se deja claro en el texto visible que el importe final depende de la configuración elegida. Un precio real, aunque no sea el definitivo, vale más para Google que un Offer vacío o inventado.
¿Puede una ficha nueva sin reseñas usar aggregateRating?
No. Sin valoraciones reales de compradores identificables, la propiedad correcta es omitir aggregateRating por completo, no rellenarla con una media heredada del catálogo. Google exige que cada reseña sea atribuible a una persona o empresa concreta, y lo revisa desde que endureció la política contra reseñas falsas en agosto de 2023.
¿Qué pasa si priceValidUntil queda en el pasado?
Google entiende que el precio ya no es vigente y puede dejar de mostrar el rich result para esa ficha, aunque el resto del Offer esté correcto. Conviene automatizar la fecha desde el ERP o el PIM en vez de fijarla a mano, porque es el campo que más se queda desactualizado sin que nadie lo note.
¿Hace falta declarar devolución en piezas fabricadas a medida?
Sí, aunque la respuesta sea que no se admite. returnPolicyCategory tiene el valor MerchantReturnNotPermitted precisamente para eso: declara la ausencia de devolución en vez de dejar la propiedad vacía. Un hasMerchantReturnPolicy completo, aunque diga que no hay devolución, cuenta más para Google que uno ausente.