Datos estructurados de producto y e-commerce en las respuestas de las IA.

Lo que un asistente de compra lee en una ficha de producto

Un asistente de compra lee cinco cosas en una ficha de producto: la identidad del producto (nombre, marca, identificador), el precio con su divisa, la disponibilidad, la valoración agregada con su número de reseñas, y las condiciones de envío y devolución. Todo lo demás, descripción, argumentos, imágenes, sirve al lector humano; para el motor, esos cinco datos deciden si la ficha puede entrar en una respuesta del tipo «qué producto elegir», y en qué posición.

El nivel documentado varía según los editores. Google describe con precisión los datos estructurados Product y Offer que explota para sus resultados de comercio, y sus funciones de compra, incluida AI Mode, se apoyan en el Shopping Graph alimentado por Merchant Center. OpenAI indicó, al lanzar los resultados de compra en ChatGPT en la primavera de 2025, que estos se basan en metadatos estructurados proporcionados por terceros y en reseñas, y después abrió un sistema de feeds de productos para los comerciantes. Perplexity lanzó un programa para comerciantes que permite transmitirle datos de producto. Anthropic no ha documentado nada específico sobre productos. El detalle de estos sistemas evoluciona deprisa; lo que no cambia es la naturaleza de los datos esperados.

De ahí una consecuencia práctica: una ficha de producto se lee por tres canales, y hay que ser legible por los tres. El HTML con su marcado JSON-LD, que los robots de búsqueda de IA rastrean; los feeds de productos, que usted transmite a las plataformas; y las fuentes de terceros, comparativas, marketplaces y sitios de reseñas, que los motores citan masivamente en las preguntas de elección. Es la declinación, para un catálogo, de las cuatro condiciones descritas en nuestro método completo.

Los tres canales deben decir lo mismo. Un precio distinto entre la página y el feed, una disponibilidad actualizada en el feed pero caducada en el marcado, un nombre de producto diferente en un marketplace: cada una de estas divergencias es, para un motor, una razón para preferir una fuente más coherente, a menudo un competidor o una comparativa.

Product: la identidad del producto y sus variantes

El bloque Product describe lo que se vende, con independencia del precio. Las propiedades que cuentan son las que permiten reconocer el producto sin ambigüedad: name, brand, gtin13 o gtin, mpn, sku, image, description. El GTIN, código de barras del producto, es el identificador más valioso: permite a un motor emparejar su ficha con las fichas del mismo producto en otros sitios, y por tanto comparar su precio y su disponibilidad con los de los demás vendedores.

Tabla: desplácese horizontalmente.

Las variantes (tallas, colores, capacidades) son el primer punto de confusión. Google documenta desde 2024 el tipo ProductGroup, que agrupa las variantes con hasVariant y declara los ejes de variación con variesBy; cada variante es un Product con su propio GTIN, su precio y su disponibilidad. Declarar un solo Product con un precio único para veinte variantes, o veinte Product con el mismo GTIN, produce en ambos casos una información falsa, y un motor que compara precios lo nota.

Offer: precio, disponibilidad, envío, devoluciones

El bloque Offer lleva todo lo que cambia con el tiempo: el precio (price, priceCurrency), la disponibilidad (availability, con los valores normalizados InStock, OutOfStock, PreOrder, BackOrder), el estado (itemCondition), la validez del precio (priceValidUntil) y el vendedor. Google documenta además dos objetos que los asistentes de compra utilizan para responder a las preguntas sobre condiciones: OfferShippingDetails para los gastos y plazos de envío por zona, y MerchantReturnPolicy para el plazo y los gastos de devolución. Para un precio tachado, Google espera un objeto UnitPriceSpecification de tipo StrikethroughPrice en lugar de un texto.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.alpir.example/sacs/cairn-40#product",
  "name": "Mochila de senderismo Cairn 40 L",
  "brand": { "@type": "Brand", "name": "Alpîr" },
  "gtin13": "…",
  "sku": "ALP-CAIRN-40-GRIS",
  "color": "Gris pizarra",
  "image": ["https://www.alpir.example/img/cairn-40-face.jpg", "https://www.alpir.example/img/cairn-40-dos.jpg"],
  "description": "Mochila de senderismo de 40 litros, 1,1 kg, espalda ventilada, funda de lluvia incluida, diseñada para dos o tres días en autonomía.",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 212,
    "bestRating": 5
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.alpir.example/sacs/cairn-40",
    "price": 139.00,
    "priceCurrency": "EUR",
    "priceValidUntil": "2026-09-30",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@type": "Organization", "name": "Alpîr" },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "EUR" },
      "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "FR" },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
        "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 4, "unitCode": "DAY" }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "FR",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

