El feed de producto como SEO para agentes de IA

El feed de producto es el archivo estructurado (XML, CSV o API) con el que tu tienda online envía su catálogo a Google Merchant Center y a otras plataformas, y hoy es también la fuente principal desde la que los agentes de IA leen tu stock, tu precio final y tus condiciones de envío y devolución. Si ese feed está incompleto o desactualizado, un asistente conversacional recomendará al competidor que sí tiene los datos completos, aunque tu ficha de producto sea mejor. Optimizar el feed se ha convertido, en la práctica, en una tarea de SEO y de GEO (Generative Engine Optimization, la optimización para motores generativos), no solo de Google Shopping.

Soy Oscar Álvarez, fundador de SEOscar, agencia de ecommerce en Barcelona. Llevo meses viendo lo mismo en las auditorías: tiendas que han invertido en contenido, en enlaces y en velocidad, y que tienen un feed de producto montado hace tres años, con el precio sin impuestos, el stock actualizado una vez al día y los campos de envío y devoluciones vacíos. Hasta hace poco eso solo te costaba rendimiento en Shopping. Ahora te cuesta visibilidad en los asistentes de IA, que es donde cada vez más gente empieza a buscar producto.

En este artículo te cuento qué es un feed de producto en términos prácticos, qué campos necesita un agente de IA para poder recomendarte, qué está moviendo Google con los atributos conversacionales en la Merchant API y cómo automatizar el feed para que no se rompa cada vez que cambias un precio. Todo desde lo que veo montando esto en Shopify, WooCommerce y Magento.

Por qué el feed de producto importa más que nunca

El feed de producto importa más que nunca porque los agentes de IA no rastrean tu tienda como un buscador clásico: consumen datos estructurados y fiables. Cuando un asistente tiene que responder "¿dónde compro unas botas impermeables talla 42 que lleguen antes del viernes?", necesita stock, talla, precio final y plazo de entrega en un formato que pueda leer sin interpretar HTML. Ese formato es el feed.

Un feed de producto es un archivo o una conexión por API que describe cada referencia de tu catálogo con campos normalizados: identificador, título, descripción, precio, disponibilidad, marca, GTIN, imagen, categoría, envío y devoluciones. En Google Merchant Center es la base de Shopping y de las fichas gratuitas de producto. Fuera de Google, es el formato que marketplaces, comparadores y cada vez más integraciones de IA esperan recibir.

La diferencia con hace dos años es la intención del consumidor del dato. Antes el feed alimentaba anuncios. Ahora alimenta decisiones automáticas. Si tu disponibilidad dice "in stock" y el producto no está, un agente que intente completar la compra fallará, y esa experiencia se paga. Por eso el feed ha dejado de ser una tarea del departamento de paid para convertirse en infraestructura de tienda.

Si quieres el marco completo de qué significa optimizar para motores generativos y en qué se diferencia del SEO de toda la vida, lo desarrollo en qué es GEO. Aquí me centro en la pieza concreta: los datos de catálogo.

El feed es la capa que conecta con el comercio agéntico

Comercio agéntico es la compra en la que un agente de IA investiga, compara y, en algunos casos, completa la transacción en nombre del usuario. Para que eso funcione, el agente necesita una fuente de verdad del catálogo que no dependa de interpretar una ficha visual. Las iniciativas que veo moverse en el sector, desde los protocolos de pago agéntico hasta las propuestas de carrito universal entre tiendas (el llamado Universal Cart), se apoyan todas en lo mismo: datos de producto estructurados, completos y actualizados.

Dicho de otra manera: puedes no tener opinión sobre el comercio agéntico y aun así necesitar un feed impecable, porque es el requisito de entrada a cualquiera de esas capas. Si el día que tu categoría se vuelve conversacional tu feed tiene el 40% de los campos vacíos, no hay forma rápida de arreglarlo.

Campos que un agente de IA necesita en tu feed de producto

Un agente de IA necesita, como mínimo, cuatro bloques de datos que muchas tiendas tienen incompletos: disponibilidad real, precio final con impuestos y promociones aplicadas, condiciones de envío con plazo y coste, y política de devoluciones. Sin esos cuatro, el agente no puede responder a la pregunta que de verdad hace el comprador, que casi nunca es solo "cuánto cuesta".

