Por qué el feed de su producto es un activo de SEO (y quién debería poseerlo)

Históricamente, el feed de productos ha estado firmemente en el dominio de los equipos de PPC, y por una buena razón. Después de todo, durante décadas, los feeds han sido la base de las compras y el lado pago de esta ecuación es donde se ubican los mayores gastos e ingresos.

Para un SEO, bastaba con comprobar los resultados de compras de Google Search Console y Bob es tu tío.

Ya no.

Los feeds de productos se han convertido (no tan) silenciosamente en uno de los activos de datos estructuralmente más importantes en el comercio electrónico: pagos, orgánicos y ahora agentes. Dan forma a cómo Google interpreta las páginas de productos en todos los canales, cómo se resuelven las discrepancias entre diferentes puntos de productos y categorías y, cada vez más, cómo la IA evalúa y muestra los productos a los usuarios.

La transmisión ha superado la propiedad de un solo equipo porque su superficie se ha expandido. Y los equipos de SEO han estado en gran medida ausentes de la conversación.

La ironía es difícil de ignorar: la industria está obsesionada con duplicar nuestros sitios web en archivos Markdown y llm.txt, mientras descuida el único activo que Google menciona explícitamente en su nueva guía de búsqueda de IA generativa como crítico para la visibilidad del producto en las respuestas de IA: el Merchant Center (y por extensión, el feed).

Este artículo trata sobre por qué es necesario cambiar eso, qué sucede cuando mantenemos el status quo y cómo es ponerlo en práctica.

La Santísima Trinidad: 3 sistemas, 1 objetivo

En Search Central Live del año pasado, Google bromeó sobre esto. Agrega un estándar para unificar los estándares, solo para terminar con un lío aún mayor.

En lugar de un sistema unificado para comprender sus productos, Google en realidad administra tres capas distintas de datos que tienen diferentes reglas, diferentes estructuras y, por supuesto, diferentes equipos que los administran en el extremo organizacional.

Primero, tienes los feeds de productos. Estos son los archivos manuales a los que envía:

• Google Merchant Center (GMC) contiene sus atributos principales, como títulos, GTIN y precios.
• El Manufacturer Center que contiene información de producto más rica y detallada

Se trata de una estructura de datos paralela que existe de forma totalmente independiente de su sitio web.

Lo siguiente son los datos estructurados en la página. Por lo general, se trata de un marcado JSON-LD escondido en su código, diseñado principalmente como un punto de verificación del feed, pero que también impulsa directamente algunos de los ricos resultados del comercio electrónico. Y Schema.org tampoco es el único actor en la ciudad. Esto surgió repetidamente en Search Central Live el año pasado, donde Google hizo referencia explícita a GS1, UN/CEFACT y otras ontologías.

Finalmente, está el sitio web en sí. Esta es la página renderizada real que ve un humano o la versión legible por máquina que ve un agente, que verificó con las otras dos fuentes.

La fricción proviene del hecho de que estos sistemas se rigen por reglas diferentes y los humanos y las máquinas los interpretan de manera diferente.

Google es muy consciente de que esta configuración es un dolor de cabeza. En 2024, incluso discutieron la posibilidad de unificar el marcado del esquema y los datos del feed para simplificar la forma en que los comerciantes brindan información. El objetivo era avanzar hacia un sistema de procesamiento más integrado.

Hasta que esa unificación realmente ocurra, estarás atrapado administrando tres capas separadas. Y ese es el problema.

Una y otra vez, vemos marcas con feeds en completo desorden, con esquemas que dicen algo completamente diferente y un sitio web que contradice ambos. Esto obliga a Google (y a los agentes) a tomar una decisión.

Por lo general, esa llamada no resulta a tu favor.

La precisión en los tres ya no es sólo algo “bueno de tener”; es la base para ser reconocible y adquirible. Y la falta de armonía entre ellos puede hundir los resultados de su negocio.

Cuando todo sale mal

Cualquiera que trabaje en comercio electrónico ha visto una larga lista de problemas que surgen de esta trinidad impía.

Algunos son más fáciles de solucionar que otros porque caen en una carga mental compartida entre los equipos. Un excelente ejemplo de esto son los títulos de los productos alimentarios. Una y otra vez, los administradores de PPC utilizan títulos optimizados para SEO para modificar los feeds de sus productos mediante reglas o feeds complementarios. Entienden que el equipo de SEO ha pasado horas investigando palabras clave y ajustando el meta para adaptarlo a la intención de búsqueda.

