Datos estructurados de producto

Un rastreador ve una ficha de producto como texto y etiquetas de maquetación. El precio puede vivir en un span con clase «precio», en una tabla, dentro de una pestaña o incluso en una imagen. El marcado de producto suprime esa ambigüedad: declara en un bloque legible por máquina que ese número es el precio vigente, que esa cadena es el nombre del artículo y que ese 4,6 resume 128 opiniones.

El vocabulario procede de schema.org y el tipo central es Product. A su alrededor se ordenan Offer, que recoge las condiciones comerciales; AggregateRating, que resume la media de valoraciones; y Review, que representa una opinión concreta con su autor y su puntuación.

Conviene separar tres capas que se confunden a diario. El marcado vive en el HTML de la página y lo lee el rastreador. El feed de producto es un fichero que la tienda envía a Merchant Center. La ficha visible es lo que lee la persona. Las tres deben contar lo mismo, aunque son canales distintos con reglas distintas.

También conviene delimitar el tipo. Product describe un artículo comercial concreto: ni una categoría, ni un listado, ni la tienda como empresa. Para la empresa existe Organization, y sus reglas sobre valoraciones son diferentes.

El marcado se inserta como un bloque JSON-LD en el HTML. Google distingue dos salidas para ese mismo tipo.

Los fragmentos de producto están pensados para páginas donde el artículo no se puede comprar allí mismo, por ejemplo una reseña editorial. Basta con incluir una de estas tres propiedades: review, aggregateRating u offers.

Las fichas de comerciante están pensadas para páginas donde sí se compra, y alimentan experiencias como el panel de conocimiento de compras, los productos populares y Google Imágenes. Ahí son obligatorios name, image y un offers con price (o priceSpecification.price) y priceCurrency, con un precio mayor que cero. Se recomiendan además availability, shippingDetails, hasMerchantReturnPolicy, url y priceValidUntil. En julio de 2026 la documentación incorporó Product.category y la duración de una oferta rebajada, alineada con el atributo equivalente del feed.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Silla de oficina Kora",
  "image": ["https://ejemplo.es/kora-1.jpg"],
  "sku": "KORA-01",
  "brand": { "@type": "Brand", "name": "Kora" },
  "offers": {
    "@type": "Offer",
    "url": "https://ejemplo.es/silla-kora",
    "price": "249.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

Hay un segundo circuito, el de Merchant Center. Las actualizaciones automáticas de artículos leen el precio, la disponibilidad y el estado desde el marcado de la página de destino y corrigen el feed mientras este va por detrás. Si esa corrección está desactivada y los valores no coinciden, el producto recibe una desaprobación a nivel de artículo y deja de mostrarse en fichas gratuitas y anuncios.

La decisión que depende de esto no es «¿subo posiciones?», sino «¿con qué aspecto y con qué permiso aparece mi catálogo?». Dos páginas en la misma posición no rinden igual si una muestra precio, disponibilidad y estrellas y la otra solo un título azul.

La segunda decisión es operativa y cuesta dinero de verdad. En el circuito de Merchant Center, la discrepancia entre feed, página y marcado no degrada nada de forma silenciosa: desaprueba el artículo. Un despliegue que cambia precios en la plantilla visible pero deja el JSON-LD generado por una caché antigua puede sacar del escaparate a miles de referencias en cuestión de horas.

La tercera es de reparto de esfuerzo. Con el marcado mínimo (name, image, offers) la ficha ya es elegible; el resto de propiedades amplía dónde puede aparecer. Saber qué es obligatorio y qué es recomendado permite decidir si merece la pena que el equipo de desarrollo exponga la política de devoluciones o los gastos de envío en el marcado, o si ese esfuerzo rinde más en el feed.

Y una advertencia sobre expectativas: el marcado no crea elegibilidad para funciones que Google ha retirado. Publicar vocabulario que ya no tiene salida visual no perjudica, pero tampoco devuelve nada.

• Genera el JSON-LD desde la misma fuente de datos que pinta el precio en pantalla. El marcado escrito a mano o cacheado aparte se desincroniza al primer cambio de tarifa.
• Marca únicamente el producto principal de la ficha, con el mismo precio y la misma moneda que ve la persona, y sin símbolo de moneda ni separador de miles dentro de price.
• Publica en el mismo despliegue el cambio de precio en la página, en el marcado y en el feed. Las tres capas deben coincidir antes de que pase el rastreador.
• Usa availability e itemCondition con las URL completas de schema.org, y mantén priceValidUntil con una fecha futura mientras la oferta siga viva.
• Emplea aggregateRating solo cuando las valoraciones sean de clientes reales sobre ese artículo y estén visibles en la propia página.
• Valida con la prueba de resultados enriquecidos antes de desplegar y revisa después el informe correspondiente en Search Console, que es donde se ve el comportamiento real a escala.

• Colocar aggregateRating en una página de categoría o en la portada, sobre un conjunto que no es un producto concreto.
• Describir la empresa con Organization o LocalBusiness y colgar de ahí las opiniones que la propia empresa gestiona sobre sí misma. Google declara esas páginas no elegibles para las estrellas.
• Dejar priceValidUntil con una fecha ya pasada, lo que puede impedir que la ficha se muestre.
• Traducir el precio con separador de miles o incluir el símbolo del euro dentro del valor numérico.
• Tratar el marcado y el feed como proyectos de equipos distintos, sin nadie que compare ambos valores tras cada cambio de tarifa o de stock.