• Identificadores: id, GTIN o MPN y marca. Sin identificador fiable, tu producto no se puede casar con el mismo producto en otras fuentes y pierdes la comparación.

• Disponibilidad y cantidad: in stock, out of stock, preorder o backorder, con la frecuencia de actualización lo más alta que permita tu plataforma.

• Precio final: el precio que pagará el cliente, con impuestos según el mercado, más sale_price y las fechas de la promoción si la hay.

• Envío: coste, país y región, y plazo estimado de entrega separando tiempo de preparación y tiempo de tránsito.

• Devoluciones: plazo en días, quién paga el porte y si se admite devolución en tienda.

• Atributos del producto: talla, color, material, género, grupo de artículos (item_group_id) para las variantes y medidas cuando aplique.

• Descripción útil: texto que explique de verdad el producto, no una lista de palabras clave. El agente lo usa para decidir si encaja con la consulta.

En las tiendas que audito, el campo que falla más a menudo no es el precio: es el plazo de entrega. Muchas tiendas lo tienen escrito en una página de "Envíos y devoluciones" en HTML y no lo han llevado nunca al feed. Para un humano eso se resuelve con un clic. Para un agente, es un dato que no existe, y la recomendación se va a quien sí lo declara.

Cómo saber qué campos te faltan hoy

Entra en Google Merchant Center, abre la sección de diagnóstico y mira tanto los errores como las advertencias y las "mejoras sugeridas". Esa última pestaña es la que casi nadie revisa y es donde Google te lista los atributos opcionales que no estás enviando. Exporta el feed a una hoja de cálculo, cuenta celdas vacías por columna y prioriza por número de productos afectados y por margen. Es un trabajo de una tarde y suele dar más que muchas acciones de contenido.

Atributos conversacionales en Merchant Center: qué son y por qué mirarlos

Los atributos conversacionales son campos del feed pensados para que los sistemas de IA puedan responder preguntas abiertas sobre un producto, más allá de los datos transaccionales clásicos. Google los ha ido incorporando a la Merchant API, la interfaz de programación que sustituye progresivamente a la antigua Content API for Shopping, y publica los cambios en su página de novedades (developers.google.com/merchant/api/latest-updates).

La idea de fondo es sencilla. Una consulta conversacional no es "zapatillas running hombre 43", es "zapatillas para correr en asfalto si tengo pisada pronadora y peso 90 kilos". Para responder eso hacen falta atributos descriptivos que normalmente viven en tu ficha de producto y nunca han salido de ahí. Llevarlos al feed es el trabajo nuevo.

En esa misma línea, Google anunció en mayo de 2026 un servicio MCP para la Merchant API en fase alfa, según su propia página de novedades para desarrolladores. MCP (Model Context Protocol) es un protocolo que permite a un modelo de lenguaje conectarse a herramientas y fuentes de datos externas de forma estandarizada; si quieres entender el concepto con más detalle, lo explico en qué es RAG, la técnica hermana con la que los modelos consultan datos externos. Traducido al caso que nos ocupa: Google está preparando el camino para que un modelo pueda consultar datos de Merchant Center directamente. Es alfa, no es para producción, pero marca la dirección con bastante claridad.

Mi recomendación práctica, sin humo: no reconstruyas tu stack por un anuncio en alfa. Haz lo que ya es útil hoy y que además te deja preparado, que es rellenar todos los atributos descriptivos que tu catálogo permita. Material, uso recomendado, público, compatibilidades, medidas, certificaciones. Son datos que ya tienes en algún sitio, normalmente en el ERP o en la cabeza de quien compra el producto.

De dónde sacar esos atributos sin morir en el intento

Tres fuentes, por orden de rentabilidad. Primera, las fichas técnicas del proveedor, que casi siempre llegan en PDF o Excel y nadie ha normalizado. Segunda, las preguntas que te hacen por WhatsApp, email o el buscador interno de la tienda: ahí está literalmente el atributo que falta. Tercera, las devoluciones: si devuelven por talla, te falta una guía de tallas estructurada; si devuelven por "no era lo que esperaba", te faltan medidas o material.

En los proyectos donde montamos un agente de ventas IA pasa algo útil: el agente necesita exactamente los mismos datos que el feed, porque responde con el catálogo real de la tienda, no con respuestas genéricas. Al prepararlo, salen a la luz todos los huecos del catálogo de golpe. Es el mejor auditor de datos de producto que he encontrado.