Ese tipo de intercambio informal de conocimientos funciona bien cuando el activo ya se encuentra dentro del ámbito de competencia de ambos equipos.

Cuando un administrador de PPC ve un aumento de desaprobación, su instinto de diagnóstico se dirige naturalmente a los atributos del feed, la verificación rápida del sitio web, la estrategia de oferta, las infracciones de políticas… todo dentro de su dominio. Y eso no es una falta de habilidad; es una falla de alcance. La mayoría de las veces, arreglan lo que pueden ver, escalan lo que no pueden al desarrollo y el SEO nunca recibe la llamada. No porque la estructura haya fallado, sino porque ningún equipo de un solo canal tiene visibilidad de los tres de forma predeterminada.

Para ilustrar este punto, aquí hay dos ejemplos recientes de mi agencia de cómo esto se desarrolla en la práctica.

Desalineación de esquemas, feeds y sitios web

Hay atributos que es bueno tener y que pueden ayudar a que sus productos funcionen mejor en listados orgánicos y pagos.

Por ejemplo, supongamos que tiene una tienda de comercio electrónico que también vende vestidos de mujer a rayas. En esos productos, puede usar g:pattern en su feed y una propiedad Pattern Schema.org equivalente dentro del tipo de esquema de Producto. Agregarlo a ambos podría ayudarte un poco al aparecer en búsquedas como (vestido de mujer a rayas). O podría aparecer en esas búsquedas de todos modos. De todos modos, es probable que su sitio web o los títulos de feeds/esquemas tengan algunos datos sobre el patrón en el texto. Definitivamente, sus productos no serán rechazados en GMC si omite agregarlos al feed o al esquema.

El precio no es uno de esos campos que es bueno tener. Es un atributo esencial en su feed, marcado en sus datos estructurados y punto de información en su sitio web.

Recientemente, hemos notado en varios clientes de comercio electrónico hasta qué punto Google está tomando medidas enérgicas contra esto. Productos rechazados en GMC a izquierda, derecha y centro debido al desajuste de precios entre las tres capas.

Un ejemplo de ello es nuestro cliente que trabaja en muebles de oficina, cuyos productos comenzaron a ser rechazados en masa recientemente.

Productos como este, donde el sitio web decía £34,80, el precio en el feed principal era £34,80 GBP y el comerciante decidió que el precio era £33,54.

Y, cuando miramos el esquema, nos enfrentamos a un cuarto precio de £29.

El marcado de esquema en las páginas de productos generaba el precio sin IVA en lugar del precio final con IVA incluido, junto con un campo priceValidUntil.

Google utiliza un esquema para verificar y, a veces, sobrescribir los precios de los feeds mediante actualizaciones automáticas de artículos, razón por la cual se mostraba la cifra incorrecta en GMC y por qué todos esos productos terminaron en la lista de rechazados.

Este es el tipo de problema que sólo surge cuando alguien tiene visibilidad en ambos sistemas.

¡Y este es fácil de detectar! Las cosas se vuelven aún más complejas con campos que no tienen un esquema directo equivalente o tienen reglas diferentes.

Por ejemplo, campos como disponibilidad.

En un feed de GMC, Google acepta cuatro valores estándar:

• En stock
• Agotado
• Hacer un pedido
• Pedido pendiente

Tanto el pedido anticipado como el pedido pendiente requieren un atributo de fecha de disponibilidad: la fecha prevista en que el producto se enviará o estará disponible.

En el lado de Schema.org, el equivalente es la propiedad de disponibilidad en una Oferta, que utiliza un vocabulario diferente:

etcétera. Si los administra por separado (alimentación en un equipo, esquema en otro), las posibilidades de que no coincidan son altas.

Navegar por la brecha de variantes (item_group_id vs ProductGroup) es otro ejemplo aquí y probablemente una de las áreas más complejas de alinear. En gran parte porque los feeds y los datos estructurados los manejan a través de arquitecturas completamente diferentes.

En un feed de Google Merchant Center, las variantes de productos se envían como una lista plana, unidas por un item_group_id compartido. El esquema en la página requiere relaciones padre-hijo anidadas y complejas utilizando el esquema ProductGroup, junto con propiedades como hasVariant y varíaBy.

Debido a que un sitio de comercio electrónico puede tener un feed que es enormemente más grande que sus páginas de productos indexables, el mapeo de variantes se interrumpirá si el equipo de PPC administra el feed plano mientras el equipo de SEO crea el esquema anidado de forma aislada.

Fallo de infraestructura

Los desajustes de precios y los conflictos de esquemas son frustrantes, pero al menos son visibles. Puede auditarlos, encontrar la discrepancia y solucionarla.

