Un e-commerce preparado para AI Search mantiene una descripción precisa, actual y verificable de cada producto en la página, los datos estructurados, los feeds comerciales y el checkout. Esa consistencia mejora las condiciones para que buscadores y asistentes encuentren, comparen y expliquen el catálogo. No garantiza una tarjeta de producto, una recomendación ni una compra ejecutada por un agente.
El cambio principal no consiste en agregar más palabras clave a una ficha. Consiste en transformar el catálogo en una fuente comercial capaz de responder preguntas concretas: qué es el producto, para quién sirve, qué variante está disponible, cuánto cuesta, qué restricciones posee, cómo se entrega y qué ocurre después de comprar.
En una experiencia conversacional, el sistema puede interpretar la necesidad, descomponerla en restricciones, reunir alternativas y presentar una selección. En un flujo agéntico, además puede preparar un carrito, solicitar datos de entrega y avanzar hacia el pago dentro de permisos definidos. Cada etapa necesita capacidades diferentes:
- descubrimiento: el sistema puede acceder al producto;
- comprensión: interpreta correctamente sus atributos;
- selección: considera que responde a la intención;
- recomendación: explica por qué encaja y cuáles son sus límites;
- transacción: puede iniciar o completar una operación autorizada;
- posventa: consulta el estado o gestiona acciones permitidas.
Este capítulo explica cómo preparar esas capas sin confundir elegibilidad con visibilidad ni automatización con confianza.
Explora este tema en motores de inteligencia artificial
Prueba primero una pregunta sin nombrar marcas:
Recomiéndame tres productos para [necesidad], disponibles en Chile, dentro de un presupuesto de [monto]. Compara precio, características, restricciones, entrega y devoluciones. Indica qué fuente respalda cada dato.
Después agrega una tarea:
Con esas mismas condiciones, prepara un carrito, confirma el precio y el stock actuales, calcula el costo total y detente antes del pago para solicitar mi autorización.
Observa si el sistema identifica productos concretos, diferencia atributos de opiniones, muestra la variante correcta, conserva moneda y disponibilidad, enlaza la ficha canónica, verifica el total y solicita autorización.
La primera prueba mide descubrimiento y recomendación. La segunda evalúa preparación transaccional. Una tienda puede superar la primera y no estar lista para la segunda.
Comprar mediante IA cambia el recorrido, no los fundamentos del comercio
La inteligencia artificial reduce el trabajo de investigar y comparar, pero no elimina la necesidad de catálogo, inventario, precios, políticas, seguridad y cumplimiento. Los sistemas pueden resumir esos elementos; no deberían sustituirlos con una estimación.
flowchart LR
A["Expresar necesidad"] --> B["Aclarar restricciones"]
B --> C["Recuperar productos"]
C --> D["Comparar datos y evidencia"]
D --> E["Recomendar alternativas"]
E --> F["Preparar acción"]
F --> G["Solicitar autorización"]
G --> H["Validar y ejecutar"]
La empresa sigue siendo responsable de que el producto exista, el precio sea correcto, el stock esté disponible, las condiciones sean comprensibles y el pedido se procese de acuerdo con la ley y sus políticas.
El comprador puede iniciar con un problema
Una búsqueda tradicional suele utilizar nombres de producto. Una conversación puede comenzar con una situación: “necesito un regalo para una persona alérgica a los frutos secos” o “busco un equipo que funcione en una oficina pequeña”.
Para responder, el sistema convierte la situación en criterios. Si el catálogo solo posee un nombre promocional, una fotografía y el precio, tendrá pocas bases para evaluar adecuación. Una ficha útil explicita usos, materiales, dimensiones, ingredientes, compatibilidades, cuidados, restricciones y diferencias entre variantes.
La comparación ocurre antes del clic
Cuando una respuesta sintetiza varias opciones, el producto compite dentro de una tabla o recomendación redactada por un tercero. “Edición premium” es una afirmación vaga. “Incluye 24 unidades de 8 gramos, contiene leche y se entrega en una caja de 192 gramos” es una descripción contrastable.
El checkout puede convertirse en una capacidad
En comercio agéntico, el checkout deja de ser solamente una secuencia visual. Puede exponerse como una capacidad controlada para crear una sesión, consultar el total, seleccionar entrega y completar una orden. Esto exige contratos técnicos, autenticación, firmas, idempotencia, validación en servidor y estados explícitos. No se resuelve con Schema.org ni con un chatbot.
Qué es el comercio agéntico
El comercio agéntico es un modelo en el que un sistema de inteligencia artificial puede asistir o actuar durante una compra en representación de una persona, dentro de permisos, políticas y controles definidos. El agente puede investigar, comparar, preparar una selección o ejecutar pasos autorizados. El alcance depende de la plataforma, el comercio, el medio de pago, el mercado y el consentimiento.
No toda recomendación es comercio agéntico. Mostrar una tarjeta con imagen y enlace continúa siendo descubrimiento. Crear un carrito es una acción. Completar un pago es una acción de mayor riesgo.
| Nivel | Capacidad | Datos necesarios | Control mínimo |
|---|---|---|---|
| 1. Descubrir | encontrar una ficha | URL, nombre, descripción e imagen | rastreo e indexabilidad |
| 2. Comprender | interpretar el producto | atributos, entidades y variantes | coherencia semántica |
| 3. Comparar | evaluar alternativas | criterios equivalentes y datos actuales | fuente y fecha |
| 4. Recomendar | justificar una opción | adecuación, límites y evidencia | transparencia |
| 5. Preparar | crear selección o carrito | ID, cantidad, precio, stock y entrega | sesión e idempotencia |
| 6. Comprar | autorizar y completar | identidad, pago, impuestos y consentimiento | seguridad y confirmación |
| 7. Gestionar | consultar o modificar una orden | estado, reglas y credenciales | trazabilidad |
La preparación debe evaluarse por nivel. Un sitio no necesita habilitar transacciones agénticas para mejorar la comprensión de su catálogo.
Elegibilidad, recomendación y transacción son capas distintas
Que un producto pueda ser leído no significa que será elegido; que sea recomendado no significa que un agente pueda comprarlo.
Capa 1: acceso y elegibilidad
El producto necesita una URL accesible, rastreable y canónica. La información principal no debería quedar bloqueada por autenticación, robots, estados incorrectos ni una interfaz que solo revele datos después de ejecutar código frágil.
Los datos estructurados y feeds amplían la información disponible. Su presencia no obliga a mostrar el producto.
Capa 2: relevancia y recomendación
El sistema puede comparar la intención con atributos, disponibilidad, precio, calidad de la fuente, opiniones y contexto. La selección varía entre personas, mercados, sesiones y plataformas.
Una descripción rica y consistente mejora la capacidad de evaluar el producto. No garantiza que sea la mejor alternativa.
Capa 3: acción y transacción
Para avanzar hacia una compra, el agente necesita capacidades operativas: consultar inventario, crear una sesión, calcular totales, autenticar a la persona y comunicar la orden.
Esta capa utiliza APIs, protocolos e integraciones. El JSON-LD no autoriza un cobro y un feed no sustituye al backend.
flowchart TD
A["Producto accesible"] --> B["Producto comprensible"]
B --> C["Producto elegible"]
C --> D["Producto recuperado"]
D --> E["Producto considerado"]
E --> F["Producto recomendado"]
F --> G["Acción disponible"]
G --> H["Acción autorizada"]
H --> I["Compra validada"]
La ficha debe ser la fuente primaria del producto
La página de detalle debe expresar de forma visible la información que el comercio declara en feeds y datos estructurados. El comprador, el buscador y la IA no deberían recibir versiones incompatibles.
Una ficha preparada incluye:
- nombre descriptivo y estable;
- marca y fabricante cuando corresponda;
- identificadores reales;
- descripción directa;
- imágenes representativas;
- precio y moneda;
- disponibilidad y condición;
- variantes y atributos diferenciadores;
- materiales, ingredientes o componentes;
- dimensiones, peso o capacidad;
- compatibilidad y requisitos;
- restricciones, advertencias y alérgenos;
- entrega, cambios, devoluciones y garantía;
- preguntas específicas y opiniones auténticas;
- mecanismo de actualización.
El objetivo no es llenar todos los campos posibles. Es declarar los atributos que ayudan a decidir y que pueden mantenerse.
El nombre debe identificar
Un nombre como “Experiencia Suprema” puede funcionar en campaña, pero no explica categoría, formato ni variante. Una estructura útil combina:
tipo de producto + atributo diferenciador + formato o variante + marca
Chocolate de origen 70% cacao, barra de 80 g — Marca Ejemplo
El nombre no necesita convertirse en una lista de palabras clave. Debe ser estable entre ficha, feed, inventario y checkout.
La descripción debe responder qué es, para quién y bajo qué condiciones
La primera frase puede aplicar BLUF:
Esta barra contiene 70% de cacao, pesa 80 gramos y está dirigida a personas que prefieren sabores intensos con notas tostadas.
Después se amplían ingredientes, alérgenos, origen, conservación, textura y entrega. Si existe posibilidad de contaminación cruzada, debe declararse. Si una certificación no fue otorgada, no debe inferirse.
Los beneficios necesitan anclaje
“Ideal para viajar” es más útil cuando se explica por qué:
El producto pesa 420 gramos y mide 18 × 10 × 4 centímetros. Ese formato permite transportarlo en un bolso pequeño sin utilizar un contenedor adicional.
La segunda oración interpreta el dato sin convertirlo en garantía universal.
La identidad evita mezclar productos y variantes
Cada artículo necesita identificadores estables que permitan distinguirlo y reconocerlo a través de sistemas.
Pueden incluir SKU interno, GTIN o ISBN cuando existan, MPN, marca, URL canónica, ID de grupo, ID de variante y atributos como color, talla, sabor o material. No se debe inventar un GTIN para completar el marcado.
Producto, oferta y variante no son lo mismo
El producto describe el artículo. La oferta expresa precio, moneda, disponibilidad, condición y vendedor. La variante representa una versión comprable con atributos propios.
Dos tamaños pueden compartir marca y descripción general, pero poseen SKU, precio, peso y stock diferentes. La interfaz, el marcado y la orden deben señalar cuál fue seleccionada.
ProductGroup representa familias
La documentación de variantes de Google explica el uso de “ProductGroup”, “variesBy”, “hasVariant” y “productGroupID”.
La implementación depende de si las variantes viven en una URL o en páginas separadas. En ambos casos, cada alternativa debe tener un destino identificable y la información debe coincidir con la opción seleccionada.
El modelo C.A.T.Á.L.O.G.O. de LOBIK
C.A.T.Á.L.O.G.O. es un marco de LOBIK para evaluar si la información puede descubrirse, compararse y utilizarse sin contradicciones. No es una especificación de plataforma ni garantiza inclusión.
C — Consistencia
Precio, moneda, stock, nombre, variante y políticas coinciden entre página, marcado, feed, carrito y checkout.
A — Atributos
El producto posee datos suficientes para responder preguntas reales. Un alimento requiere ingredientes y alérgenos; un dispositivo necesita compatibilidad; una prenda necesita talla y material.
T — Trazabilidad
Cada dato tiene fuente y propietario. La empresa sabe qué sistema modifica el precio, quién actualiza imágenes y dónde se registra una política.
Á — Actualización
La información dinámica posee frecuencia y mecanismo de sincronización. El inventario no depende de editar manualmente cinco lugares.
L — Legibilidad
La ficha utiliza HTML semántico, texto claro, tablas accesibles y contenido crítico disponible sin interacción frágil.
O — Oferta
La oferta expresa costo, moneda, disponibilidad y condiciones. Descuentos y promociones poseen fechas y reglas.
G — Gobernanza
El catálogo tiene políticas para reseñas, afirmaciones, certificaciones, privacidad, devoluciones, errores y contenido generado por IA.
O — Operabilidad
Cuando existen acciones, el servidor valida producto, cantidad, precio, entrega, pago y estado. La operación es idempotente, observable y recuperable.
Página, JSON-LD, feed y checkout deben coincidir
La tienda necesita una fuente operacional de verdad y varias representaciones sincronizadas, no fuentes independientes.
flowchart TD
PIM["Catálogo o PIM"] --> PDP["Ficha de producto"]
PIM --> JSON["JSON-LD Product y Offer"]
PIM --> FEED["Feeds comerciales"]
PIM --> API["Índice y API de catálogo"]
INV["Inventario y precios"] --> PIM
INV --> CART["Carrito y checkout"]
PDP --> CART
CART --> ORDER["Pedidos y posventa"]
La página comunica
La ficha responde objeciones, muestra el producto y permite comprar. Es la fuente primaria sobre la oferta de la empresa.
JSON-LD clasifica
“Product”, “Offer” y, cuando corresponde, “ProductGroup” expresan entidades y relaciones. Deben reflejar el contenido visible. No se utilizan para publicar reseñas, precios o stock imposibles de comprobar.
La guía oficial de Google indica que el marcado puede dar elegibilidad a experiencias enriquecidas, cuya presentación queda a discreción de sus sistemas.
El feed distribuye
Un feed publica identificadores, títulos, imágenes, precio, stock y enlaces bajo las reglas de una plataforma. Para Google, la información puede entregarse mediante marcado, Merchant Center o ambos. La combinación amplía elegibilidad y verificación; no obliga a mostrar el producto.
El checkout decide
Antes de cobrar, el servidor vuelve a comprobar variante, cantidad, precio, moneda, descuento, inventario, impuestos, entrega, identidad, autorización, medio de pago y total.
Cómo estructurar Product y Offer
El JSON-LD debe generarse desde los datos que renderizan la ficha. Escribir valores manualmente en una plantilla produce divergencias.
Una implementación puede expresar nombre, descripción, imagen, SKU, marca, URL y una oferta con precio, moneda, disponibilidad y condición. Según la categoría, se amplía con envío, devoluciones, dimensiones, identificadores, variantes y valoraciones válidas.
No existe un “schema para IA” que sustituya estas entidades. Schema.org describe información; cada plataforma decide qué propiedades utiliza.
Las valoraciones deben ser reales
“AggregateRating” no se agrega para decorar el resultado. Debe corresponder a reseñas auténticas y visibles. Si no existen, se omite.
El schema de la portada no enumera todo el catálogo
Cada ficha describe su producto. La portada puede representar la organización y productos destacados, pero no necesita insertar cientos de artículos en un único grafo.
Las imágenes de Cloudinary pueden utilizarse
Una imagen alojada en Cloudinary u otro CDN es válida si su URL es estable, accesible y representa el producto correcto.
Buenas prácticas:
- HTTPS y URLs estables;
- rastreo permitido;
- resolución suficiente;
- variante correcta;
- texto alternativo descriptivo;
- poco texto promocional sobre la imagen;
- varios ángulos cuando aportan;
- coherencia entre página, marcado y feed.
El nombre del archivo ayuda a administrar, pero no compensa una imagen deficiente. “chocolate-origen-70-80g-frente.webp” es más claro que un identificador opaco, aunque el sistema también necesita título, alt y atributos.
Una imagen muestra textura o escala; un video demuestra uso; un documento aporta ficha técnica. Cada medio necesita contexto textual para que la información importante no quede encerrada en el recurso.
Los datos conversacionales describen decisiones
Un catálogo preparado para conversaciones responde preguntas que normalmente resolvería una persona de ventas.
| Pregunta | Dato | Fuente | Representación |
|---|---|---|---|
| ¿Sirve para exterior? | resistencia y uso | ficha técnica | página y atributo |
| ¿Contiene alérgenos? | ingredientes y advertencias | calidad | página y feed |
| ¿Es compatible? | modelos y requisitos | ingeniería | tabla y atributo |
| ¿Cuándo llega? | stock y transporte | logística | oferta y checkout |
| ¿Puedo devolverlo? | plazo y condiciones | política | página y marcado |
| ¿Qué variante necesito? | criterio de selección | catálogo | guía y ProductGroup |
Google ha documentado atributos conversacionales adicionales en Merchant Center. Su disponibilidad puede cambiar. La empresa debe aplicar solo atributos compatibles con su cuenta, mercado y categoría.
Reseñas y relaciones aportan contexto
Las opiniones muestran experiencia, pero no sustituyen especificaciones. Una reseña de calidad explica el uso, la variante, el tiempo, lo que funcionó y la limitación encontrada.
La tienda distingue entre afirmación oficial, experiencia del cliente, resumen generado, recomendación editorial y contenido patrocinado. No debe comprar reseñas, inventar autores, duplicar textos ni convertir una experiencia en garantía.
Los productos relacionados también necesitan contexto:
- complemento: se utiliza junto con el producto;
- alternativa: resuelve una necesidad similar;
- progresión: representa una versión de entrada o avanzada.
La funda A es compatible con los modelos X e Y. No es compatible con Z porque la cámara está en otra posición.
Esa relación reduce errores mejor que “también te puede gustar”.
Cómo pueden aparecer productos en Google y ChatGPT
Cada plataforma combina fuentes, criterios y experiencias propias; ninguna implementación garantiza una tarjeta o una posición.
La documentación de Google Search señala que los datos pueden habilitar presentaciones enriquecidas en Search, Images y Lens. Utilizar datos estructurados y Merchant Center puede maximizar elegibilidad y ayudar a verificar la información.
La base práctica es ficha canónica, “Product” y “Offer” válidos, Merchant Center cuando corresponda, feed actualizado, políticas coherentes, imágenes accesibles, sitemap y monitoreo.
ChatGPT
ChatGPT puede presentar productos cuando detecta intención de compra y considera que responden a la consulta. Los datos pueden provenir de sitios públicos, proveedores comerciales o feeds directos habilitados.
Los mecanismos de feed y checkout dependen de documentación, elegibilidad, políticas y disponibilidad vigentes. Un archivo “products.json”, “llms.txt” o el marcado Schema.org no inscribe automáticamente el catálogo.
La empresa debe mantener fichas accesibles, datos actuales, identificadores coherentes, imágenes recuperables, ausencia de contradicciones y cumplimiento de los programas oficiales disponibles.
Una tarjeta no es la meta final
Debe comprobarse si el producto era pertinente, si la descripción fue correcta, si la variante existía, si el precio coincidía, si la fuente era la tienda y si la interacción generó una visita o compra válida.
UCP, MCP, A2A y ACP cumplen funciones distintas
| Concepto | Función | Aplicación | No garantiza |
|---|---|---|---|
| UCP | estandarizar comercio | capacidades, checkout y órdenes | ranking |
| MCP | conectar contexto y herramientas | consultar catálogo o actuar | autorización automática |
| A2A | coordinar agentes | delegación entre sistemas | identidad por sí solo |
| ACP | habilitar flujos comerciales compatibles | agente, comercio y pago | presencia orgánica |
| Schema.org | describir entidades | producto, oferta y variante | ejecución |
Google presenta Universal Commerce Protocol como un estándar abierto y evolutivo que puede utilizar APIs, A2A o MCP.
La guía de Google aclara que no todas las capacidades están disponibles en sus superficies y que la integración exige Merchant Center, aprobación, un perfil, endpoints y sincronización de órdenes.
No conviene implementar un protocolo solo para declarar que la tienda está “lista para agentes”. Primero se define caso, mercado, elegibilidad, riesgo y beneficio.
Un checkout agéntico debe validar más
La automatización aumenta la necesidad de controles porque el comprador puede no ver cada pantalla intermedia.
stateDiagram-v2
[*] --> Borrador
Borrador --> Cotizado: validar producto y entrega
Cotizado --> AutorizacionPendiente: mostrar total
AutorizacionPendiente --> Autorizado: consentimiento
AutorizacionPendiente --> Cancelado: rechazo
Autorizado --> Procesando: pago tokenizado
Procesando --> Confirmado: orden única
Procesando --> Fallido: error
Confirmado --> Enviado
Confirmado --> Reembolso: política aplicable
El total se calcula en servidor. La idempotencia evita cobros duplicados. La autorización indica qué se compra, por cuánto y bajo qué condiciones. El pago utiliza proveedores y tokens; no expone tarjetas en prompts. La orden registra solicitud, agente, usuario, cotización, consentimiento, pago, estado, cambios y errores.
Arquitectura Headless y comercio agéntico
Headless puede facilitar la reutilización del catálogo y las capacidades, pero no convierte automáticamente una tienda en agent-ready.
La arquitectura puede separar experiencia web, catálogo, inventario, precios, promociones, carrito, checkout, pagos, órdenes, logística, CRM y analítica. Así, un agente consulta un producto o crea un borrador sin entrar al panel administrativo.
Una plataforma monolítica también puede integrarse si ofrece APIs, feeds, webhooks y controles. “Headless” no es garantía de velocidad, posicionamiento ni seguridad.
Auditoría de preparación
Catálogo y fichas
- productos y variantes inventariados;
- IDs estables;
- URL canónica;
- atributos críticos visibles;
- estados activo, agotado y discontinuado;
- variantes consistentes.
Datos y feeds
- “Product”, “Offer” y “ProductGroup” correctos;
- valores coincidentes;
- reseñas reales;
- feed actual;
- imágenes recuperables;
- rechazos monitoreados.
Rastreo y recuperación
- fichas con status 200;
- sitemap actualizado;
- filtros y duplicación controlados;
- preguntas sin marca;
- productos y atributos citados;
- fuentes y competidores registrados.
Transacción
- precio revalidado;
- inventario reservado;
- idempotencia;
- autorización explícita;
- pago seguro;
- orden auditable;
- fallos y reversión.
Cómo medir la visibilidad de productos en IA
La medición combina cobertura, exactitud, posición relativa y resultado comercial.
Métricas:
- porcentaje rastreable e indexado;
- cobertura de marcado y feed;
- tasa de aprobación;
- cobertura de preguntas con productos de la marca;
- Share of Voice por categoría;
- Top 1 y Top 3;
- citación de la ficha canónica;
- precisión de atributos, precio y stock;
- estabilidad entre repeticiones;
- clic, carrito, checkout, venta y margen;
- sesiones agénticas, autorización, errores, duplicados evitados y devoluciones.
La metodología completa se desarrolla en Cómo medir visibilidad en IA.
Hoja de ruta
- Normalizar: IDs, grupos, variantes y propietarios.
- Fortalecer fichas: BLUF, contenido atómico, tablas, políticas y medios.
- Generar JSON-LD: desde la fuente del catálogo.
- Sincronizar feeds: publicar, revisar rechazos y controlar latencia.
- Medir recuperación: preguntas por necesidad, presupuesto y restricción.
- Mejorar confianza: reseñas, políticas, soporte y evidencia.
- Pilotear acciones: comenzar por consultar stock o preparar carrito.
- Habilitar checkout: solo con elegibilidad, seguridad y pruebas.
Errores frecuentes
- fichas casi idénticas;
- nombres sin categoría;
- una imagen para variantes diferentes;
- stock desactualizado;
- precios distintos en feed y carrito;
- atributos dentro de imágenes;
- reseñas inventadas;
- GTIN o certificaciones falsos;
- catálogo completo en el schema de la portada;
- “llms.txt” tratado como feed;
- endpoint sin autenticación;
- precio enviado por el agente;
- pago sin autorización;
- promesas de recomendación;
- una captura presentada como Share of Voice.
Preguntas frecuentes
- ¿Qué es un e-commerce preparado para AI Search?
- Es una tienda cuyo catálogo, fichas, datos estructurados, feeds y condiciones mantienen información clara, accesible y coherente. Facilita que buscadores y asistentes identifiquen productos, pero no garantiza que los muestren.
- ¿Qué es el comercio agéntico?
- Es un modelo en el que un agente asiste o ejecuta pasos de compra en nombre de una persona dentro de permisos definidos. El comercio conserva responsabilidad sobre precio, pago, orden, entrega y posventa.
- ¿Cómo hacer que mis productos aparezcan en ChatGPT?
- Publica fichas accesibles y actuales, utiliza identificadores e imágenes coherentes y sigue los mecanismos oficiales disponibles para comerciantes. La aparición depende de relevancia, elegibilidad, políticas, mercado y consulta.
- ¿Schema.org genera tarjetas automáticamente?
- No. Describe productos, ofertas y variantes, pero no obliga a una plataforma a crear una tarjeta. Debe combinarse con acceso, feeds, actualidad y una oferta confiable.
- ¿Debo agregar JSON-LD a cada producto?
- Sí, cada ficha comprable debería representar el producto y la oferta con datos reales y visibles. Las variantes pueden requerir “ProductGroup”. El marcado debe generarse desde el catálogo.
- ¿Cuál es la diferencia entre feed y JSON-LD?
- JSON-LD describe una página; un feed distribuye catálogo a una plataforma. Pueden compartir la misma fuente, pero cumplen funciones distintas.
- ¿UCP está disponible para todas las tiendas en Chile?
- No debe asumirse. Es un estándar en evolución y la implementación de Google requiere aprobación y capacidades compatibles. Primero se fortalece catálogo, feed y backend; después se verifica elegibilidad.
- ¿Puedo usar imágenes de Cloudinary?
- Sí. Deben tener URLs HTTPS estables, ser rastreables, poseer buena resolución y corresponder al producto y variante.
- ¿Cómo evitar precios incorrectos?
- Centraliza el precio, sincroniza página, marcado y feed, y vuelve a validarlo en checkout. Antes de cobrar, el backend presenta el total actual y solicita autorización.
- ¿Una tienda Headless ya está lista para agentes?
- No. Headless facilita APIs y reutilización de datos, pero todavía necesita seguridad, estados, permisos, pagos, gobernanza y operación.
- ¿Cómo se mide la comprensión del catálogo?
- Se ejecuta un banco de preguntas sin marca y se compara la respuesta con la fuente oficial. Se miden productos, atributos, variantes, precio, stock, citas, estabilidad y errores.