Por qué los agentes de compras con IA leen mal tus precios

Los agentes de compras con IA citan un precio equivocado cuando leen en el código de tu página un número que no es el que realmente paga una persona. Los agentes analizan el HTML y los datos estructurados de forma literal, no visual, así que un precio original tachado, un total renderizado con JavaScript, un código de moneda ausente o un precio de pack dividido resultan igual de válidos para un script. La diferencia entre lo que se muestra y lo que dice el marcado permanece invisible hasta que un agente se la repite a un comprador.

Por qué los agentes de compras con IA muestran un precio equivocado

Cuando un cliente le pide a ChatGPT, Perplexity o un agente similar que encuentre un producto y su precio, el agente no abre tu sitio en un navegador ni lo lee como lo haría una persona. Descarga la página, busca primero datos estructurados y luego recurre a los nodos de texto del HTML. Si nada de eso coincide con el número que realmente cobra tu checkout, el agente cita lo primero que encontró, no lo correcto.

Vemos los mismos cinco fallos en casi todas las auditorías:

1. Totales renderizados en el cliente. El precio lo inyecta JavaScript después de la carga inicial de la página, así que la descarga del agente devuelve un marcador de posición, un vacío o "$0.00".
2. Marcado de rebajas ambiguo. Un precio original tachado aparece junto al precio rebajado sin ninguna etiqueta que los distinga, así que el agente no puede saber qué número citar.
3. Schema ausente o incompleto. Sin Offer.price, o con un precio sin priceCurrency, el agente se ve obligado a adivinar a partir del texto visible.

Los otros dos son problemas de formato que a una persona le parecen correctos pero significan otra cosa para un script:

4. Packs y precios por tramos. El precio por unidad, el precio del pack y el precio de suscripción conviven en el DOM, y el agente toma el primer número que encuentra en lugar del que corresponde al producto por el que se pregunta.
5. Colisiones de símbolos de moneda. Un $ a secas usado tanto para USD como para CAD, o £ para GBP y también para antiguas fichas en libras egipcias, sin código ISO que lo desambigüe.

Las colisiones de moneda merecen una mirada más atenta, porque son el fallo que los dueños de tienda detectan más tarde. Una tienda que vende en USD y CAD usando siempre un $ a secas no le da al agente forma alguna de saber a qué moneda pertenece cada precio.

La ambigüedad solo se resuelve si el contexto que la rodea (un locale en la URL, una etiqueta hreflang o el propio campo priceCurrency) la desambigua. Hemos visto agentes asumir USD por convención incluso cuando la página claramente atiende a un comprador canadiense, simplemente porque el símbolo no lleva ningún código.

Cualquiera de estos casos basta para que un agente le cite un precio equivocado a un comprador que nunca llega a tu página para comprobarlo por su cuenta.

¿Cómo leen realmente un precio los agentes con IA?

La mayoría de los agentes de compras siguen un orden de preferencia estricto. Primero revisan los datos estructurados de schema.org, porque son explícitos y legibles por máquinas por diseño. Si faltan o están incompletos, recurren al texto visible del DOM renderizado, y solo algunos agentes ejecutan JavaScript antes de leer ese DOM.

Algunos agentes ni siquiera descargan tu página directamente. Consultan un feed de retailer, una API de compras o una copia en caché de un índice de búsqueda, y esa caché puede ir por detrás de un cambio de precio en vivo durante horas o días. Si tu feed y tu schema en vivo no coinciden, un agente que cite desde el feed seguirá equivocándose aunque tu web sea técnicamente correcta en el momento en que alguien la consulta.

Esto importa porque un precio que a una persona le parece perfectamente claro, en negrita y al principio de la página, puede aún no existir en el marcado que el agente recibe. La propia guía de Google sobre datos estructurados para productos es explícita: precio, moneda y disponibilidad deben estar presentes como campos discretos y tipados, no solo como texto visible. El tipo Offer de schema.org existe precisamente para que un precio no tenga que deducirse del formato.