Una falla de infraestructura es diferente y, en cierto modo, más alarmante porque todos los datos pueden estar perfectamente alineados y los productos seguirán desapareciendo.

En un caso reciente, vimos que los productos de un cliente pasaron de estar aprobados a no estar aprobados a gran escala casi de la noche a la mañana. La alimentación estuvo bien. El esquema estaba bien. El sitio web estaba bien.

Pero un cambio en la configuración de seguridad CDN del cliente había comenzado a bloquear inadvertidamente el rastreador de Google. Las reglas de protección de bots, diseñadas para defender el sitio, trataban al robot de Google como una amenaza. Con la capa del sitio web inaccesible, Google no pudo verificarla con los datos del feed y del esquema que ya tenía, y con esa verificación rota, se retiraron los productos.

Si bien la solución fue bastante sencilla, identificar la causa definitivamente no lo fue. Un gerente de PPC habría visto la desaprobación. Pero solo alguien que hubiera pensado simultáneamente en el comportamiento de rastreo, el estado del feed y la infraestructura del sitio habría encontrado la causa raíz.

Caso de SEO para la propiedad compartida de feeds

La vieja lógica era simple: Merchant Center es principalmente compras pagadas, compras es PPC, por lo tanto, el feed es un problema de PPC. Este tipo de pensamiento está cada vez más desactualizado.

Merchant Center maneja listados pagos y gratuitos, los feeds impactan en resultados enriquecidos, Google Shopping Graph y ahora el comercio electrónico agente. Es la infraestructura para toda la presencia de su producto. Pero la infraestructura es tan buena como los datos que la atraviesan y, en este momento, demasiadas fuentes están plagadas de problemas.

La propiedad compartida no es una redistribución del crédito. Para los equipos de PPC, significa menos desaprobaciones para combatir, datos de atributos más limpios para optimizar y un socio de diagnóstico.

Los SEO deben estar presentes cuando se toman decisiones porque:

Los datos del feed están escritos para bases de datos, no para buscadores

Cuando los SEO no participan en la gestión del feed, el feed permanece como lo que exporta la plataforma. Y eso no siempre está impulsado por los comportamientos de búsqueda. Con demasiada frecuencia, lo que los distintos complementos de feeds muestran son títulos genéricos, categorizaciones aproximadas y atributos finos.

Este es el error que no aparece en Merchant Center.

En el mejor de los casos, los equipos de PPC están solucionando esto silenciosamente con reglas de feed o feeds complementarios, ambas herramientas legítimas en el contexto correcto, con su propia lógica de optimización, pero ninguna diseñada para compensar un feed principal que nunca se creó con la intención de búsqueda en mente.

El alimento es técnicamente saludable, pero si no se trata, también es comercialmente invisible.

Tratar el feed como un activo de búsqueda en lugar de un activo de datos significa presentar títulos con palabras clave de alta intención, refinar la taxonomía para que los productos no queden enterrados en categorías generalizadas, garantizar que la profundidad de los atributos coincida con la forma en que los clientes realmente filtran y consultan, y mantener el tipo de higiene continua que evita que los productos fantasma desaparezcan silenciosamente de los resultados.

Estas son cosas que los SEO hacen instintivamente en otros lugares; sólo que rara vez se les pide que los apliquen aquí.

Los datos estructurados son la variable oculta en los listados pagos, orgánicos y gratuitos

Cuando surgió la discrepancia de precios de nuestros clientes, mi equipo de PPC pudo ver la desaprobación. Lo que no pudieron ver fue por qué, porque la respuesta estaba en el esquema y el esquema no es un dominio de PPC.

El radio de explosión tampoco se limita a lo pagado. El mismo error de esquema afecta los listados gratuitos, donde Google extrae directamente de GMC. En un feed de GMC, Google acepta cuatro valores estándar y aplica la misma lógica de validación.

Y afecta los resultados orgánicos ricos (precio, disponibilidad, recuento de reseñas que aparecen en las SERP estándar) que se basan en datos estructurados en la página y no cuentan con ningún mecanismo de desaprobación para señalar cuando algo anda mal. La información incorrecta simplemente surge silenciosamente.

Encontré esto porque estaba en la habitación. Si el SEO no es copropietario del feed, no hay razón para que alguien mire el esquema cuando el pago sale mal. Y no hay razón para que alguien conecte los puntos con lo que está haciendo con listados gratuitos y resultados orgánicos ricos al mismo tiempo.

La calidad del pienso es cada vez más una señal, no sólo un requisito de campaña