Coherencia entre feed, ficha de producto y schema

El feed, la ficha de producto y el marcado schema.org deben decir exactamente lo mismo sobre precio, disponibilidad y envío. Cuando no coinciden, los sistemas automáticos pierden confianza en la fuente: Google puede desaprobar artículos por discrepancia de precio y un agente de IA que detecte contradicciones tenderá a recomendar una tienda cuyos datos sí cuadran. La coherencia no es un detalle técnico, es una señal de fiabilidad.

El fallo clásico que veo en WooCommerce: el plugin de feed coge el precio base y la ficha muestra el precio con una regla de descuento de otro plugin. Dos cifras distintas para el mismo producto. En Shopify el fallo suele estar en las variantes, con un item_group_id mal configurado que hace que cada talla viaje como producto independiente sin relación entre sí.

• Precio: el mismo número en Product/Offer de schema, en el HTML visible y en el campo price del feed, con la misma moneda e idéntico tratamiento de impuestos.

• Disponibilidad: si la ficha dice "últimas unidades", el feed no puede decir out of stock, ni al revés.

• Envío: declara shippingDetails en schema y los atributos de envío en el feed con el mismo plazo que anuncias en la ficha.

• Devoluciones: hasMerchantReturnPolicy en schema alineado con la política de devoluciones del feed y con tu página legal.

• Identificadores: el mismo GTIN en schema y en el feed. Si no lo tienes, mejor vacío que inventado.

Para comprobarlo no hace falta herramienta de pago: coge diez productos representativos, uno de cada tipo, y compara a mano las tres fuentes. Si fallan dos de diez, tienes un problema sistémico, no un caso aislado. Esa revisión es parte de lo que hacemos en una auditoría de SEO y GEO, porque hoy ya no tiene sentido separar la capa de contenido de la capa de datos de producto.

Automatizar el feed de producto para que no se rompa

Un feed de producto se rompe siempre por lo mismo: alguien cambia un precio, agota un stock o crea una categoría nueva, y el feed se regenera cada 24 horas o directamente se generó una vez y se quedó estático. La solución no es revisarlo a mano cada lunes, es automatizar la generación, la validación y la alerta. Tres piezas, no una.

1. Generación: que el feed salga de la fuente de verdad

En WooCommerce lo habitual es un plugin que genera un feed XML de producto (woocommerce xml product feed) para Google Shopping. Funciona, pero conviene revisar dos cosas: la frecuencia de regeneración, que en tiendas con stock vivo debería ser al menos cada pocas horas, y de dónde toma el precio, para que respete las reglas de descuento activas. En Shopify, el canal nativo de Google ayuda, aunque las variantes y los metacampos suelen necesitar mapeo manual.

Cuando el catálogo es grande o el stock lo manda un ERP, prefiero trabajar contra la Merchant API en lugar de contra un XML estático: empujas solo lo que cambia y actualizas disponibilidad y precio casi en tiempo real. Montamos ese tipo de integraciones sobre la plataforma que ya tiene el cliente, sea WooCommerce, Shopify o Magento, sin obligar a migrar nada.

2. Validación: reglas antes de publicar

Antes de que el feed llegue a Merchant Center conviene pasarlo por un conjunto de reglas propias. Las que uso siempre: precio mayor que cero, título por debajo del límite de caracteres, imagen accesible con respuesta 200, GTIN con dígito de control válido, disponibilidad presente, y variaciones de precio superiores a un porcentaje marcado como sospechosas. Si un producto incumple, no entra y se avisa.

3. Alertas: enterarte tú antes que Google

La parte que más tranquilidad da y menos cuesta montar. Un flujo en n8n, la herramienta de automatización de flujos que usamos en SEOscar, que descarga el feed cada hora, cuenta productos válidos, compara con el día anterior y avisa por Slack o email si la caída supera un umbral. Si un martes pasas de 4.200 a 2.900 productos activos, lo sabes en una hora y no en la revisión mensual.

Ese tipo de vigilancia es barata de construir y evita el escenario caro: dos semanas con media tienda fuera de Shopping y fuera de cualquier respuesta generativa. Lo detallo en automatizaciones, y el código y los flujos quedan en propiedad del cliente, como todo lo que entregamos.

Qué haría yo desde SEOscar en tu tienda