Los compradores humanos tienen un problema relacionado, aunque por otra causa. La investigación de Baymard sobre checkout ha encontrado repetidamente que los precios poco claros o revelados tarde son uno de los mayores motivos de carrito abandonado, porque la gente no logra cuadrar lo que ve en la página de producto con lo que se le cobra en el checkout. Un marcado de precios confuso no solo te cuesta con los agentes, también te cuesta con las personas, algo que tratamos con más detalle en nuestro artículo sobre por qué los compradores abandonan tu página de producto sin comprar.

Los cinco patrones de fallo que más vemos en las auditorías

En las tiendas que hemos pasado por la auditoría de 115 reglas de UXFix, los fallos de lectura de precios se concentran en un puñado de causas raíz. Las cifras siguientes provienen de nuestro propio conjunto de auditorías, no son una afirmación sobre ningún retailer concreto.

Las dos primeras filas son las que más directamente hacen que un agente cite mal un precio. La tercera se incluye porque muestra que el mismo problema de fondo, la ambigüedad entre lo prometido y lo cobrado, también aparece con personas, solo que más adelante en el embudo. Si tu checkout además introduce costes nuevos en el último paso, esa es una fuga distinta pero relacionada que tratamos en por qué los compradores abandonan el checkout en el pago.

Ninguna de estas cifras describe a un solo retailer. Describen un patrón entre las tiendas de nuestro conjunto de auditorías, y el patrón se repite sin importar la plataforma, ya sea una tienda sobre un carrito alojado, un stack de comercio headless o un desarrollo a medida. El denominador común es siempre el mismo: el número que un script puede extraer en la primera descarga no coincide con el número que el comprador acaba pagando.

Cómo formatear los precios para que los agentes los lean bien

La solución casi siempre es un cambio de marcado, no un rediseño. Tres cosas importan más que ninguna otra: el precio tiene que existir en la respuesta HTML inicial, tiene que estar correctamente tipado en el schema, y la distinción entre precio rebajado y precio original tiene que ser inequívoca para algo que lee código, no píxeles.

Así se ve un marcado correcto en la práctica, usando el mismo precio rebajado de $61 del ejemplo anterior:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Product",
  "offers": {
    "@type": "Offer",
    "price": "61.00",
    "priceCurrency": "USD",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock"
  }
}

El precio de referencia, el $89 tachado, no debe ir en Offer.price. Si quieres exponerlo a agentes y motores de búsqueda, PriceSpecification te permite registrar un precio de comparación por separado, de modo que el descuento sea explícito en lugar de estar implícito en un estilo tachado. Vale la pena usarlo si tu plataforma lo soporta, en vez de dejar el precio "antes" como texto sin estructurar junto al precio "ahora".

Un detalle que conviene señalar: los agentes no esperan de forma fiable a animaciones, descuentos con cuenta atrás o scripts de "el precio baja en tu carrito". Si el precio real solo aparece después de que el cliente añade el artículo al carrito, indica el precio del carrito en tu schema, no el precio de estantería antes del descuento, o el agente transmitirá el número equivocado.

Precios de packs, suscripciones y tiendas multidivisa

El precio estándar de un solo SKU es el caso fácil. Un puñado de situaciones provoca la mayoría de los errores restantes que vemos.

El hilo común en los seis casos es que el agente no tiene forma de deducir la intención a partir del diseño. Una persona que lee "3 por $45" entiende la oferta al instante. Un parser que lee esas mismas tres palabras necesita que el $45 esté explícitamente ligado a la cantidad de tres en los datos subyacentes, o informará $45 como el precio de una unidad.

El precio por variante afecta a tiendas que por lo demás tienen un marcado limpio. Un único nodo Product con un Offer y un precio de $40 parece correcto hasta que un comprador le pregunta a un agente por la talla que en realidad cuesta $52.