Google ha sido explícito en que la calidad del feed de Merchant Center afecta más que la elegibilidad de los anuncios de Shopping. El estado general de una cuenta de Merchant Center (cosas como: tasas de desaprobación, advertencias de atributos faltantes, cumplimiento de políticas…) contribuye a la forma en que Google evalúa la confiabilidad de un comerciante como fuente de datos. Un feed con lagunas generalizadas en los atributos o desaprobaciones recurrentes es una señal sobre la calidad de los datos a escala, lo que afecta la elegibilidad y la visualización en todas las superficies de Google. El feed se lee como un indicador de cuán confiable es usted como fuente de datos.

Google también ha formalizado esto a través del programa Shop Quality, que evalúa a los comerciantes entre sí según señales, incluidas las tasas de aprobación, la integridad de los datos de envío y la claridad de la política de devoluciones. Un buen desempeño aquí tiene un impacto directo y visible en los listados, con la insignia de Tienda de alta calidad que aparece en las ubicaciones tanto en resultados pagados como orgánicos. Esto hace que la salud de la cuenta sea un factor competitivo, no solo de cumplimiento.

La capa Shopping Graph hace que esto sea aún más importante. Shopping Graph ahora contiene más de 50 mil millones de listados de productos y se alimenta directamente de AI Overviews, AI Mode y Gemini. La confiabilidad con la que Google puede verificar y confiar en los datos de su producto determina su posición dentro de ese gráfico.

En pocas palabras, la coherencia entre los datos estructurados, las páginas de destino y los feeds de Merchant Center es lo que ayuda a Google a confiar en lo que ve, y la confianza es la diferencia entre una lista elegible y atractiva y una que tiene un rendimiento inferior.

Lo que está en juego en lo orgánico está cambiando

Las compras orgánicas nunca han sido invisibles para los SEO. Trabajamos en la optimización para compras orgánicas utilizando estrategias como datos estructurados y elementos en la página, y lo informamos a través de Google Search Console. Simplemente no prestamos mucha atención al Merchant Center ni al feed. Y, sin embargo, esto es lo que también impulsa esos resultados.

El propio SERP también se está reestructurando silenciosamente a nuestro alrededor.

La gravedad de este cambio la ilustra brillantemente el experto en SEO de comercio electrónico Brodie Clark, quien señala que los resultados de búsqueda de Google se sienten cada vez más como una página de detalles del producto por derecho propio. Los resultados enriquecidos, como las cuadrículas de productos visuales que ocupan espacios SERP destacados, están canibalizando los términos de búsqueda de marcas, particularmente para marcas almacenadas por importantes minoristas externos. El problema se agrava en los dispositivos móviles, donde pueden ocupar varios desplazamientos antes de que aparezcan las páginas de categorías propias de una marca.

Esto hace que el feed sea una fuente de datos cada vez más importante detrás de una mayor proporción de las SERP comerciales.

El comercio agente cambia lo que significa “descubrible” y “comprable”

Esta es la parte que es más fácil de subestimar y donde los riesgos del abandono alimentario pasan de ser significativos a estructurales.

El descubrimiento ya no es sólo dirigido por humanos

Las superficies impulsadas por IA, como AI Overviews, recurren cada vez más a los datos de Merchant Center para mostrar productos en respuesta a consultas comerciales. Un producto con atributos de alimentación reducidos y datos estructurados mínimos parte de una desventaja significativa en la fase de descubrimiento. No solo en Compras, sino también en la capa de IA que se construye sobre ella.

Esto ya no es especulativo. La documentación UCP de Google establece explícitamente que los comerciantes deben usar los feeds de compras de su cuenta GMC existente para capturar clientes con alta intención durante el descubrimiento, y UCP desbloquea el acceso a superficies como el Modo AI en Búsqueda y Gemini.

Google ya está ampliando esto aún más al introducir atributos de comercio conversacional en Merchant Center, como compatibilidad, sustitutos y productos relacionados, diseñados específicamente para alimentar modos de inteligencia artificial y reducir las alucinaciones.

La capacidad de compra es un problema técnico, no de contenido

La visibilidad también es sólo la mitad del problema. Si un agente de IA intenta comprar ese producto, se basa en una representación legible por máquina de su sitio: el HTML sin formato, el árbol de accesibilidad y las capturas de pantalla renderizadas.

El árbol de accesibilidad es aquí especialmente interesante. Su árbol es un mapa de alta fidelidad que resume la página en las funciones, nombres y estados de los elementos interactivos. HTML no semántico, es decir,