Paridad entre el feed de Merchant y la página

El feed y la página de producto son dos representaciones del mismo artículo, mantenidas por equipos distintos, así que se separan. El desajuste suprime el artículo sin tocar el posicionamiento orgánico, y por eso pasa desapercibido durante meses. El instinto es ir resolviendo los rechazos en la interfaz uno a uno, pero casi siempre los produce un puñado de reglas del feed o campos que faltan en el catálogo de origen.

El archivo de la habilidad

---
name: merchant-feed-and-page-parity
description: Úsalo cuando las fichas gratuitas de producto muestran muchos menos artículos de los que tiene el catálogo, o cuando se rechazan artículos mientras las páginas de producto parecen correctas.
---

# Paridad entre el feed de Merchant y la página

El feed y la página de producto son dos representaciones del mismo artículo, mantenidas por equipos distintos, así que se separan. El desajuste suprime el artículo sin tocar el posicionamiento orgánico, y por eso pasa desapercibido durante meses. El instinto es ir resolviendo los rechazos en la interfaz uno a uno, pero casi siempre los produce un puñado de reglas del feed o campos que faltan en el catálogo de origen.

## Qué necesitas antes

- La exportación actual del feed más el diagnóstico a nivel de artículo con los motivos de rechazo adjuntos
- Páginas de producto renderizadas de una muestra de todas las categorías, mostrando precio y disponibilidad tal y como los ve un rastreador
- Las cifras de cobertura de GTIN, MPN y marca por categoría, tomadas del catálogo de origen y no del feed
- La configuración de impuestos y de envío de la cuenta de Merchant

## Método

1. Cuenta los artículos rechazados y pendientes por motivo antes de abrir ni un solo artículo. Dos o tres motivos suelen explicar la mayor parte del volumen y son fallos de configuración o de cobertura, no de artículos concretos.
2. Reconcilia primero los recuentos: filas del feed frente a SKU vendibles en la base de datos. Un feed al que le falta un tercio del catálogo tiene un fallo de generación y ningún trabajo de atributos importa hasta que eso se arregle.
3. Contrasta precio y disponibilidad entre el feed y la página renderizada en toda la muestra, comparando también las marcas de tiempo. Que las dos rutas tengan cachés distintas es la causa más frecuente de desajuste.
4. Arregla la cobertura de identificadores en el catálogo de origen y no con una regla del feed. Un identificador inventado durante una transformación del feed no pasa la validación y corrompe el registro que vas a necesitar más adelante.
5. Construye los títulos del feed con tu propio orden de atributos, marca y luego producto y luego el atributo por el que busca el comprador, en lugar de reutilizar el title de la página. Los títulos del feed se cotejan contra las consultas y se cortan sin miramientos, así que el orden del title de la página rara vez es el adecuado.
6. Deja por escrito en qué campos se permite que el feed difiera. El envío y los impuestos van en la configuración de la cuenta y no en los datos del artículo, y las descripciones pueden ser legítimamente más cortas que las de la página.
7. Vuelve a mirar el diagnóstico a los 14 días y fíjate en la mezcla de motivos y no en el recuento principal, ya que resolver un motivo destapa habitualmente un segundo que quedaba oculto detrás.

## Qué produce esto

Un feed reconciliado con una regla de paridad de campos declarada, los rechazos resueltos en su causa y la cobertura de identificadores reparada en el catálogo de origen.

## Dónde falla esto

- Parchear los desajustes con reglas del feed mientras el catálogo de origen sigue mal, con lo que los mismos errores vuelven en la siguiente regeneración completa
- Generar identificadores de relleno para cumplir con un campo obligatorio, lo que produce rechazos más difíciles de diagnosticar que el campo que faltaba
- Leer la tasa de aprobación de la cuenta como señal de salud cuando los rechazos están en unas pocas referencias de mucha facturación
- Comparar el feed contra el HTML de origen cuando el precio y el stock se inyectan en cliente, de forma que el desajuste nunca aparece en las pruebas

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/merchant-feed-and-page-parity

Qué necesitas antes

• La exportación actual del feed más el diagnóstico a nivel de artículo con los motivos de rechazo adjuntos
• Páginas de producto renderizadas de una muestra de todas las categorías, mostrando precio y disponibilidad tal y como los ve un rastreador
• Las cifras de cobertura de GTIN, MPN y marca por categoría, tomadas del catálogo de origen y no del feed
• La configuración de impuestos y de envío de la cuenta de Merchant

Método

1. 01 Cuenta los artículos rechazados y pendientes por motivo antes de abrir ni un solo artículo. Dos o tres motivos suelen explicar la mayor parte del volumen y son fallos de configuración o de cobertura, no de artículos concretos.
2. 02 Reconcilia primero los recuentos: filas del feed frente a SKU vendibles en la base de datos. Un feed al que le falta un tercio del catálogo tiene un fallo de generación y ningún trabajo de atributos importa hasta que eso se arregle.
3. 03 Contrasta precio y disponibilidad entre el feed y la página renderizada en toda la muestra, comparando también las marcas de tiempo. Que las dos rutas tengan cachés distintas es la causa más frecuente de desajuste.
4. 04 Arregla la cobertura de identificadores en el catálogo de origen y no con una regla del feed. Un identificador inventado durante una transformación del feed no pasa la validación y corrompe el registro que vas a necesitar más adelante.
5. 05 Construye los títulos del feed con tu propio orden de atributos, marca y luego producto y luego el atributo por el que busca el comprador, en lugar de reutilizar el title de la página. Los títulos del feed se cotejan contra las consultas y se cortan sin miramientos, así que el orden del title de la página rara vez es el adecuado.
6. 06 Deja por escrito en qué campos se permite que el feed difiera. El envío y los impuestos van en la configuración de la cuenta y no en los datos del artículo, y las descripciones pueden ser legítimamente más cortas que las de la página.
7. 07 Vuelve a mirar el diagnóstico a los 14 días y fíjate en la mezcla de motivos y no en el recuento principal, ya que resolver un motivo destapa habitualmente un segundo que quedaba oculto detrás.

Qué produce esto

Un feed reconciliado con una regla de paridad de campos declarada, los rechazos resueltos en su causa y la cobertura de identificadores reparada en el catálogo de origen.

Dónde falla esto

• Parchear los desajustes con reglas del feed mientras el catálogo de origen sigue mal, con lo que los mismos errores vuelven en la siguiente regeneración completa
• Generar identificadores de relleno para cumplir con un campo obligatorio, lo que produce rechazos más difíciles de diagnosticar que el campo que faltaba
• Leer la tasa de aprobación de la cuenta como señal de salud cuando los rechazos están en unas pocas referencias de mucha facturación
• Comparar el feed contra el HTML de origen cuando el precio y el stock se inyectan en cliente, de forma que el desajuste nunca aparece en las pruebas

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en SEO para ecommerce