La regla es la misma que para cualquier dato estructurado: lo que dice el marcado debe ser lo que dice la página, y ambos deben ser lo que dice el feed. El precio marcado es el precio mostrado, con todos los impuestos incluidos para un comprador particular; la disponibilidad marcada es la del stock en el momento en que se sirve la página, no la de una caché del día anterior.

Reseñas y valoraciones en una ficha de producto

La valoración agregada y las reseñas las leen todos los asistentes de compra, y pesan en las respuestas de recomendación tanto como el precio. En una ficha de producto, el marcado AggregateRating (valoración, número de reseñas, escala) y Review (autor, fecha, texto, valoración) es aceptado por Google a condición de que las reseñas se hayan recogido de sus clientes y traten del producto de la página; las reseñas copiadas de otros sitios no deben marcarse. La restricción sobre las reseñas autoatribuidas, que afecta a Organization y LocalBusiness, no se aplica a los productos.

Lo que da valor a una reseña para un motor se detalla en el artículo dedicado a las reseñas de clientes; para una ficha de producto, retenga tres puntos. El número de reseñas debe mostrarse junto a la valoración: «4,6 sobre 5» no significa nada sin «sobre 212 reseñas». Las reseñas deben estar fechadas y, si es posible, vinculadas a la variante en cuestión. Y las reseñas negativas deben seguir visibles; una ficha que solo muestra cinco estrellas es tratada con desconfianza por un lector humano, y no aporta ningún hecho aprovechable a un modelo que busca puntos débiles que mencionar.

Los feeds de productos: la segunda puerta de entrada

Un feed de productos es un archivo, o una API, que transmite su catálogo a una plataforma en un formato que ella impone. Merchant Center, en Google, es el más antiguo y el mejor documentado: alimenta Shopping, los resultados de comercio de la búsqueda clásica y, según Google, las funciones de compra de AI Mode. OpenAI y Perplexity han abierto sistemas comparables, cuyas especificaciones son públicas pero recientes; compruébelas en el momento de comprometerse, y considérelas canales que vigilar más que logros adquiridos.

El punto clave es la coherencia entre el feed y la página. Google verifica que el precio y la disponibilidad del feed coinciden con los de la página de destino, rechaza las ofertas en caso de diferencia, y recomienda el marcado Product en la página precisamente para esa verificación. No hay ninguna razón para pensar que las demás plataformas serán más tolerantes. La única forma de mantener esa coherencia a escala de un catálogo es generar página, marcado y feed desde la misma fuente, y controlar las diferencias antes de publicar.

Lo que hace descartar una ficha, y cómo medirlo

En nuestras auditorías de sitios de comercio electrónico, las fichas ausentes de las respuestas de compra comparten unos cuantos defectos, ninguno espectacular. Cada uno se comprueba en una muestra de diez fichas en menos de una hora.

• Un precio y una disponibilidad inyectados en JavaScript tras la carga, invisibles en el HTML inicial y ausentes del JSON-LD.
• Una disponibilidad marcada «en stock» en productos agotados desde hace semanas, porque el marcado está en caché.
• Un GTIN ausente, erróneo o compartido entre varias variantes.
• Una descripción copiada del fabricante, idéntica a la de otros veinte vendedores: nada justifica citar la suya.
• Ninguna información de envío ni de devolución, ni en el texto ni en el marcado.
• Una valoración mostrada sin número de reseñas, o reseñas sin fecha.
• Imágenes bloqueadas a los robots por una regla del CDN o un dominio de imágenes prohibido.
• Un feed de productos cuyos precios difieren de los de las páginas, con ofertas rechazadas que nadie vigila.

La medición sigue la lógica de la cuota de citación, aplicada a un catálogo. Se constituye un panel de preguntas de compra reales («qué X para Y», «X o Y», «mejor X por menos de Z euros»), se pasan cada semana por los motores, y se anotan tres cosas: si se nombra un producto del catálogo, si el precio y la disponibilidad citados son exactos, y qué fuente ha utilizado el motor, su ficha, una comparativa o un marketplace. Este último punto dice dónde dirigir el esfuerzo; las estrategias de contenido para las preguntas de elección se desarrollan en el artículo GEO para el e-commerce.

Qué recordar