Empezaría por el diagnóstico con datos reales, que es la primera etapa de mi método de cuatro etapas. En la semana uno exportaría tu feed completo, mediría el porcentaje de relleno por atributo, cruzaría diez productos entre feed, ficha y schema, y revisaría la pestaña de mejoras sugeridas de Merchant Center. Con eso ya sabes dónde pierdes visibilidad y cuánto catálogo está afectado.

Después priorizaría por impacto: primero los productos con margen y demanda que tienen campos críticos vacíos, luego los atributos descriptivos que alimentan consultas conversacionales, y en paralelo montaría la validación y las alertas para que lo arreglado no se vuelva a romper. Nada de esto requiere cambiar de plataforma ni rehacer la tienda.

El mejor contenido del mundo no te salva si el dato que un agente necesita para recomendarte no está en ninguna parte.

Si quieres saber en qué estado real está tu feed de producto y qué se te está escapando en buscadores y en asistentes de IA, reserva un diagnóstico. El plan que sale de ahí es tuyo, trabajes luego conmigo o no.

Preguntas frecuentes

¿Qué es un feed de producto y para qué sirve en 2026?

Un feed de producto es un archivo o conexión por API (XML, CSV o Merchant API) que describe cada referencia del catálogo de una tienda online con campos normalizados: identificador, título, precio, disponibilidad, marca, imagen, envío y devoluciones. Sirve para alimentar Google Merchant Center, marketplaces y comparadores. Hoy además es la fuente estructurada desde la que los agentes de IA leen stock, precio final y plazos de entrega para recomendar productos.

¿Qué campos del feed son imprescindibles para que un agente de IA pueda recomendar mi producto?

Los imprescindibles son identificador y GTIN o MPN, título y descripción útiles, precio final con impuestos, disponibilidad real, coste y plazo de envío, y política de devoluciones con plazo y porte. A partir de ahí suman mucho los atributos descriptivos como talla, color, material, uso recomendado y medidas. El campo que veo vacío con más frecuencia en las auditorías es el plazo de entrega.

¿Qué son los atributos conversacionales de Merchant Center?

Son campos del feed orientados a que los sistemas de IA puedan responder preguntas abiertas sobre un producto, más allá de los datos transaccionales clásicos como precio y stock. Google los ha ido incorporando a la Merchant API y documenta los cambios en su página de novedades para desarrolladores. En la práctica consisten en llevar al feed los atributos descriptivos que hoy solo viven en la ficha de producto.

¿Cómo creo un feed XML de producto en WooCommerce para Google Shopping?

Lo más habitual es usar un plugin de feed XML que genere el archivo y lo publique en una URL que conectas a Google Merchant Center. Al configurarlo revisa dos puntos críticos: la frecuencia de regeneración, que en tiendas con stock vivo debería ser de pocas horas, y el origen del precio, para que respete las reglas de descuento activas y coincida con el que ve el cliente en la ficha.

¿Por qué mi feed y mi ficha de producto muestran precios distintos y qué consecuencias tiene?

Suele ocurrir porque el generador del feed toma el precio base del producto mientras la ficha aplica una regla de descuento gestionada por otro módulo o plugin. Las consecuencias son dos: Google puede desaprobar los artículos por discrepancia de precio, y los sistemas de IA pierden confianza en tus datos y tienden a recomendar tiendas cuya información sí es coherente entre feed, ficha y schema.

¿Cómo evito que el feed de producto se rompa sin darme cuenta?

Con tres piezas: generación automática desde la fuente de verdad del stock, un conjunto de reglas de validación previas a la publicación (precio mayor que cero, imagen accesible, disponibilidad presente, GTIN válido) y alertas automáticas. En SEOscar montamos un flujo en n8n que descarga el feed cada hora, compara el número de productos válidos con el día anterior y avisa si la caída supera un umbral.

¿Hay que esperar al MCP de la Merchant API para empezar a optimizar el feed?

No. El servicio MCP de la Merchant API se anunció en fase alfa en mayo de 2026 y no es algo sobre lo que convenga rediseñar tu stack ahora mismo. Lo rentable hoy es completar todos los atributos que tu catálogo permita y garantizar la coherencia entre feed, ficha y schema, porque es trabajo que ya mejora Shopping y te deja preparado para cualquier integración conversacional futura.