Si tus variantes están modeladas como un ProductGroup con entradas Offer individuales por hasVariant, el agente puede resolver el SKU correcto. Si están modeladas como un solo producto con un desplegable que cambia el precio del DOM mediante JavaScript, el agente citará el precio que se cargó primero, normalmente la variante más barata, y ese es el número que le repite al comprador sin importar por cuál preguntó.

La visualización de impuestos causa una versión más silenciosa del mismo problema. Una tienda que muestra precios con impuestos incluidos en la página pero expone una cifra sin impuestos en el schema hará que un agente cite con total seguridad un número menor al que el comprador paga en el checkout. Es la misma causa raíz que el problema de costes tardíos documentado por Baymard en su investigación sobre checkout, solo que aflora antes, en el momento en que un agente lee la página en vez de cuando una persona llega al pago.

Si no tienes claro si los agentes pueden siquiera descubrir estas páginas antes de llegar al problema de precios, ese es un punto de fallo distinto y anterior, que cubrimos en nuestra checklist de rastreabilidad para agentes de compras con IA. El formato del precio solo importa una vez que la página ha sido encontrada y descargada.

Preguntas que nos hacen

¿Puede ChatGPT leer bien los precios rebajados?

Solo cuando el precio rebajado es explícito en los datos estructurados de la página o está claramente separado del precio original en el texto renderizado. Si la única señal es un estilo tachado sobre el precio original, sin etiqueta ni campo de schema que lo acompañe, ChatGPT y agentes similares citan con frecuencia el número tachado, el número con descuento o un promedio de ambos, porque ninguna de esas pistas visuales sobrevive igual al texto plano o al marcado.

¿El precio tiene que estar en el marcado schema?

No tiene por qué, pero debería. Los agentes que revisan primero los datos Offer de schema.org obtienen un precio y una moneda precisos y tipados sin adivinar. Sin eso, recurren al texto visible en el DOM, que es mucho más propenso a incluir formatos ambiguos, varios números candidatos o un precio que aún no ha terminado de cargarse.

¿Por qué mi precio aparece vacío para los agentes con IA?

Casi siempre significa que el precio se inyecta con JavaScript después de la respuesta HTML inicial, y la descarga del agente o no ejecuta ese script o agota el tiempo antes de que termine. La solución es renderizar el precio en el servidor, dentro del HTML que se devuelve en la primera petición, para que esté presente independientemente de si luego se ejecuta un script.

¿La selección de variantes, como talla o color, también afecta a la exactitud del precio?

Sí, y es uno de los casos límite más comunes que vemos. Si tu página de producto usa un solo Offer para todas las variantes y actualiza el precio visible con JavaScript según la selección de un desplegable, un agente que lea el schema inicial encontrará el precio presente en la carga, que suele ser el de la variante base o la más barata. Estructurar las variantes como un ProductGroup con un Offer distinto por SKU resuelve esto de raíz.

¿El schema debe mostrar precios con o sin impuestos?

El número que el comprador realmente paga en el checkout, indicado de forma explícita y no implícito por convención regional. Si tu checkout añade impuestos sobre el precio mostrado, ese es el mismo problema de revelación tardía que Baymard ha vinculado al carrito abandonado, solo que ocurriendo a nivel de schema en lugar de en el paso de pago. Usa campos priceSpecification para indicar si el impuesto está incluido, en vez de dejar que un agente lo adivine según el país de tu tienda.

¿Esto también afecta a los resultados de Google Shopping, no solo a los agentes conversacionales?

Sí. La guía de datos estructurados de Google para productos aplica tanto a sus superficies de shopping como de búsqueda, y los mismos campos Offer.price y priceCurrency que corrigen las citas erróneas de los agentes son los que usa el Shopping Graph de Google para validar fichas. Una discrepancia de precio entre tu schema y tu checkout puede hacer que una ficha se suprima por completo, no solo que se cite mal.